--- Comment #60 from giovannibajo at libero dot it 2008-06-10 17:26 ---
If a knowledgable GCC developer could suggest *any* workaround at -O1 for this
bug in 4.2 (including disabling whatever alias analysys causes the problem), it
might be proposed as a fix within distros at least
--- Comment #56 from giovannibajo at libero dot it 2008-05-21 15:49 ---
What is the workaround for this bug? It looks like not even -O1 fixes the
compile-time hog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
--- Comment #6 from giovannibajo at libero dot it 2007-10-09 16:15 ---
Scratch that, sorry, "svn info" wouldn't convey the correct info. You need to
use svn log to roughly convert between dates and revnums.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
--- Comment #5 from giovannibajo at libero dot it 2007-10-09 16:14 ---
After each merge command, use "svn info" to identify the unique revision number
to which those dates correspond. You can then use the same "svn merge" with
revision number to furt
--- Comment #44 from giovannibajo at libero dot it 2007-09-11 10:59 ---
Daniel, are you then going to fix the "slow" part of this bug?
As for the memhog, CC'ing Honza which is expert on memory allocations and leaks
:)
--
giovannibajo at libero dot it changed:
--- Comment #25 from giovannibajo at libero dot it 2007-09-05 06:47 ---
Daniel, can we backport this patch to 4.2, please? It's a P1 regression!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
--- Comment #15 from giovannibajo at libero dot it 2007-07-16 13:39 ---
ping: anything that can be done for 4.2.1? This is a really serious regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
--- Comment #13 from giovannibajo at libero dot it 2007-05-01 02:11 ---
(In reply to comment #2)
> Hmm,
> typedef typed_slot_rep typed_slot;
> typed_slot *typed_rep = static_cast(rep);
> return (typed_rep->functor_)();
>
> This code could
--- Comment #18 from giovannibajo at libero dot it 2007-04-10 15:34 ---
(In reply to comment #15)
> Yes, the tendency to handle far too many items as 16 bits (the
> sizeof(int) on that machine) when 8 bits would suffice is one of the
> major issues the AVR-GCC users have
--- Comment #7 from giovannibajo at libero dot it 2007-04-02 22:47 ---
Anatoly, can you have a look? It's a regression in 4.2 for AVR!
--
giovannibajo at libero dot it changed:
What|Removed |
--- Comment #4 from giovannibajo at libero dot it 2007-01-05 00:37 ---
Thanks Ira. What about store with gaps?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438
--- Comment #2 from giovannibajo at libero dot it 2006-04-12 22:25 ---
RTH, this bug is very serious for OpenMP and C++. Can you please have a look?
--
giovannibajo at libero dot it changed:
What|Removed |Added
--- Comment #28 from giovannibajo at libero dot it 2006-02-18 14:48 ---
Jakub, you have provided some infrastructure to compute object size and provide
warnings for unsafe use of builtins. Do you believe that infrastructure could
be reused/enhanced for this bug?
--
giovannibajo at
--- Comment #7 from giovannibajo at libero dot it 2005-12-24 21:53 ---
This is by design. It's out typeof() implementation works. It has pros and
cons. See this link (and followups) for papers about this.
http://gcc.gnu.org/ml/gcc/2005-01/msg01642.html
--
giovannibajo at liber
--- Comment #7 from giovannibajo at libero dot it 2005-12-04 23:17 ---
Further bonus points if you can spot which function is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #1 from giovannibajo at libero dot it 2005-12-02 12:43 ---
This is a FAQ. You need the accompanying definition for static member
variables, irrespective of the use of an initialization on the declaration.
--
giovannibajo at libero dot it changed:
What
--- Comment #10 from giovannibajo at libero dot it 2005-11-30 09:52 ---
Jeff, did you backport the patch to the 4.1 branch? I don't see the commit
there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
--- Comment #4 from giovannibajo at libero dot it 2005-11-28 13:01 ---
Out of curiosity, can you show the code before and after Paolo's patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
--- Comment #12 from giovannibajo at libero dot it 2005-11-27 23:38 ---
Thanks Volker
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15938
--
giovannibajo at libero dot it changed:
What|Removed |Added
Summary|Python miscompilation - TOC |[4.0 Regression] Python
|reload
--- Comment #9 from giovannibajo at libero dot it 2005-11-14 00:30 ---
Mark, do you believe that the introduction of COMPOUND_LITERAL_EXPR in the C++
frontend could be feasable for 4.1?
--
giovannibajo at libero dot it changed:
What|Removed |Added
--- Comment #2 from giovannibajo at libero dot it 2005-11-02 09:20 ---
Template parameters can't be used in friend declarations (nor in any elaborated
type specifier construct).
--
giovannibajo at libero dot it changed:
What|Removed |
--- Comment #17 from giovannibajo at libero dot it 2005-10-14 18:54 ---
Danny, is it possible to have a less invadent fix for the 4.0 branch? Something
hackish that can get the bug fixed just for the branch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
--- Comment #19 from giovannibajo at libero dot it 2005-10-11 22:57 ---
(In reply to comment #16)
> > Probably. But what if the problem with dereferencing p was that it is NULL,
> > instead of a misalignment? Would that case be caught in reorg by something
> > else?
--- Comment #15 from giovannibajo at libero dot it 2005-10-11 17:16 ---
Probably. But what if the problem with dereferencing p was that it is NULL,
instead of a misalignment? Would that case be caught in reorg by something
else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
--- Comment #7 from giovannibajo at libero dot it 2005-10-11 13:43 ---
Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that
either branch must not be evaluated because it could be illegal; if you hoist a
mem from a branch into the delay slot of the condition
--- Comment #9 from giovannibajo at libero dot it 2005-10-06 06:44 ---
The patch was rejected. Not working on this anymore.
--
giovannibajo at libero dot it changed:
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-09-20
12:34 ---
Yes, this is how C++ works. There is no template argument deduction from
constructors.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-09-12
10:08 ---
The problem is that the gimplifier always want the index field of the
constructor element to be filled. If you fix that in the obvious way (so
that "no index" means "previous index + 1&
--- Additional Comments From giovannibajo at libero dot it 2005-09-05
23:28 ---
Not yet, I still have to find some time to commit the patch. It will be fixed
in GCC 4.1 and GCC 4.0.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23437
--- Additional Comments From giovannibajo at libero dot it 2005-09-04
11:19 ---
Roger, want to have a look at this?
--
What|Removed |Added
CC
--- Additional Comments From giovannibajo at libero dot it 2005-08-19
18:06 ---
Patch posted, waiting for review:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01169.html
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-08-19
16:28 ---
If there was a voting system in this Bugzilla, I'd vote for this. It's a very
useful feature in embedded programming. I also believe that it could be enabled
by default in GNU C, since it's
--- Additional Comments From giovannibajo at libero dot it 2005-08-18
00:42 ---
Yes, I posted a patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01678.html
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-08-17
22:13 ---
Dumdelidum...
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From giovannibajo at libero dot it 2005-08-17
21:59 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From giovannibajo at libero dot it 2005-08-13
18:00 ---
Why doesn't this happen with the copy constructor, then? there we should be
calling the copyctor with *a, which would have the same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
--- Additional Comments From giovannibajo at libero dot it 2005-08-13
10:01 ---
One thing is that if 'a' and 'b' are originally pointers of the same type, it
should be clear the the loop can be removed. When they are lowered to integers,
instead, we lose th
--- Additional Comments From giovannibajo at libero dot it 2005-08-12
12:58 ---
Can you document what's the compile-time effect of raising salias-max-array-
elements? For instance, how much do we lose in bootstrap+tramp3d if we raise it
to 16 or even 1024?
--
http://gcc.gn
--
What|Removed |Added
Summary|ICE: verify_ssa failed -|ICE with vectorizer:
|definition does not dominate|verify_ssa failed -
|us
--- Additional Comments From giovannibajo at libero dot it 2005-08-12
09:35 ---
Sure, but it's a good start. I read on http://gcc.gnu.org/wiki/BerndSchmidt
that the reload-branch would need some testing/fixing on autoinc target. Maybe
Joern might be interested in giving a look
--- Additional Comments From giovannibajo at libero dot it 2005-08-11
22:50 ---
Yes, the concept of "used" and "put in a specific section" should be kept
separate. I'm sure that it might be overloaded for specific variables in
specific applications, but I can
--- Additional Comments From giovannibajo at libero dot it 2005-08-11
17:13 ---
I don't think the hack should be removed until a verifier is committed,
otherwise we could still get wrong code for other yet-to-be-fixed cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23329
--- Additional Comments From giovannibajo at libero dot it 2005-08-11
17:05 ---
Bernd, do you believe this is taken care of by the reload branch?
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-08-10
13:52 ---
Please read:
http://gcc.gnu.org/gcc-3.4/changes.html
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-08-10
13:49 ---
No testcase was added, so reopening this until the testcase is committed.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-08-10
11:25 ---
Small testcase from PR 23313, showing ICE on invalid:
-
int main(){
int i;
asm (
"xorl %%ebp, %%ebp\n\t"
"movl %0, %%ebp\n\t
--- Additional Comments From giovannibajo at libero dot it 2005-08-09
23:12 ---
So, using limit 0 for when calculating the integer mode for the size would fix
the regression on sh?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23290
--- Additional Comments From giovannibajo at libero dot it 2005-07-28
10:26 ---
Fixed also for GCC 3.4.5.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From giovannibajo at libero dot it 2005-07-28
10:25 ---
Fixed also for GCC 3.4.5.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From giovannibajo at libero dot it 2005-07-28
10:25 ---
Fixed also for GCC 3.4.5.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From giovannibajo at libero dot it 2005-07-28
10:24 ---
Fixed also for GCC 3.4.5.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From giovannibajo at libero dot it 2005-07-28
10:24 ---
Fixed also for GCC 3.4.5.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 17993 depends on bug 19885, which changed state.
Bug 19885 Summary: [4.0/4.1 Regression] avr dwarf-2 support is broken for head
4.0/4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
What|Old Value |New Value
-
--
Bug 19087 depends on bug 19885, which changed state.
Bug 19885 Summary: [4.0/4.1 Regression] avr dwarf-2 support is broken for head
4.0/4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
What|Old Value |New Value
-
--
Bug 17994 depends on bug 19885, which changed state.
Bug 19885 Summary: [4.0/4.1 Regression] avr dwarf-2 support is broken for head
4.0/4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
What|Old Value |New Value
-
--- Additional Comments From giovannibajo at libero dot it 2005-07-27
23:37 ---
Fixed for GCC 4.0.2 and GCC 4.1.0.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From giovannibajo at libero dot it 2005-07-27
08:56 ---
This is the patch RTH already approved for head and 4.0:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01899.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
--- Additional Comments From giovannibajo at libero dot it 2005-07-27
08:54 ---
Bjorn, do you have a copyright assignment filed with the FSF?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
--- Additional Comments From giovannibajo at libero dot it 2005-07-26
16:39 ---
The testcase in PR18602 does not cause a segfault anymore for GCC 3.4 CVS. Is
this bug fixed then? Or do we need a new testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18462
--- Additional Comments From giovannibajo at libero dot it 2005-07-26
09:46 ---
What is the value of 'type' when error() is called?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19932
--- Additional Comments From giovannibajo at libero dot it 2005-07-25
22:17 ---
Downgrading to normal. This is a bug in a C++ extension (borrowed from C99)
which has been broken since 3.0.
The bug appears to be in the FINISH_COND macro which does not seem ready to
handle the
--- Additional Comments From giovannibajo at libero dot it 2005-07-25
21:43 ---
Works for me too on today's 3.4 branch. No feedback in 3 months.
--
What|Removed |
--- Additional Comments From giovannibajo at libero dot it 2005-07-25
21:13 ---
Fixed in GCC 3.4.5 too.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From giovannibajo at libero dot it 2005-07-25
20:41 ---
Patch posted for 3.4:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01653.html
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-07-24
12:40 ---
Can you measure how much memory do all the overload nodes take in the big
testcases? Theoretically, an OVERLOAD could measure 8 bytes or so (on 32 bit
systems). So we currently waste more than 100 bytes
--- Additional Comments From giovannibajo at libero dot it 2005-07-23
21:37 ---
Thanks Steve!
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From giovannibajo at libero dot it 2005-07-21
16:59 ---
It would greatly help to identify the patch that broke either this PR or PR
22513. One possible offender is the new alias stuff by Diego/Daniel.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-07-21
15:32 ---
It might indeed be obsolete code: I don't think you can currently create an
union (or a record) with only unnamed fields. If you want to purse this
further, you could regtest changing this:
--- Additional Comments From giovannibajo at libero dot it 2005-07-21
13:28 ---
http://gcc.gnu.org/gcc-3.4/changes.html
--
What|Removed |Added
Status
--- Additional Comments From giovannibajo at libero dot it 2005-07-21
13:18 ---
=
typedef union
{
struct { int i; };
struct { char c; };
} A;
A a = { 0 };
A b = {{ 0 }};
A c = {{{ 0 }}}; // { dg-error "b
--- Additional Comments From giovannibajo at libero dot it 2005-07-21
02:08 ---
Does ICC put this in .rodata?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22575
--- Additional Comments From giovannibajo at libero dot it 2005-07-21
01:51 ---
Yes, it's because of my patch.
I would like to know if we agree that the code is invalid or not. It's a bit
hard to have a definitive answer since it is GNU C++ (uses an extension), but
given
--- Additional Comments From giovannibajo at libero dot it 2005-07-21
01:01 ---
Created an attachment (id=9313)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9313&action=view)
Proposed patch
Can you test this patch please?
--
What|
--- Additional Comments From giovannibajo at libero dot it 2005-07-20
18:22 ---
Absolutely not! There is no "best" way: sometimes it is better to go through
the typedef, sometimes it is better to print the typedef.
To tell you the truth, I consider the fact that GCC pri
--- Additional Comments From giovannibajo at libero dot it 2005-07-20
17:32 ---
OK thanks. But let me stress one point:
> IMHO the graphs suggest that the daily bugfixes increased the
> compilation time day after day.
In those days, we added something like 20 new projects to GC
--- Additional Comments From giovannibajo at libero dot it 2005-07-20
09:53 ---
Try again with GCC 3.4.4, and come back to us. You should always try the latest
version of the compiler line you're using, otherwise we could all be wasting
time on the bug report.
--
--- Additional Comments From giovannibajo at libero dot it 2005-07-20
08:15 ---
Of course: March 1st is when GCC went back to Stage 1. There have been dozen
and dozen of projects contributed for GCC 4.1, and probably some still require
tuning.
The best way to attack this is to find
--- Additional Comments From giovannibajo at libero dot it 2005-07-16
19:15 ---
Might be latent in HEAD
--
What|Removed |Added
CC
--- Additional Comments From giovannibajo at libero dot it 2005-07-16
09:52 ---
I guess a reduced testcase might help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22504
--- Additional Comments From giovannibajo at libero dot it 2005-07-09
15:48 ---
This will likely change to an ICE in varasm.c after my CONSTRUCTOR patch goes
in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20063
--- Additional Comments From giovannibajo at libero dot it 2005-07-07
23:01 ---
Notice that this is just a QoI issue, as the standard explicitly says that no
diagnostic is required for this violation. Marking as enhancement.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-07-07
20:52 ---
I think Andres is right: what if C's constructor calls f() (only the first time
it is invoked)?
I believe this bug is invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22355
--- Additional Comments From giovannibajo at libero dot it 2005-07-07
00:20 ---
Thus, we have a regression in 4.0. The regression does not show in 4.1, but
it's unclear whether it was fixed or it is just hidden by the different code
produced with the new tree passes.
The compile
--- Additional Comments From giovannibajo at libero dot it 2005-07-06
22:35 ---
I reopen the bug so we don't forget about this for 4.0.2.
Stephen, to clarify: we know that this is indeed a bug, and this is why it
*was* fixed for 4.1. The fact is that the 4.0 serie is already out
--- Additional Comments From giovannibajo at libero dot it 2005-07-05
23:17 ---
Approved here already:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00293.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963
--- Additional Comments From giovannibajo at libero dot it 2005-07-05
23:16 ---
Zdenek, is the patch still valid? If so, maybe it's time to ping it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963
--- Additional Comments From giovannibajo at libero dot it 2005-07-04
15:34 ---
To produce a testcase, you could try extracting the routine that is miscompiled
and attach it to this bug (in a compilable form, so preprocessed with all
needed headers). I believe the GIMP folk can help
--- Additional Comments From giovannibajo at libero dot it 2005-07-02
19:10 ---
Can we get a preprocessed/reduced source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22279
--- Additional Comments From giovannibajo at libero dot it 2005-07-02
11:00 ---
Provide a preprocessed testcase, this bug might be target-independent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22276
--- Additional Comments From giovannibajo at libero dot it 2005-06-30
18:27 ---
It's there: -Wsequence-point, which is also enabled by -Wall.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22248
--- Additional Comments From giovannibajo at libero dot it 2005-06-30
18:09 ---
It does.
--
What|Removed |Added
BugsThisDependsOn||21963
http
--- Additional Comments From giovannibajo at libero dot it 2005-06-30
18:08 ---
I wonder why it's not caught by a tree verifier then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22253
--- Additional Comments From giovannibajo at libero dot it 2005-06-30
17:58 ---
Also you could simply use std::swap as Gaby suggested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22248
--- Additional Comments From giovannibajo at libero dot it 2005-06-29
22:04 ---
Created an attachment (id=9175)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9175&action=view)
Current CONSTRUCTOR patch
As per Steven's request in private mail, I attach the current p
nitializer weirdness
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: fortran
AssignedTo: stevenb at suse dot de
ReportedBy: giovannibajo at libero dot it
CC:
--- Additional Comments From giovannibajo at libero dot it 2005-06-22
01:24 ---
For mainline, my patch has to be reworked as suggested by Jason in the review.
It is not a difficult work, but I am working on another couple of big patches
so don't hold your breath.
As for the re
--- Additional Comments From giovannibajo at libero dot it 2005-06-21
00:19 ---
Does my patch for 8271 fix this bug? If so, whatever caused this might just
have exposed the problem, and fixing 8271 would fix this as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
--- Additional Comments From giovannibajo at libero dot it 2005-06-21
00:10 ---
Doesn't -fmudflap handle this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
--
What|Removed |Added
Attachment #9108|text/x-cpp |text/plain
mime type||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22114
1 - 100 of 601 matches
Mail list logo
