http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #23 from Eric Botcazou 2012-11-06
07:49:43 UTC ---
> Eric, I checked, and that is not how Debian builds their gcc.
>
> They build with "sparc-unknown-linux" as the triplet.
>
> So they configure their compiler correctly, an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55186
Hans-Peter Nilsson changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55186
Hans-Peter Nilsson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49220
--- Comment #3 from Jorn Wolfgang Rennecke
2012-11-06 04:35:14 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > I think that create_pre_exit is used by SH target only.
>
> The Epiphany target defines MODE_ENTRY and MODE_EXIT, whi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43350
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last recon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #22 from davem at gcc dot gnu.org 2012-11-06 04:15:21 UTC ---
Ok IRA is where the allocation of %o1 for DImode is performed.
I'll try to figure out why it isn't consulting HARD_REGNO_MODE_OK
to validate this choice.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #21 from davem at gcc dot gnu.org 2012-11-06 01:49:28 UTC ---
And now I remember more about this. They did that utterly stupid
sparc64+--with-cpu=v8 thing exactly because --enable-targets=all didn't exist
for sparc way back when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #20 from davem at gcc dot gnu.org 2012-11-06 01:44:09 UTC ---
Eric, I checked, and that is not how Debian builds their gcc.
They build with "sparc-unknown-linux" as the triplet.
So they configure their compiler correctly, and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #19 from davem at gcc dot gnu.org 2012-11-06 01:43:40 UTC ---
I always use --enable-targets=all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.7.4
Severity|critica
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219
--- Comment #1 from Matt Hargett 2012-11-06 01:31:22 UTC
---
Perhaps worth noting that gcc/trunk and google/4_7 also still exhibit the
problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219
Bug #: 55219
Summary: [4.7 regression] attempting to compile a pre-processed
unit eats up memory until OOM kills the cc1 process
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54526
--- Comment #6 from Paolo Carlini 2012-11-06
01:01:23 UTC ---
Follow up patch submitted as:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00337.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #37 from Paolo Carlini 2012-11-06
00:58:37 UTC ---
Francois, can you please look further into this, possibly basing on the new
testcase? Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
--- Comment #22 from Benjamin Kosnik 2012-11-05
23:43:32 UTC ---
Fixed on trunk and 4.7 branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
--- Comment #21 from Benjamin Kosnik 2012-11-05
23:42:36 UTC ---
Author: bkoz
Date: Mon Nov 5 23:42:32 2012
New Revision: 193195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193195
Log:
2012-11-05 Benjamin Kosnik
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54482
--- Comment #5 from Benjamin Kosnik 2012-11-05
23:42:36 UTC ---
Author: bkoz
Date: Mon Nov 5 23:42:32 2012
New Revision: 193195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193195
Log:
2012-11-05 Benjamin Kosnik
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55188
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #18 from Eric Botcazou 2012-11-05
22:31:13 UTC ---
> If sparc+--with-cpu=v8 and sparc64+--with-cpu=v8 were "equal" then my build
> would trigger the problem too :-)
Yep, you might want to configure with --enable-targets=all a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #17 from davem at gcc dot gnu.org 2012-11-05 22:21:32 UTC ---
If sparc+--with-cpu=v8 and sparc64+--with-cpu=v8 were "equal" then my build
would trigger the problem too :-)
I'll look more deeply into this, thanks Eric.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #16 from Eric Botcazou 2012-11-05
22:19:38 UTC ---
> The bug does not trigger using that var-tracking test file using a properly
> configures 32-bit compiler, I just checked.
Configure a regular cross to sparc64 on x86-64, co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55186
--- Comment #1 from Hans-Peter Nilsson 2012-11-05
22:17:18 UTC ---
Author: hp
Date: Mon Nov 5 22:17:14 2012
New Revision: 193194
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193194
Log:
PR testsuite/55186
* gcc.dg/c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
Lawrence changed:
What|Removed |Added
CC||tlawrence85 at gmail dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54986
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #15 from Eric Botcazou 2012-11-05
22:08:00 UTC ---
> That configuration doesn't make any sense.
>
> It's going to pass -m64 down into the libgcc2 build, then
> the internal --with-cpu=v8 setting is going to override
> all th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #14 from davem at gcc dot gnu.org 2012-11-05 22:04:10 UTC ---
The bug does not trigger using that var-tracking test file using a properly
configures 32-bit compiler, I just checked.
This sparc64+--with-cpu=v8 is not a legal con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55218
Michael Hope changed:
What|Removed |Added
Target||arm
--- Comment #1 from Michael
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #25 from Steven Bosscher 2012-11-05
22:02:18 UTC ---
This problem has been fixed in DF with the DF_RD_PRUNE_DEAD_DEFS flag.
I see no good reason to deprecate the param, though. For such a huge
loop, any loop invariant code mot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55218
Bug #: 55218
Summary: armv6 doesn't use unaligned access for packed
structures
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #13 from Eric Botcazou 2012-11-05
21:55:13 UTC ---
Created attachment 28621
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28621
Preprocessed file
/home/ebotcazou/build/./prev-gcc/cc1plus -fpreprocessed var-tracking.ii
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028
--- Comment #9 from Benjamin Kosnik 2012-11-05
21:54:29 UTC ---
Fixed in trunk and 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028
--- Comment #8 from Benjamin Kosnik 2012-11-05
21:53:40 UTC ---
Author: bkoz
Date: Mon Nov 5 21:53:31 2012
New Revision: 193191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193191
Log:
2012-11-05 Benjamin Kosnik
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028
--- Comment #7 from Benjamin Kosnik 2012-11-05
21:52:32 UTC ---
Author: bkoz
Date: Mon Nov 5 21:52:28 2012
New Revision: 193190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193190
Log:
2012-11-05 Benjamin Kosnik
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #12 from davem at gcc dot gnu.org 2012-11-05 21:50:38 UTC ---
That configuration doesn't make any sense.
It's going to pass -m64 down into the libgcc2 build, then
the internal --with-cpu=v8 setting is going to override
all tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #11 from Eric Botcazou 2012-11-05
21:47:17 UTC ---
> I'm having a hard time reproducing this, I've tried 32-bit
> bootstraps with several variations of your listed configure
> command line.
I can reproduce it on gcc62 of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55151
--- Comment #3 from H.J. Lu 2012-11-05 21:44:50
UTC ---
On Linux/x86-64:
[hjl@gnu-tools-1 gcc]$
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr
on/54986
* gimple-fold.c (canonicalize_constructor_val): Strip again all no-op
conversions on entry but add them back on exit if needed.
Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/20121105-1.C
- copied unchanged from r193188,
trunk/gcc/testsuite/g++.dg/torture/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #10 from Jakub Jelinek 2012-11-05
21:41:09 UTC ---
I guess best would be if you could attach your var-tracking.ii and the exact
cc1plus command line used to compile it.
on/54986
* gimple-fold.c (canonicalize_constructor_val): Strip again all no-op
conversions on entry but add them back on exit if needed.
Added:
trunk/gcc/testsuite/g++.dg/torture/20121105-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #9 from davem at gcc dot gnu.org 2012-11-05 21:38:40 UTC ---
I'm having a hard time reproducing this, I've tried 32-bit
bootstraps with several variations of your listed configure
command line.
But meanwhile I want some clarif
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791
--- Comment #12 from Adi 2012-11-05 21:14:22 UTC
---
(In reply to comment #11)
> I believe that the G++ front end tries to create a unique name from the first
> symbol it sees. I do not now if this is related to the constructor name
> co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53988
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191
--- Comment #6 from Markus Trippelsdorf
2012-11-05 21:05:07 UTC ---
*** Bug 55176 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55176
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolutio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028
--- Comment #6 from Benjamin Kosnik 2012-11-05
21:01:15 UTC ---
Author: bkoz
Date: Mon Nov 5 21:01:08 2012
New Revision: 193185
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193185
Log:
2012-11-05 Benjamin Kosnik
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #15 from joseph at codesourcery dot com 2012-11-05 20:49:24 UTC ---
The glibc code is pretty complicated (using glibc's copies of mpn_*
low-level GMP functions for multiple-precision arithmetic) and entangled
with other bits o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191
--- Comment #5 from Steven Bosscher 2012-11-05
20:23:55 UTC ---
Ugliness in cfganal.c, it depends on the block ordering for the DFS it
performs on the reverse CFG. The following patch should fix the issue.
Index: cfganal.c
=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
Bug #: 55217
Summary: False -Wstrict-overflow warning
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55215
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55215
--- Comment #4 from paolo at gcc dot gnu.org
2012-11-05 20:11:44 UTC ---
Author: paolo
Date: Mon Nov 5 20:11:32 2012
New Revision: 193183
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193183
Log:
2012-11-05 Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55215
--- Comment #3 from paolo at gcc dot gnu.org
2012-11-05 19:25:27 UTC ---
Author: paolo
Date: Mon Nov 5 19:25:20 2012
New Revision: 193181
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193181
Log:
2012-11-05 Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55216
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Status|UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55028
Benjamin Kosnik changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #8 from davem at gcc dot gnu.org 2012-11-05 19:16:14 UTC ---
Thanks for tracking this down, I'll fix or revert.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #7 from Mikael Pettersson 2012-11-05
19:13:30 UTC ---
(In reply to comment #2)
> I'm now trying a bootstrap with r192871, r192824, and r192757 reverted, as
> those were the only recent SPARC-specific changes I could find.
Te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55204
rsand...@gcc.gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55216
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.8.0
Summary|Infinit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55204
--- Comment #4 from rsandifo at gcc dot gnu.org
2012-11-05 18:55:38 UTC ---
Author: rsandifo
Date: Mon Nov 5 18:55:35 2012
New Revision: 193179
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193179
Log:
gcc/
PR target/552
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791
--- Comment #11 from David Edelsohn 2012-11-05
18:54:47 UTC ---
I believe that the G++ front end tries to create a unique name from the first
symbol it sees. I do not now if this is related to the constructor name
collision that you are s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55204
--- Comment #3 from rsandifo at gcc dot gnu.org
2012-11-05 18:51:40 UTC ---
Author: rsandifo
Date: Mon Nov 5 18:51:33 2012
New Revision: 193178
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193178
Log:
gcc/
PR target/552
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55216
Bug #: 55216
Summary: Infinite loop generated on non-infinite code
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #6 from davem at gcc dot gnu.org 2012-11-05 18:24:11 UTC ---
Oh I see, you're forcing v8 in the configure line.
It's so much easier to "sparc32 bash" before running configure so that the
build/host/target ends up being correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #5 from davem at gcc dot gnu.org 2012-11-05 18:22:17 UTC ---
I'm really surprised to see the integer ldd/std patterns matching in a 64-bit
build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
Jonathan Larmour changed:
What|Removed |Added
CC||jifl-bugzilla at jifvik dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53264
rbmj at verizon dot net changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
--- Comment #6 from janus at gcc dot gnu.org 2012-11-05 17:45:23 UTC ---
Created attachment 28620
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28620
patch
Here is an extended patch, based on comment 3, which fixes the storage_size_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55215
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55151
--- Comment #2 from Vladimir Makarov 2012-11-05
16:38:34 UTC ---
Author: vmakarov
Date: Mon Nov 5 16:38:27 2012
New Revision: 193170
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193170
Log:
2012-11-05 Vladimir Makarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55188
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55201
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Targe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55187
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54776
--- Comment #12 from Jan Hubicka 2012-11-05
16:24:07 UTC ---
Yeah + there is quite nice code size savings. I must say it took quite a while
to chase out all bugs that was affecting tramp3d's performance.
One thing I noticed however is t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
Jorn Wolfgang Rennecke changed:
What|Removed |Added
Component|target |middle-end
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55215
--- Comment #1 from wgh at beyondunreal dot com 2012-11-05 16:15:06 UTC ---
Created attachment 28619
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28619
reproduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55215
Bug #: 55215
Summary: Constructor seeding is broken for Mersenne twister
Classification: Unclassified
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55210
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466
--- Comment #8 from Joel Sherrill 2012-11-05 15:30:46
UTC ---
I was careful to say "this issue" :) \
That is the next issue to face on the lm32 and was reported before this cropped
up.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5092
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466
--- Comment #7 from Ralf Corsepius 2012-11-05
15:17:21 UTC ---
(In reply to comment #6)
> Created attachment 28618 [details]
> For sjlj exceptions on for lm32*-*-*
>
> Is this the correct way to force it on?
AFAICT, yes.
> I don't s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54828
--- Comment #6 from Jakub Jelinek 2012-11-05
15:09:34 UTC ---
Author: jakub
Date: Mon Nov 5 15:09:28 2012
New Revision: 193166
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193166
Log:
Backported from mainline
2012-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54988
--- Comment #10 from Jakub Jelinek 2012-11-05
15:07:22 UTC ---
Author: jakub
Date: Mon Nov 5 15:07:14 2012
New Revision: 193165
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193165
Log:
Backported from mainline
2012-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54877
--- Comment #6 from Jakub Jelinek 2012-11-05
15:05:48 UTC ---
Author: jakub
Date: Mon Nov 5 15:05:42 2012
New Revision: 193164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193164
Log:
Backported from mainline
2012-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55214
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
Status|UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466
--- Comment #6 from Joel Sherrill 2012-11-05 14:47:31
UTC ---
Created attachment 28618
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28618
For sjlj exceptions on for lm32*-*-*
Is this the correct way to force it on? I don't see an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466
--- Comment #5 from Joel Sherrill 2012-11-05 14:44:34
UTC ---
(In reply to comment #4)
> I always used to configure with --enable-sjlj-exceptions.
Thanks for the pointer.
I see in gcc/configure.ac, the command line handling for
--en
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175
--- Comment #15 from Ralf Corsepius 2012-11-05
14:38:44 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
>
> > Then the problem is either in newlib or generic libgcc configury.
I meanwhile came to the latter conclusion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971
--- Comment #16 from Jakub Jelinek 2012-11-05
14:36:52 UTC ---
Author: jakub
Date: Mon Nov 5 14:36:47 2012
New Revision: 193162
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193162
Log:
PR debug/54970
PR debug/54971
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54970
--- Comment #4 from Jakub Jelinek 2012-11-05
14:36:52 UTC ---
Author: jakub
Date: Mon Nov 5 14:36:47 2012
New Revision: 193162
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193162
Log:
PR debug/54970
PR debug/54971
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791
--- Comment #10 from Adi 2012-11-05 14:34:25 UTC
---
I found the real problem !
Now it can be reproducible even with a small test case.
I can summarize it like this: If you have a global object/function defined in
"n" different object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54776
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolutio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175
--- Comment #14 from Uros Bizjak 2012-11-05 14:24:43
UTC ---
(In reply to comment #13)
> Then the problem is either in newlib or generic libgcc configury.
Please note that t-fdpbit is not enabled by default for x86 anymore. I don't
kn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175
--- Comment #13 from Uros Bizjak 2012-11-05 14:15:16
UTC ---
(In reply to comment #12)
> > You should use t-softfp instead of 386/t-softfp for i[34567]86-*-rtems* in
> > libgcc/config.host.
> >
> > In fact, there should be no i386/t-s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #3 from Mikael Pettersson 2012-11-05
14:12:09 UTC ---
(In reply to comment #0)
> => 0x00575f94 <_ZL27emit_note_insn_var_locationPPvS_+1604>: ldd [ %i0 +
> %g1 ], %o1
The destination register field is odd. That's invali
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55214
--- Comment #1 from pmarguinaud at hotmail dot com 2012-11-05 14:03:32 UTC ---
$ gfortran -g -O0 -ffpe-trap=invalid -static where.F90
$ ./a.out
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55214
Bug #: 55214
Summary: Program fail to evaluate where clause
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55213
--- Comment #2 from vincenzo Innocente
2012-11-05 13:28:51 UTC ---
reading PR49279 it seems to me that gcc should NOT emit runtime alias checks,
Instead I see
15: create runtime check for data references *_12 and *_9
15: create runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #2 from Mikael Pettersson 2012-11-05
13:14:22 UTC ---
I'm now trying a bootstrap with r192871, r192824, and r192757 reverted, as
those were the only recent SPARC-specific changes I could find.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
Paolo Carlini changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|fdum
1 - 100 of 123 matches
Mail list logo
