diff mbox

[i386] Fix PR 57756

Message ID CAAs8Hmz2iRtgbPVBqSqvU+1XHbChhzigHmXEscU6rPrbMDYysg@mail.gmail.com
State New
Headers show

Commit Message

Sriraman Tallam Oct. 17, 2013, 5:23 p.m. UTC
On Thu, Oct 17, 2013 at 9:52 AM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:
> On Thu, Oct 17, 2013 at 09:28:26AM -0700, Steve Ellcey wrote:
>> On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
>> > On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> >
>> > > How is Google going to change its patch commit policies to ensure that
>> > > this does not happen again?
>> >
>> > There is nothing to change.  Google follows
>> > http://gcc.gnu.org/contribute.html, like everyone else. Sri just fixed
>> > the oversight and if there is any other fallout from his patch, he
>> > will address it.
>> >
>> > I don't see anything out of the ordinary here.
>> >
>> >
>> > Diego.
>>
>> FYI: I just want to make sure everyone is aware that there are still
>> broken targets.  rs6000 may be fixed but mips still doesn't work and
>> I presume other platforms like sparc are also still broken.
>>
>> /local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c: In
>> function 'void cpp_atomic_builtins(cpp_reader*)':
>> /local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c:594:7: error: 'target_flags_explicit' was not declared in this scope
>> /local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c:606:7: error: 'target_flags_explicit' was not declared in this scope
>> /local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c:618:7: error: 'target_flags_explicit' was not declared in this scope
>> /local/home/sellcey/nightly_full/src/gcc/gcc/c-family/c-cppbuiltin.c:630:7: error: 'target_flags_explicit' was not declared in this scope
>> make[1]: *** [c-family/c-cppbuiltin.o] Error 1
>>
>> Sriraman, are you looking at how to fix this globally or are the target
>> maintainers expected to fix this?  Currently I am using this one line
>> patch to get things building, but I presume this is not what we want
>> long term.
>
> You probably want to do something similar to what I did in the powerpc.

I would need the help of target maintainers to fix it this way since
it touches every target and it would take time for me to build and
test every target.

Michael, OTOH, I dont see any other targets other than i386 and rs6000
(grepping for "specific_save" and "specific_restore") using
function_specific save and restore functions. Would it be easier then
to just add back that line to "opth-gen.awk"?,the patch is below.
Since, they are not using function specific opts, they presumably
should not be validating target options a lot.

FWIW, I am testing this patch on i386 and powerpc right now.



