--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-16 06:25
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu
|
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-16 06:10
---
Subject: Bug 27666
Author: mmitchel
Date: Fri Jun 16 06:09:55 2006
New Revision: 114705
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114705
Log:
PR c++/27666
* call.c (build_conditional_e
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-16 06:09
---
Subject: Bug 27666
Author: mmitchel
Date: Fri Jun 16 06:09:14 2006
New Revision: 114704
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114704
Log:
PR c++/27666
* call.c (build_conditional_e
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-16 06:08
---
Subject: Bug 27689
Author: mmitchel
Date: Fri Jun 16 06:08:49 2006
New Revision: 114703
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114703
Log:
PR c++/27689
* cp-tree.h (CLASSTYPE_SPECIA
I tested using gcc-3.4.6 and gcc-4.1.1. The code generated by gcc-4.1.1 is
wrong, because a function attributed to weak is discarded by optimization.
I wander if this problem is gcc4's specification because I can see same problem
with gcc-4.1.1 for PowerPC.
The source code is as follows. The com
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-06-16 03:30
---
Fixed in 4.2.0, perhaps by the fix for PR c++/20103.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
The following invalid code snippet causes an ICE on mainline:
struct A;
struct B
{
friend A : 2;
};
bug.cc:5: error: name 'A' has incomplete type
bug.cc:5: internal compiler error: tree check: expected
The following invalid code snippet causes an ICE on mainline:
struct X {};
struct A
{
X x : 2;
};
struct B : A {};
bug.cc:5: error: bit-field 'X A::x' with non-integral type
bug.cc:8: internal compiler
The following invalid code snippet causes an ICE on mainline:
struct A
{
double d : 2;
A() {}
};
bug.cc:3: error: bit-field 'double A::d' with non-integral type
bug.cc: In constructor 'A::A()':
bug.cc:4:
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-16 02:36
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-16 02:33
---
Subject: Bug 27666
Author: mmitchel
Date: Fri Jun 16 02:33:35 2006
New Revision: 114702
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114702
Log:
PR c++/27666
* call.c (build_conditional_e
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-06-16 02:23
---
Confirmed as the bug was reproduced by Steve.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid code snippet causes an ICE since GCC 3.4.0:
template struct A {};
template struct B : A
{
using A::operator typename A::X;
};
B<0> b;
bug.cc: In instantiation of 'B<0>':
bug.cc:8:
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-16 02:11
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
The following invalid code snippet causes an ICE since GCC 4.1.0:
==
int i = [0];
==
bug.m:1: error: expected ':' before ']' token
bug.m:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
This also happens with the objc+
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-16 02:09
---
Subject: Bug 27640
Author: mmitchel
Date: Fri Jun 16 02:09:10 2006
New Revision: 114701
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114701
Log:
PR c++/27640
* pt.c (instantiate_template)
The following invalid code snippet causes an ICE since GCC 4.1.0:
==
+
==
bug.m:1: error: expected ':' at end of input
bug.m:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2 regression
The testcase below generates a segmentation fault in g++ 4.0.0 to 4.2.0.
/tmp/test.cpp:3: internal compiler error: Segmentation fault
--GCC Info--
Version: g++ (GCC) 4.2.0 20060615 (experimental) SVN revision 114692
(Also tested on g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8))
Configure command
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27979
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27977
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27952
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-15 23:47
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-15 23:47
---
Subject: Bug 27665
Author: mmitchel
Date: Thu Jun 15 23:47:15 2006
New Revision: 114694
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114694
Log:
PR c++/27665
* parser.c (cp_parser_unquali
--- Comment #6 from sje at cup dot hp dot com 2006-06-15 23:46 ---
I believe I understand why this test fails on IA64. It may or may not be the
same issue as on mmix.
See http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00864.html for more info.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #4 from flameeyes at gentoo dot org 2006-06-15 23:30 ---
This is still an issue in 4.1.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25272
--- Comment #7 from langton at gcc dot gnu dot org 2006-06-15 23:11 ---
I've backported the patch to 4.1, so this bug should be resolved.
--
langton at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from langton at gcc dot gnu dot org 2006-06-15 23:07 ---
Subject: Bug 27786
Author: langton
Date: Thu Jun 15 23:07:14 2006
New Revision: 114692
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114692
Log:
PR fortran/27786
* cray_pointers_2.f90: Add -
--- Comment #14 from pinskia at physics dot uc dot edu 2006-06-15 23:03
---
Subject: Re: compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450)
get error on long exixting code
> The problem turned up a week or so before I filed PR 27528, and after
> considerable rs6000 chan
> The problem turned up a week or so before I filed PR 27528, and after
> considerable rs6000 changes made by David Edelsohn.
The change just exposed a latent bug. I am trying to make sure that
you understand that and not blaming David.
Could someone please CC Richard Sandiford, if he is not alr
--- Comment #13 from malitzke at metronets dot com 2006-06-15 22:58 ---
Hans_Peter
Your, not mine, concern seems to be comment 3. For that you have to contact
Pinski. I saw a number os inconsitencies in his comments and after the
reception got did not want to pursue this further. My pro
While doing some DWARF-related work, I noticed that output_file_names in
dwarf2out.c parses filenames assuming they are UNIX, things like:
/* Skip all leading "./". */
f = d->filename;
while (f[0] == '.' && f[1] == '/')
f += 2;
I'm fairly sure it won't work right on DOS-style pathnames
My mainline testing gets intermittent failures for test
libgomp/testsuite/libgomp.g++/pr27337.c. Some of the failures are due to wrong
counts from the constructor and destructor after the call to foo, and others
are for wrong values of x.i (with values in the range 19-27) after the call to
bar. T
On Thu, 2006-06-15 at 15:59 -0400, Thomas Fitzsimmons wrote:
> Andrew MacLeod wrote:
> > On Thu, 2006-06-15 at 14:14 -0400, Andrew MacLeod wrote:
> >> I assume I'm not the only one seeing this build failure:
> >>
> >>
> >> make[5]: Entering directory
> >> `/build/gcc/2006-06-15/i686-pc-linux-gnu/l
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-15 20:04 ---
Works for me on the mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
Andrew MacLeod wrote:
On Thu, 2006-06-15 at 14:14 -0400, Andrew MacLeod wrote:
I assume I'm not the only one seeing this build failure:
make[5]: Entering directory
`/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools'
/bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc
On Thu, 2006-06-15 at 14:14 -0400, Andrew MacLeod wrote:
> I assume I'm not the only one seeing this build failure:
>
>
> make[5]: Entering directory
> `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools'
> /bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc
> -B/build/
This is a stripped-down bit of code representing a bad code generation problem
we've been having with XEmacs 21.5 + gcc 4.X + optimization. I can reproduce
with Fedora Core 5's packaging of gcc 4.1.1 on the x86_64 platform, and with
Ubuntu's packaging of gcc 4.0.3 on the i386 platform.
Compile th
--- Comment #2 from widman at gimpel dot com 2006-06-15 18:51 ---
(In reply to comment #1)
> This works correctly in 4.2.0.
>
Ok; should the fix be back-ported to earlier versions? If not I guess this
should be a "WONTFIX".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28044
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-15 18:31 ---
This works correctly in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I assume I'm not the only one seeing this build failure:
make[5]: Entering directory
`/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools'
/bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc
-B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/
-B/install
See below; G++ appears to correctly handle the use of 'struct B' to declare the
function template g(), but if there is no prior declaration of the class (as in
the declaration of f()), the class is erroneously taken as a class template.
extern "C" int printf( const char*, ... );
struct B{ int n;
--- Comment #7 from pault at gcc dot gnu dot org 2006-06-15 17:39 ---
Created an attachment (id=11675)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11675&action=view)
A near submission level patch for the PR
I have not marked the previous version as obsolete because it could wel
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-06-15 17:30 ---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-15 17:23 ---
Subject: Bug 27781
Author: rguenth
Date: Thu Jun 15 17:23:41 2006
New Revision: 114681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114681
Log:
2006-06-16 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #4 from barryb at cwipapps dot net 2006-06-15 17:15 ---
Sorry, you are right; you have to cast it twice.
I'd moved on to
d is 32765.00, as integer is 0x7ffd, and (ushort)d is 0x7ffd while
(uchar)(ushort)d is 0xfd
d is 32766.00, as integer is 0x7ffe, and (ush
--- Comment #12 from hp at gcc dot gnu dot org 2006-06-15 16:50 ---
In reply to comment #11, "i" *is* an appropriate constraint, if any.
I see the problem with the reduced test-case in comment #3,
so I'm going to limit the scope of my involvement to fixing that.
Hopefully we can leave t
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-15 16:19 ---
(In reply to comment #6)
> e.c:1: error: previous declaration of 'int i' with 'C++' linkage
> e.c:4: error: conflicts with new declaration with 'C' linkage
>
> extern int i;
> extern "C" {
> extern int i;
>
--- Comment #6 from sje at cup dot hp dot com 2006-06-15 16:14 ---
Could I get clarification if the following error is a desired effect of this
change. Prior to this, the included program gave no error. I believe the
change was caused by this patch. This is causing a problem with the
--- Comment #3 from schwab at suse dot de 2006-06-15 16:04 ---
It is still undefined to convert a float to an integer that is too narrow. The
range of short is irrelevant when converting to char. Since the behaviour is
undefined there is no requirement on the resulting value. If you w
--- Comment #2 from barryb at cwipapps dot net 2006-06-15 15:54 ---
The integers in the example ARE all within the range of unsigned short.
Therefore Falk's comments may be true, but are not relevant.
Note also that the same code works as expected on sparc.
We think that the problem li
--- Comment #5 from patchapp at dberlin dot org 2006-06-15 15:30 ---
Subject: Bug number PR27781
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/2006-06/msg00808.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #13 from mark at codesourcery dot com 2006-06-15 15:27 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error:
no-op convert from 4 to 8 bytes in initializer
dj at redhat dot com wrote:
> --- Comment #12 from dj at redhat dot com 2006-06-15 15:19 ---
> Subj
--- Comment #12 from dj at redhat dot com 2006-06-15 15:19 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from
4 to 8 bytes in initializer
> I don't understand the assertion, given that removing it seems to
> generate correct output for this test case.
T
--- Comment #12 from dberlin at gcc dot gnu dot org 2006-06-15 15:18
---
Subject: Bug 27341
Patch I am testing for all the testcases here.
It turns out to be a problem not actually in the 02-20-06 patch.
Index: gcc/tree-complex.c
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-06-15 15:04
---
This should fix it
It looks like gimplify_val never calls mark_new_vars_to_rename, but may create
new statements that nothing else gets a handle to.
Index: tree-cfg.c
==
--- Comment #10 from sebastian dot pop at cri dot ensmp dot fr 2006-06-15
14:52 ---
Subject: Re: [4.2 Regression] segfault in fold_convert with -ftree-vectorize
You said that you had a fix in predcom, is that fix in your local
tree, or have you sent a patch to gcc-patches?
Here is a
--- Comment #10 from dberlin at gcc dot gnu dot org 2006-06-15 14:35
---
Uh, nobody told me it was exposed by my patch, and it's certainly not in the
bug history, or else i would be working on the bug.
In fact, as comment 8 shows, even if you disable the code i added in
2006-02-20, an
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-06-15 14:21
---
Daniel, this bug was exposed by your 2006-02-20 patch. It's been blocking
testing/submission of one of my libgfortran patches for more than two months
now. It's in an area of the compiler I don't have any experien
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-15 14:15 ---
The tesstcase works in "4.2.0 20060608" but fails with Apple's "gcc version
4.0.1 (Apple Computer, Inc. build 5341)". I bet I have seen this bug before.
--
pinskia at gcc dot gnu dot org changed:
Wha
See lower part of my article at
http://www.ba-stuttgart.de/~helbig/st80/bsearch.txt
--
Summary: optimizer (-O2) changes the semantics of my programs
Product: gcc
Version: 2.95.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
--- Comment #21 from amacleod at redhat dot com 2006-06-15 13:30 ---
Subject: Bug 27793
Author: amacleod
Date: Thu Jun 15 13:30:17 2006
New Revision: 114678
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114678
Log:
2006-06-15 Andrew MacLeod <[EMAIL PROTECTED]>
PR mi
--- Comment #9 from sebastian dot pop at cri dot ensmp dot fr 2006-06-15
13:19 ---
Subject: Re: [4.2 Regression] segfault in fold_convert with -ftree-vectorize
rakdver at gcc dot gnu dot org wrote:
> Ccing people responsible for data dependence analysis.
Thanks, for the ping, this
The compilation crashes in
/* Gimplify an OMP_ATOMIC statement. */
static enum gimplify_status
gimplify_omp_atomic (tree *expr_p, tree *pre_p)
{
tree addr = TREE_OPERAND (*expr_p, 0);
tree rhs = TREE_OPERAND (*expr_p, 1);
>>> tree type = TYPE_MAIN_VARIANT (TREE_TYPE
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-06-15 12:36
---
See http://gcc.gnu.org/install/specific.html#x-x-solaris2
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-06-15 12:34
---
> I fixed this problem. But, as I don't have a Solaris box,
> I can't test whether this means that the build works.
This report was actually invalid, we don't support /bin/sh on Solaris.
--
ebotcazou at gcc
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-15 12:26 ---
> .so, an error is definitely in order.
Maybe one could spit out a default warning and only with -std=f90 an error as
this is might be a commonly used Fortran extension. Or one simply always
r
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-06-15 11:31 ---
Ccing people responsible for data dependence analysis. I have hacked this over
on predcom branch, but I would prefer if someone who understands the code could
fix it properly.
--
rakdver at gcc dot gnu dot org c
--- Comment #2 from aph at gcc dot gnu dot org 2006-06-15 11:23 ---
gcj creates all its trampolines on the heap, so exec stack shouldn't be needed.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-06-15 11:17
---
Hello,
> > http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00241.html suggests we
> > still
> > have the bug. Can someone confirm this still passes with
> > -fno-move-loop-invariants?
>
> Confirmed.
could you
Hi
I think gcc-4.1.1 generates wrong outputs on coldfire v4 at this code.
-
struct ab {
int a;
unsigned int b;
};
int
main () {
struct ab _ab;
short a = 0;
unsigned short b = 0;
_ab.a = -999;
_ab.b = 1000;
a = _ab.a;
b = _ab.b;
printf("%d\n", a );
Assume the following case:
One had somewhere '(3(a,),f)', now one copies this and realizes that one
does not need the 3(..) anymore. Result:
'(a,),f)'
Ups, the ",f)" is ignored.
Currently, gfortran does not warn in such a case.
Expected: gfortran warns at compile time
Ifort (9.1) even d
--- Comment #1 from falk at debian dot org 2006-06-15 10:16 ---
If the value of the integral part cannot be represented by the integer type,
the behavior is undefined. So this is not a bug.
--
falk at debian dot org changed:
What|Removed |Added
---
The program
#include
main()
{
double d;
int i;
printf("Starting at 32758\n");
for (d=32758.0, i=0; i<20; i++) {
printf("d is %f, as integer is 0x%0.8x, and (ushort)d is 0x%0.4x
while (unsigned char)d is 0x%0.2x\n",
--- Comment #12 from bonzini at gnu dot org 2006-06-15 07:21 ---
Created an attachment (id=11670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11670&action=view)
updated configure script for libdecnumber
Gerald, here it is. Again, don't forget to disable fortran.
--
http://
78 matches
Mail list logo
