--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-10 07:41 ---
I can reproduce the crash with GCC/gfortran 4.1, but not with 4.2 or 4.3.
GCC 4.3 is the current developer version which gets all the fixes. GCC 4.2 and
4.1 are open only for regressions; some of the fixes are also
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-10 07:12 ---
With 4.3.0 20070404/x86_64-unknown-linux-gnu I don't get the ICE - and no
problem is discovered using valgrind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-04-10 06:07
---
Fixed in 4.1.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-04-10 06:07
---
Subject: Bug 31449
Author: mmitchel
Date: Tue Apr 10 06:07:41 2007
New Revision: 123691
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123691
Log:
PR c++/31449
* class.c (build_base_path):
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-04-10 04:01
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-04-10 04:01
---
Subject: Bug 31449
Author: mmitchel
Date: Tue Apr 10 04:01:08 2007
New Revision: 123690
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123690
Log:
PR c++/31449
* class.c (build_base_path):
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-04-10 03:43 ---
> Andrew, are you going to apply the patch to the 4.1 branch, too?
When I get around to testing it, it wil not be until Thursday at the earliest.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30168
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-04-10 03:40
---
You can use -pedantic to get rid of the automatically defining of i386 or use
-Ui386.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20682
--- Comment #12 from igodard at pacbell dot net 2007-04-10 02:45 ---
Funny indeed - that's a scream :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20682
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-10 02:31 ---
This is the fix which I am going to fully test:
Index: c-decl.c
===
--- c-decl.c(revision 123681)
+++ c-decl.c(working copy)
@@ -3383,7 +3383,7
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-10 02:24 ---
CCing the guys who wrote -Warray-bounds to make sure they understand this
exists.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-10 02:22 ---
I have a patch already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Ass
Testcase:
int a[] = (int[4]){1, 1, 2};
int f(void)
{
int sum = 0; int i;
for(i = 0;i<4;i++)
sum = a[i];
return sum;
}
This testcase should compile without warning but currently does not.
--
Summary: [4.1/4.2/4.3 Regression] Latent bug in finish_decl
caus
--- Comment #13 from echristo at apple dot com 2007-04-10 01:57 ---
Any hope of getting this in 4.2 as well? It's not a regression, but is a fairly
longstanding bug that's easier to trip than we'd like.
--
echristo at apple dot com changed:
What|Removed
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-04-10 01:22
---
Well, it crashes for me:
GCC 2.95.3:
PR31516.cc: In method `A<{anon}>::B<{anon}>::foo()::C::C()':
PR31516.cc:7: ../../../gcc-2.95.3/gcc/cp/pt.c:2493: Expect 't', have
'function_decl'
GCC 3.0.4:
PR31516.cc: In mem
--- Comment #1 from bangerth at dealii dot org 2007-04-10 00:30 ---
Confirmed, though this appears to work up to and including the 4.1.2
release at least, in contrast to your assertion...
W.
--
bangerth at dealii dot org changed:
What|Removed |Add
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-04-10 00:19
---
I am not sure this is formatted I/O related. I will investigate further, but I
suspect we are allocating buffer memory to write to memory and we should not
have to do that.
--
jvdelisle at gcc dot gnu dot org
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-04-10 00:06
---
Subject: Bug 27869
Author: hubicka
Date: Tue Apr 10 00:06:16 2007
New Revision: 123682
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123682
Log:
PR target/27869
* config/i386/sse.md
--- Comment #8 from pierre42d at 9online dot fr 2007-04-10 00:02 ---
Same problem with gcc 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28298
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31137
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
GCC build triplet|4.1.1 |
GCC host triplet|AVR |
GCC target t
--- Comment #1 from eweddington at cso dot atmel dot com 2007-04-09 23:33
---
Bernd, what mcu type was this compiled for?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
--- Comment #7 from pierre42d at 9online dot fr 2007-04-09 23:32 ---
Documentation says :
First, we highly recommend that GCC be built into a separate directory than the
sources which does not reside within the source tree. This is how we generally
build GCC; building where srcdir == ob
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Kno
For the program
module foo
intger :: i ! intger should be integer
end module foo
program xfoo
use foo, only: i
end program xfoo
gfortran -c -v gfbug.f90
gives
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran,c++,objc
--- Comment #9 from jason at gcc dot gnu dot org 2007-04-09 22:43 ---
Fixed in 4.2 branch and trunk.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pcarlini at suse dot de 2007-04-09 22:35 ---
Doesn't really block this one.
--
pcarlini at suse dot de changed:
What|Removed |Added
BugsThisDependsO
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18553
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Kno
The _M_max_length member variable of _Error_formatter is not configurable. It
is currently initialized directly with the value 78, in
libstdc++-v3/include/debug/formatter.h . Having this be configurable (using a
macro, for example) would nicely follow gcc's -fmessage-length=N example.
--
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last r
--
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=31517
The following invalid code snippet triggers a segfault since GCC 4.1.2:
=
template struct A
{
static const int i=0;
};
template const int A::i = 0=0;
=
bug.cc:6: error: duplicate initialization of
The following valid code snippet triggers an ICE since at least GCC 2.95.3:
=
template struct A
{
template struct B
{
template void foo()
{
struct C { C() {} };
}
};
};
=
bug.cc: In member function 'void A< >:
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Kno
stephane duverger wrote:
Father was removed because of "goto __end", simply because gcc thought
that this code part will never be reached. But process is cloned() and
it should have taken into account the "jnz father"
Gcc does not look at the contents of an asm, so it does not know that
there
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-04-09 20:51
---
Fixed in 4.3.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-04-09 20:46
---
Subject: Bug 31449
Author: mmitchel
Date: Mon Apr 9 20:45:53 2007
New Revision: 123679
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123679
Log:
PR c++/31449
* class.c (build_base_path):
--- Comment #4 from mrs at apple dot com 2007-04-09 20:25 ---
radr://5076058
--
mrs at apple dot com changed:
What|Removed |Added
CC|
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-09 19:30 ---
I want to say this is related to PR 27979.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-09 19:21 ---
struct tree_type {
unsigned int precision : 9;
};
void bork(unsigned int Subpart);
void foo(struct tree_type *t)
{
bork(t->precision);
}
we miss the zero extension of the argument (comparing cc1 to cc1plus outpu
--- Comment #4 from daney at gcc dot gnu dot org 2007-04-09 18:49 ---
Fixed on the trunk.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-09 18:47 ---
Complex operations are lowered at the tree-level so this would require
vectorizing
of straight line code. Second, calling conventions are different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-09 18:45 ---
comment #5 in PR19020 mentions several reasons why -ftrapv doesn't really work
right now. I'd be in favor of removing it rather than trying to fix it...
--
rguenth at gcc dot gnu dot org changed:
Wha
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-04-09 18:45
---
Just a side note: You should remove the "template<>" as it is invalid
and only accidentally accepted by GCC, see PR24314.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30836
--- Comment #3 from daney at gcc dot gnu dot org 2007-04-09 18:40 ---
Subject: Bug 23758
Author: daney
Date: Mon Apr 9 18:40:20 2007
New Revision: 123676
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123676
Log:
PR libgcj/23758
* java/lang/natPosixProcess.cc (n
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-04-09 18:32
---
Btw, since GCC 4.1.0 the error message is:
bug.cc:13: error: reference to 'S' is ambiguous
bug.cc:4: error: candidates are: typedef struct S A::S
bug.cc:7: error: struct S
bug.cc:13: error: templat
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #11 from reichelt at gcc dot gnu dot org 2007-04-09 18:16
---
This is really a non-bug.
The following code snippet illustrates this:
#define VAR1(i,j) i##j
#define VAR2(i,j) VAR1(i,j)
#define VAR(i) VAR2(i,__LINE__)
#line 385
int VAR(i) = 0;
==
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #12 from steven at gcc dot gnu dot org 2007-04-09 17:51 ---
Yay to making it an ICE instead of a warning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from sabre at nondot dot org 2007-04-09 17:38 ---
Among other things, this bug causes GCC 4.2 to miscompile LLVM.
--
sabre at nondot dot org changed:
What|Removed |Added
---
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-04-09 17:19
---
Andrew, are you going to apply the patch to the 4.1 branch, too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30168
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-04-09 15:35
---
Confirmed.
The code fails to compile since GCC 3.3.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from gdr at cs dot tamu dot edu 2007-04-09 15:33 ---
Subject: Re: [4.3 Regression] Canonical types failures
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| Talking about canonical types: I think the idea of only issuing a warning
| in cases like the current
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| Talking about canonical types: I think the idea of only issuing a warning
| in cases like the current one is a really bad idea.
Fully agreed. I believe we discussed this on the main list. It
should not be a warning. It should be an ICE
--- Comment #10 from bangerth at dealii dot org 2007-04-09 15:23 ---
Great, thanks. Hopefully someone approves the patch soon.
Talking about canonical types: I think the idea of only issuing a warning
in cases like the current one is a really bad idea. Warnings are meant for
things wher
--- Comment #9 from dgregor at gcc dot gnu dot org 2007-04-09 15:09 ---
I can't reproduce this bug with r123671 on i686-pc-linux-gnu. However, since
the above patch does fix the problem, I'll add this PR to the ChangeLog for
that patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-04-09 15:08
---
This is a duplicate of PR 27102.
*** This bug has been marked as a duplicate of 27102 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #18 from reichelt at gcc dot gnu dot org 2007-04-09 15:08
---
*** Bug 31277 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from bangerth at dealii dot org 2007-04-09 14:56 ---
(In reply to comment #6)
> Does the following patch fix the problem?
>
> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00188.html
Yes. I think it would be good if you added Andrew's testcase to the patch
as well, comp
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-04-09 14:52
---
Fixed on mainline by Sandra's patch (revision 122411).
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from bangerth at dealii dot org 2007-04-09 14:49 ---
(In reply to comment #6)
> This is clearly my bug, but I am not able to reproduce it on
> i686-pc-linux-gnu.
This was with r123617, on i686-pc-linux-gnu. I can reproduce with this
version and Andrew's testcase, though
--- Comment #1 from gianni at mariani dot ws 2007-04-09 13:51 ---
I just built gcc-4.3-20070202 x86_64-redhat-linux and confirmed behaviour is
the same as 4.1.1.
--
gianni at mariani dot ws changed:
What|Removed |Added
-
--- Comment #1 from haskell dot vivian dot mcphail at gmail dot com
2007-04-09 13:36 ---
Created an attachment (id=13341)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13341&action=view)
File that causes crash
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31515
I know nothing about fortran. This occured while attempting to compile the
espresso DFT package from http://www.pwscf.org/
When compiling, the compiler seg faults and asks for a bug report to be filed
with command:
$ gfortran -c input_parameters.f90
I tried including the file in this comment bu
--- Comment #1 from schwab at suse dot de 2007-04-09 13:08 ---
Don't write beyond array bounds.
--
schwab at suse dot de changed:
What|Removed |Added
Status|U
--- Comment #16 from reichelt at gcc dot gnu dot org 2007-04-09 13:00
---
*** Bug 31049 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-04-09 13:00
---
This is a duplicate of PR 29106 which was present in GCC 4.0.3, 4.1.0, and
4.1.1.
It's fixed in GCC 4.0.4 and 4.1.2, though.
*** This bug has been marked as a duplicate of 29106 ***
--
reichelt at gcc dot gnu
this small program causes a seg fault in libc.
i don't think this is a libc bug because insignificant changes to the program
cure the problem.
i have run valgrind with the executable, too
in the program below, change the assignment c=s[1] to c=0
and the seg fault disappears
to run the progra
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-09 11:07
---
See PR20278. Do we really want to separate PR for these?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from dgregor at gcc dot gnu dot org 2007-04-09 10:39 ---
This is clearly my bug, but I am not able to reproduce it on i686-pc-linux-gnu.
Does the following patch fix the problem?
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00188.html
If not, which platform are you s
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-09 08:57 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
74 matches
Mail list logo
