On Tue, Oct 22, 2013 at 11:05 PM, Sriraman Tallam tmsri...@google.com wrote:
This simple patch fixes the -m32 -mno-sse bugs you reported. A few
more places where I did not change references to global_options.
Uros/Richard: Is this ok to commit?
* config/i386/i386.c
Hi Jakub,
This simple patch fixes the -m32 -mno-sse bugs you reported. A few
more places where I did not change references to global_options.
Uros/Richard: Is this ok to commit?
* config/i386/i386.c (ix86_option_override_internal):
Change TARGET_SSE2 to TARGET_SSE2_P (opts-...)
Sriraman,
The tests gcc.target/i386/funcspec-5.c and gcc.target/i386/pr57756.c fail
on targets for which -msse is the default (see
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01365.html or
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01345.html ).
This is fixed with the following
On Fri, Oct 18, 2013 at 3:03 AM, Dominique Dhumieres domi...@lps.ens.fr wrote:
Sriraman,
The tests gcc.target/i386/funcspec-5.c and gcc.target/i386/pr57756.c fail
on targets for which -msse is the default (see
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01365.html or
On Fri, Oct 18, 2013 at 10:27 AM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, Oct 18, 2013 at 3:03 AM, Dominique Dhumieres domi...@lps.ens.fr
wrote:
Sriraman,
The tests gcc.target/i386/funcspec-5.c and gcc.target/i386/pr57756.c fail
on targets for which -msse is the default (see
I see why pr57756.c could fail, if -msse4.2 is turned on by default. I
think this test needs {dg-options -mno-sse4.2}.
This change allows the test to pass. The failure of
gcc.target/i386/funcspec-5.c is
/opt/gcc/work/gcc/testsuite/gcc.target/i386/funcspec-5.c:34:1: warning: SSE
instruction
On Thu, Oct 17, 2013 at 7:47 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Oct 17, 2013 at 4:51 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump mikest...@comcast.net
On Thu, Oct 17, 2013 at 3:10 PM, Jakub Jelinek ja...@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.
Figured out why this
On Wed, 2013-10-16 19:40:21 -0700, Xinliang David Li davi...@google.com wrote:
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@gmail.com wrote:
On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam tmsri...@google.com
wrote:
I was unable to build a native powerpc compiler. I checked
What about all the other targets you broke?
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
And now for something completely different.
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@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
On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@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
On Thu, Oct 17, 2013 at 9:28 AM, Steve Ellcey sell...@mips.com 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@gmail.com wrote:
How is Google going to change its patch commit policies to ensure that
this does not happen
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@gmail.com wrote:
How is Google going to change its patch commit policies to ensure that
this does not happen
On Thu, Oct 17, 2013 at 9:52 AM, Michael Meissner
meiss...@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@gmail.com wrote:
How is Google
On Thu, 2013-10-17 10:23:27 -0700, Sriraman Tallam tmsri...@google.com 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.
Then you should have probably waited some time, mark
On Thu, Oct 17, 2013 at 10:49 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
On Thu, 2013-10-17 10:23:27 -0700, Sriraman Tallam tmsri...@google.com
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
JBG, Steve, Can you help testing Sri's latest patch on your targets?
This will help speed up the process.
thanks,
David
On Thu, Oct 17, 2013 at 10:49 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
On Thu, 2013-10-17 10:23:27 -0700, Sriraman Tallam tmsri...@google.com
wrote:
[...]
I would
On Thu, 2013-10-17 at 11:06 -0700, Xinliang David Li wrote:
JBG, Steve, Can you help testing Sri's latest patch on your targets?
This will help speed up the process.
thanks,
David
I have already tested the one line patch to opth-gen.awk. It fixes the
MIPS build and a testsuite run looked
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
On Thu, Oct 17, 2013 at 11:25 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
On Thu, 2013-10-17 11:06:44 -0700, Xinliang David Li davi...@google.com
wrote:
JBG, Steve, Can you help testing Sri's latest patch on your targets?
This will help speed up the process.
The one-line revert will
On Thu, 2013-10-17 11:06:44 -0700, Xinliang David Li davi...@google.com wrote:
JBG, Steve, Can you help testing Sri's latest patch on your targets?
This will help speed up the process.
The one-line revert will probably fix all of those. Though it's
open to discussion if we want to do that, or
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.
On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek ja...@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
On Thu, Oct 17, 2013 at 12:08 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek ja...@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
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
On Oct 17, 2013, at 10:23 AM, Sriraman Tallam tmsri...@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
On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump mikest...@comcast.net wrote:
On Oct 17, 2013, at 10:23 AM, Sriraman Tallam tmsri...@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
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
Hello!
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
On Thu, Oct 17, 2013 at 3:10 PM, Jakub Jelinek ja...@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
On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump mikest...@comcast.net wrote:
On Oct 17, 2013, at 10:23 AM, Sriraman Tallam tmsri...@google.com wrote:
You probably want to do something similar to what I did in the powerpc.
On Oct 17, 2013, at 4:51 PM, Sriraman Tallam tmsri...@google.com wrote:
I am running cross-compile builds on all the 33 failing targets. Like
Mike said, it is only taking a few minutes per target. If there is no
objection, I *will check in* this patch in another 2 hours provided
all 33 targets
On Thu, Oct 17, 2013 at 4:51 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump mikest...@comcast.net wrote:
On Oct 17, 2013, at 10:23 AM, Sriraman Tallam tmsri...@google.com
On Oct 17, 2013, at 7:47 PM, Sriraman Tallam tmsri...@google.com wrote:
I can build cross-compile on 32/33 targets. I cannot build
nios2-unknown-elf alone, I get *** Configuration nios2-unknown-elf
not supported error.
nios2 is not a contributed port yet on trunk.
I have submitted this one
On Thu, Oct 17, 2013 at 8:37 PM, Mike Stump mikest...@comcast.net wrote:
On Oct 17, 2013, at 7:47 PM, Sriraman Tallam tmsri...@google.com wrote:
I can build cross-compile on 32/33 targets. I cannot build
nios2-unknown-elf alone, I get *** Configuration nios2-unknown-elf
not supported error.
On Tue, Oct 15, 2013 at 10:54 PM, Alan Modra amo...@gmail.com wrote:
On Tue, Oct 15, 2013 at 02:45:23PM -0700, Sriraman Tallam wrote:
I committed this patch after making the above change.
/src/gcc-virgin/gcc/config/rs6000/rs6000.c: At global scope:
On Wed, Oct 16, 2013 at 02:34:56PM -0700, Sriraman Tallam wrote:
On Tue, Oct 15, 2013 at 10:54 PM, Alan Modra amo...@gmail.com wrote:
On Tue, Oct 15, 2013 at 02:45:23PM -0700, Sriraman Tallam wrote:
I committed this patch after making the above change.
On Wed, Oct 16, 2013 at 4:13 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
On Wed, Oct 16, 2013 at 02:34:56PM -0700, Sriraman Tallam wrote:
On Tue, Oct 15, 2013 at 10:54 PM, Alan Modra amo...@gmail.com wrote:
On Tue, Oct 15, 2013 at 02:45:23PM -0700, Sriraman Tallam wrote:
I
On Wed, Oct 16, 2013 at 04:23:56PM -0700, Sriraman Tallam wrote:
On Wed, Oct 16, 2013 at 4:13 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
On Wed, Oct 16, 2013 at 02:34:56PM -0700, Sriraman Tallam wrote:
On Tue, Oct 15, 2013 at 10:54 PM, Alan Modra amo...@gmail.com wrote:
On
On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam tmsri...@google.com wrote:
I was unable to build a native powerpc compiler. I checked for
build_target_node and build_optimization_node throughout and changed
rs6000 because it had references. I did not realize
function_specific_save and
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@gmail.com wrote:
On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam tmsri...@google.com wrote:
I was unable to build a native powerpc compiler. I checked for
build_target_node and build_optimization_node throughout and changed
rs6000
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn dje@gmail.com wrote:
On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam tmsri...@google.com wrote:
I was unable to build a native powerpc compiler. I checked for
build_target_node and build_optimization_node throughout and changed
rs6000
On Sat, Oct 12, 2013 at 12:10 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Oct 12, 2013 at 2:16 AM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
This looks nice. I suppose you grepped for effected targets and rs6000
was the only one besides i386.
This is ok given target
On Tue, Oct 15, 2013 at 02:45:23PM -0700, Sriraman Tallam wrote:
I committed this patch after making the above change.
/src/gcc-virgin/gcc/config/rs6000/rs6000.c: At global scope:
/src/gcc-virgin/gcc/config/rs6000/rs6000.c:31122:29: error: invalid conversion
from ‘void (*)(cl_target_option*)’
On Sat, Oct 12, 2013 at 2:16 AM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
This looks nice. I suppose you grepped for effected targets and rs6000
was the only one besides i386.
This is ok given target maintainers do not object within 24h and the test
successfully bootstrapped and
Ping.
On Mon, Oct 7, 2013 at 1:27 PM, Sriraman Tallam tmsri...@google.com wrote:
I have updated the patch with one more test.
Thanks
Sri
On Thu, Oct 3, 2013 at 5:02 PM, Sriraman Tallam tmsri...@google.com wrote:
On Mon, Sep 23, 2013 at 4:09 AM, Richard Biener
richard.guent...@gmail.com
On Sat, Sep 21, 2013 at 4:09 AM, Sriraman Tallam tmsri...@google.com wrote:
Forgot to add the test case. Patch updated.
Sri
On Fri, Sep 20, 2013 at 7:06 PM, Sriraman Tallam tmsri...@google.com wrote:
On Wed, Aug 14, 2013 at 3:38 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed,
On Wed, Aug 14, 2013 at 3:38 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Aug 14, 2013 at 2:02 AM, Sriraman Tallam tmsri...@google.com
wrote:
Hi,
I have attached a patch to fix PR57756. Description: The
following program,
__attribute__((always_inline,target(sse4.2)))
Hi,
I have attached a patch to fix PR57756. Description: The
following program,
__attribute__((always_inline,target(sse4.2)))
__inline int callee ()
{
return 0;
}
__attribute__((target(sse)))
__inline int caller ()
{
return callee();
}
does not generate an error and callee is inlined
50 matches
Mail list logo