--- Comment #1 from igodard at pacbell dot net 2006-02-05 06:21 ---
Created an attachment (id=10780)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10780&action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26100
The attached code does various things with a type ("inv") that increments a
count on constructor calls and decrements on destructor calls. As there are no
declarations of this type, only temporaries, the net should be zero at the end
of each statement. Unfortunately, the count goes negative.
Ivan
--- Comment #25 from gdr at integrable-solutions dot net 2006-02-05 04:00
---
Subject: Re: gcc lays down two copies of constructors
"pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes:
| But that does not work for some assemblers/file formats (like Darwin) as
| Darwin's as
--- Comment #24 from gdr at integrable-solutions dot net 2006-02-05 03:58
---
Subject: Re: gcc lays down two copies of constructors
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| I don't feel that this PR should be suspended, at least not until we
| have fixed the common case.
--- Comment #6 from gdr at integrable-solutions dot net 2006-02-05 03:56
---
Subject: Re: support for type traits is not available
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The interest should really go to the committe than one
| implementation. Now GCC can add
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-05 03:55 ---
The patch I am testing right now:
Index: tree-cfg.c
===
--- tree-cfg.c (revision 110536)
+++ tree-cfg.c (working copy)
@@ -1108,7 +1108,8 @@ cleanup_d
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-05 03:30 ---
In cleanup_dead_labels, we forget to check if the label's address has been
taken. The reason why this works with a C example is because the labels are
not marked as artificial.
Fixing it now.
--
http://gcc.gnu
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-05 03:25 ---
I am going to take this one over. Final_cleanup is removing the labels for
some reason. Will look more into why it is removing them.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from kargl at gcc dot gnu dot org 2006-02-05 03:10 ---
Created an attachment (id=10779)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10779&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-02-05 00:55
---
For future reference:
a patch which would fix this:
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00354.html
Previous discussions about this issue:
http://gcc.gnu.org/ml/gcc/2002-12/msg00474.html
More about the pa
--- Comment #22 from ian at airs dot com 2006-02-05 00:42 ---
The fact that it does not work everywhere is not a valid reason that it should
not be implemented where it can work, particularly since the places where it
can work are, as it happens, most places.
--
http://gcc.gnu.org/b
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-02-05 00:27
---
Subject: Re: gcc lays down two copies of constructors
On Feb 4, 2006, at 7:20 PM, ian at airs dot com wrote:
>
>
> --- Comment #20 from ian at airs dot com 2006-02-05 00:19 ---
> In many common cases,
On Feb 4, 2006, at 7:20 PM, ian at airs dot com wrote:
--- Comment #20 from ian at airs dot com 2006-02-05 00:19 ---
In many common cases, the two constructors are identical. It should
not be
hard to simply emit both appropriate symbols before the function.
That does
not require
--- Comment #20 from ian at airs dot com 2006-02-05 00:19 ---
In many common cases, the two constructors are identical. It should not be
hard to simply emit both appropriate symbols before the function. That does
not require any change to the ABI, but it eliminates the problem in the c
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-02-05 00:19 ---
Fixed on trunk and 4.1. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-02-05 00:16 ---
Fixed on trunk and 4.1. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-02-05 00:14 ---
Subject: Bug 26039
Author: tkoenig
Date: Sun Feb 5 00:14:37 2006
New Revision: 110600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110600
Log:
2006-02-04 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-02-05 00:14 ---
Subject: Bug 25046
Author: tkoenig
Date: Sun Feb 5 00:14:37 2006
New Revision: 110600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110600
Log:
2006-02-04 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #3 from tromey at gcc dot gnu dot org 2006-02-04 23:51 ---
*** Bug 25948 has been marked as a duplicate of this bug. ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from tromey at gcc dot gnu dot org 2006-02-04 23:51 ---
*** This bug has been marked as a duplicate of 24461 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from julius at zgod dot cjb dot net 2006-02-04 23:50 ---
I just tried:
env LANG=C gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -g3 -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE
-O6 -march=i586 -fomit-frame-pointer-c -o channel
--- Comment #5 from pcarlini at suse dot de 2006-02-04 23:41 ---
Really, what Stefaan is saying is trivially correct and totally sensible. The
only doubt I have is which *specific* shape the compiler support must take. In
fact, I find TR1, 4.9 too vague about that. Then the point would b
--- Comment #4 from stefaan dot deroeck at gmail dot com 2006-02-04 23:41
---
> Yes TR1 refers to the technical report which is really just the library part.
For the library to provide this functionality, it has to exist in the compiler,
as a whole, or by a clever combination of langua
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-04 23:36 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from tromey at gcc dot gnu dot org 2006-02-04 23:35 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--
--- Comment #2 from tromey at gcc dot gnu dot org 2006-02-04 23:34 ---
Subject: Bug 25676
Author: tromey
Date: Sat Feb 4 23:34:06 2006
New Revision: 110599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110599
Log:
gcc/java
PR java/25676:
* builtins.c (max_built
--- Comment #11 from tromey at gcc dot gnu dot org 2006-02-04 23:30 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|N
--- Comment #10 from tromey at gcc dot gnu dot org 2006-02-04 23:30 ---
Subject: Bug 26097
Author: tromey
Date: Sat Feb 4 23:30:01 2006
New Revision: 110598
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110598
Log:
PR java/26097:
* expr.c (push_type): Avoid sid
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-04 23:22 ---
(In reply to comment #2)
> When I saw "tr1" in the path, I assumed this referred to the technical report
> of the standards committee. I recognize a technical report is not a standard,
> thus I am simply inquiring i
--- Comment #2 from stefaan dot deroeck at gmail dot com 2006-02-04 23:13
---
When I saw "tr1" in the path, I assumed this referred to the technical report
of the standards committee. I recognize a technical report is not a standard,
thus I am simply inquiring if there is interest in a
--- Comment #1 from tromey at gcc dot gnu dot org 2006-02-04 22:36 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #3 from tromey at gcc dot gnu dot org 2006-02-04 22:29 ---
I played with this a bit today and I'm not able to reproduce.
Do you need special arguments to the test program?
I tried with my current 4.0.x and 4.1 builds.
--
tromey at gcc dot gnu dot org changed:
--- Comment #2 from tromey at gcc dot gnu dot org 2006-02-04 22:29 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #9 from andreast at gcc dot gnu dot org 2006-02-04 22:26
---
build completes with the patch from Tom. (#8)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-04 22:23
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-04 22:17 ---
Wouldn't it be better to ask the standards committee to add support than asking
GCC to add an extension?
Also what kind of optimizations can you do with a trival destructor?
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #13 from aoliva at gcc dot gnu dot org 2006-02-04 22:13 ---
Subject: Bug 2
Author: aoliva
Date: Sat Feb 4 22:13:20 2006
New Revision: 110597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110597
Log:
PR debug/2
* config/ia64/ia64.c: Include debug.h.
(MAX_ART
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-02-04 22:12 ---
Subject: Bug 25075
Author: tkoenig
Date: Sat Feb 4 22:11:57 2006
New Revision: 110596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110596
Log:
2006-02-04 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
currently, in , code exists like:
template
struct has_trivial_destructor
: public integral_constant::value> { };
It would be nice to have compiler support to detect non-pod types that have a
trivial destructor. (this would provide support for certain optimizations)
--
Sum
--- Comment #12 from aoliva at gcc dot gnu dot org 2006-02-04 22:08 ---
Subject: Bug 2
Author: aoliva
Date: Sat Feb 4 22:08:04 2006
New Revision: 110594
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110594
Log:
PR debug/2
* config/ia64/ia64.c: Include debug.h.
(MAX_ART
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-04 22:06 ---
Just for the record the error message is:
In file t.f90:5
write(6,*) PRODUCT(A,B)
1
Error: Incompatible ranks in arguments 'array' and 'mask' for intrinsic product
at (1)
--
http://gcc.gn
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
|
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-02-04 22:04 ---
This is now caught on trunk, since revision 110453 (I had overlooked
this PR when fixing this).
Thomas
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from tromey at gcc dot gnu dot org 2006-02-04 21:53 ---
Created an attachment (id=10778)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10778&action=view)
proposed patch
Please try this patch.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
--- Comment #7 from tromey at gcc dot gnu dot org 2006-02-04 21:49 ---
At least the change in push_type is wrong.
Perhaps others too, I'm looking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
--- Comment #26 from dberlin at gcc dot gnu dot org 2006-02-04 21:30
---
Buzz, thanks for playing.
The reassoc rewrite has nothing to do with this. It won't actually touch those
operations because they are memory loads and stores.
If you look at the reassoc dumps, the most it will do h
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-02-04 21:30 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00333.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from pcarlini at suse dot de 2006-02-04 20:53 ---
(In reply to comment #17)
> Out of curiosity, I was checking the LWG website; I couldn't find these issues
> (but then, I don't have inside access). I'm more than willing write a DR for
> both points mentioned, but I'd hat
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-02-04 20:52
---
Created an attachment (id=10777)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10777&action=view)
Patch to fix the bug.
We also get into trouble if we try to pass the result of a pointer-to-array
returning f
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-04 20:51 ---
Please try with Linux and gcc that are still supported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26094
--- Comment #7 from laurent at guerby dot net 2006-02-04 20:34 ---
I dont't remember having seen this one (ce3107b) fail. I see some random test
failing with run not finding the exe after gnatmake exits successfully, I've
always assumed this was a timing problem within the Linux kernel.
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-02-04 20:27
---
> It looks like ce3107b is one of those spurious failures I'm getting from
> time to time -- I've never quite understood what's going on here, but it
> looks like a test suite issue:
Indeed, I run into that from
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-04 20:21 ---
CCing Ben as I think his abort -> gcc_assert patch caused this.
I suspect one of the conversion caused a side effect to be removed when doing
--disable-checking (which disables also the asserts).
--
pinskia at gc
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-02-04 20:16
---
(In reply to comment #4)
> Thanks. ce3107b is new to me but all the others are fully understood.
It looks like ce3107b is one of those spurious failures I'm getting from
time to time -- I've never quite understo
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-04 20:11 ---
Confirmed, just a 4.0 regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from hjl at lucon dot org 2006-02-04 20:05 ---
Yes, I used --disable-checking. I saw it on i686, x86-64 and ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-04 20:01 ---
Reproduces with --disable-checking but not without on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
This code causes ICE on gcc 4.0.3 on x86_64.
typedef long long vec __attribute__ ((vector_size(16)));
vec vecsqr(vec a) { return a*a; }
Commandline:
gcc -O1 -S -o - tmp.c
Resulting output:
.file "tmp.c"
tmp.c: In function 'vecsqr':
tmp.c:2: error: unrecognizable insn:
(insn 13 12 15
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-04 19:47 ---
Quick question, what options did you use to bootstrap (Please say
--disable-checking)?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-02-04 19:42
---
> Yes, this fixes the problem. Bootstrap and regression test passes
> on s390x-ibm-linux (and s390-ibm-linux) with this fix.
Great. I've successfully tested it on x86_64-suse-linux.
> The following test case f
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-04 19:36 ---
I am going to put this into the java component as this is reproducible on i686,
x86_64 and powerpc64.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-04 19:35 ---
One of the following patches caused:
+2006-02-03 Jason Merrill <[EMAIL PROTECTED]>
+
+ PR c++/25979
+ * gimplify.c (gimplify_modify_expr_rhs): Disable *& optimization for
now.
+
+ PR middle-end/2
--- Comment #10 from tobi at gcc dot gnu dot org 2006-02-04 19:27 ---
I'm changing the summary, and pushing this to component middle-end. See
comments #3 and #5 for an analysis of what's going wrong.
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-02-04 19:11
---
(In reply to comment #2)
> Could you try the following fix?
Yes, this fixes the problem. Bootstrap and regression test passes
on s390x-ibm-linux (and s390-ibm-linux) with this fix.
The following test case failur
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-04 18:49 ---
"Linux 7.1" that is a new one.
Also 3.1 came out almost 4 years ago.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26094
With revision 110590, I got
gnu/CORBA/NamingService/NamingServiceTransient.java: In method
'gnu.CORBA.NamingService.NamingServiceTransient.main(java.lang.String[])':
gnu/CORBA/NamingService/NamingServiceTransient.java:100: error: stack underflow
gnu/CORBA/NamingService/NamingServiceTransient.java:
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-02-04 17:11
---
If I compile the original testcase with current mainline (revision 110561), the
binary dies on execution with
*** glibc detected *** double free or corruption (out): 0xbfc9d020 ***
Aborted
If I remove the line
--- Comment #25 from rguenth at gcc dot gnu dot org 2006-02-04 13:52
---
On the mainline now even g() regresses, probably because of the reassoc pass
rewrite. Of course on the mainline this is also "fixed" by --param
salias-max-array-elements=6, which makes load/store motion work on th
--- Comment #17 from squell at alumina dot nl 2006-02-04 12:45 ---
Out of curiosity, I was checking the LWG website; I couldn't find these issues
(but then, I don't have inside access). I'm more than willing write a DR for
both points mentioned, but I'd hate to duplicate any effort. Comm
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-02-04 11:31
---
Reduced testcase:
template struct arr {
long s;
T *d;
arr(long sz) : s(sz), d (s>0 ? new T[s] : 0) {}
~arr() { delete[] d; }
T &operator[] (int n) {return d[n];}
};
void map2alm (const double
--- Comment #9 from steven at gcc dot gnu dot org 2006-02-04 10:34 ---
No longer a 4.1/4.2 regression.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from olivier dot aumage at labri dot fr 2006-02-04 10:17
---
(In reply to comment #2)
> It looks like we have an interaction between the alignment attribute and the
> IA64 calling conventions. In this example GCC is treating my_t type as an
> aligned pointer and not as a
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-02-04 08:44
---
> Is this supposed to work this way?
No, of course, the tree is broken from the very beginning. The problem shows
up only on s390x because it features a low BIGGEST_ALIGNMENT for a 64-bit
target.
Could you try
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-02-04 08:38
---
Confirmed with a cross.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-02-04 08:36
---
Well, I'm closing this one as invalid. Steve, if you disagree, feel free to
reopen it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-02-04 08:34
---
(In reply to comment #4)
> Opps, I think that the change suggested in Comment #1 actually does fix the
> problem on the LINUX version.
Dale, can you submit this one-line patch on the [EMAIL PROTECTED] mailing-lis
76 matches
Mail list logo
