--- Comment #2 from laurent dot bonnaud at inpg dot fr 2007-11-10 08:30
---
I get exactly the same error:
$ ../gcc-4.2.2/configure --prefix=/usr/local/gcc-4.2
$ make bootstrap
[...]
checking for x86_64-unknown-linux-gnu-gcc... /var/tmp/LB/build/./gcc/xgcc
-B/var/tmp/LB/build/./gcc/
--- Comment #13 from steven at gcc dot gnu dot org 2007-11-10 10:46 ---
Created an attachment (id=14523)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14523action=view)
Nukes -fforce-addr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
gcc rejects following valid code.
//test.c
struct foo
{
int operator[](int) const { return 0; }
};
int main()
{
(foo()[0]);
return 0;
}
--
Summary: Parentheses-enclosed expression.
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
--- Comment #19 from burnus at gcc dot gnu dot org 2007-11-10 12:29 ---
Harald, can you test the patch at
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00552.html
with your real-world program? Due to .mod changes, the gfc-excessive.tar.gz
does not work. And for the other tests I have,
--- Comment #14 from bonzini at gnu dot org 2007-11-10 13:04 ---
I reviewed the patch and it seems ok except that the option should be kept
undocumented for 4.3.
fforce-addr
- Common Report Var(flag_force_addr) Optimization
- Copy memory address constants into registers before use
+
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-10 13:26 ---
soplex.o is miscompiled.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-10 13:35 ---
All the tree difference is in
virtual void soplex::SoPlex::reDim() (this)
and it looks like an alias issue (what else...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
--- Comment #1 from manu at gcc dot gnu dot org 2007-11-10 14:11 ---
Testing a patch.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-10 14:31 ---
tree-ssa-sink is the culprit (we re-compute aliasing after PRE, right before
sink,
so an error there might be the bug as well):
Sinking newdim_31 = newdim_1 + -1 from bb 15 to bb 12
Sinking # SFT.2356_213 = VDEF
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-10 14:36 ---
bb 10:
# SFT.2355_186 = VDEF SFT.2355_161
D.37036.themem.val = 0.0;
D.45669_134 = D.37036.themem + 16;
...
bb 11:
# VUSE SFT.2356_197
n_142 = D.45672_138-idx;
pretmp.2399_154 = (long unsigned int)
--- Comment #37 from oshima at eng dot niigata-u dot ac dot jp 2007-11-10
14:58 ---
Created an attachment (id=14524)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14524action=view)
A proposed patch for bootstrapping GCC-4.2.2 on Interix 6
The attached patch is to bootstrap GCC
--- Comment #20 from anlauf at gmx dot de 2007-11-10 15:17 ---
Tobias,
Harald, can you test the patch at
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00552.html
with your real-world program?
I would love to test it with a i586/i686-compatible build. (f951 should
be sufficient
--- Comment #7 from dirtyepic at gentoo dot org 2007-11-10 15:56 ---
looks like this only occurs with profiledbootstrap. i'll test a vanilla build
to see if this is Gentoo specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-10 16:09 ---
Again aliasing is completely dependent on whether unrelated functions are
present or not. *sigh*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
--- Comment #14 from steven at gcc dot gnu dot org 2007-11-10 16:40 ---
Patch is waiting for approval of the C++ bits.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-10 16:42 ---
This looks like a bug in soplex. It does:
class UnitVector : public SVector
{
private:
Element themem;
Element themem1;
public:
...
UnitVector(int i = 0)
: SVector(2, themem)
{
add(i,
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-10 16:43 ---
Created an attachment (id=14525)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14525action=view)
patch for 450.soplex
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-10 16:44 ---
So, invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2007-11-10 16:49 ---
Eric, the PRE issue you mention was fixed (xf. bug 32540). The target issue is
still open.
The test case you posted in the patch from the Patch URL is already in the test
suite as
--- Comment #20 from steven at gcc dot gnu dot org 2007-11-10 16:51 ---
Next week has come and gone... News?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #17 from steven at gcc dot gnu dot org 2007-11-10 16:57 ---
HJ, what is up with this bug 31090? Not only is the status of the bug itself
unclear, but it is also keeping bug 30735 open for vague reasons.
Do we have an issue here, or not? If not, can you please close this
--- Comment #43 from steven at gcc dot gnu dot org 2007-11-10 17:05 ---
What is the status of this bug now? Re. comment #39, a meta-bug for what?
There is only one open bug left that depends on this one.
Are we still tracking an issue in this bug? If so, what? If not, please close
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-11-10 17:06
---
Let's close it as a dup of PR33974.
*** This bug has been marked as a duplicate of 33974 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-10 17:06 ---
*** Bug 31090 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-10 17:07 ---
*** Bug 30735 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33974
The following code snippet triggers an ICE on mainline:
===
struct A {};
templatetypename... T struct B : T...
{
B() : T()... {}
};
BA b;
===
bug.cc: In constructor 'BT::B() [with T = A]':
bug.cc:8:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34050
The following (probably invalid) code snippet triggers an ICE on mainline:
===
struct A
{
operator int();
};
template typename... T struct B : A
{
using A::operator T;
};
Bint b;
===
bug.cc: In instantiation of
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
--- Comment #1 from steven at gcc dot gnu dot org 2007-11-10 17:23 ---
How can this be a regression? Support variadic templates did not exist in
previous releases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34050
--- Comment #10 from patchapp at dberlin dot org 2007-11-10 17:25 ---
Subject: Bug number PR c/29062
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00111.html
--
--- Comment #7 from patchapp at dberlin dot org 2007-11-10 17:26 ---
Subject: Bug number PR33945
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00416.html
--
--- Comment #1 from steven at gcc dot gnu dot org 2007-11-10 17:27 ---
Why is this a regression? Previous GCC releases did not even support variadic
templates.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
The following code snippet is IMHO wrongly accepted on mainline:
=
templatetemplatetypename... T, typename = T class U struct A {};
=
A slightly modified
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-10
17:49 ---
Subject: Re: FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test
My mistake. This comes from a typo in trans.c (a EQ_EXPR instead of an
NE_EXPR). Could you test this patch?
Works for me.
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-10 18:02
---
Subject: Bug 33592
Author: fxcoudert
Date: Sat Nov 10 18:02:18 2007
New Revision: 130072
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130072
Log:
PR fortran/33592
* trans.c
--- Comment #20 from patchapp at dberlin dot org 2007-11-10 18:05 ---
Subject: Bug number PR16350
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00358.html
--
. Unfortunately I don't have the
resourced to build gfortran myself.)
I made a build of the patched compiler that you can download from
http://www.coudert.name/tmp/gfortran-i686-linux-20071110.tar.gz
I think the
first benchmark is to have the module files of the reworked
example to all have
--- Comment #9 from bonzini at gnu dot org 2007-11-10 18:10 ---
You should report the problem to SPEC so they update
http://www.spec.org/cpu2006/Docs/450.soplex.html and create a src.alt (I think,
at least this is how it was for CPU2000).
--
--- Comment #10 from rguenther at suse dot de 2007-11-10 18:20 ---
Subject: Re: [4.3 Regression]: Revision 130040
miscompiles 450.soplex
On Sat, 10 Nov 2007, bonzini at gnu dot org wrote:
--- Comment #9 from bonzini at gnu dot org 2007-11-10 18:10 ---
You should report
--- Comment #11 from hjl at lucon dot org 2007-11-10 18:41 ---
(In reply to comment #10)
Subject: Re: [4.3 Regression]: Revision 130040
miscompiles 450.soplex
On Sat, 10 Nov 2007, bonzini at gnu dot org wrote:
--- Comment #9 from bonzini at gnu dot org 2007-11-10 18:10
--- Comment #2 from patchapp at dberlin dot org 2007-11-10 18:55 ---
Subject: Bug number PR c++/33160
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00563.html
--
--- Comment #10 from patchapp at dberlin dot org 2007-11-10 19:00 ---
Subject: Bug number PR c++/17577
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00564.html
--
--- Comment #12 from hjl at lucon dot org 2007-11-10 19:17 ---
(In reply to comment #7)
Created an attachment (id=14525)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14525action=view) [edit]
patch for 450.soplex
This patch is incomplete. I got
unitvector.cc: In member
Using -fopenmp or -frecursive, local variables are put on the stack. This makes
sense, but for the main program there is no need for the stack and the static
memory can be used. This seems to be done what sunf95 does (contrary to ifort
and gfortran).
The following example is based on the thread
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-10 19:23 ---
As follow up, currently -frecursive is implemented as:
/* Implied -frecursive; implemented as -fmax-stack-var-size=-1. */
if (gfc_option.flag_max_stack_var_size == -2 gfc_option.flag_openmp)
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-11-10 19:30
---
How can this be a regression? Support variadic templates did not exist in
previous releases.
The C++ frontend shouldn't crash with any input, even with line-noise.
It didn't crash with this input in previous
The following invalid code snippet triggers an ICE on mainline:
=
templatetypename... T T foo() {}
=
bug.cc:1: error: parameter packs not expanded with `...':
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34054
--- Comment #13 from hjl at lucon dot org 2007-11-10 19:42 ---
Created an attachment (id=14526)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14526action=view)
A patch
This patch seems to work.
--
hjl at lucon dot org changed:
What|Removed
The following invalid code snippet triggers an ICE on mainline:
=
templatetypename... struct A;
templatetypename...T struct AT*
{
void foo();
};
templatetypename...T void AT*::foo() {}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
--- Comment #1 from law at redhat dot com 2007-11-10 19:51 ---
I don't see how my patch could be the root cause -- more likely than not my
patch is exposing a latent bug elsewhere.
I'm on an extended leave-of-absence from GCC stuff, but I'll try to take a
looksie and at least get
The following invalid code snippet triggers an ICE on mainline:
=
templatetypename... T struct A
{
void foo(T*) { ++p; }
T* p;
};
=
bug.cc:3: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34056
The following invalid code snippet triggers an ICE on mainline:
=
templatetypename... T struct A
{
typedef T X __attribute__((vector_size(8)));
};
=
bug.cc:3:
The following invalid code snippet triggers an ICE on mainline:
=
template typename...T struct A
{
typedef T X;
};
Aint a;
=
bug.cc:3: error: parameter packs
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34058
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34057
The following invalid code snippet triggers an ICE since GCC 4.1.2:
===
struct A
{
templateint void foo();
};
struct B : A {};
struct C : A {};
void bar()
{
B().C::foo0();
}
===
bug.cc: In function 'void bar()':
bug.cc:11: internal
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34059
--- Comment #2 from simartin at gcc dot gnu dot org 2007-11-10 20:33
---
For information, the compiler accepts this because it implements DR 45
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#45).
It looks like the implementation has been in for a long time, but the it
The following invalid code snippet triggers an ICE on mainline:
==
templateint struct A
{
templatetypename... struct B {};
templatetypename...T struct Bint,T* {};
};
A0::Bint b;
==
bug.cc:5:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34060
The following invalid code snippet triggers an ICE on mainline:
===
templatetemplateint class ...T struct A : T0 {};
===
bug.cc:1: error: parameter packs not expanded with `...':
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34061
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-10 21:28 ---
Still valid in GCC 4.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8570
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-10 21:28 ---
Use --disable-multilib as you don't have a full install of GNU/Linux glibc on
x86_64 which includes the 32bits headers/libraries.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-11-10 22:03
---
And also the ones on powerpc64-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-10 22:05 ---
Hmm, I think these options are a bit weird:
-ffast-math -fsignaling-nans
-ffast-math enables -fno-signal-math so how can NaNs signal?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-10 22:14 ---
D.2119_6 = xMeasure_4(D) * zMeasure_7(D);
D.2120_8 = D.2119_6 * yMeasure_5(D);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-10 22:15 ---
The rewrite of tree-ssa-reassoc.c caused this. That is the crash is after
tree-ssa-reassoc.c runs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-10 22:18 ---
This is also a 4.2 regression.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-10 23:54 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from miles at gnu dot org 2007-11-11 00:54 ---
Wouldn't it be nice if the configure script caught this sort of thing
automatically?
It's obviously going to be a very common problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34045
--- Comment #8 from dirtyepic at gentoo dot org 2007-11-11 02:42 ---
reproduced with gcc-4.3-20071109 snapshot.
[EMAIL PROTECTED] ~/tmp/gccbuild $ ../gcc-4.3-20071109/configure --disable-nls
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
On the trunk r129918 configured:
../trunk/configure --with-arch=r5000 --disable-java-awt --without-x
--enable-__cxa_atexit --disable-jvmpi --disable-libgomp --disable-static
--enable-languages=c,c++,java --disable-fixed-point --enable-checking=release
--with-gmp=/home/daney/mp
--- Comment #44 from sebpop at gmail dot com 2007-11-11 05:16 ---
Subject: Re: [4.1/4.2/4.3 regression] Quadratic behavior with many sets for
the same register in VRP
IMVHO this should be closed as WONTFIX.
Steven, why isn't your patch from comment #37 not a candidate for
fixing
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0
Target Milestone|--- |4.3.0
/vol1/tmp/rwgk/gcc_trunk_130073_x86_64_fc7
--enable-languages=c,c++,fortran --with-mpfr=/usr
Thread model: posix
gcc version 4.3.0 20071110 (experimental) (GCC)
I'll upload a small standalone reproducer.
To reproduce the problem:
% g++ -c -O1 ice_build2_stat.cpp
ice_build2_stat.cpp: In function
--- Comment #1 from rwgk at yahoo dot com 2007-11-11 05:53 ---
Created an attachment (id=14527)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14527action=view)
reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34063
--- Comment #1 from daney at gcc dot gnu dot org 2007-11-11 06:29 ---
The problem is that $gp is clobbered at the nonlocal_goto_receiver but it is
not being restored.
Currently the nonlocal_goto_receiver has a condition of
TARGET_CALL_CLOBBERED_GP, but this is not correct. I think it
--- Comment #6 from daney at gcc dot gnu dot org 2007-11-11 06:32 ---
Well the fix only works for o32. As noted in PR 34062, n32 is broken. I would
guess n64 as well.
I will take another try at fixing it. Perhaps the second attempt will work out
a little better than the first.
--
--- Comment #7 from daney at gcc dot gnu dot org 2007-11-11 07:05 ---
Created an attachment (id=14528)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14528action=view)
Proposed patch second half.
Completely untested patch. It will probably take me a couple of weeks to test
it
--- Comment #14 from bonzini at gnu dot org 2007-11-11 07:16 ---
It could also be possible to do something like this to avoid default
construction.
@@ -46,8 +46,8 @@ namespace soplex
class UnitVector : public SVector
{
private:
- Element themem; /// memory for 1st sparse vector
86 matches
Mail list logo
