http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #37 from Eric Botcazou 2012-02-07
17:24:32 UTC ---
Author: ebotcazou
Date: Tue Feb 7 17:24:27 2012
New Revision: 183975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183975
Log:
PR middle-end/51994
* expr.c (get_inne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921
--- Comment #6 from Eric Botcazou 2012-02-07
17:54:18 UTC ---
> You know perfectly well that such a proof is practically impossible:
> that would mean updating a machine through every single Solaris 8/9/10
> kernel/libc/libthread patch ever relea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
Bug #: 52178
Summary: [4.7 regression] Ada bootstrap failure in LTO mode
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-cod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52197
Bug #: 52197
Summary: library cannot be rebuilt by make all-target
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #2 from Eric Botcazou 2012-02-10
17:51:19 UTC ---
> I don't understand this sentence completely - if the types have been merged
> then the COMPONENT_REFs should have been updated, too (do they only have
> "weak" matched types at the p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921
--- Comment #12 from Eric Botcazou 2012-02-11
10:50:53 UTC ---
> Did the revert fix any regression that was reported as a bug and has gotten
> a testcase? If not, then the proper way to address this new regression is
> to revert the revert espec
||bosch at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #51 from Eric Botcazou 2012-02-11
14:43:54 UTC ---
Geert's proposal at http://gcc.gnu.org/ml/gcc-patches/20
at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #4 from Eric Botcazou 2012-02-12
10:06:07 UTC ---
Fixing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
--- Comment #5 from Eric Botcazou 2012-02-12
15:33:17 UTC ---
Created attachment 26643
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26643
Tentative fix
Would you mind giving it a try on the Solaris 11 machine? TIA.
||2012-02-12
CC||ebotcazou at gcc dot
||gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Eric Botcazou 2012-02-12
20:17:54 UTC ---
x86-64/Linux is still clean
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
--- Comment #7 from Eric Botcazou 2012-02-12
20:24:56 UTC ---
> The patch fixes the test case and also passes some relevant Go tests.
Great. For the records, it was also tested on 5 different versions of Solaris
8, 9 and 10, covering all the ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #4 from Eric Botcazou 2012-02-13
11:53:38 UTC ---
> Merging happens at WPA time, it happens again at LTRANS but that is an
> implementation artifact (it should not be necessary to merge again).
OK.
> Ok, this sounds like it is a rea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #6 from Eric Botcazou 2012-02-13
12:17:46 UTC ---
> Sth I'm not very familiar is the QUAL_UNION record kinds - maybe you
> can eye the two merging machineries for obvious errors here?
I did, and only came up with the following no-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #8 from Eric Botcazou 2012-02-13
12:39:06 UTC ---
> I see. I came up with the following, but it's unlikely to make a
> difference either
Thanks, I'll give it a try. While Ada doesn't use METHOD_TYPE, it extensively
uses type attrib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #12 from Eric Botcazou 2012-02-13
13:53:01 UTC ---
> Still they are refered to globally. I'm refering to
> atree__atree_private_part__node_record___is_extension___XVN
> (it doesn't have any TYPE_CONTEXT though, and its TYPE_SIZE is a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #13 from Eric Botcazou 2012-02-13
13:54:31 UTC ---
> Should PLACEHOLDER_EXPRs even survive gimplification? I see tree.c says
> if they survive until expand we'll ICE - but that comment is probably from
> before gimple/SSA times.
Yes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #14 from Eric Botcazou 2012-02-13
13:55:47 UTC ---
> Or, alternatively - should DECL_QUALIFIER matter at all after gimplification?
No, it shouldn't.
> Can we simply not stream it (thus, have a NULL_TREE DECL_QUALIFIER in WPA
> and L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #19 from Eric Botcazou 2012-02-13
14:21:57 UTC ---
> Which should avoid the issue. But I suppose that variably_modified_type_p
> wrongly checks
>
> if (TREE_CODE (type) == QUAL_UNION_TYPE)
> RETURN_TRUE_IF_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #21 from Eric Botcazou 2012-02-13
17:06:44 UTC ---
> Yeah. I'm now getting further with Ada LTO bootstrap, but hit an ICE
> during optimization:
>
> /space/rguenther/src/svn/trunk/gcc/ada/sem_prag.adb: In function
> 'sem_prag__analy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
--- Comment #9 from Eric Botcazou 2012-02-14
22:04:35 UTC ---
> I'm currently doing so, and preliminary results look good. I've got a
> couple of comments on the patch as-is which I find harder than necessary
> to read/understand:
>
> * It uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #23 from Eric Botcazou 2012-02-15
00:10:06 UTC ---
Author: ebotcazou
Date: Wed Feb 15 00:10:00 2012
New Revision: 184246
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184246
Log:
PR lto/52178
* gimple.c (iterative_has
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|ebotcazou at gcc d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
--- Comment #11 from Eric Botcazou 2012-02-15
08:13:29 UTC ---
Author: ebotcazou
Date: Wed Feb 15 08:13:22 2012
New Revision: 184256
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184256
Log:
PR target/51921
PR target/52205
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921
--- Comment #14 from Eric Botcazou 2012-02-15
08:13:29 UTC ---
Author: ebotcazou
Date: Wed Feb 15 08:13:22 2012
New Revision: 184256
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184256
Log:
PR target/51921
PR target/52205
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921
--- Comment #13 from Eric Botcazou 2012-02-15
08:13:20 UTC ---
Author: ebotcazou
Date: Wed Feb 15 08:13:09 2012
New Revision: 184255
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184255
Log:
PR target/51921
PR target/52205
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51921
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205
--- Comment #10 from Eric Botcazou 2012-02-15
08:13:20 UTC ---
Author: ebotcazou
Date: Wed Feb 15 08:13:09 2012
New Revision: 184255
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184255
Log:
PR target/51921
PR target/52205
*
||2012-02-15
CC||ebotcazou at gcc dot
||gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Eric Botcazou 2012-02-15
13:38:35 UTC ---
> Caused by trunk r184
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297
--- Comment #4 from Eric Botcazou 2012-02-21
10:13:57 UTC ---
That's (essentially) independent of the target, as it's a pure testsuite issue.
Tests that require linking with -litm should go in libitm/testsuite instead.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #7 from Eric Botcazou 2012-02-23
14:28:10 UTC ---
Created attachment 26734
--> h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
--- Comment #8 from Eric Botcazou 2012-02-23
15:23:44 UTC ---
This reproduces only on Solaris 8 because the sort of the ready list isn't
stable in the presence of debug insns, given that rank_for_schedule isn't
anti-symmetrical:
if (MAY_HAVE_D
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
--- Comment #11 from Eric Botcazou 2012-02-23
16:00:58 UTC ---
Created attachment 26736
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26736
Tentative fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297
--- Comment #8 from Eric Botcazou 2012-02-23
17:54:26 UTC ---
> This looks like a regression brought about by:
>
> +2012-02-13 Eric Botcazou
> +
> + * gcc.c (LINK_COMMAND_SPEC): Deal with -fgnu-tm.
> + (GTM_SELF_SPECS): Define if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
--- Comment #12 from Eric Botcazou 2012-02-23
22:15:53 UTC ---
Author: ebotcazou
Date: Thu Feb 23 22:15:44 2012
New Revision: 184531
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184531
Log:
PR bootstrap/52287
* haifa-sched.c (ra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52287
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||2012-02-27
CC||ebotcazou at gcc dot
||gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Eric Botcazou 2012-02-27
08:30:01 UTC ---
> The Ada FE has it, but I gues
||2012-02-27
CC||ebotcazou at gcc dot
||gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Eric Botcazou 2012-02-27
08:37:20 UTC ---
Is the failure reproducible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #22 from Eric Botcazou 2012-02-27
08:45:52 UTC ---
> If the C or C++ standards say that vv1 = vv2 should behave as if the copy was
> elementwise then the frontends need changing. Certainly not the gimplifier -
> that's not the kitche
||2012-02-27
CC||ebotcazou at gcc dot
||gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Eric Botcazou 2012-02-27
09:25:01 UTC ---
> I have traced the regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397
Bug #: 52397
Summary: [4.7 regression] comparison failure with Ada enabled
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397
Eric Botcazou changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397
--- Comment #4 from Eric Botcazou 2012-02-27
12:04:16 UTC ---
> What is specific about FUNCTION_ARG_REGNO_P regs?
We know more or less how they behave. They (may) hold arguments on entry and
thus have an artificial def in the entry block.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397
--- Comment #6 from Eric Botcazou 2012-02-27
17:14:14 UTC ---
> We should already have code that should handle it, the question is where we
> have a bug in it.
Do you mean the debug code in df-problems.c?
> Anyway, can't reproduce with a cross:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397
--- Comment #9 from Eric Botcazou 2012-02-28
16:33:42 UTC ---
> I wonder if df_reg_chain_unlink/df_install_ref shouldn't just ignore
> DEBUG_INSN
> refs when updating df->hard_regs_live_count array, do we care at all when
> testing regs_ever_liv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397
--- Comment #10 from Eric Botcazou 2012-02-28
16:41:04 UTC ---
> Untested fix. Not sure if that is the way we want to solve this though.
You might want to adjust the comment in df.h because it will be totally off.
||2012-03-03
CC||ebotcazou at gcc dot
||gnu.org
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
],
|sparc-sun-solaris2.11 |sparc-sun-solaris2.*
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-03-03
CC||ebotcazou at gcc dot
||gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52425
--- Comment #7 from Eric Botcazou 2012-03-03
13:44:59 UTC ---
Author: ebotcazou
Date: Sat Mar 3 13:44:52 2012
New Revision: 184855
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184855
Log:
PR target/52425
Backport from mainline
gcc dot|
|gnu.org |
Resolution||FIXED
Known to fail||4.6.3
--- Comment #8 from Eric Botcazou 2012-03-03
13:48:13 UTC ---
Thanks for reporting the problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110
--- Comment #6 from Eric Botcazou 2012-03-04
07:52:24 UTC ---
> Attached is updated change for hpux10. Test results are here:
> http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02575.html
Does it change anything if you put a pragma Volatile in
||2012-03-06
CC||ebotcazou at gcc dot
||gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Eric Botcazou 2012-03-06
11:48:03 UTC ---
Please post the patch when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52511
--- Comment #3 from Eric Botcazou 2012-03-06
16:02:07 UTC ---
> * Is there some codegen problem leading to the factor 2 slowdown from sun4u
> to sun4v?
UltraSPARC T1/T2 are just trounced by UltraSPARC III+/IV when it comes to
single threaded p
||2012-03-09
CC||ebotcazou at gcc dot
||gnu.org
Ever Confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Eric Botcazou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110
--- Comment #8 from Eric Botcazou 2012-03-12
06:46:41 UTC ---
> Build is successful with pragma Volatile in lieu of the Atomic.
> However, test results appear similar:
> http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01197.html
OK, let's use p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52134
--- Comment #7 from Eric Botcazou 2012-03-13
22:17:35 UTC ---
> See how the lattice's already have its last 3 bits unset. In fact I think we
> should only do this in the ccp/vrp passes to remove the & rather than fold.
For size calculations (TY
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52362
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52362
--- Comment #4 from Eric Botcazou 2012-03-14
21:10:38 UTC ---
> After that, I tested an tail-merge (AFAIK unrelated) patch on top of the same
> sources, and now the test fails for both:
With exactly the same invocation of make -k check, in parti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52438
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
||ebotcazou at gcc dot
||gnu.org
Resolution||WORKSFORME
--- Comment #2 from Eric Botcazou 2012-03-17
09:59:59 UTC ---
Do not build libjava if you don't need it (configure with --disable-libgcj)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
||2012-03-18
CC|ebotcazou at gcc dot|
|gnu.org |
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
Ever Confirmed|0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52601
--- Comment #4 from Eric Botcazou 2012-03-20
11:48:47 UTC ---
> Is this correct or should i again compiled gcc-4.4.4 to get complete
> successful compilation ?
If you still have the build tree around, do
rm -rf sparc-sun-solaris2.9/boehm-gc sp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #10 from Eric Botcazou 2
||2012-03-21
CC|ebotcazou at gcc dot|
|gnu.org |
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
Ever Confirmed|0
||2012-03-21
CC||ebotcazou at gcc dot
||gnu.org
Resolution|INVALID |
Ever Confirmed|0 |1
Severity|normal
||2012-03-21
CC||ebotcazou at gcc dot
||gnu.org
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
Ever
||2012-03-21
CC||ebotcazou at gcc dot
||gnu.org
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
Ever
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52657
Bug #: 52657
Summary: [4.7/4.8 regression] error on asm during GMP build
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-cod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52657
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52624
--- Comment #4 from Eric Botcazou 2012-03-22
07:41:25 UTC ---
I think that it should be available on all architectures, like the 32-bit and
64-bit flavors. And, for x86, you don't really need to add new patterns.
at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #6 from Eric Botcazou 2012-03-22
08:05:52 UTC ---
> Regarding new patterns - we need at least named expander, and the existing
> ones
> are strict_low_part types. They model the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52624
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |4.8.0
Summary|Missing __builti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52624
--- Comment #8 from Eric Botcazou 2012-03-22
10:04:44 UTC ---
> Please note that the rotate is split back into bswap, so we can avoid rotate
> by
> using "xchg %rh, %rl" on P4.
Sure, 16-bit rotates are already emitted as xchg when appropriate.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #41 from Eric Botcazou 2012-03-22
18:17:59 UTC ---
> Any plans w.r.t the fix to this problem?
Yes, I have plans, but less time unfortunately. But I'll definitely tackle it
during this stage #1.
||2012-03-23
CC||ebotcazou at gcc dot
||gnu.org
Summary|[4.7 regression]|[4.7 regression] segfault
|profiledbootstrap-lean |during profiled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52674
--- Comment #3 from Eric Botcazou 2012-03-23
21:30:26 UTC ---
> I was doing profiledbootstrap with the bootstrap-lto config on x64 just fine
> until about 6 weeks ago. The speedup in the resulting binary was notable, and
> was very useful to have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52656
--- Comment #2 from Eric Botcazou 2012-03-24
18:42:29 UTC ---
Author: ebotcazou
Date: Sat Mar 24 18:42:24 2012
New Revision: 185764
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185764
Log:
PR target/52656
* config/sparc/sparc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52656
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610
--- Comment #3 from Eric Botcazou 2012-03-24
18:47:43 UTC ---
Author: ebotcazou
Date: Sat Mar 24 18:47:38 2012
New Revision: 185765
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185765
Log:
PR target/52610
* config/sparc/sparc.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610
--- Comment #4 from Eric Botcazou 2012-03-24
18:48:00 UTC ---
Author: ebotcazou
Date: Sat Mar 24 18:47:55 2012
New Revision: 185766
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185766
Log:
PR target/52610
* config/sparc/sparc.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||2012-03-26
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
Ever Confirmed|0 |1
Severity|major |normal
--- Comment #2 from Eric Botcazou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52629
--- Comment #2 from Eric Botcazou 2012-03-26
08:41:14 UTC ---
Author: ebotcazou
Date: Mon Mar 26 08:41:02 2012
New Revision: 185787
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185787
Log:
PR rtl-optimization/52629
* reload1.c (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717
--- Comment #4 from Eric Botcazou 2012-03-26
11:05:19 UTC ---
> Hmm, if the sparc_get_pc_thunk is reference to libgcc, how it can end up being
> defined in ltrans24? Perhaps renaming interfere here with the references
> done
> in sparc fronten
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52730
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893
--- Comment #11 from Eric Botcazou 2012-03-27
20:50:21 UTC ---
Author: ebotcazou
Date: Tue Mar 27 20:50:16 2012
New Revision: 185897
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185897
Log:
PR middle-end/51893
* expmed.c (store_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893
--- Comment #12 from Eric Botcazou 2012-03-28
09:06:30 UTC ---
Author: ebotcazou
Date: Wed Mar 28 09:06:03 2012
New Revision: 185909
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185909
Log:
PR middle-end/51893
* expmed.c (store_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
||ebotcazou at gcc dot
||gnu.org
Resolution||WORKSFORME
--- Comment #2 from Eric Botcazou 2012-03-28
09:26:55 UTC ---
You can pass -Wtrampolines in the 4.6.x series.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52629
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52823
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52838
--- Comment #2 from Eric Botcazou 2012-04-04
21:41:02 UTC ---
> This looks like a combine problem:
>
> (insn 8 6 9 2 (set (reg/f:SI 59 [ D.1705 ])
> (subreg/s/u:SI (reg:DI 60) 0)) pr52838.c:6 64 {*movsi_internal}
> (expr_list:REG_DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52838
--- Comment #5 from Eric Botcazou 2012-04-05
16:16:41 UTC ---
> Can we somehow keep the knowledge that it is a zero-extended 32-bit value?
> It is useful for encoding purpose.
After combine has run, this seems hard. So the easiest approach migh
901 - 1000 of 5309 matches
Mail list logo
