--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-04-25 14:39
---
> Putting a breakpoint at fancy_abort is not enough to get a backtrace:
Because you aren't debugging the right executable (xgcc instead of cc1). Pass
-v to the driver to get the command line involving
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-04-25 14:07
---
Please try with a more recent version (or avoid bootstrapping with mainline at
all, it's in constant flux).
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-04-23 18:55
---
Too delicate to fix on release branches. Reopen if it pops up elsewhere.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-04-23 18:08
---
This at least works for me on SPARC/Solaris 8, 9 and 10.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2010-04-18 16:00
---
On all branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-04-18 15:57
---
Subject: Bug 43769
Author: ebotcazou
Date: Sun Apr 18 15:56:56 2010
New Revision: 158491
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158491
Log:
PR tree-optimization/43769
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-04-18 15:56
---
Subject: Bug 43769
Author: ebotcazou
Date: Sun Apr 18 15:56:32 2010
New Revision: 158490
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158490
Log:
PR tree-optimization/43769
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-04-18 07:15
---
Present on x86 and x86-64/Linux, as well as on the 4.4 branch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-04-16 15:35
---
> Yes, the patch looks like it can't make things worse and so is
> certainly fine (4.4 looks also affected? if not, how was it
> fixed there - maybe that fix should be backported instead)
Ye
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-04-16 15:20
---
Richard, do you think this kind of patches is worth installing on the branch at
this point? If no, we should mark the PR as WONTFIX, the workaround is easy.
--
ebotcazou at gcc dot gnu dot org changed
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-04-16 15:17
---
Created an attachment (id=20398)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20398&action=view)
Potential, untested fix.
* tree-sra.c (bitfield_overlaps_p): If the length of the ele
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-04-16 15:15
---
Known problem in the SRA pass.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-04-13 15:48
---
Subject: Bug 32628
Author: ebotcazou
Date: Tue Apr 13 15:47:38 2010
New Revision: 158274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158274
Log:
PR middle-end/32628
* c-
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-04-09 08:08
---
Sorry, I saw the ppc bootstrap message yesterday but missed this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43699
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-04-09 07:40
---
Other affected files are lto-wrapper.c, gcc.c and lto/lto.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43699
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-04-09 07:34
---
Created an attachment (id=20344)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20344&action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43699
nassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
GCC host triplet: ix86-*-linux, x86-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43699
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-04-08 10:48
---
> I did want to remove that optimization at some point but people complained
> that it was highly useful (the C++ FE can still set TYPE_PRECISION
> accordingly if it wants to, but TYPE_MIN/MAX_VALUE cann
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-04-06 21:25
---
Please reconfirm for sparc-rtems, arm-linux has been clean for some time:
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00436.html
--
ebotcazou at gcc dot gnu dot org changed:
What
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-04-06 21:19
---
Reclassifying.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-04-02 21:03
---
Another datapoint: I now get
WARNING: program timed out.
FAIL: gcc.c-torture/compile/limits-fnargs.c -O3 -g (test for excess errors)
consistently on a somewhat old machine. It hadn't showed up for m
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-04-01 10:10
---
> Is it to ask for warn at the following test case?
Yes, it is. An additional condition could be that the type be non-void.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36367
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-31 10:08
---
Not clear what happened but the aforementioned commit is not a fix for this PR.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-03-30 14:36
---
Doesn't this belong in the linker as a relaxation? This would solve the reloc
problem in the process.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-03-26 11:50
---
> If this is indeed required for tree_low_cst (which is defined as signed HWI!),
> then the patch that reverses the semantics of my previous patch works as well.
>
> Index: s
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-03-26 10:54
---
> There is a mismatch in a guard expression. Following patch fixes ICE for me
> (I'm not sure if it makes any sense, though):
No, it isn't correct, because:
/* Return 1 if T is an INTEGER
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-22 00:19
---
> "Between the previous and next sequence point an object shall have its stored
> value modified at most once by the evaluation of an expression.
> Furthermore, the prior value shall be read only to
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-03-22 00:18
---
More precisely, C99 6.5 §2 reads:
"Between the previous and next sequence point an object shall have its stored
value modified at most once by the evaluation of an expression.
Furthermore, the prior value
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-03-19 07:22
---
Presumably by the overhaul of the subtypes support.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-19 07:19
---
Subject: Bug 43106
Author: ebotcazou
Date: Fri Mar 19 07:18:47 2010
New Revision: 157558
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157558
Log:
PR ada/43106
*
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-17 17:34
---
Glibc is a separate project, see http://sources.redhat.com/bugzilla/
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2010-03-17 08:59
---
I just posted the same fix. :-) Yes, it is OK for all branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-03-14 21:40
---
> So, the solution is to teach loop2_invariant to also look into REG_EQUAL notes
> if the insn is _really_ invariant or eventually clear REG_EQUAL notes when
> insn is moved out of the loop.
Both shoul
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2010-03-12 21:27
---
> Like Eric I'm still seeing this fail on mainline on 32-bit sparc.
The problem is that this is hard to fix without pessimizing the common case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-03-09 09:04
---
Sorry for this late breakage.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-03-09 09:02
---
Subject: Bug 43276
Author: ebotcazou
Date: Tue Mar 9 09:01:56 2010
New Revision: 157305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157305
Log:
PR bootstrap/43276
* lto-elf.c
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-03-09 08:56
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-03-08 21:09
---
If it works with 4.3.x then this is not a 4.3 regression.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-03-08 20:51
---
You need to ./configure the toplevel dir, not the gcc subir. See instructions.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2010-03-08 12:03
---
The original bug is fixed.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-03-08 09:20
---
Created an attachment (id=20041)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20041&action=view)
Tentative patch
Tested only on Linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43276
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-06 16:19
---
> libelf uses the system's , not libelf/elf_repl.h. The system
> headers don't provide the SPARC defines.
I see, one of those "severely broken" systems libelf/sys_elf.h talks abo
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-03-06 15:58
---
It is defined in /usr/include/libelf/elf_repl.h for libelf 0.8.12 so you'll
need to find out what's going on here.
--
ebotcazou at gcc dot gnu dot org changed:
What
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-03-05 23:17
---
For the sake of completeness, the error on Solaris 8 is the same as on Solaris
9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-03-05 15:03
---
-xarch is an option specific to the Sun Studio compiler, it cannot be used for
GCC, you need to adjust your Makefile.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-03-04 17:45
---
Same on SPARC/Solaris 10:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00295.html
Present on SPARC/Solaris 9:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00294.html
but the error is different
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-02-27 14:34
---
Thanks for reporting the problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-02-27 14:30
---
Subject: Bug 42253
Author: ebotcazou
Date: Sat Feb 27 14:30:12 2010
New Revision: 157108
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157108
Log:
PR ada/42253
* gcc-interface/
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-27 14:27
---
Subject: Bug 42253
Author: ebotcazou
Date: Sat Feb 27 14:27:27 2010
New Revision: 157107
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157107
Log:
PR ada/42253
* gcc-interface/
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-02-26 23:12
---
This should be fixed. Reopen if not.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-02-26 23:10
---
Subject: Bug 43096
Author: ebotcazou
Date: Fri Feb 26 23:10:24 2010
New Revision: 157102
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157102
Log:
PR ada/43096
* tree-ssa
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-26 17:46
---
> We might be able to save the day with the help of TYPE_CANONICAL in this case
> since the size is fixed.
TYPE_CANONICAL is too strong, it will cause useless_type_conversion_p to return
true for conve
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-02-26 17:15
---
I'll fix the bug, but are you sure about the commit? It looks unrelated to the
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-02-26 10:19
---
It looks like only c87b39a still fails as of this writing, but the 3 mentioned
tests (c37105a, c46051a, c87b39a) use a common pattern, namely discriminated
record types with fixed size and associated subtypes
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-02-25 22:12
---
Miscompilations are always nasty I guess... Simply don't use thin pointers,
they are quite inefficient.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-02-18 09:56
---
Looking into it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-11 18:55
---
> Note this works correctly on targets that define STACK_CHECK_BUILTIN to be 1.
> This includes the spu target. The main reason is that the code goes through a
> different path.
Indeed, only gene
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-02-11 12:23
---
I'll write a book about -fstack-check someday... -fstack-check was severely
broken during the GCC3 -> GCC4 transition and, despite years of patches posting
and pinging, only GCC 4.5 has the beginn
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-02-10 10:02
---
> The non-working code is vectorized, and vectorized code can have strict
> alignment requirements.
Yes, the alignment requirements are surreptitiously changed by -ftree-vectorize
on x86 and x86-64. This
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-09 18:20
---
> Your pointer isn't properly aligned to be accessed via uint32_t*.
That's hardly satisfactory an answer. GCC has always generated working code on
non-strict alignment platforms in this case and o
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2010-01-31 21:08
---
Subject: Bug 42898
Author: ebotcazou
Date: Sun Jan 31 21:08:15 2010
New Revision: 156416
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156416
Log:
2010-01-31 Eric Botcazou
PR mi
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2010-01-31 21:06
---
Subject: Bug 42898
Author: ebotcazou
Date: Sun Jan 31 21:06:20 2010
New Revision: 156415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156415
Log:
PR middle-end/42898
Backp
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2010-01-31 20:01
---
Subject: Bug 42898
Author: ebotcazou
Date: Sun Jan 31 20:00:54 2010
New Revision: 156414
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156414
Log:
PR middle-end/42898
* gcc.dg
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-30 16:47
---
So what's the story here? Is it the case that const/pure function removal must
now be done entirely at the tree level because everything is frozen EH-wise at
the RTL level? Why isn't there the obv
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-26 07:59
---
It even fails with -m32 for me. Looking into it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Priority|P1 |P3
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-25 07:35
---
3.x isn't supported anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2010-01-25 06:58
---
Jakub, what to do with this PR? It is still marked "blocker" although it seems
to have blocked nothing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2010-01-16 15:11
---
> strictly speaking, I would argue that Ada should not set COMMON flag for
> !PUBLIC variables since it has no effect: all static variables that have no
> initializer go to .common anyway.
That seems r
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2010-01-15 21:50
---
> I have reverted the whole patch on mainline and 4.4
That was unnecessary.
> I will modify the testcase and send the whole patch again.
Just send a message to gcc-patches@ and apply the fix to the te
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2010-01-15 08:27
---
> sorry for replying late, I was missed this problem somehow in my bugzilla
> folder. The test in question verify that variables that are common or weak are
> also either public or external.
No doubt a
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-01-13 23:27
---
> Otherwise, I would simply remove this comment.
Fine with me, it's indeed a little confusing.
> I does hunk #3, because I am not sure if all combination results from
> case2 would pass "rec
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-01-13 10:03
---
> This patch fixes the bug.
> Do you think if this patch is favorable? If yes, I will do dejagnu
> test and send it to gcc-patches for review.
The patch is probably correct, but I'd ditch hunks
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-01-13 08:45
---
Jan, are you there?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-01-12 08:57
---
> Then gcc comes to line3657. Since changed_i3_dest is 0, gcc does not
> call adjust_for_new_dest at all.
>
> line3657:
> if (changed_i3_dest)
> {
> PATTERN (i3) = newpat;
>
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-11 22:00
---
The REG_EQUAL note is correct after fwprop but not after combine, so the
problem lies in combine. The note should have been removed by
adjust_for_new_dest since the destination of I3 has changed
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2010-01-11 21:41
---
> Um, I could submit a patch for PR middle-end/42068 if it would help? Not aware
> of procedure here.
You'd need to go through the full testing procedure described here:
http://gcc.gnu.org/cont
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2010-01-11 11:31
---
Still present?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2010-01-11 11:30
---
I think we should consider that x86_64-apple-darwin is not supported in 4.4 and
make sure that it will be in 4.5, in particular fix PR middle-end/42068.
--
ebotcazou at gcc dot gnu dot org changed
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-01-11 11:27
---
Jan, are you there?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-01-09 22:21
---
Thanks for fixing this.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-09 22:16
---
Subject: Bug 42626
Author: ebotcazou
Date: Sat Jan 9 22:16:43 2010
New Revision: 155780
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155780
Log:
PR ada/42626
* gcc-i
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-09 22:13
---
Subject: Bug 42626
Author: ebotcazou
Date: Sat Jan 9 22:12:47 2010
New Revision: 155779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155779
Log:
PR ada/42626
* Makefile.in
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-01-09 18:27
---
Fixed in the upcoming 4.5 series.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-09 18:22
---
Subject: Bug 42659
Author: ebotcazou
Date: Sat Jan 9 18:21:52 2010
New Revision: 155771
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155771
Log:
PR ada/42659
* configure.ac
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-08 17:16
---
Patches should be posted to the gcc-patc...@gcc.gnu.org mailing list. Also see
http://gcc.gnu.org/contribute.html for guidelines.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42659
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2010-01-07 08:22
---
> I'm thinking about the same situation with cse2, where constant assignment
> (with its REG_EQUAL note) would match another assignment with the same
> REG_EQUAL note. cse2 can equal this ot
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2010-01-07 07:39
---
> Because at the point of propagation, propagated constant _is_ equal to
> whatever REG_EQUAL says. Removing this note at the point of propagation
> would IMO disable much more optimization opportuniti
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2010-01-07 00:00
---
> Following patch changes the fix from PR21767 to remove REG_EQUAL notes from
> all
> moved instructions, not only from ones that have non-function-invariant
> sources.
This seems like a tad aggr
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2010-01-06 22:46:02 |2010-01-06 22
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-01-06 22:45
---
ICE on x86_64-apple-darwin10 too.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-01-06 22:43
---
*** Bug 42627 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-06 22:43
---
*** This bug has been marked as a duplicate of 42068 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-01-06 07:14
---
Presumably a duplicate of PR middle-end/42068. Still waiting for Jan's
input...
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2010-01-05 22:43
---
On all active branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-01-05 22:34
---
Subject: Bug 42564
Author: ebotcazou
Date: Tue Jan 5 22:34:01 2010
New Revision: 155664
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155664
Log:
PR target/42564
* config/sparc
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-01-05 22:32
---
Subject: Bug 42564
Author: ebotcazou
Date: Tue Jan 5 22:32:25 2010
New Revision: 155663
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155663
Log:
PR target/42564
* config/sparc
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-01-05 22:29
---
Subject: Bug 42564
Author: ebotcazou
Date: Tue Jan 5 22:29:18 2010
New Revision: 155662
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155662
Log:
PR target/42564
* config/sparc
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-01-02 23:00
---
The root of the problem is plus_constant wrapping up a TLS symbol in a CONST:
(const:DI (plus:DI (symbol_ref:DI ("m") [flags 0x1a] )
(const_int 4 [0x4])))
what the SPARC back-end doesn&#
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-01-02 22:26
---
Created an attachment (id=19451)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19451&action=view)
Reduced testcase.
Requires TLS support.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
201 - 300 of 2634 matches
Mail list logo
