--- Comment #15 from bonzini at gnu dot org 2009-09-01 08:54 ---
Please try -O2 and -O2 -funroll-loops too, since -O3 is not always good for
speed. (It would be even better if -O2 is not slower and you can find out what
the culprit is at -O3; this is not necessarily possible though
--- Comment #14 from bonzini at gnu dot org 2009-09-03 07:27 ---
Can you also try with 4.5?
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from bonzini at gnu dot org 2009-09-03 17:11 ---
Yes, if you use nested functions you can just use -mregparm=2 globally, that's
a much better solution.
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #6 from bonzini at gnu dot org 2009-09-03 17:15 ---
Created an attachment (id=18482)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18482&action=view)
patch erroring out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
--- Comment #4 from bonzini at gnu dot org 2009-09-09 15:11 ---
I don't see the reload failure anymore.
The code is:
push{r4, lr}
mov r4, r0
mov r1, #0
bl __gesf2
cmp r0, #0
it lt
movlt r
--- Comment #2 from bonzini at gnu dot org 2009-09-09 20:50 ---
has already been reverted.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from bonzini at gnu dot org 2009-09-24 06:06 ---
Not a dup, since this is about shortening the mode, rather than about
eliminating zero extensions.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org
--- Comment #5 from bonzini at gnu dot org 2009-10-24 09:59 ---
I agree with Andrew, but as a middle way you could put something like this in
config/elf.m4:
dnl usage: ACX_ELF_TARGET_IFELSE([if-elf], [if-not-elf])
AC_DEFUN([ACX_ELF_TARGET_IFELSE]), [
AC_REQUIRE([AC_CANONICAL_TARGET
--- Comment #7 from bonzini at gnu dot org 2009-10-28 10:43 ---
Fixed (patch had been approved a long time ago).
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2009-10-28 10:44 ---
First testcase fixed, bootstrapping now the patch for the second.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
--- Comment #3 from bonzini at gnu dot org 2009-10-28 12:21 ---
The patch is wrong because the result of MD is used also to process notes,
while the live registers problem does not consider a register live if it is
only used in notes. We have:
;; lr in1 [1] 2 [2] 31 [31] 67
--- Comment #5 from bonzini at gnu dot org 2009-10-28 14:27 ---
fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from bonzini at gnu dot org 2009-10-28 16:47 ---
patch committed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from bonzini at gnu dot org 2009-11-02 16:32 ---
Subject: Re: .../prev-gcc/xgcc used for the install step of
the lto-plugin
Try making all-gcc depend on all-lto-plugin (or vice versa :-P).
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41569
--- Comment #12 from bonzini at gnu dot org 2009-11-02 16:45 ---
Subject: Re: .../prev-gcc/xgcc used for the install step of
the lto-plugin
On 11/02/2009 05:44 PM, rguenther at suse dot de wrote:
> --- Comment #11 from rguenther at suse dot de 2009-11-02 16:44 ---
> S
--- Comment #7 from bonzini at gnu dot org 2009-11-03 10:23 ---
Part of the problem is that for each open parenthesis we go through
c_parser_postfix_expression
c_parser_expression
c_parser_expr_no_commas
c_parser_conditional_expression
c_parser_binary_expression
--- Comment #8 from bonzini at gnu dot org 2009-11-03 12:18 ---
Memory allocation is O(n^2) in the nesting of the structures: when changing
LIM4 from 6 to 7 invocations of the lower-level, memory goes from 583976 KB to
798116 KB (which is 1.366 times more, almost exactly a factor of (7
--- Comment #8 from bonzini at gnu dot org 2009-11-03 12:23 ---
Created an attachment (id=18953)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18953&action=view)
patch to fix the bug
The attached patches together reduce the stack usage of expression parsing by
~30%. On a
--- Comment #15 from bonzini at gnu dot org 2009-11-03 12:24 ---
I still want to look into it, at least we have a workaround.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41569
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org
--- Comment #9 from bonzini at gnu dot org 2009-11-03 18:58 ---
The patch is not enough for mainline because some functions have a bigger stack
frame. With the patch, mainline aborts after 9827 recursive calls.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #5 from bonzini at gnu dot org 2009-11-07 09:21 ---
bt with a memory object and a register index will _not_ truncate the argument:
static int btm(int *a, int b) {
asm ("btl %2, %1; movl $0, %0; setc %b0" : "=r" (b) : "m" (*a), "0" (
--- Comment #5 from bonzini at gnu dot org 2009-11-07 09:35 ---
Confirmed, the code for -O2 -funroll-loops includes things such as
movzwl 2(%eax), %esi
movl$1, -44(%ebp)
subl%ecx, -44(%ebp)
movl-44(%ebp), %edi
movzbl (%edx,%edi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
--- Comment #10 from Paolo Bonzini 2010-12-17 21:23:38
UTC ---
Author: bonzini
Date: Fri Dec 17 21:23:36 2010
New Revision: 167999
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167999
Log:
gcc:
2010-12-17 Paolo Bonzini
PR c/20385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47366
--- Comment #3 from Paolo Bonzini 2011-01-20 13:12:02
UTC ---
Indeed, it never occurred to me but it should.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47435
--- Comment #2 from Paolo Bonzini 2011-01-24 14:47:15
UTC ---
The code hardly makes any sense, so it's difficult to say which error message
makes more sense. I'll look at the regression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47449
--- Comment #7 from Paolo Bonzini 2011-01-24 23:45:01
UTC ---
Is this a regression?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47449
--- Comment #8 from Paolo Bonzini 2011-01-24 23:47:10
UTC ---
Ah, [32] means 32-bit x86_64...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225
--- Comment #24 from Paolo Bonzini 2011-02-07 09:48:42
UTC ---
Please use LDFLAGS, not LIBADD.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47255
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225
--- Comment #34 from Paolo Bonzini 2011-02-08 08:06:28
UTC ---
Iain,
the correct fix is to add -module to the LTO plugin LDFLAGS. This changes the
extension from .dylib to .so.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225
--- Comment #36 from Paolo Bonzini 2011-02-08 10:00:41
UTC ---
No, it should be added for all targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--- Comment #22 from Paolo Bonzini 2011-02-21 07:55:35
UTC ---
What is the performance with 4.3 -O2? A regression that is limited to -O3 is
(a bit) less important since -O3 is still a "mixing bag" of optimizations that
might or might not be prof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50123
Bug #: 50123
Summary: cmpxchg generated for atomic and with zero/or with -1
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50573
--- Comment #5 from Paolo Bonzini 2011-09-30 10:41:32
UTC ---
I'd just close it as wontfix. Perhaps we can fix the quoting problems, and
hope that autoconf removes duplicates another day.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50448
--- Comment #4 from Paolo Bonzini 2011-10-28 14:26:57
UTC ---
Can't you just test on x86_64-linux?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #6 from Paolo Bonzini 2011-11-03 18:27:23
UTC ---
> Paolo's suggestion probably was not well thought through.
Yes, it assumed that the patch would be tested by maintainers...
The patch looks good.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50991
--- Comment #3 from Paolo Bonzini 2011-11-04 14:23:40
UTC ---
I think the problem is that "make clean" is not removing libgcc_tm.stamp.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50991
--- Comment #5 from Paolo Bonzini 2011-11-04 14:32:30
UTC ---
John didn't say that but you're right, because otherwise the move-if-change
would not have happened. John, can you attach libgcc/Makefile?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50991
--- Comment #9 from Paolo Bonzini 2011-11-06 12:02:43
UTC ---
Yes, please commit the fix!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53144
--- Comment #2 from Paolo Bonzini 2012-04-28 06:19:31
UTC ---
In the case of PR53138 this was a preexisting bug in handling -(a < b), made
more explicit by the new phi-opt conversion. Looking at vector-compare-1.c and
pass ordering (phiopt runs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53144
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53347
--- Comment #1 from Paolo Bonzini 2012-05-15 09:56:59
UTC ---
The code in conforming_compare matches this comment with or without the
duplicate test:
(1) All comparison patterns are represented as
[(set (reg:CC) (compare:CC (reg) (immedi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53336
--- Comment #4 from Paolo Bonzini 2012-05-22 08:32:07
UTC ---
Author: bonzini
Date: Tue May 22 08:31:52 2012
New Revision: 187759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187759
Log:
gcc:
2012-05-16 Paolo Bonzini
PR tree-opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
Paolo Bonzini changed:
What|Removed |Added
Target Milestone|4.6.4 |4.7.2
--- Comment #40 from Paolo Bonzini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53087
--- Comment #9 from Paolo Bonzini 2012-04-25 20:00:57
UTC ---
The handling of this code sequence in fold-const changed back and forth many
times, and this is likely the reason why GCC 4.1 produced straight-line code
while GCC 4.3 produced branchy
at gcc dot |bonzini at gnu dot org
|gnu.org |
--- Comment #10 from Paolo Bonzini 2012-04-26 15:52:32
UTC ---
Created attachment 27248
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27248
tentative patch
Any change in expmed.c is not enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53138
Bug #: 53138
Summary: [4.7/4.8 Regression] spaceship operator miscompiled
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53138
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53138
--- Comment #1 from Paolo Bonzini 2012-04-27 12:18:03
UTC ---
Author: bonzini
Date: Fri Apr 27 12:17:50 2012
New Revision: 186904
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186904
Log:
2012-04-27 Paolo Bonzini
PR target/53
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50123
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39200
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
Bug 21676 depends on bug 39200, which changed state.
Bug 39200 Summary: ivopts slows down SciMark sparse matrix benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39200
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39201
Bug 39201 depends on bug 39200, which changed state.
Bug 39200 Summary: ivopts slows down SciMark sparse matrix benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39200
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935
--- Comment #5 from Paolo Bonzini 2011-11-21 17:25:20
UTC ---
What's exactly the problem with gdb that requires disabling largefiles?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447
--- Comment #4 from Paolo Bonzini 2011-12-07 13:48:42
UTC ---
The bug is that rbx is added to the EXIT_BLOCK uses:
Basic block 1 , prev 2, loop_depth 0, count 0, freq 0.
Predecessors:
;; bb 1 artificial_defs: { }
;; bb 1 artificial_uses: { u-1(3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447
--- Comment #5 from Paolo Bonzini 2011-12-07 14:04:04
UTC ---
Untested patch...
Index: df-problems.c
===
--- df-problems.c (revision 177688)
+++ df-problems.c (working c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505
--- Comment #4 from Paolo Bonzini 2011-12-13 19:34:25
UTC ---
No, it should be easy. Just look at the EQ_USES in df_kill_notes and, if one
EQ_USE refers to a dead pseudo, kill the REG_EQUAL or REG_EQUIV note.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51447
--- Comment #8 from Paolo Bonzini 2011-12-15 12:01:25
UTC ---
For ud_dce it's simplest to add/remove fake edges around it. For 4.8 it could
be worthwhile to try adding fake edges around all RTL passes (at least those
running in cfglayout mode) a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829
--- Comment #4 from Paolo Bonzini 2012-01-03 13:06:50
UTC ---
You can just set enable_static=no early in libstdc++-v3/configure.ac. It will
still install libstdc++-v3.a, which is a bit ugly, but that's quite hard to
achieve due to libtool.
One
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505
--- Comment #6 from Paolo Bonzini 2012-01-17 16:22:08
UTC ---
Yeah, perhaps you can make the code nicer by avoiding the nested loops:
for (use_rec = DF_INSN_EQ_USES (insn); *use_rec; use_rec++)
{
df_ref use = *use_rec;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505
--- Comment #8 from Paolo Bonzini 2012-01-18 08:58:33
UTC ---
I think you can just kill the note and call df_notes_rescan, can't you? (Sorry
for leaving this implicit in comment 4 and then forgetting about it yesterday).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505
--- Comment #10 from Paolo Bonzini 2012-01-18 10:58:19
UTC ---
Not using df_notes_rescan looks like premature optimization to me...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829
--- Comment #7 from Paolo Bonzini 2012-01-19 08:59:02
UTC ---
The convenience library can be linked with -L.../.libs -lsupc++convenience
-lstdc++convenience98.
But it really looks like you attached the wrong patch?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829
--- Comment #12 from Paolo Bonzini 2012-01-20 07:52:26
UTC ---
(In reply to comment #10)
> When there is not one convenience library, but three. Seems like my options
> are:
>
> 1) combine the three convenience libraries into one, meta or super
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
Paolo Bonzini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
--- Comment #8 from bonzini at gnu dot org 2007-05-11 07:19 ---
I started bootstrap and SPEC2000 on i686-pc-linux-gnu, I'll post the result
tomorrow hopefully (if the weekend swamps me it I might delay that). :-(
--
bonzini at gnu dot org changed:
What|Re
--- Comment #11 from bonzini at gnu dot org 2007-05-13 09:20 ---
I confirm the compile-time improvements from the complete patch (2%
enable-checking, 0.8% disable-checking), but there's no improvement in SPEC (no
regression either).
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #1 from bonzini at gnu dot org 2007-05-21 08:19 ---
I know what's going on :-)
--
bonzini at gnu dot org changed:
What|Removed |Added
Assig
--- Comment #2 from bonzini at gnu dot org 2007-05-21 08:21 ---
Created an attachment (id=13593)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13593&action=view)
tentative patch?
Please test this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #11 from bonzini at gnu dot org 2007-05-21 08:48 ---
Micha, do you mean transforming (while expanding to RTL)
asm ("": "=mr" (inout_2) : "0" (inout_1));
to
inout_2 = inout_1;
asm ("": "=mr" (inout_2) : "0&qu
--- Comment #13 from bonzini at gnu dot org 2007-05-21 09:32 ---
So we'd just be replacing a weak workaround with a stronger (but not
definitive) workaround. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #6 from bonzini at gnu dot org 2007-05-22 10:33 ---
Please try this patch on top of the previous one. Its purpose is just to
validate the logic of the previous one, it's not meant to be committed.
Index: libgcc/configu
--- Comment #8 from bonzini at gnu dot org 2007-05-23 15:24 ---
I have a Mac so I can fix this, but I'm not sure on the timing. I'm commenting
out the BOOT_CFLAGS setting for a moment to unbreak bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #5 from bonzini at gnu dot org 2007-05-30 15:57 ---
A bug with the same symptom resurfaced. David, did I understand right that
this time the problem is the huge environment passed from the toplevel
makefile?
--
bonzini at gnu dot org changed:
What
--- Comment #2 from bonzini at gnu dot org 2007-05-31 06:06 ---
I'm not sure we actually want to build libgcc stage1 optimized. But yes,
fixing 32009 will provide a way to fix this.
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #6 from bonzini at gnu dot org 2007-06-11 06:54 ---
can you please show the difference in assembly code between the two?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #10 from bonzini at gnu dot org 2007-06-20 11:13 ---
DJ, do you think this patch is ok?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #14 from bonzini at gnu dot org 2007-06-25 07:01 ---
wrong bug marked as duplicate... reopening...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2007-06-25 07:02 ---
*** This bug has been marked as a duplicate of 30563 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #15 from bonzini at gnu dot org 2007-06-25 07:02 ---
*** Bug 30537 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from bonzini at gnu dot org 2007-06-25 07:03 ---
... to close as fixed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #17 from bonzini at gnu dot org 2007-06-29 19:25 ---
And that's why I left it assigned to me. I'll work on it next week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #3 from bonzini at gnu dot org 2007-06-29 19:26 ---
CCing Honza, he had a patch for this bug.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #17 from bonzini at gnu dot org 2007-07-04 07:11 ---
I'm working on this, but don't hold your breath (hence not assigning to
myself).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #5 from bonzini at gnu dot org 2007-07-04 07:12 ---
*** This bug has been marked as a duplicate of 32004 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #18 from bonzini at gnu dot org 2007-07-04 07:12 ---
*** Bug 25216 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2007-07-04 07:13 ---
PR25216 is a dup of PR32004.
--
bonzini at gnu dot org changed:
What|Removed |Added
BugsThisDependsOn
--- Comment #19 from bonzini at gnu dot org 2007-07-04 08:16 ---
Created an attachment (id=13843)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13843&action=view)
patch under testing
QED (Quite Easily Done :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #20 from bonzini at gnu dot org 2007-07-04 13:54 ---
The attached patch makes PR30311 resurface; this seems like a minor problem
because that code is dubious, and can be worked around by not doing the
transformation when the modes mismatch.
--
http://gcc.gnu.org
--- Comment #7 from bonzini at gnu dot org 2007-07-05 10:27 ---
Using "s,g,g," or "s,^,," or even "b" as the default sed command doesn't seem
to bad to me.
--
bonzini at gnu dot org changed:
What
--- Comment #13 from bonzini at gnu dot org 2007-07-05 10:36 ---
Can we mark it as WONTFIX for 4.0 to 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
--- Comment #11 from bonzini at gnu dot org 2007-07-05 11:13 ---
Actually any no-op command would do, I think even "b" would be ok unless it
triggers other bugs. In particular, replacing one g with a g, or all g's with
g's, should not matter. :-)
--
http://
--- Comment #8 from bonzini at gnu dot org 2007-07-05 20:03 ---
Subject: Re: BOOT_CFLAGS is not passed to stage2 and stage3
compile
Sebastian Pop wrote:
> Hi,
>
> here is a fix for PR32622 that I've bootstrapped and tested on
> i686-linux with "configure BOOT
--- Comment #22 from bonzini at gnu dot org 2007-07-05 20:11 ---
The patch does not fix this one, which also works in 3.3 and fails in 4.1. I'm
not sure it's 100% the same bug. Still, I committed the patch to fix the
testcase from PR21291.
--
http://gcc.gnu.or
--- Comment #23 from bonzini at gnu dot org 2007-07-06 12:08 ---
In particular, this one could be rewritten to
inline void g(int b)
{
register int reg = 0;
asm volatile ("nop" : "+a"(reg), "+r"(b));
}
void f(int a)
{
a /= 1000;
g(a);
}
bu
801 - 900 of 1283 matches
Mail list logo