>
> Provide a target_flags_explicit as a Variable in <machine>.opt.  This creates
> x_target_flags_explicit in the gcc_options structure, and does the definition.
> Here is the powerpc changes that does this for rs6000_isa_flags.
>
> Index: gcc/config/rs6000/rs6000.opt
> ===================================================================
> --- gcc/config/rs6000/rs6000.opt        (revision 203723)
> +++ gcc/config/rs6000/rs6000.opt        (working copy)
> @@ -30,6 +30,9 @@ TargetSave
>  HOST_WIDE_INT x_rs6000_isa_flags
>
>  ;; Miscellaneous flag bits that were set explicitly by the user
> +Variable
> +HOST_WIDE_INT rs6000_isa_flags_explicit
> +
>  TargetSave
>  HOST_WIDE_INT x_rs6000_isa_flags_explicit
>
>
> Then in your option override function, initialize it from the
> global_set.target_flags:
>
> Index: gcc/config/rs6000/rs6000.c
> ===================================================================
> --- gcc/config/rs6000/rs6000.c  (revision 203723)
> +++ gcc/config/rs6000/rs6000.c  (working copy)
> @@ -2796,6 +2796,10 @@ rs6000_option_override_internal (bool gl
>      = ((global_init_p || target_option_default_node == NULL)
>         ? NULL : TREE_TARGET_OPTION (target_option_default_node));
>
> +  /* Remember the explicit arguments.  */
> +  if (global_init_p)
> +    rs6000_isa_flags_explicit = global_options_set.x_rs6000_isa_flags;
> +
>    /* On 64-bit Darwin, power alignment is ABI-incompatible with some C
>       library functions, so warn about it. The flag may be useful for
>       performance studies from time to time though, so don't disable it
>
> If you have target specific save/restore functions, you need to deal with the
> gcc_options argument.  I think it should use a field in the gcc_options
> structure, which was the point of creating the variable in the .opt file
> above.  That way, when the save/restore function are called in the future not
> using the global switches, it will continue to work.  Here is the rs6000
> changes:
>
> Index: gcc/config/rs6000/rs6000.c
> ===================================================================
> --- gcc/config/rs6000/rs6000.c  (revision 203723)
> +++ gcc/config/rs6000/rs6000.c  (working copy)
> @@ -29995,19 +29999,22 @@ rs6000_set_current_function (tree fndecl
>  /* Save the current options */
>
>  static void
> -rs6000_function_specific_save (struct cl_target_option *ptr)
> +rs6000_function_specific_save (struct cl_target_option *ptr,
> +                              struct gcc_options *opts)
>  {
> -  ptr->x_rs6000_isa_flags = rs6000_isa_flags;
> -  ptr->x_rs6000_isa_flags_explicit = rs6000_isa_flags_explicit;
> +  ptr->x_rs6000_isa_flags = opts->x_rs6000_isa_flags;
> +  ptr->x_rs6000_isa_flags_explicit = opts->x_rs6000_isa_flags_explicit;
>  }
>
>  /* Restore the current options */
>
>  static void
> -rs6000_function_specific_restore (struct cl_target_option *ptr)
> +rs6000_function_specific_restore (struct gcc_options *opts,
> +                                 struct cl_target_option *ptr)
> +
>  {
> -  rs6000_isa_flags = ptr->x_rs6000_isa_flags;
> -  rs6000_isa_flags_explicit = ptr->x_rs6000_isa_flags_explicit;
> +  opts->x_rs6000_isa_flags = ptr->x_rs6000_isa_flags;
> +  opts->x_rs6000_isa_flags_explicit = ptr->x_rs6000_isa_flags_explicit;
>    (void) rs6000_option_override_internal (false);
>  }
>
> The last change was to remove the rs6000_isa_flags_explicit declaration in
> rs6000.h.  If you are using target_flags_explicit, you probably don't need
> this.
>
> Index: gcc/config/rs6000/rs6000.h
> ===================================================================
> --- gcc/config/rs6000/rs6000.h  (revision 203723)
> +++ gcc/config/rs6000/rs6000.h  (working copy)
> @@ -593,9 +593,6 @@ extern int rs6000_vector_align[];
>  #define MASK_PROTOTYPE                 OPTION_MASK_PROTOTYPE
>  #endif
>
> -/* Explicit ISA options that were set.  */
> -#define rs6000_isa_flags_explicit      global_options_set.x_rs6000_isa_flags
> -
>  /* For power systems, we want to enable Altivec and VSX builtins even if the
>     user did not use -maltivec or -mvsx to allow the builtins to be used inside
>     of #pragma GCC target or the target attribute to change the code level for a
>
>> % git diff opth-gen.awk
>> diff --git a/gcc/opth-gen.awk b/gcc/opth-gen.awk
>> index 01c5ab6..46bd570 100644
>> --- a/gcc/opth-gen.awk
>> +++ b/gcc/opth-gen.awk
>> @@ -114,6 +114,7 @@ print "};"
>>  print "extern struct gcc_options global_options;"
>>  print "extern const struct gcc_options global_options_init;"
>>  print "extern struct gcc_options global_options_set;"
>> +print "#define target_flags_explicit global_options_set.x_target_flag
>> s"
>>  print "#endif"
>>  print "#endif"
>>  print ""
>
> In terms of the whole saga, mistakes happen, and presumably Sriraman Tallam
> will do better in the future.

Lesson learnt, I clearly messed up.

  I do think it should be a requirement that if
> you touch a backend file in a patch, that you do at least a cross compiler
> build of that target to make sure that the syntax is correct.  For the major
> hosted targets that we have machines for in the compile farm (like the powerpc,
> mips, etc.) you should do a full bootstrap build, and it would be nice for a
> make check on at least C/C++.  I did get angry yesterday, when this change
> wasn't even tested with a build (and of course it lost me the better part of a
> day of work to fix it).
>
> --
> Michael Meissner, IBM
> IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
> email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797
>

Comments

Michael Meissner Oct. 17, 2013, 6:22 p.m. UTC | #1
On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
> I would need the help of target maintainers to fix it this way since
> it touches every target and it would take time for me to build and
> test every target.
> 
> Michael, OTOH, I dont see any other targets other than i386 and rs6000
> (grepping for "specific_save" and "specific_restore") using
> function_specific save and restore functions. Would it be easier then
> to just add back that line to "opth-gen.awk"?,the patch is below.
> Since, they are not using function specific opts, they presumably
> should not be validating target options a lot.

I believe only x86 and powerpc use the target specific feature (that I added
for x86 in the 4.3 time frame, and then added to powerpc last year).

In terms of target_flags and target_flags_explicit, the powerpc no longer uses
this field, since we have more than 32 flag bits, and needed to move the flag
processing to something that is HOST_WIDE_INT sized instead of int sized.  So,
it won't matter if you redefine the flag once again.  I don't believe the x86
uses it either (for much the same reason).  So, if it fixes the other ports, I
would say it is ok (but I haven't looked in detail at it).
Jakub Jelinek Oct. 17, 2013, 6:48 p.m. UTC | #2
On Thu, Oct 17, 2013 at 02:22:57PM -0400, Michael Meissner wrote:
> On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
> > I would need the help of target maintainers to fix it this way since
> > it touches every target and it would take time for me to build and
> > test every target.
> > 
> > Michael, OTOH, I dont see any other targets other than i386 and rs6000
> > (grepping for "specific_save" and "specific_restore") using
> > function_specific save and restore functions. Would it be easier then
> > to just add back that line to "opth-gen.awk"?,the patch is below.
> > Since, they are not using function specific opts, they presumably
> > should not be validating target options a lot.
> 
> I believe only x86 and powerpc use the target specific feature (that I added
> for x86 in the 4.3 time frame, and then added to powerpc last year).
> 
> In terms of target_flags and target_flags_explicit, the powerpc no longer uses
> this field, since we have more than 32 flag bits, and needed to move the flag
> processing to something that is HOST_WIDE_INT sized instead of int sized.  So,
> it won't matter if you redefine the flag once again.  I don't believe the x86
> uses it either (for much the same reason).  So, if it fixes the other ports, I
> would say it is ok (but I haven't looked in detail at it).

BTW, I believe the patch caused also various regressions on i?86-linux, in
particular:
+FAIL: gcc.target/i386/avx-inline.c (test for excess errors)
+FAIL: gcc.target/i386/fastcall-sseregparm.c (test for excess errors)
+UNRESOLVED: gcc.target/i386/fastcall-sseregparm.c compilation failed to produce executable
+FAIL: gcc.target/i386/pr57756_2.c (test for excess errors)
+UNRESOLVED: gcc.target/i386/pr57756_2.c compilation failed to produce executable
+FAIL: g++.dg/ext/mv2.C -std=gnu++98 (test for excess errors)
+FAIL: g++.dg/ext/mv2.C -std=gnu++11 (test for excess errors)
+FAIL: g++.dg/ext/mv3.C -std=gnu++98 (test for excess errors)
+FAIL: g++.dg/ext/mv3.C -std=gnu++11 (test for excess errors)
+FAIL: g++.dg/ext/mv4.C -std=gnu++98 (test for excess errors)
+FAIL: g++.dg/ext/mv4.C -std=gnu++11 (test for excess errors)

The errors are:
/usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-inline.c: In function 'caller':
/usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-inline.c:6:12: error: inlining failed in call to always_inline 'callee': target specific option mismatch
/usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-inline.c:14:3: error: called from here
In file included from /usr/src/gcc/obj737/gcc/include/xmmintrin.h:31:0,
                 from /usr/src/gcc/gcc/testsuite/gcc.target/i386/m128-check.h:2,
                 from /usr/src/gcc/gcc/testsuite/gcc.target/i386/sse-check.h:2,
                 from /usr/src/gcc/gcc/testsuite/gcc.target/i386/fastcall-sseregparm.c:6:
/usr/src/gcc/obj737/gcc/include/mmintrin.h:317:1: error: -mpreferred-stack-boundary=0 is not between 2 and 12
...
/usr/src/gcc/gcc/testsuite/gcc.target/i386/pr57756_2.c:19:1: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default]
/usr/src/gcc/gcc/testsuite/gcc.target/i386/pr57756_2.c:24:14: error: inlining failed in call to always_inline 'c4': target specific option mismatch
/usr/src/gcc/gcc/testsuite/gcc.target/i386/pr57756_2.c:98:3: error: called from here
/usr/src/gcc/gcc/testsuite/g++.dg/ext/mv2.C:103:6: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default]
and similarly for mv{3,4}.C.

This was on x86_64-linux, configured with:
mkdir ~/hbin
cat > ~/hbin/gcc <<\EOF
#!/bin/sh
exec /usr/bin/gcc -m32 "$@"
EOF
cat > ~/hbin/g++ <<\EOF
#!/bin/sh
exec /usr/bin/g++ -m32 "$@"
EOF
cat > ~/hbin/as <<\EOF
#!/bin/sh
exec /usr/bin/as --32 "$@"
EOF
cat > ~/hbin/ld <<\EOF2
#!/bin/sh
case "$*" in
  --version) cat <<\EOF
GNU ld version 2.20.52.0.1-10.fc17 20100131
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
EOF
  exit 0;;
esac
exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"
EOF2
chmod 755 ~/hbin/{gcc,g++,as,ld}
PATH=~/hbin:$PATH i386 ../configure --enable-languages=all,obj-c++,lto,go --enable-checking=yes,rtl
PATH=~/hbin:$PATH i386 make -j48 > LOG 2>&1 && PATH=~/hbin:$PATH i386 make -j48 -k check > LOGC 2>&1; ../contrib/test_summary > LOGT 2>&1

	Jakub
Sriraman Tallam Oct. 17, 2013, 7:08 p.m. UTC | #3
On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Oct 17, 2013 at 02:22:57PM -0400, Michael Meissner wrote:
>> On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
>> > I would need the help of target maintainers to fix it this way since
>> > it touches every target and it would take time for me to build and
>> > test every target.
>> >
>> > Michael, OTOH, I dont see any other targets other than i386 and rs6000
>> > (grepping for "specific_save" and "specific_restore") using
>> > function_specific save and restore functions. Would it be easier then
>> > to just add back that line to "opth-gen.awk"?,the patch is below.
>> > Since, they are not using function specific opts, they presumably
>> > should not be validating target options a lot.
>>
>> I believe only x86 and powerpc use the target specific feature (that I added
>> for x86 in the 4.3 time frame, and then added to powerpc last year).
>>
>> In terms of target_flags and target_flags_explicit, the powerpc no longer uses
>> this field, since we have more than 32 flag bits, and needed to move the flag
>> processing to something that is HOST_WIDE_INT sized instead of int sized.  So,
>> it won't matter if you redefine the flag once again.  I don't believe the x86
>> uses it either (for much the same reason).  So, if it fixes the other ports, I
>> would say it is ok (but I haven't looked in detail at it).
>
> BTW, I believe the patch caused also various regressions on i?86-linux, in
> particular:
> +FAIL: gcc.target/i386/avx-inline.c (test for excess errors)
> +FAIL: gcc.target/i386/fastcall-sseregparm.c (test for excess errors)
> +UNRESOLVED: gcc.target/i386/fastcall-sseregparm.c compilation failed to produce executable
> +FAIL: gcc.target/i386/pr57756_2.c (test for excess errors)
> +UNRESOLVED: gcc.target/i386/pr57756_2.c compilation failed to produce executable
> +FAIL: g++.dg/ext/mv2.C -std=gnu++98 (test for excess errors)
> +FAIL: g++.dg/ext/mv2.C -std=gnu++11 (test for excess errors)
> +FAIL: g++.dg/ext/mv3.C -std=gnu++98 (test for excess errors)
> +FAIL: g++.dg/ext/mv3.C -std=gnu++11 (test for excess errors)
> +FAIL: g++.dg/ext/mv4.C -std=gnu++98 (test for excess errors)
> +FAIL: g++.dg/ext/mv4.C -std=gnu++11 (test for excess errors)

I did not see these failures, I bootstrapped and tested for parity on
i?86-linux. I will look at this again. In particular pr57756.c and
pr57756_2.c were added as part of this patch and passed.

Sri


>
> The errors are:
> /usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-inline.c: In function 'caller':
> /usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-inline.c:6:12: error: inlining failed in call to always_inline 'callee': target specific option mismatch
> /usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-inline.c:14:3: error: called from here
> In file included from /usr/src/gcc/obj737/gcc/include/xmmintrin.h:31:0,
>                  from /usr/src/gcc/gcc/testsuite/gcc.target/i386/m128-check.h:2,
>                  from /usr/src/gcc/gcc/testsuite/gcc.target/i386/sse-check.h:2,
>                  from /usr/src/gcc/gcc/testsuite/gcc.target/i386/fastcall-sseregparm.c:6:
> /usr/src/gcc/obj737/gcc/include/mmintrin.h:317:1: error: -mpreferred-stack-boundary=0 is not between 2 and 12
> ...
> /usr/src/gcc/gcc/testsuite/gcc.target/i386/pr57756_2.c:19:1: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default]
> /usr/src/gcc/gcc/testsuite/gcc.target/i386/pr57756_2.c:24:14: error: inlining failed in call to always_inline 'c4': target specific option mismatch
> /usr/src/gcc/gcc/testsuite/gcc.target/i386/pr57756_2.c:98:3: error: called from here
> /usr/src/gcc/gcc/testsuite/g++.dg/ext/mv2.C:103:6: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default]
> and similarly for mv{3,4}.C.
>
> This was on x86_64-linux, configured with:
> mkdir ~/hbin
> cat > ~/hbin/gcc <<\EOF
> #!/bin/sh
> exec /usr/bin/gcc -m32 "$@"
> EOF
> cat > ~/hbin/g++ <<\EOF
> #!/bin/sh
> exec /usr/bin/g++ -m32 "$@"
> EOF
> cat > ~/hbin/as <<\EOF
> #!/bin/sh
> exec /usr/bin/as --32 "$@"
> EOF
> cat > ~/hbin/ld <<\EOF2
> #!/bin/sh
> case "$*" in
>   --version) cat <<\EOF
> GNU ld version 2.20.52.0.1-10.fc17 20100131
> Copyright 2012 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
> EOF
>   exit 0;;
> esac
> exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"
> EOF2
> chmod 755 ~/hbin/{gcc,g++,as,ld}
> PATH=~/hbin:$PATH i386 ../configure --enable-languages=all,obj-c++,lto,go --enable-checking=yes,rtl
> PATH=~/hbin:$PATH i386 make -j48 > LOG 2>&1 && PATH=~/hbin:$PATH i386 make -j48 -k check > LOGC 2>&1; ../contrib/test_summary > LOGT 2>&1
>
>         Jakub
Sriraman Tallam Oct. 17, 2013, 7:30 p.m. UTC | #4
On Thu, Oct 17, 2013 at 12:08 PM, Sriraman Tallam <tmsriram@google.com> wrote:
> On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Thu, Oct 17, 2013 at 02:22:57PM -0400, Michael Meissner wrote:
>>> On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
>>> > I would need the help of target maintainers to fix it this way since
>>> > it touches every target and it would take time for me to build and
>>> > test every target.
>>> >
>>> > Michael, OTOH, I dont see any other targets other than i386 and rs6000
>>> > (grepping for "specific_save" and "specific_restore") using
>>> > function_specific save and restore functions. Would it be easier then
>>> > to just add back that line to "opth-gen.awk"?,the patch is below.
>>> > Since, they are not using function specific opts, they presumably
>>> > should not be validating target options a lot.
>>>
>>> I believe only x86 and powerpc use the target specific feature (that I added
>>> for x86 in the 4.3 time frame, and then added to powerpc last year).
>>>
>>> In terms of target_flags and target_flags_explicit, the powerpc no longer uses
>>> this field, since we have more than 32 flag bits, and needed to move the flag
>>> processing to something that is HOST_WIDE_INT sized instead of int sized.  So,
>>> it won't matter if you redefine the flag once again.  I don't believe the x86
>>> uses it either (for much the same reason).  So, if it fixes the other ports, I
>>> would say it is ok (but I haven't looked in detail at it).
>>
>> BTW, I believe the patch caused also various regressions on i?86-linux, in
>> particular:
>> +FAIL: gcc.target/i386/avx-inline.c (test for excess errors)
>> +FAIL: gcc.target/i386/fastcall-sseregparm.c (test for excess errors)
>> +UNRESOLVED: gcc.target/i386/fastcall-sseregparm.c compilation failed to produce executable
>> +FAIL: gcc.target/i386/pr57756_2.c (test for excess errors)
>> +UNRESOLVED: gcc.target/i386/pr57756_2.c compilation failed to produce executable
>> +FAIL: g++.dg/ext/mv2.C -std=gnu++98 (test for excess errors)
>> +FAIL: g++.dg/ext/mv2.C -std=gnu++11 (test for excess errors)
>> +FAIL: g++.dg/ext/mv3.C -std=gnu++98 (test for excess errors)
>> +FAIL: g++.dg/ext/mv3.C -std=gnu++11 (test for excess errors)
>> +FAIL: g++.dg/ext/mv4.C -std=gnu++98 (test for excess errors)
>> +FAIL: g++.dg/ext/mv4.C -std=gnu++11 (test for excess errors)

I checked my build again for these tests and they all pass.

Looking at the test results mailing list, I see pr57756.c reported
failing http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01177.html on
i686-pc-linux-gnu in rev. 203635.

I do not see any other tests reported as failing. What am I missing?
I also see "SSE instruction set disabled, using 387 arithmetics"
warning in your  messages. Is this the problem?

Sri

>
> I did not see these failures, I bootstrapped and tested for parity on
> i?86-linux. I will look at this again. In particular pr57756.c and
> pr57756_2.c were added as part of this patch and passed.
>
> Sri
>
>
>>
>> The errors are:
>> /usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-inline.c: In function 'caller':
>> /usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-inline.c:6:12: error: inlining failed in call to always_inline 'callee': target specific option mismatch
>> /usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-inline.c:14:3: error: called from here
>> In file included from /usr/src/gcc/obj737/gcc/include/xmmintrin.h:31:0,
>>                  from /usr/src/gcc/gcc/testsuite/gcc.target/i386/m128-check.h:2,
>>                  from /usr/src/gcc/gcc/testsuite/gcc.target/i386/sse-check.h:2,
>>                  from /usr/src/gcc/gcc/testsuite/gcc.target/i386/fastcall-sseregparm.c:6:
>> /usr/src/gcc/obj737/gcc/include/mmintrin.h:317:1: error: -mpreferred-stack-boundary=0 is not between 2 and 12
>> ...
>> /usr/src/gcc/gcc/testsuite/gcc.target/i386/pr57756_2.c:19:1: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default]
>> /usr/src/gcc/gcc/testsuite/gcc.target/i386/pr57756_2.c:24:14: error: inlining failed in call to always_inline 'c4': target specific option mismatch
>> /usr/src/gcc/gcc/testsuite/gcc.target/i386/pr57756_2.c:98:3: error: called from here
>> /usr/src/gcc/gcc/testsuite/g++.dg/ext/mv2.C:103:6: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default]
>> and similarly for mv{3,4}.C.
>>
>> This was on x86_64-linux, configured with:
>> mkdir ~/hbin
>> cat > ~/hbin/gcc <<\EOF
>> #!/bin/sh
>> exec /usr/bin/gcc -m32 "$@"
>> EOF
>> cat > ~/hbin/g++ <<\EOF
>> #!/bin/sh
>> exec /usr/bin/g++ -m32 "$@"
>> EOF
>> cat > ~/hbin/as <<\EOF
>> #!/bin/sh
>> exec /usr/bin/as --32 "$@"
>> EOF
>> cat > ~/hbin/ld <<\EOF2
>> #!/bin/sh
>> case "$*" in
>>   --version) cat <<\EOF
>> GNU ld version 2.20.52.0.1-10.fc17 20100131
>> Copyright 2012 Free Software Foundation, Inc.
>> This program is free software; you may redistribute it under the terms of
>> the GNU General Public License version 3 or (at your option) a later version.
>> This program has absolutely no warranty.
>> EOF
>>   exit 0;;
>> esac
>> exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"
>> EOF2
>> chmod 755 ~/hbin/{gcc,g++,as,ld}
>> PATH=~/hbin:$PATH i386 ../configure --enable-languages=all,obj-c++,lto,go --enable-checking=yes,rtl
>> PATH=~/hbin:$PATH i386 make -j48 > LOG 2>&1 && PATH=~/hbin:$PATH i386 make -j48 -k check > LOGC 2>&1; ../contrib/test_summary > LOGT 2>&1
>>
>>         Jakub
Jakub Jelinek Oct. 17, 2013, 7:57 p.m. UTC | #5
On Thu, Oct 17, 2013 at 12:30:46PM -0700, Sriraman Tallam wrote:
> I checked my build again for these tests and they all pass.

Perhaps it is the question of the default arch/tuning selection,
What do you get with ./cc1 -E -dD /dev/null | grep SSE in the 32-bit
cc1?  Try compiling the testcases with -march=i386, -march=i686 -mno-sse
or similar?

	Jakub
Mike Stump Oct. 17, 2013, 8:23 p.m. UTC | #6
On Oct 17, 2013, at 10:23 AM, Sriraman Tallam <tmsriram@google.com> wrote:
>> You probably want to do something similar to what I did in the powerpc.
> 
> I would need the help of target maintainers to fix it this way since
> it touches every target and it would take time for me to build and
> test every target.

For changes that only need a compile to ensure one didn't brake a port, a configure and build of a target is 2 minutes.  Over night (6 hours), you can 180 targets.  Before you laugh, there are people that have done this sort of building in the past as well.  The hardest part, literally, would be to come up with the list of targets.
Jakub Jelinek Oct. 17, 2013, 10:10 p.m. UTC | #7
On Thu, Oct 17, 2013 at 12:30:46PM -0700, Sriraman Tallam wrote:
> I checked my build again for these tests and they all pass.

Even on x86_64-linux I can reproduce all of those with
-m32 -mno-sse.

	Jakub
Sriraman Tallam Oct. 17, 2013, 10:23 p.m. UTC | #8
On Thu, Oct 17, 2013 at 3:10 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Oct 17, 2013 at 12:30:46PM -0700, Sriraman Tallam wrote:
>> I checked my build again for these tests and they all pass.
>
> Even on x86_64-linux I can reproduce all of those with
> -m32 -mno-sse.

Ok, I never  tested for no-sse. I will take a look at it.

>
>         Jakub
diff mbox

Patch

Index: opth-gen.awk
===================================================================
--- opth-gen.awk (revision 203779)
+++ opth-gen.awk (working copy)
@@ -114,6 +114,7 @@  print "};"
 print "extern struct gcc_options global_options;"
 print "extern const struct gcc_options global_options_init;"
 print "extern struct gcc_options global_options_set;"
+print "#define target_flags_explicit global_options_set.x_target_flags"
 print "#endif"
 print "#endif"
 print ""