--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2006-04-12
14:09 ---
Subject: Re: [4.2 Regression] gcc fails to build on sh64-elf
targets
> I think the best solution is to have an INDEX_REG_CLASS_FOR_MODE macro,
> which defaults to INDEX_REG_CLASS. Then this mac
--- Comment #11 from paolo dot bonzini at lu dot unisi dot ch 2006-04-14
07:27 ---
Subject: Re: [4.1/4.2 Regression] Invalid altivec constant
loading code
> I'm not sure why you think that two splats and two adds is too
> expensive.
>
I'd hope that these co
--- Comment #7 from paolo dot bonzini at lu dot unisi dot ch 2006-04-18
14:47 ---
Subject: Re: [4.1/4.2 Regression] Segfault in find_lattice_value()
for complex operands.
rguenth at gcc dot gnu dot org wrote:
> --- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-18 14
--- Comment #5 from paolo dot bonzini at lu dot unisi dot ch 2006-05-22
07:35 ---
Subject: Re: [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c
execution fails at -O0
> It was mentioned in
> http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00390.html
> Also
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2005-11-14
18:26 ---
Subject: Re: scheduling takes 40% or more time
>Is it the first scheduling pass? If so, we have a patch at AdaCore to limit
>its explosion.
>
>
Yes, it is. schedule_insns2 takes not
--- Comment #17 from paolo dot bonzini at lu dot unisi dot ch 2005-11-16
09:41 ---
Subject: Re: [4.1 Regression] f2c miscompilation
rguenth at gcc dot gnu dot org wrote:
>--- Comment #16 from rguenth at gcc dot gnu dot org 2005-11-16 09:39
>---
>Is the secon
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2005-12-07
10:52 ---
Subject: Re: bootstrap failures on non-C99 platforms
>>I bootstrapped this on i686-pc-linux-gnu, all languages. Eric, can you test
>>it on a non-C99 platform?
>>
>>
>
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2005-12-16
08:02 ---
Subject: Re: stage build no longer works
hjl at lucon dot org wrote:
>--- Comment #2 from hjl at lucon dot org 2005-12-16 07:37 ---
>I made a change to i386.c. I just want to rebuild the
--- Comment #25 from paolo dot bonzini at lu dot unisi dot ch 2006-01-04
16:29 ---
Subject: Re: [4.1/4.2 Regression] Massive performance
regression for -ffast-math due to the recip tree pass
>For PowerPC, it is effective to use the instruction if
>there are multiple divides
--- Comment #1 from paolo dot bonzini at lu dot unisi dot ch 2006-01-16
07:56 ---
Subject: Re: New: make clean fails
aoliva at gcc dot gnu dot org wrote:
>It appears that make clean (on a native bootstrap) always fails for me. After
>make clean on a tree containing a
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2006-01-20
17:21 ---
Subject: Re: make clean fails
aoliva at gcc dot gnu dot org wrote:
>--- Comment #2 from aoliva at gcc dot gnu dot org 2006-01-20 17:16 ---
>If you mean make -k for sub-makes, yes. But
--- Comment #40 from paolo dot bonzini at lu dot unisi dot ch 2006-08-07
16:58 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
>> I don't see how the last fmul[sl] can be removed without increasing code
>> size.
>
--- Comment #42 from paolo dot bonzini at lu dot unisi dot ch 2006-08-07
18:19 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> We should get some idea by comparing gcc3 vs. your
> patched compiler on the various platforms,
--- Comment #48 from paolo dot bonzini at lu dot unisi dot ch 2006-08-08
07:05 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> In x86/x86-64 world one can be almost sure that the load+execute instruction
> pair will e
--- Comment #51 from paolo dot bonzini at lu dot unisi dot ch 2006-08-09
04:33 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> I've been scoping this a little closer on the Athlon64X2. I have found that
> the patc
--- Comment #59 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10
06:52 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> Thanks for the response, but I believe you are conflating two issues (as is
> this flag, which
--- Comment #9 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10
08:04 ---
Subject: Re: sincos can be folded at the tree
level
> If this PR was only about x87 using fsincos for sincos this is fixed now.
Well, it was mostly about getting rid of TREE_ADDRESSABLE, which you
--- Comment #61 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10
14:28 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> Making vectorization depend on a flag that says it is allowed to violate IEEE
> is therefore a kill
--- Comment #63 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10
15:22 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
>> If you want a -freassociate-fp math, open an enhancement PR and somebody
>>
> Ah,
--- Comment #7 from paolo dot bonzini at lu dot unisi dot ch 2006-08-18
14:08 ---
Subject: Re: one reference to powerpc-ibm-eabi-ar.exe
when only xar.exe installed
etienne_lorrain at yahoo dot fr wrote:
> --- Comment #6 from etienne_lorrain at yahoo dot fr 2006-08-18 13
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2006-09-21
08:21 ---
Subject: Re: [ecj] update build instructions to account for
changes
> This is found using the normal gcc specs approach. In a distribution
> I'd expect ecj1 to end up in the gcc-lib dir.
--- Comment #18 from paolo dot bonzini at lu dot unisi dot ch 2006-10-03
05:20 ---
Subject: Re: [4.2 Regression] Performace problem with
indexed load/stores on powerpc
> * rtlanal.c (swap_commutative_operands_p): Preference a REG_POINTER
> over a non REG_P
--- Comment #11 from paolo dot bonzini at lu dot unisi dot ch 2006-10-11
13:05 ---
Subject: Re: [4.0/4.1/4.2 Regression] address selection does
not work correctly
> movl8(%ebp), %edx
> addl$1, %edx
> movsbl b(%edx),%eax
> mo
--- Comment #7 from paolo dot bonzini at lu dot unisi dot ch 2007-02-01
06:13 ---
Subject: Re: "make check" fails to compile library testcases
>> I'll take a look.
>
> Any ideas?
Sure, I'm just a little busy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
--- Comment #29 from paolo dot bonzini at lu dot unisi dot ch 2007-02-06
08:26 ---
Subject: Re: Shared libstdc++ fails to link
> Paolo, would you be able to undo the change to make "foo" not marked
> TREE_NOTHROW? IIUC, that would be different than the patch you pos
--- Comment #12 from paolo dot bonzini at lu dot unisi dot ch 2007-04-03
13:59 ---
Subject: Re: [4.3] inf loop/long compile time, time spent
in var-tracking.c
> With dataflow branch that was compiled with profiling the testcase finishes
> not too slow:
This suggest that i
--- Comment #41 from paolo dot bonzini at lu dot unisi dot ch 2007-08-06
11:52 ---
Subject: Re: [4.2/4.3 Regression] Performace problem
with indexed load/stores on powerpc
> This is now more like a meta-bug, see the other two bugs which are opened for
> the current issues (ye
--- Comment #2 from paolo dot bonzini at lu dot unisi dot ch 2007-08-24
14:53 ---
Subject: Re: missed store sinking opportunity
Danny said he knows how to fix it (I guess in store sinking though he
didn't say). From knowing him, there might be additional less obvious
cases
--- Comment #23 from paolo dot bonzini at lu dot unisi dot ch 2007-08-29
11:47 ---
Subject: Re: [4.3 Regression] ecj1 hangs
> df_simulate_one_insn_forwards and df_simulate_one_insn_backwards
> (why we have the former when nothing ever uses it?) both call
> df_simulate_fixu
--- Comment #24 from paolo dot bonzini at lu dot unisi dot ch 2007-08-29
12:15 ---
Subject: Re: [4.3 Regression] ecj1 hangs
> Here is what I will try to regtest (already verified it fixes the testcase).
This is wrong, because local_live changes during execution of
dce_process_bl
--- Comment #6 from paolo dot bonzini at lu dot unisi dot ch 2007-09-25
14:22 ---
Subject: Re: wrong code for multiple output asm,
wrong df?
ubizjak at gmail dot com wrote:
> --- Comment #5 from ubizjak at gmail dot com 2007-09-25 13:58 ---
> (In reply to comm
--- Comment #8 from paolo dot bonzini at lu dot unisi dot ch 2007-09-25
14:40 ---
Subject: Re: wrong code for multiple output asm,
wrong df?
> There is a comment in the '%' documentation:
>
> GCC can only handle one commutative pair in an asm; if you u
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-03-15 06:36 ---
Subject: Re: [4.1] sincos can be folded at the
tree level
> Paolo, are you going to submit this one?
Yes, but I am wy too busy at work now. Maybe as soon as Thursday.
--
h
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-05-21
09:41 ---
Subject: Re: [4.3 regression] : gcc.target/i386/pr21291.c
matz at gcc dot gnu dot org wrote:
> --- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 ---
> Yes. The place w
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2007-06-17
14:14 ---
Subject: Re: [4.3 Regression] ICE in df_refs_verify
with -O2 -fmodulo-sched for spec tests
> ok to commit?
Yes.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
--- Comment #2 from paolo dot bonzini at lu dot unisi dot ch 2007-06-18
04:41 ---
Subject: Re: [4.3 Regression] ICE in df_lr_verify_transfer_functions,
at df-problems.c:1924
> The possible second problem is that something in one of
>
> delete_trivially_d
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2007-06-19
05:09 ---
Subject: Re: tree-ssa-math-opts.c performs too
many IL scans
> We have reciprocal pass (in fact CSE recip pass) that CSEs 1.0/z from x/z,
> y/z,
> .../z. This is done by scanning fun
--- Comment #9 from paolo dot bonzini at lu dot unisi dot ch 2007-06-23
16:03 ---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
Kenneth Zadeck wrote:
> This patch changes dce:deletable_insn_p so that it looks at all of the
> top level
> cla
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-07-05
10:46 ---
Subject: Re: [4.0/4.1/4.2 Regression] address
selection does not work correctly
Yes, we should add a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
--- Comment #34 from paolo dot bonzini at lu dot unisi dot ch 2007-07-12
19:01 ---
Subject: Re: [4.1/4.2/4.3 regression] : can't find
a register in class 'GENERAL_REGS' while reloading 'asm'
kkojima at gcc dot gnu dot org wrote:
> --- Comment #33 fro
--- Comment #36 from paolo dot bonzini at lu dot unisi dot ch 2007-07-13
09:57 ---
Subject: Re: [4.1/4.2/4.3 regression] : can't find
a register in class 'GENERAL_REGS' while reloading 'asm'
kkojima at gcc dot gnu dot org wrote:
> --- Comment #33 fro
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-09-21 06:51 ---
Subject: Re: x87 reg allocated for constants for -mfpmath=sse
>Note that in this pattern cost computation of MMX_REGS are all ignored ('*'
>in front of y). So, the cost
>w
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-09-21 14:33 ---
Subject: Re: [4.1 Regression] internal compiler
error: verify_stmts failed
rguenth at gcc dot gnu dot org wrote:
>--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-09-30 12:53 ---
Subject: Re: [4.1 Regression] Massive performance
regression for -ffast-math due to the recip tree pass
>It looks to me that header is reversed! pov::sbisect is 1.50 _with_ recip.
>
ehm,
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-09-30 14:13 ---
Subject: Re: [4.1 Regression] Massive performance
regression for -ffast-math due to the recip tree pass
>Currently, there seems to be some problems, i.e.:
>
>double pov::f_polytub
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-09-30 14:40 ---
Subject: Re: [4.1 Regression] Massive performance
regression for -ffast-math due to the recip tree pass
>>>Function double pov::POVFPU_RunDefault(pov::FUNCTION)
>>>
>>&
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-10-01 11:00 ---
Subject: Re: [4.0/4.1 Regression] gcc.dg/asm-1.c (test
for excess errors) fails
pinskia at gcc dot gnu dot org wrote:
>--- Additional Comments From pinskia at gcc dot gnu dot org 2005
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2005-10-22
09:52 ---
Subject: Re: [4.0 Regression] missing error messages passing vectors with
-mno-altivec -mabi=altivec
I *think* it is also fixed on 4.0; a grep for the error message in
config/rs6000/rs6000.c would
--- Comment #17 from paolo dot bonzini at lu dot unisi dot ch 2005-10-28
19:16 ---
Subject: Re: [4.1 Regression] ICE in extract_insn with
altivec
>On IRC it was suggested that we just need to get a version of
>easy_vector_constant which does the right thing in any mode.
>
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-08-17 20:07 ---
Subject: Re: [meta-bug] optimizations that CSE still
catches
>>unsigned outcnt;
>>extern void flush_outbuf(void);
>>
>>void
>>bi_windup(unsign
--- Comment #13 from paolo dot bonzini at lu dot unisi dot ch 2007-11-07
06:03 ---
Subject: Re: [4.3 Regression] Revision 119502
causes significantly slower results with 4.3 compared to 4.2
> I don't think we want to start playing with the heuristics ;) That patch
> cer
--- Comment #5 from paolo dot bonzini at lu dot unisi dot ch 2007-11-07
13:53 ---
Subject: Re: [4.3 Regression] Pessimization caused
by fwprop
> BTW, why don't you use just rtx_cost instead of insn_rtx_cost?
> In each case you have an insn, so you can do single_set on
--- Comment #8 from paolo dot bonzini at lu dot unisi dot ch 2007-11-08
06:10 ---
Subject: Re: [4.3 Regression] Pessimization caused
by fwprop
jakub at gcc dot gnu dot org wrote:
> --- Comment #7 from jakub at gcc dot gnu dot org 2007-11-07 20:18 ---
> Created an atta
--- Comment #22 from paolo dot bonzini at lu dot unisi dot ch 2007-11-08
06:12 ---
Subject: Re: [4.3 Regression] Revision 119502
causes significantly slower results with 4.3 compared to 4.2
jacob at math dot jussieu dot fr wrote:
> --- Comment #21 from jacob at math dot juss
--- Comment #10 from paolo dot bonzini at lu dot unisi dot ch 2007-11-08
16:32 ---
Subject: Re: [4.3 Regression] can't find a register
in class 'GENERAL_REGS' while reloading 'asm'
ubizjak at gmail dot com wrote:
> --- Comment #9 from ubizjak at gma
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-11-13
11:43 ---
Subject: Re: [4.3 regression] gfortran.dg/char_cshift_2.f90
fails with -O3 -funroll-loops fails on Intel Darwin
> bzip2 tar archive with four directories r42_O1, r42_O2, r43_O1, and r43
--- Comment #19 from paolo dot bonzini at lu dot unisi dot ch 2007-11-13
16:46 ---
Subject: Re: [4.3 regression] gfortran.dg/char_cshift_2.f90
fails with -O3 -funroll-loops fails on Intel Darwin
> [ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fschedule-insns -fregmove
> -fexp
--- Comment #25 from paolo dot bonzini at lu dot unisi dot ch 2007-11-14
13:24 ---
Subject: Re: [4.3 regression] gfortran.dg/char_cshift_2.f90
fails with -O3 -funroll-loops fails on Intel Darwin
> Yes, it does. Thanks a lot for the quick fix.
Note that even if the patch
--- Comment #6 from paolo dot bonzini at lu dot unisi dot ch 2007-11-21
12:51 ---
Subject: Re: [4.3 Regression] Segfault in df_chain_remove_problem
with -O3 on alpha
So it means the basic block has been deleted.
I want to see what happens if I consolidate all the
--- Comment #32 from paolo dot bonzini at lu dot unisi dot ch 2007-12-04
12:38 ---
Subject: Re: [4.3 Regression] Revision 119502
causes significantly slower results with 4.3 compared to 4.2
> The difference between 4.2 and 4.3 is not as big but is still there:
> 0.7s vs. 1.6s
--- Comment #1 from paolo dot bonzini at lu dot unisi dot ch 2006-03-06
14:35 ---
Subject: Re: New: [4.2 Regression] warning with cross
build
pinskia at gcc dot gnu dot org wrote:
> I get the following warnings when doing a cross (any kind of cross really)
> Makefile:13366: w
--- Comment #6 from paolo dot bonzini at lu dot unisi dot ch 2006-03-21
15:53 ---
Subject: Re: stage build no longer works
hjl at lucon dot org wrote:
> --- Comment #5 from hjl at lucon dot org 2006-03-21 15:09 ---
> When I make a backend change, "make"
--- Comment #24 from paolo dot bonzini at lu dot unisi dot ch 2006-03-31
07:37 ---
Subject: Re: [4.1/4.2 Regression] Insane amount
of compile-time / memory needed at -O1 and above
> Note that the regression is in 4.1, too, so we should consider backporting
> changes that accu
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-05-11 12:31 ---
Subject: Re: [4.1 Regression] More problems with simple type
names as superclasses
>I saw something like this before in a different bug.
>
It must have been PR21436, which I also re
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-05-24 11:59 ---
Subject: Re: poisoned ggc memory used for -ftree-vectorize
>Paolo, is the above solution ok with you? If so, I'll go ahead and prepare a
>patch. Alternatively, if ggc_collec
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-05-24 14:26 ---
Subject: Re: poisoned ggc memory used for -ftree-vectorize
>there are several places in loop opts that are not GGC-safe (in
>particular the tree nodes refered from loop structures are not
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2004-12-26 11:00 ---
Subject: Re: [4.0 Regression] Building in src dir fails
aoliva at gcc dot gnu dot org wrote:
> --- Additional Comments From aoliva at gcc dot gnu dot org 2004-12-23
>
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-01-19 12:55 ---
Subject: Re: [4.0 regression] missing ra.h
steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org 2005-01-19
> 12:26 ---
> ...and r
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-02-09 12:30 ---
Subject: Re: [4.0 Regression] Building in src dir fails
> I have considered doing this in the truly parallel way: namely, introducing
> HOST_SUBDIR to go along with BUILD_SUBD
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2004-11-18 08:03 ---
Subject: Re: ICE in do_jump, at dojump.c:274
> And that would mean it was caused by:
> * dojump.c (do_jump) TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR, COMPOUND_EXPR>:
>
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2004-11-23 08:19 ---
Subject: Re: [4.0 Regression] ABI breakage for 16-byte
vectors (non-Altivec ABI & ISA)
> patches committed
Thank you very much. Sorry for the misunderstandings.
Paolo
--
--- Comment #17 from paolo dot bonzini at lu dot unisi dot ch 2006-11-26
09:05 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory
fault(coredump)
I wonder if it is enough to just add DF_HARD_REGS in the df_i
--- Comment #23 from paolo dot bonzini at lu dot unisi dot ch 2006-11-30
19:18 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory
fault(coredump)
> I had an unexpected eye operation Tuesday and the vision
--- Comment #27 from paolo dot bonzini at lu dot unisi dot ch 2006-12-02
09:27 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory
fault(coredump)
dave at hiauly1 dot hia dot nrc dot ca wrote:
> --- C
--- Comment #29 from paolo dot bonzini at lu dot unisi dot ch 2006-12-02
17:38 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory
fault(coredump)
>> I'm pretty sure that's the same issue as t
--- Comment #16 from paolo dot bonzini at lu dot unisi dot ch 2006-12-06
09:58 ---
Subject: Re: sincos tree representation causes
extra addressable vars
> Paolo, are you working on this?
No. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
--- Comment #13 from paolo dot bonzini at lu dot unisi dot ch 2007-01-23
14:55 ---
Subject: Re: Top-level should pass GNATBIND, GNATLINK
and GNATMAKE variables down
>> True, they seem to be unused, but it's better to be consistent; for the same
>> reason I prefer
77 matches
Mail list logo
