ing rules, according to g++
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
--- Comment #14 from guillaume dot melquiond at ens-lyon dot fr 2007-09-02
11:56 ---
Created an attachment (id=14150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14150&action=view)
Implements folding of "(&function & 1)"
I encountered the same issue
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33103
from compiler
optimizations
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond a
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31549
--- Comment #1 from guillaume dot melquiond at ens-lyon dot fr 2007-04-11
09:43 ---
As a follow-up, it seems the wrong code is generated during the "combine" pass:
the RTL after the "life1" pass is still correct: "(-b) * a + c" (whether
-frounding-math is
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31530
--- Comment #95 from guillaume dot melquiond at ens-lyon dot fr 2007-04-03
17:51 ---
> I think that Uros' patch to add a -mpc switch for precision control would
> "fix" this.
> The real fix would be to automatically insert fldcw instructions before
> float/
mbols
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
http://gcc.gn
--- Comment #1 from guillaume dot melquiond at ens-lyon dot fr 2007-03-20
11:22 ---
I just encountered another instance of a missing typename diagnostic. This time
with a different message, so I add it here for completeness:
a.cpp:5: error: dependent-name T::#typename_type not
ot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
--- Comment #4 from guillaume dot melquiond at ens-lyon dot fr 2007-01-04
11:25 ---
Just for the sake of completeness. Wrong code is also generated when addition
and multiplication are mixed, because of distributivity:
int f(int a)
{
if (a > 0x7FF0) return 0;
int b = (a -
--- Comment #1 from guillaume dot melquiond at ens-lyon dot fr 2007-01-04
10:15 ---
Is it really a middle-end issue?
It could also be seen as a front-end issue, as it does produce "a + b - 40",
doesn't it? If the front-end had given "(a - 20) + (b - 20)" to
signedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
--- Comment #15 from guillaume dot melquiond at ens-lyon dot fr 2006-11-13
09:41 ---
Actually, not only is it wrong-code, but this is also a regression (see
PR29538). Programs using interval arithmetic that were working fine when
compiled with GCC 3.3 are broken now.
--
http
--- Comment #13 from guillaume dot melquiond at ens-lyon dot fr 2006-11-13
08:45 ---
Unless I'm mistaken, the patch has only been applied to the trunk and not to
the branches, in particular not to the current release series. Shouldn't this
bug-report, either be reopened un
unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29538
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29042
--- Comment #3 from guillaume dot melquiond at ens-lyon dot fr 2006-08-25
08:34 ---
> Which looks ok if we are passing via value but since we need to pass by
> reference, the middle-end thinks we need a new stack space for it because it
> does not know that D.1992 is not used
pass-by-value parameter
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon
--- Comment #16 from guillaume dot melquiond at ens-lyon dot fr 2006-06-08
06:35 ---
Sorry if I'm misunderstanding your patch (I didn't try it), but it seems to me
that GCC will still generate wrong code if the testcase is compiled with
-fwrapv -fno-trapv.
--
http://g
--- Comment #2 from guillaume dot melquiond at ens-lyon dot fr 2006-04-28
09:03 ---
I tried setting the nonnull attribute, it indeed allowed the optimization. In
particular, codes containing dynamic casts are now straight lines. This is a
nice improvement. Unfortunately GCC was not
is; }
--
Summary: "this" pointer is not assumed to be not null
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #5 from guillaume dot melquiond at ens-lyon dot fr 2006-04-16
18:15 ---
I have tried to look at why it fails. Here are my observations. The function
gcc/expr.c:emit_block_move tries to expand a movmem pattern. The backend
refuses, since a call to memcpy would be a lot more
--- Comment #9 from guillaume dot melquiond at ens-lyon dot fr 2006-04-12
05:28 ---
> This is undefined only if b is known to be negative otherwise it is defined.
What is undefined? The value of "b" does not matter here. As soon as "a" is
INT_MAX, the
--- Comment #7 from guillaume dot melquiond at ens-lyon dot fr 2006-04-11
15:55 ---
> I disagree. Could you give an explicit example?
Sorry, my mistake, I should not have suggested this testcase: this optimization
is indeed fine (yet GCC 4.1 does not apply it). The following testc
--- Comment #3 from guillaume dot melquiond at ens-lyon dot fr 2006-04-06
13:05 ---
> for -march=i{345}86 I get
> for -march=i686,pentium2,... I get
Thanks to your tests, I noticed that the change of behavior between GCC 3.4
versions was actually caused by the addition of --wit
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27055
--- Comment #36 from guillaume dot melquiond at ens-lyon dot fr 2006-04-06
10:59 ---
The generated code is getting both better and worse. I just tested with GCC
4.1, and there is now a byte-by-byte (!) copy instead of memcpy. So not only
does GCC use superfluous copies, but it
--- Comment #3 from guillaume dot melquiond at ens-lyon dot fr 2006-04-05
08:59 ---
Since the runtime slowdown between the binaries produced by GCC3 and GCC4 was
not negligible, I did search a bit more for workarounds. It was quite simple in
fact: passing -mno-sse produced assembly
--- Comment #2 from guillaume dot melquiond at ens-lyon dot fr 2006-03-21
15:27 ---
> But using the *ps variants on an SSE1 target is ok - the xmm
> registers are just used as temporary storage.
I can't really think of situations where it makes sense. If this a temporary
middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
--- Comment #11 from guillaume dot melquiond at ens-lyon dot fr 2005-11-25
08:31 ---
Your testcases are too minimal. The issue lies in the diagnostic, when there is
a compilation error involving an anonymous enumeration. In the original
bug-report, GCC was trying to delete a file
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24560
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2005-09-25 08:49 ---
Created an attachment (id=9803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9803&action=view)
Trivial fix
The error message is a bit better now:
a.cpp:3: error: no match for &#
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24052
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2005-09-22 20:16 ---
Created an attachment (id=9793)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9793&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24020
ssive (x20) stack usage for 4.0 with -O3
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at en
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2005-09-20 05:07 ---
Created an attachment (id=9779)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9779&action=view)
Remove gratuitous calls to _S_get_pool in __mt_alloc
Since I didn't find an
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2005-09-18 21:54 ---
Some additional information. Looking through the CVS log, it appears the
__mt_alloc constructors were empty in GCC 3.4, and they were filled when fixing
PR 17780. The patch was huge and the log
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
CC: gcc-bugs at gcc dot gnu dot
mponent: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23869
ent: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23756
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2005-08-26 17:38 ---
> all of 3.4 and 4.1 produce exactly two temporaries.
Yet I said that g++ 3.4 did not produce any temporary, and I still think so. No
temporaries, only g's stack frame. See the f
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2005-08-14 06:45 ---
Looking at it again, I found an even worse regression with respect to g++ 3.4.
Consider this testcase:
struct A { int a[1000]; }
A f();
void g(A);
void h() { g(f()); }
Ideally, h will allocate
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2004-08-24 12:49 ---
Bugzilla complains each time I'm trying to attach the test-case. So here is an URL.
http://perso.ens-lyon.fr/guillaume.melquiond/divers/bug.ii.bz2
Sorry for the inconvenience.
--
47 matches
Mail list logo
