--- 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-list
--- 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 #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 #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 #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 #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 #2 from martin at mpa-garching dot mpg dot de 2006-02-04 11:31
---
Reduced testcase:
template typename T struct arr {
long s;
T *d;
arr(long sz) : s(sz), d (s0 ? new T[s] : 0) {}
~arr() { delete[] d; }
T operator[] (int n) {return d[n];}
};
void map2alm
--- 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.
--- 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 the
--- 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
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
--- 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
--- 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
--- 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 #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
--- 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 #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
--- 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
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 0
--- 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
--- 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 #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 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
--- 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
--- 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 #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 #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 #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=10777action=view)
Patch to fix the bug.
We also get into trouble if we try to pass the result of a pointer-to-array
returning
--- 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 hate
--- 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 #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
--- 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 #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=10778action=view)
proposed patch
Please try this patch.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26097
--- 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
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
|
--- 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)
--
--- 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=gccview=revrev=110594
Log:
PR debug/2
* config/ia64/ia64.c: Include debug.h.
currently, in tr1/type_traits, code exists like:
templatetypename _Tp
struct has_trivial_destructor
: public integral_constantbool, is_pod_Tp::value { };
It would be nice to have compiler support to detect non-pod types that have a
trivial destructor. (this would provide support for
--- 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=gccview=revrev=110596
Log:
2006-02-04 Thomas Koenig [EMAIL PROTECTED]
PR
--- 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=gccview=revrev=110597
Log:
PR debug/2
* config/ia64/ia64.c: Include debug.h.
--- 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?
--
--- 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
--- 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 #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
--- 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 #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
--- 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
--- 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 if
--- 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=gccview=revrev=110598
Log:
PR java/26097:
* expr.c (push_type): Avoid side
--- 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
--- 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=gccview=revrev=110599
Log:
gcc/java
PR java/25676:
* builtins.c
--- 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
--- 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 #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
--- 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
--- 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
--- 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 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 #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=gccview=revrev=110600
Log:
2006-02-04 Thomas Koenig [EMAIL PROTECTED]
PR
--- 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=gccview=revrev=110600
Log:
2006-02-04 Thomas Koenig [EMAIL PROTECTED]
PR
--- 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 #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 #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
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 #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, the
--- 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.
--
--- 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
--- 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=10779action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25251
--- 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 #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.
--
--- 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 @@
--- 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 #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.
I
--- 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
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 #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=10780action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26100
76 matches
Mail list logo
