On Tue, Oct 22, 2013 at 11:05 PM, Sriraman Tallam 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 (ix86_option_override_internal):
> Cha
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->...)
(ix86_valid_ta
On Thu, Oct 17, 2013 at 3:10 PM, Jakub Jelinek 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 happens in -m32
On Thu, Oct 17, 2013 at 7:47 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 4:51 PM, Sriraman Tallam wrote:
>> On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam wrote:
>>> On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
>> Y
> 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
instructio
On Fri, Oct 18, 2013 at 10:27 AM, Sriraman Tallam wrote:
> On Fri, Oct 18, 2013 at 3:03 AM, Dominique Dhumieres
> 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-tes
On Fri, Oct 18, 2013 at 3:03 AM, Dominique Dhumieres 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
> http://gcc.gnu.org/ml/gcc-testre
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 patch:
On Thu, Oct 17, 2013 at 8:37 PM, Mike Stump wrote:
> On Oct 17, 2013, at 7:47 PM, Sriraman Tallam 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 por
On Oct 17, 2013, at 7:47 PM, Sriraman Tallam 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 line fix.
Or,
On Thu, Oct 17, 2013 at 4:51 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam wrote:
>> On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
>>> On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
> You probably want to do something similar to what I did in the p
On Oct 17, 2013, at 4:51 PM, Sriraman Tallam 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 succeed. This w
On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
>> On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
You probably want to do something similar to what I did in the powerpc.
>>>
>>> I would need the help of target maintainers to
On Thu, Oct 17, 2013 at 3:10 PM, Jakub Jelinek 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 wil
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 m
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
On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
> On Oct 17, 2013, at 10:23 AM, Sriraman Tallam 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
On Oct 17, 2013, at 10:23 AM, Sriraman Tallam 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 c
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 wit
On Thu, Oct 17, 2013 at 12:08 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek 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 maintai
On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek 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
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, 2013-10-17 11:06:44 -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.
The one-line revert will probably "fix" all of those. Though it's
open to discussion if we want to do that, or forward-port al
On Thu, Oct 17, 2013 at 11:25 AM, Jan-Benedict Glaw wrote:
> On Thu, 2013-10-17 11:06:44 -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.
>
> The one-line revert will probably "fix" all of those. Th
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 rs60
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 l
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 wrote:
> On Thu, 2013-10-17 10:23:27 -0700, Sriraman Tallam
> wrote:
> [...]
>> I would need the help of target maintaine
On Thu, Oct 17, 2013 at 10:49 AM, Jan-Benedict Glaw wrote:
> On Thu, 2013-10-17 10:23:27 -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, 2013-10-17 10:23:27 -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.
Then you should have probably waited some time, mark your patch as RFC
u
On Thu, Oct 17, 2013 at 9:52 AM, Michael Meissner
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 wrote:
>> >
>> > > How is Google going to change its patch commi
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 wrote:
> >
> > > How is Google going to change its patch commit policies to ensure that
> > > this does not happen again?
> >
On Thu, Oct 17, 2013 at 9:28 AM, 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 wrote:
>>
>> > How is Google going to change its patch commit policies to ensure that
>> > this does not happen again?
>>
>> There is n
On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
> On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn 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/contr
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn 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 th
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, 2013-10-16 19:40:21 -0700, Xinliang David Li wrote:
> On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
> > On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam
> > wrote:
> > > I was unable to build a native powerpc compiler. I checked for
> > > build_target_node and build_optimizatio
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
> On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam 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 n
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
> On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam 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 n
On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam 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 function_specific_rest
On Wed, Oct 16, 2013 at 04:23:56PM -0700, Sriraman Tallam wrote:
> On Wed, Oct 16, 2013 at 4:13 PM, Michael Meissner
> 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 wrote:
> >> > On Tue, Oct 15, 2013 at 02:45:23PM -07
On Wed, Oct 16, 2013 at 4:13 PM, Michael Meissner
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 wrote:
>> > On Tue, Oct 15, 2013 at 02:45:23PM -0700, Sriraman Tallam wrote:
>> >> I committed this patch after making the ab
On Wed, Oct 16, 2013 at 02:34:56PM -0700, Sriraman Tallam wrote:
> On Tue, Oct 15, 2013 at 10:54 PM, Alan Modra 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:
On Tue, Oct 15, 2013 at 10:54 PM, Alan Modra 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:
> /src/gcc-virgin/gcc/config/rs6000/rs6000.c:31122:29: er
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*)’ t
On Sat, Oct 12, 2013 at 12:10 AM, Uros Bizjak wrote:
> On Sat, Oct 12, 2013 at 2:16 AM, Sriraman Tallam 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 obj
On Sat, Oct 12, 2013 at 2:16 AM, Sriraman Tallam 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 wrote:
> I have updated the patch with one more test.
>
> Thanks
> Sri
>
> On Thu, Oct 3, 2013 at 5:02 PM, Sriraman Tallam wrote:
>> On Mon, Sep 23, 2013 at 4:09 AM, Richard Biener
>> wrote:
>>> On Sat, Sep 21, 2013 at 4:09 AM, Sriraman Tall
On Sat, Sep 21, 2013 at 4:09 AM, Sriraman Tallam wrote:
> Forgot to add the test case. Patch updated.
>
> Sri
>
> On Fri, Sep 20, 2013 at 7:06 PM, Sriraman Tallam wrote:
>> On Wed, Aug 14, 2013 at 3:38 AM, Richard Biener
>> wrote:
>>> On Wed, Aug 14, 2013 at 2:02 AM, Sriraman Tallam
>>> wrote:
On Wed, Aug 14, 2013 at 3:38 AM, Richard Biener
wrote:
> On Wed, Aug 14, 2013 at 2:02 AM, Sriraman Tallam
> wrote:
>>
>> Hi,
>>
>> I have attached a patch to fix PR57756. Description: The
>> following program,
>>
>> __attribute__((always_inline,target("sse4.2")))
>> __inline int callee ()
>
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 inli
50 matches
Mail list logo
