--- Comment #24 from bonzini at gnu dot org 2007-07-06 12:18 ---
Also, the testcase from comment #21 is not a regression: if we do the inlining
manually, it fails in 3.3 too. The failing testcase is:
void f(int a)
{
register int reg asm ("eax") = 0;
a /= 1000;
asm vola
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ra
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i686-pc
--- Comment #27 from bonzini at gnu dot org 2007-07-06 15:13 ---
fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #32 from bonzini at gnu dot org 2007-07-09 15:38 ---
additional fix committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #15 from bonzini at gnu dot org 2007-07-09 16:31 ---
Note that this:
> Before the dataflow merge, the argument pointer was always included
> in "Registers live at start".
... was because uninitialized registers always showed up as live at start
--- Comment #16 from bonzini at gnu dot org 2007-07-09 21:04 ---
Looking out of the box, why can't we add it always, the same as we do with the
frame and stack pointer?? I wonder if the fixed/variable thing is a red
herring.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
--- Comment #3 from bonzini at gnu dot org 2007-07-11 19:49 ---
First, I'm not a reload expert. :-) But it does not look like a reload bug (or
at least it is easily worked around in the machine description, methinks).
regmove should have changed that but it does not probably be
Assignee: unassigned at gcc dot gnu.org
Reporter: bonzini at gnu dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84307
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: bonzini at gnu dot org
Target Milestone: ---
Right now the only possibility to specify that combination
-fcf-protection=full, but this is not future proof; if other suboptions are
added later, they could be applied to code that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84307
--- Comment #1 from Paolo Bonzini ---
Author: bonzini
Date: Mon Feb 12 12:47:56 2018
New Revision: 257585
URL: https://gcc.gnu.org/viewcvs?rev=257585&root=gcc&view=rev
Log:
gcc:
2018-02-12 Paolo Bonzini
PR sanitizer/84307
* in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84340
--- Comment #7 from Paolo Bonzini ---
The problem is not the transformation from *ptr to x, the problem is that x=0
is later considered dead because ASAN_CHECK references are introduced too late.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84340
--- Comment #10 from Paolo Bonzini ---
> Note that we only instrument ASAN_CHECK for memory references. x=0 is not
> that
> case.
That depends... in use-after-scope-types-1.C there is inlining involved. With
my pass ordering change ASAN_CHECK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84340
--- Comment #12 from Paolo Bonzini ---
No, I don't think computing a shadow memory address counts as memory
indirection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84307
--- Comment #2 from Paolo Bonzini ---
Author: bonzini
Date: Tue Feb 13 13:03:22 2018
New Revision: 257625
URL: https://gcc.gnu.org/viewcvs?rev=257625&root=gcc&view=rev
Log:
gcc:
2018-02-13 Paolo Bonzini
PR sanitizer/84340
* in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84340
--- Comment #13 from Paolo Bonzini ---
Author: bonzini
Date: Tue Feb 13 13:03:22 2018
New Revision: 257625
URL: https://gcc.gnu.org/viewcvs?rev=257625&root=gcc&view=rev
Log:
gcc:
2018-02-13 Paolo Bonzini
PR sanitizer/84340
* i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84340
--- Comment #14 from Paolo Bonzini ---
I'll just revert the original PR84307 patch. Changing the fnspec has way too
many ramifications. PR84307 can either be fixed with an early UNPOISON
elimination pass, or delayed to GCC 9 where we can play w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84340
Paolo Bonzini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |bonzini at gnu dot org
Known to fail||7.3.1, 8.0.1
--- Comment #3 from Paolo Bonzini ---
Patch reverted due to PR84340.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55389
--- Comment #2 from Paolo Bonzini 2012-11-19 13:05:51
UTC ---
Can you post the full log of a rm+make?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489
Bug #: 55489
Summary: [4.7 regression] insane PRE memory usage with PIE
(translate.i)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489
Paolo Bonzini changed:
What|Removed |Added
Known to work|4.8.0 |
Summary|[4.7 regress
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489
--- Comment #2 from Paolo Bonzini 2012-11-27 20:27:09
UTC ---
Author: bonzini
Date: Tue Nov 27 20:26:57 2012
New Revision: 193867
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193867
Log:
2012-11-27 Paolo Bonzini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489
--- Comment #3 from Paolo Bonzini 2012-11-27 20:29:24
UTC ---
Author: bonzini
Date: Tue Nov 27 20:29:15 2012
New Revision: 193868
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193868
Log:
2012-11-27 Paolo Bonzini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55489
Paolo Bonzini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55597
Paolo Bonzini changed:
What|Removed |Added
CC||stevenb.gcc at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128
--- Comment #3 from Paolo Bonzini 2013-01-28 13:36:36
UTC ---
--disable-target-libsanitizer should work:
# Handle --disable- generically.
for dir in $configdirs $build_configdirs $target_configdirs ; do
dirname=`echo $dir | sed -e s/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #20
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bonzini at gnu dot org
Target Milestone: ---
int f(char *restrict a, const char *restrict b)
{
__builtin_memcpy(a, b, 512);
}
$ gcc f.c -O2 - -o f.s
includes the following code:
movq%rdi, %rcx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68418
Paolo Bonzini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70079
--- Comment #2 from Paolo Bonzini ---
Yes, until combine there is the equivalent of
addl$512, %ecx;; 4
andl$-8, %ecx ;; 4.5
shrl$3, %ecx ;; 5
and combine is ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244
--- Comment #16 from Paolo Bonzini ---
> This also suggests there's an error in the current x86_64 kernel
> implementation
> as the kernel bitops are supposed to operate on machine word-size locations,
> so
> it should be using BTSQ not BTSL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #8 from Paolo Bonzini ---
g_assertion_message_cmpnum is not declared anymore as noreturn since glib 2.38.
https://bugzilla.gnome.org/show_bug.cgi?id=692125 :-O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #12 from Paolo Bonzini ---
> So AFAICT, the warning for the first testcase is valid as well.
True, but isn't the maximum object size (2^63-1 aka PTRDIFF_MAX) as bogus as
2^64-1? We are using -1 which is a bit ugly but SIZE_MAX would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #14 from Paolo Bonzini ---
And also treat it as undefined behavior and go straight to the else...
kidding, but not entirely!).
The main issue is that here we _are_ testing the overflow behavior of the
function, so we cannot pass sz
--- Comment #17 from bonzini at gnu dot org 2010-02-10 23:11 ---
Subject: Re: [4.3/4.4/4.5 regression] Code size
increase on ARM due to poor register allocation
> Perhaps we should prefer addresses based on the frame pointer over other
> addresses?
Yes, that's defini
--- Comment #31 from bonzini at gnu dot org 2010-02-11 23:56 ---
I think it's fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36101
--- Comment #7 from bonzini at gnu dot org 2010-02-16 08:16 ---
Committed the patch to 4.3 too
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from bonzini at gnu dot org 2010-02-18 13:17 ---
I'm relieved that cond-optab is in no way related to this. :-)
I'm not expert of the gimplifier but the patch makes sense and looks good.
--
bonzini at gnu dot org changed:
What
--- Comment #10 from bonzini at gnu dot org 2010-03-17 06:41 ---
REG_EQUAL notes are not there to guarantee correctness. Relying on them to
avoid misoptimization is always wrong and just hides the bug.
It is a regression from 4.2.
--
bonzini at gnu dot org changed
--- Comment #18 from bonzini at gnu dot org 2010-04-01 08:08 ---
TREE_USED then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
--- Comment #17 from bonzini at gnu dot org 2010-04-01 15:42 ---
Subject: Re: ___emutls_v.__gcov_indirect_call_[counters|callee]
undefined on *-*-darwin*
On 04/01/2010 01:27 PM, howarth at nitro dot med dot uc dot edu wrote:
> --- Comment #14 from howarth at nitro dot med dot
--- Comment #19 from bonzini at gnu dot org 2010-04-01 16:01 ---
No, I don't have time to debug this further, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
--- Comment #5 from bonzini at gnu dot org 2010-04-01 16:10 ---
Created an attachment (id=20279)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20279&action=view)
patch
Here is a totally untested patch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
--- Comment #24 from bonzini at gnu dot org 2010-04-04 07:18 ---
Subject: Re: libgcc built with -DHAVE_CC_TLS against xgcc when
emutls in use
> This provides a traverse of the emutls control var htab finalizing
> each.
>
> I didn't try to check if vars were already
--- Comment #8 from bonzini at gnu dot org 2010-04-07 10:33 ---
The patch is mostly splitting an if statement in two parts. If anyone can test
it for 4.5.1/4.6 that would be nice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bonzini at gnu dot org
Version: gcc (GCC) 5.0.0 20150319 (Red Hat 5.0.0-0.21)
The following program does not warn with -Waggressive-loop-optimizations:
int a[4] = {1, 2, 3, 4};
int main()
{
int i, j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #19 from Paolo Bonzini ---
LIVE provides live registers that MAY be initialized (are initialized on at
least one path). The comments are all wrong!
There's no code in GCC for must-initialized. Pierre's patch gets it right
(except t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #29 from Paolo Bonzini ---
> While getting familiar with DF problems, I noticed that LIVE's ignores
> the order of GENs and KILLs in basic blocks. In other words, the
> transfer function for: GEN(r1); KILL(r1) is currently the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #31 from Paolo Bonzini ---
Ah, I see now. I think you're right that the DF_REF_MUST_CLOBBER case should
also clear GEN in df_live_bb_local_compute.
However, regarding the "BTW" I am fairly sure now that df_live_bb_local_compute
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #35 from Paolo Bonzini ---
Comment on attachment 36377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36377
Updated candidate patch
> + This problem determines which registers may be uninitialized. It first
> + assumes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #37 from Paolo Bonzini ---
Bernd is right that you have a missing 'else'.
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: bonzini at gnu dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Left shifts into the sign
||2015-11-18
Assignee|unassigned at gcc dot gnu.org |bonzini at gnu dot org
Ever confirmed|0 |1
--- Comment #1 from Paolo Bonzini ---
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827
--- Comment #6 from Paolo Bonzini ---
If you really want to fix it, (-(1 << 19)) is the best.
The real fix would be to lobby the C/C++ committees so that left shift of a
negative value is unspecified behavior rather than undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68418
--- Comment #2 from Paolo Bonzini ---
Author: bonzini
Date: Sat Dec 12 08:29:27 2015
New Revision: 231582
URL: https://gcc.gnu.org/viewcvs?rev=231582&root=gcc&view=rev
Log:
gcc:
PR sanitizer/68418
* c-family/c-ubsan.c (ubsan_inst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32394
Paolo Bonzini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bonzini at gnu dot org
Target Milestone: ---
This is caused by early SRA splitting elem's assignment into separate per-field
assignments.
struct x {
unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #130 from Paolo Bonzini ---
A late update...
all.i: with GCC 4.8.3 on a Xeon E5 v3 time is taken mostly by alias stmt
walking
alias stmt walking : 272.52 (65%) (-O2)
alias stmt walking : 116.06 (67%) (-O1)
Requred mem
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: bonzini at gnu dot org
Target Milestone: ---
PR26854 is spending a lot of time in alias stmt walking
alias stmt walking : 272.52 (65%) (-O2)
alias stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66760
Paolo Bonzini changed:
What|Removed |Added
Keywords||compile-time-hog
CC|
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bonzini at gnu dot org
Target Milestone: ---
This can save one or two instructions on some architectures. For example, when
compiling
int f(int x, int t)
{
return x & ((1 << t) -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66872
--- Comment #2 from Paolo Bonzini ---
> left shift of negative value is undefined behavior in C
It's not in any of GCC's intermediate representations, though.
--- Comment #15 from bonzini at gnu dot org 2009-12-16 17:30 ---
Well, the solution could be disable PCH by default. :-) Is anybody using
it?...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #5 from bonzini at gnu dot org 2009-12-22 17:49 ---
For me it's fine to close it, however note that 2161 was reported on a
(generated) real-world program. I don't know whether there were really 11,000
else-ifs in the real-world program, probably not.
--- Comment #18 from bonzini at gnu dot org 2009-12-29 18:01 ---
True, it is P5 but it is not invalid. Andreas, if you want to close this as
invalid you should first follow the target deprecation process and propose to
remove the target for 4.6.
--
bonzini at gnu dot org changed
--- Comment #6 from bonzini at gnu dot org 2009-12-29 19:29 ---
Causes PR40414 on GCC 4.4.x, reopening to make the other PR depend on this.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #21 from bonzini at gnu dot org 2009-12-29 19:30 ---
Reopening since it is still broken on the other open branches.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #20 from bonzini at gnu dot org 2009-12-29 19:30 ---
Adding dependencies on the patches that fix the bug.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #23 from bonzini at gnu dot org 2009-12-30 10:56 ---
You need a proper patch, not instructions.
However, it's clear from the bugreport and the patches required to fix it, that
it is not important whether the target is m68k-amigaos or another OS.
--
http://gcc.gn
--- Comment #37 from bonzini at gnu dot org 2009-12-30 10:59 ---
The bootstrap failure is fixed, please reconfirm and reopen bugs for other
failures or other targets.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #38 from bonzini at gnu dot org 2009-12-30 11:09 ---
Andreas, for s390-linux I get this jumpless code:
f:
xr %r2,%r3
lpr %r2,%r2
ahi %r2,-1
srl %r2,31
br %r14
for this testcase:
int f(int a, int b)
{
return
--- Comment #25 from bonzini at gnu dot org 2009-12-30 12:22 ---
Adding target support without at least libgcc makes little sense.
The small part in config.guess/config.sub is not going to be removed, since
those files are just imported in GCC and are handled as a separate project
--- Comment #6 from bonzini at gnu dot org 2010-01-02 10:28 ---
I don't know but I found a tree that generates the 9-instruction sequence, and
it was "GCC: (GNU) 4.4.0 20090314 (experimental)".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
--- Comment #7 from bonzini at gnu dot org 2010-01-02 10:31 ---
(That would be r144855 or r144857).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
--- Comment #2 from bonzini at gnu dot org 2010-01-05 11:43 ---
Combine is doing what it knows best (forming complicated instructions,
addressing modes in this case); to do this it is already damaging the nice
shape of the code after the tree optimizers, and synthesizing things like x+2
--- Comment #16 from bonzini at gnu dot org 2010-01-21 14:45 ---
> Wrong submitter's proposal, you mean.
Yes. What I don't understand is, why is anything else than this needed:
-target_modules = { module= libgomp; lib_path=.libs; };
+target_modules = { mo
--- Comment #18 from bonzini at gnu dot org 2010-01-21 15:40 ---
Subject: Re: deps on other host libraries incorrect
On 01/21/2010 04:29 PM, amylaar at gcc dot gnu dot org wrote:
> dependencies = { module=all-target-libstdc++-v3;
> on=configure-target-libgomp; };
>
> In f
--- Comment #27 from bonzini at gnu dot org 2010-01-23 09:11 ---
Subject: Re: deps on other host libraries incorrect
On 01/22/2010 08:17 PM, amylaar at gcc dot gnu dot org wrote:
> --- Comment #25 from amylaar at gcc dot gnu dot org 2010-01-22 19:17
> ---
> C
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org
--
bonzini at gnu dot org changed:
What|Removed |Added
Last reconfirmed|2010-01-26 13:06:30 |2010-01-26 13:45:02
date
--- Comment #1 from bonzini at gnu dot org 2010-01-26 13:55 ---
Testing this:
Index: configure.ac
===
--- configure.ac(revision 156244)
+++ configure.ac(working copy)
@@ -146,7 +146,8 @@ case `echo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48156
--- Comment #8 from Paolo Bonzini 2011-03-18 16:24:25
UTC ---
I like the patch from comment 6.
--- Comment #68 from bonzini at gnu dot org 2010-08-06 07:07 ---
fwprop.c doesn't handle it directly, but local_ref_killed_between_p should see
defs created by df-scan.c for each hard register in regs_invalidated_by_call
(see df_get_call_refs).
Also, since fwprop can lengthen life
--- Comment #70 from bonzini at gnu dot org 2010-08-06 09:54 ---
The real reason is the first: why is there no def for r25?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #72 from bonzini at gnu dot org 2010-08-06 10:00 ---
No, why is there no def for r25 _where it is clobbered_?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #74 from bonzini at gnu dot org 2010-08-06 13:38 ---
Thanks for the help. I'll look at it tomorrow/next week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #7 from bonzini at gnu dot org 2010-08-16 07:56 ---
H.J., thanks very much for the analysis!
Can you please attach preprocessed source code and the output of "gcc -###"
when compiling this file using the compiler options you need to show this bug?
--
bonzini
--- Comment #9 from bonzini at gnu dot org 2010-08-16 13:29 ---
The bug seems to be that an instruction clobbering the flags is inserted after
the unspec.
140 {r127:SI=[r62:SI];[r62:SI]=unspec/v[[r62:SI],r128:SI,r129:SI]
11;flags:CCZ=cmp(unspec/v[[r62:SI],r128:SI,r129:SI] 11,r128:SI
--- Comment #10 from bonzini at gnu dot org 2010-08-16 13:48 ---
Created an attachment (id=21491)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21491&action=view)
patch to fix the bug
This is the patch to fix the bug. I'll bootstrap/regtest it soon.
Thanks H.J.
--- Comment #76 from bonzini at gnu dot org 2010-08-24 06:50 ---
Subject: Re: [4.6 regression] Revision 162270 failed
to bootstrap
On 08/23/2010 10:49 PM, sje at cup dot hp dot com wrote:
> --- Comment #75 from sje at cup dot hp dot com 2010-08-23 20:49 ---
> Paolo, a
--- Comment #78 from bonzini at gnu dot org 2010-08-24 13:44 ---
My plan for fwprop is to replace the whole update_df machinery with a call to
df_uses_record. The use-def links can be kept up to date by looking at the
original uses of both the propagated-from and propagated-into
--- Comment #46 from bonzini at gnu dot org 2010-09-02 12:44 ---
Subject: Re: [4.3/4.4/4.5/4.6 Regression] cannot build
gcc-4.4.1: fenv_t has not been declared
> Paolo (Bonzini), Ralf, I'm going to add -nostdinc++ to PCHFLAGS in
> include/Makefile.am. Are there a
--- Comment #15 from bonzini at gnu dot org 2010-09-04 09:08 ---
Please revert the patch in both gcc and src. It's clear that the way to go is
to first write small patch to smooth out the nuances you pointed out, and then
introduce the new macro in a way that doesn't
--- Comment #30 from bonzini at gnu dot org 2010-09-04 16:41 ---
> > It's clear that the way to go is to first write
> > small patch to smooth out the nuances you pointed out, and then
> > introduce the new macro in a way that doesn't change the semantics.
&g
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
901 - 1000 of 1283 matches
Mail list logo
