--- Comment #25 from bonzini at gnu dot org 2008-10-28 16:28 ---
Subject: Re: [4.4 Regression] CPPFLAGS now unset for
stage 1 build of libcpp files.
You do know that A=B in the command line overrides A=C in the makefile
right? :-)
Does the patch work?
--
http://gcc.gnu.org
--- Comment #27 from bonzini at gnu dot org 2008-10-28 16:39 ---
Ah, I missed that. But yes, only libcpp/Makefile is supposed to have INCINTL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
--- Comment #2 from bonzini at gnu dot org 2008-10-29 07:17 ---
Subject: Re: [4.4 Regression] IRA generates slower
code for -mtune=core2
hjl dot tools at gmail dot com wrote:
> --- Comment #1 from hjl dot tools at gmail dot com 2008-10-29 05:44
> ---
> It looks
--- Comment #33 from bonzini at gnu dot org 2008-10-31 06:52 ---
> Since the problem is that libintl.h can't be found
No, the problem is that INCINTL is not set correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
--- Comment #5 from bonzini at gnu dot org 2008-11-01 14:26 ---
The problem is that this bug is unconfirmed. I'd like to see a failure log;
mingw builds were tested very carefully when we upgraded Libtool.
Marked as waiting.
--
bonzini at gnu dot org changed:
--- Comment #18 from bonzini at gnu dot org 2008-01-21 08:04 ---
I agree with Steven. The trimming could be adjusted to not trim register that
are mentioned by REG_EQ* notes, but I'm not sure it would be a good idea,
either.
--
bonzini at gnu dot org changed:
--- Comment #20 from bonzini at gnu dot org 2008-01-21 13:21 ---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
> I am testing a patch that add eq_notes to the lr problem if you specify
> DF_EQ_NOTES.
> If you and steven still want me to abandon this, i
--- Comment #26 from bonzini at gnu dot org 2008-01-21 14:54 ---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
Agreed. I think we'd better revert the patch now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #29 from bonzini at gnu dot org 2008-01-22 12:39 ---
target independent
--
bonzini at gnu dot org changed:
What|Removed |Added
Component|target
--- Comment #9 from bonzini at gnu dot org 2008-01-30 16:21 ---
patch committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC
--- Comment #13 from bonzini at gnu dot org 2008-02-07 10:09 ---
when was this approved? I think I have a better patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35049
--- Comment #14 from bonzini at gnu dot org 2008-02-07 13:11 ---
posted at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00212.html
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2008-02-07 15:19 ---
Indeed. I developed my 35049 patch in an old check-out (to avoid conflicts
with Doug's patch), but after updating the tree it fails for me too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35113
--- Comment #5 from bonzini at gnu dot org 2008-02-07 17:10 ---
Unrelated, but why couldn''t vector/vector shifts/rotates overload LSHIFT_EXPR
instead? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35004
--- Comment #10 from bonzini at gnu dot org 2008-02-13 08:44 ---
I doubt it is a 4.3 regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
--- Comment #26 from bonzini at gnu dot org 2008-02-19 15:00 ---
patch at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00775.html
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2008-02-20 07:55 ---
actually it is not a dup. but I do have a patch that will solve both.
--
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 #20 from bonzini at gnu dot org 2008-02-20 19:32 ---
Subject: Re: [4.1/4.2/4.3/4.4 regression] cross build's
libgcc picks up CFLAGS
ubizjak at gmail dot com wrote:
> --- Comment #19 from ubizjak at gmail dot com 2008-02-20 18:44 ---
> Patch at http://
--- Comment #21 from bonzini at gnu dot org 2008-02-21 08:13 ---
fixed in 4.4.0
--
bonzini at gnu dot org changed:
What|Removed |Added
Known to work|4.0.2
--- Comment #5 from bonzini at gnu dot org 2008-02-21 15:52 ---
I want to clear 17236 first (and Jakub's tweaks are needed anyway).
Feel free to beat me to it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
--- Comment #16 from bonzini at gnu dot org 2008-02-21 16:32 ---
So this line of add_builtin_function
tree libname = get_identifier (library_name);
should instead invoke a target hook (defaulting to get_identifier)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #22 from bonzini at gnu dot org 2008-02-22 08:25 ---
You can call it at the end of rs6000_init_builtins, something like
#ifdef SUBTARGET_INIT_BUILTINS
SUBTARGET_INIT_BUILTINS;
#endif
and in config/rs6000/darwin.h
#define SUBTARGET_INIT_BUILTINS darwin_patch_builtins
--- Comment #23 from bonzini at gnu dot org 2008-02-22 08:39 ---
No, the math functions optabs are only used to invoke
define_insns/define_expands, not to create libcalls. If the optab says there
is no insn, the original CALL_EXPR is expanded which uses the builtin's
ASSEMBLER
--- Comment #27 from bonzini at gnu dot org 2008-02-22 10:47 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
> but the Fortran front-end apparently doesn't benefit from it:
From what I understand, you have to rebuild libgfortran.
--- Comment #30 from bonzini at gnu dot org 2008-02-22 12:05 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
> (As a sidenote, there is one minor thing for which recompiling libgfortran is
> needed, and that's specific functions; I&
--- Comment #31 from bonzini at gnu dot org 2008-02-22 12:08 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
> Where the problem becomes serious is for languages such as fortran which has
> no
> direct way to access math.h. So fa
--- Comment #36 from bonzini at gnu dot org 2008-02-22 14:02 ---
I think you should use set_user_assembler_name instead of
SET_DECL_ASSEMBLER_NAME.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #37 from bonzini at gnu dot org 2008-02-22 14:03 ---
(Not that I knew that this morning, of course).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #39 from bonzini at gnu dot org 2008-02-22 14:36 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
>> I think you should use set_user_assembler_name instead of
>> SET_DECL_ASSEMBLER_NAME.
>
> Nope. Doing thi
--- Comment #43 from bonzini at gnu dot org 2008-02-22 15:08 ---
I don't think you have to be afraid. Note that with your patch there wouldn't
even be need to patch math.h -- in other words, your patch DTRT and it should
have been done this way ever since the feature was int
--- Comment #46 from bonzini at gnu dot org 2008-02-22 15:20 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
[off bugzilla]
I think FX is going to submit a patch soon.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #41 from bonzini at gnu dot org 2008-02-22 14:53 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
ubizjak at gmail dot com wrote:
> --- Comment #40 from ubizjak at gmail dot com 2008-02-22 14:49 ---
> This simple pr
--- Comment #37 from bonzini at gnu dot org 2008-02-27 17:05 ---
Subject: Re: [4.3/4.4 Regression] Revision 119502 causes
significantly slower results with 4.3/4.4 compared to 4.2
jacob at math dot jussieu dot fr wrote:
> --- Comment #36 from jacob at math dot jussieu dot
--- Comment #61 from bonzini at gnu dot org 2008-02-27 21:32 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
I think it depends on the version of mpfr that you have installed?
> Also I don't understand why there is a test for "
--- Comment #39 from bonzini at gnu dot org 2008-03-02 12:26 ---
Subject: Re: [4.3/4.4 Regression] Revision 119502 causes
significantly slower results with 4.3/4.4 compared to 4.2
> The problem still exists for the first two test cases.
> As I noted in comment #8 ther
--- Comment #8 from bonzini at gnu dot org 2008-03-05 13:21 ---
Should be handled by this code in simplify_subreg:
/* A SUBREG resulting from a zero extension may fold to zero if
it extracts higher bits that the ZERO_EXTEND's source bits. */
if (GET_COD
--- Comment #9 from bonzini at gnu dot org 2008-03-05 13:22 ---
> fwprop does not because the memory is written to
(and fwprop does not do alias analysis).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
--- Comment #6 from bonzini at gnu dot org 2008-03-07 07:09 ---
mine.
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Comment #29 from bonzini at gnu dot org 2008-03-07 08:26 ---
ira branch produces the same code as with my patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--- Comment #10 from bonzini at gnu dot org 2008-03-10 14:14 ---
I have a patch.
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #11 from bonzini at gnu dot org 2008-03-10 15:19 ---
The patch at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00623.html fixes
mul16.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2008-03-11 13:53 ---
The patch does not remove the --target option. It just causes the "real"
--target option (which is not equal to the host if we're building a cross) to
be passed down to gmp/mpfr.
Does this issue actuall
--- Comment #5 from bonzini at gnu dot org 2008-03-11 13:56 ---
Also, I would like to understand what does the "Some past versions of GMP used
`--target' incorrectly" part mean. Does it mean that those past versions
changed their configuration according to `--targ
--- Comment #12 from bonzini at gnu dot org 2008-03-11 16:49 ---
For 4.4, both mul16 and mul32 will be fixed by the pending patch.
The pending patch is what cures the regression part of this bug.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #6 from bonzini at gnu dot org 2008-03-12 09:00 ---
testing
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #7 from bonzini at gnu dot org 2008-03-12 12:50 ---
The expand patch does not bootstrap, even with the tweaks Jakub suggested.
I'm also hesitant to fold it on the tree level because it's actually undefined
code unless -fwrapv. For example if a = b = 65536LL,
--- Comment #8 from bonzini at gnu dot org 2008-03-12 12:56 ---
Hmm maybe I can go through an unsigned type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
--- Comment #9 from bonzini at gnu dot org 2008-03-12 15:34 ---
fixed in 4.4
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from bonzini at gnu dot org 2008-03-13 10:46 ---
has already been reported and fixed
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from bonzini at gnu dot org 2008-03-14 17:32 ---
yes, there's actually no testcase.
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #32 from bonzini at gnu dot org 2008-03-14 17:40 ---
Yes, I don't remember if it was committed before or after the branchpoint...
:-(
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #18 from bonzini at gnu dot org 2008-03-14 20:05 ---
The NSS testcase has been fixed, but we found that the committed fix just made
the bug latent. We don't have a failing testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
e-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
--- Comment #1 from bonzini at gnu dot org 2008-03-19 15:51 ---
Created an attachment (id=15344)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15344&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #7 from bonzini at gnu dot org 2008-03-20 13:51 ---
Indeed my patch exposes additional vectorization abilities (which was
unexpected).
Kenny, can you run the failing testcase under valgrind?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
--- Comment #9 from bonzini at gnu dot org 2008-03-20 14:07 ---
Subject: Re: heisenbug in tree vectorizer
> I would suggest that you go roll back to that release mentioned in
> message 1, where you have exactly the same code base for bootstrapped
> and non bootstrapped com
--- Comment #1 from bonzini at gnu dot org 2008-03-27 14:27 ---
my build patches are innocent :-)
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2008-03-31 17:53 ---
Patch seems fine, but before approving it I would like a description of why
"tries to [...] relink itself" (important part is *re*link itself), and that
description should also go in exec-tool.in.
Thanks!
--- Comment #10 from bonzini at gnu dot org 2008-04-01 07:08 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap
hjl dot tools at gmail dot com wrote:
> --- Comment #5 from hjl dot tools at gmail dot com 2008-03-31 18:16
> --
--- Comment #12 from bonzini at gnu dot org 2008-04-01 11:21 ---
I think there are two bugs. One is the infinite loop, and H.J.'s patch is
"masking" it by patching gcc/exec-tool.in (which is why I'd prefer to have the
"masking" in ld/Makefile.am). The
--- Comment #14 from bonzini at gnu dot org 2008-04-01 11:54 ---
hm, I see now. H.J. hold on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #16 from bonzini at gnu dot org 2008-04-01 12:08 ---
> The stage 1 ld works as far as linking the stage 1 gcc which is directly after
> it. It's only when we get to stage 2 that things break.
This is a red herring. stage 1 ld goes through the same relink proc
--- Comment #18 from bonzini at gnu dot org 2008-04-01 12:33 ---
Created an attachment (id=15402)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15402&action=view)
my version of H.J.'s patch
I think this is the right way to do it, more or less.
Can anyone test it? (
--- Comment #20 from bonzini at gnu dot org 2008-04-01 13:49 ---
if it reaches the end of ld compilation in stage2, that's already enough. (and
less than 4 hours).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #23 from bonzini at gnu dot org 2008-04-01 15:36 ---
and if you modify collect-ld manually to set it to yes?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #27 from bonzini at gnu dot org 2008-04-01 15:42 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap
oblivian at users dot sourceforge dot net wrote:
> --- Comment #24 from oblivian at users dot sourceforge dot net
&
--- Comment #30 from bonzini at gnu dot org 2008-04-01 16:11 ---
Created an attachment (id=15409)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15409&action=view)
new patch
@Ralf: yes, I understood that (I just wanted to understand if the failure was
just that my way of
--- Comment #14 from bonzini at gnu dot org 2008-04-02 09:57 ---
committed to trunk as 133828
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from bonzini at gnu dot org 2008-04-02 09:57 ---
committed to trunk, will backport to 4.3 in due time (causes regressions for
AVR)
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #35 from bonzini at gnu dot org 2008-04-02 10:08 ---
the infinite loop is fixed, don't know if the second bug remains.
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #15 from bonzini at gnu dot org 2008-04-02 11:24 ---
oops, still on 4.3
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #38 from bonzini at gnu dot org 2008-04-02 13:59 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap with --enable-shared
> I'll be opening a new bug on the sysroot problems I'm having with 4.3 since it
> app
--- Comment #11 from bonzini at gnu dot org 2008-04-02 14:08 ---
Carlos, I think Greg has a point here:
> the problem is that xgcc thinks it is a relocated compiler when it
> runs from $objdir eg: when building libgcc* and other target libs, when in
> actual fact, it is not
--- Comment #5 from bonzini at gnu dot org 2008-04-02 15:25 ---
I meant that this is a patch that is scheduled for backporting to 4.3, because
it fixes regressions on AVR.
The text between parentheses should have been "bug causes regressions for AVR".
Sorry.
--
http://g
--- Comment #13 from bonzini at gnu dot org 2008-04-02 20:27 ---
Subject: Re: Native GCC no longer searches $prefix/lib for startfiles when run
from $objdir
> What's the test-case?
I'm talking of Greg's setting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
--- Comment #7 from bonzini at gnu dot org 2008-04-05 08:53 ---
this was fixed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #50 from bonzini at gnu dot org 2008-04-08 15:00 ---
I guess that you had modified the precedences in order to allow additional
simplifications. Can you report here what is missed using the current values?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #52 from bonzini at gnu dot org 2008-04-08 19:07 ---
Subject: Re: [4.2 Regression] Performace problem with
indexed load/stores on powerpc
> Index: explow.c
> ===
> --- explow.c(revisi
--- Comment #11 from bonzini at gnu dot org 2009-02-01 08:07 ---
still present.
--
bonzini at gnu dot org changed:
What|Removed |Added
Last reconfirmed|2008-03-25 03
--- Comment #48 from bonzini at gnu dot org 2009-02-01 08:14 ---
Fixed on the trunk with the original testcase:
4.2 -O2 0m13.897s
4.2 -O3 miscompiled
4.4 -O2/-O3 0m8.714s
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from bonzini at gnu dot org 2009-02-02 08:26 ---
Subject: Re: [4.2/4.3 Regression] NULL pointers
always considered distinct by PTA, even with -fno-delete-null-pointer-checks
rguenth at gcc dot gnu dot org wrote:
> --- Comment #15 from rguenth at gcc dot gnu
--- Comment #10 from bonzini at gnu dot org 2009-02-03 09:45 ---
How is it now?
--
bonzini at gnu dot org changed:
What|Removed |Added
CC
--- Comment #10 from bonzini at gnu dot org 2009-02-03 09:47 ---
Can you try the patch of PR38824?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #14 from bonzini at gnu dot org 2009-02-03 09:49 ---
What about canonicalizing to a *positive* number?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2009-02-03 11:11 ---
caused by r90059 (convert_nontype_argument rewrite). Giovanni, do you have
time to see if the patch I made makes sense?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #12 from bonzini at gnu dot org 2009-02-03 11:17 ---
What if we forbid altogether memory operands and we *synthesize* them with a
peephole2? Anyway, it seems safe to me to declare this a dup of PR38824?
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #6 from bonzini at gnu dot org 2009-02-03 13:58 ---
News?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37437
--- Comment #2 from bonzini at gnu dot org 2009-02-03 14:00 ---
Is this a regression? I don't see anything in the patches or in their
description that would prevent a backport to 4.4.
--
bonzini at gnu dot org changed:
What|Removed |
--- Comment #34 from bonzini at gnu dot org 2009-02-03 14:02 ---
Is this still a 4.4 regression?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #13 from bonzini at gnu dot org 2009-02-03 14:23 ---
Adjusting subject, the testcase from comment #2 still produces suboptimal code.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #14 from bonzini at gnu dot org 2009-02-03 14:30 ---
what remains is a dup of 22141.
*** This bug has been marked as a duplicate of 22141 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from bonzini at gnu dot org 2009-02-03 14:30 ---
*** Bug 37135 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084
--- Comment #12 from bonzini at gnu dot org 2009-02-03 14:56 ---
Maybe we can approach the problem from the other side, for example marking I/O
functions as cold, or marking I/O functions as cold so that
PRED_FLAG_FIRST_MATCH hits in predict.def?
--
bonzini at gnu dot org changed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #8 from bonzini at gnu dot org 2009-02-03 15:09 ---
Great.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from bonzini at gnu dot org 2009-02-03 15:15 ---
No, the patch does not fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
501 - 600 of 1283 matches
Mail list logo
