[Bug bootstrap/31039] Latest CVS-stage 2-Cannot create executables
--- Comment #3 from tprince at computer dot org 2007-03-24 03:06 --- The failure can be worked around by commenting out the section of in the cygwin distribution which sets __SCLE (conversion of \r\n to \n, according to comments). The code thus commented out apparently requires some cygwin extensions in the library which have disappeared since 20070224 (quoted by submitter as last working build). I concur, having built successfully the 20070223. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug bootstrap/31039] Latest CVS-stage 2-Cannot create executables
--- Comment #2 from tprince at computer dot org 2007-03-24 01:22 --- Note that the newly built bootstrap compiler fails the configure tests which have a trailing -V on the command line. Nearly all the various configure scripts provoke this failure. The one cited here happens to be the first. -- tprince at computer dot org changed: What|Removed |Added CC||tprince at computer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #39 from manu at gcc dot gnu dot org 2007-03-24 00:28 --- (In reply to comment #37) > The tests in gcc.dg/dfp are only run for a compiler configured with > --enable-decimal-float; the diagnostics tests there often just have "error" or > "warning" as the expression to match. I have patches for those and for most > of > the tests in gcc.dg/cpp. I'm planning to submit patches with batches of > fixes, > ask for comments, and then just check them in. The results are no different > and they can be changed back later. I recommend that you do the same, Manuel, > and copy me so I can approve them, since I've been behind in keeping up with > gcc-patches recently. I built always with --enable-decimal-float. We are duplicating work :( First, you don't need to fix those testcases that use "warning" or "error" as the expression to match, since those can be fixed automatically by the script that I have attached and are guaranteed to work. Moreover, until the final patch is in, those are guaranteed to keep working, so they should be the last ones to be committed. (But it is good to fix them in your working copy using my script so they don't distract you from the real failures). The testcases that we should really fix (see the list that I have attached) are: 1) Those where the wrong directive is used. 2) Those that use a dg-warning or dg-error to match something that is neither a warning nor an error. 3) Those that fail for some other reason. And (3) are the most important because they typically mean that we need to tweak something in the current patch. Two failures of type (3) are gcc/testsuite/gcc.dg/20041213-1.c and gcc/testsuite/gfortran.dg/badline.f Could you look why those two fail? I am sure that if we fix the patch to match correctly those testcases, then a bunch of other failures will go away as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug c++/31330] small template-use example crashes g++ w/internal error
--- Comment #1 from fang at csl dot cornell dot edu 2007-03-24 00:26 --- PR 27102 dup? using template parameter as a class name of member function. -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31330
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #38 from janis at gcc dot gnu dot org 2007-03-23 23:52 --- For comment #32 I get the failure but don't understand the problem; the regexp matches the message, doesn't it? This doesn't seem any different from other Fortran tests but it's the only one that fails; perhaps there's something special about specifying the line number in the test directive, or that the message comes from a file with a different name. I'll stare at it again later. For comment #33, is this still an issue with janis-try-2.diff? I changed the test to remove "error:" from regular expressions and to fix a few dg-warnings that should have been dg-error and the test passes for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #37 from janis at gcc dot gnu dot org 2007-03-23 22:48 --- The tests in gcc.dg/dfp are only run for a compiler configured with --enable-decimal-float; the diagnostics tests there often just have "error" or "warning" as the expression to match. I have patches for those and for most of the tests in gcc.dg/cpp. I'm planning to submit patches with batches of fixes, ask for comments, and then just check them in. The results are no different and they can be changed back later. I recommend that you do the same, Manuel, and copy me so I can approve them, since I've been behind in keeping up with gcc-patches recently. I'll take a closer look at comments #22 and #23. If you show up on irc we can chat about this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #29 from anlauf at gmx dot de 2007-03-23 22:43 --- (In reply to comment #27) Jerry, with the latest variant of your patch I get a failing namelist read with the new reduced testcase gfcbug61a.f90 (uses gfcbug61a.nml). If I remove one of the entries in the namelist file, the second read succeeds. There must still be a problem with REWIND/BACKSPACE/READ. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #28 from anlauf at gmx dot de 2007-03-23 22:39 --- Created an attachment (id=13274) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13274&action=view) Namelist for the modified demo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #27 from anlauf at gmx dot de 2007-03-23 22:39 --- Created an attachment (id=13273) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13273&action=view) Another variant of the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/18937] quadratic behaviour with many label "spaghetti" code
--- Comment #12 from tobi at gcc dot gnu dot org 2007-03-23 22:35 --- Well, "within the blink of an eye" because I was looking at spaghetti 1000 :-) But the increase in time is linear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug fortran/18937] quadratic behaviour with many label "spaghetti" code
--- Comment #11 from tobi at gcc dot gnu dot org 2007-03-23 22:27 --- I've implemented Steven's bitmap idea (see PR18540). spaghetti 9 compiles within the blink of an eye. Unfortunately, my current patch foregos step four from resolve_branch, which is necessary to establish validity of the source program, and at the moment I have no convincong idea on how to implement this in the framework with bitmaps. I hope I can attend to this soon, thus re-assigning to myself. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-14 19:03:18 |2007-03-23 22:27:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #36 from manu at gcc dot gnu dot org 2007-03-23 22:13 --- Created an attachment (id=13272) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13272&action=view) List of broken testcases at revision 123028 Janis, this is the list of testcases broken by the last version of the patch (after running fixtestsuite.sh). Notice that the list is one iteration old, that is, some failures have fixes already (in the list of fix-*.diff files I gave before). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #35 from manu at gcc dot gnu dot org 2007-03-23 22:06 --- (In reply to comment #32) > Manuel, I'm starting to clean up tests so they can be used with or without the > patch, like the fixes you've been posting. First I'm doing tests in > gcc.dg/dfp. I don't see any failures in gcc.dg/dfp. Janis, what do you mean by cleaning? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #34 from manu at gcc dot gnu dot org 2007-03-23 21:59 --- Created an attachment (id=13271) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13271&action=view) Script to make automatic fixes to the testsuite This script fixes the work-arounds used in the testsuite with some sed magic. It also applies the custom fixes for broken testcases that I am collecting. I am keeping those in files named as fix-X.diff where X is the basename of the testcase. I have around 15 of those. (I can attach them, send them to gcc-patches or commit them as obvious, since it seems nobody can or want to review them...). fix-19940712-1.diff fix-2625-1.diff fix-20050121-1.diff fix-940510-1.diff fix-arith-3.diff fix-attribute2.diff fix-bitfld-1.diff fix-charconst.diff fix-direct2.diff fix-empty2.diff fix-endif-pedantic2.diff fix-escape-1.diff fix-extratokens.diff fix-glibc-uclibc.diff fix-pack-test-2.diff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #33 from manu at gcc dot gnu dot org 2007-03-23 21:52 --- (In reply to comment #32) > Manuel, I'm starting to clean up tests so they can be used with or without the > patch, like the fixes you've been posting. First I'm doing tests in > gcc.dg/dfp. Let me know if there's an area you're not already looking at that > I can do next. > I can give you the list of tests that still fail with the most recent patch + fixes + sed-magic. Those are the tricky ones because they need to be checked one by one. However, I think it is more urgent to fix the issues described in comment #22, (that is, the regexp does not match the output of fortran) and in comment #23, (that is out-of-order diagnostics are not handled correctly). Those are show-stoppers from my point of view. As you said, the issue in comment #30 can be worked around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/30878] Rejects function f1; namelist /nml/ f1
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-23 21:41 --- There are only two restrictions on the namelist-group-objects, and this one is not in the list: C574 (R553) A namelist-group-object shall not be an assumed-size array. C575 (R552) A namelist-group-object shall not have the PRIVATE attribute if the namelist-group-name has the PUBLIC attribute. (PS: when fixing this, someone should check that the two constraints above are checked) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-23 21:41:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30878
[Bug fortran/31310] gfortran is missing -fcase-preserve option
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-23 21:34 --- We probably don't want to add all the g77 case options, but I can see why -fcase-preserve would be a good one to add. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-23 21:34:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
[Bug fortran/31270] print subscript value and array bounds when out-of-bounds error occurs
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-23 21:32 --- We could do that, I even know precisely how and it's not too hard. It requires creating a call to a va_arg function in the front-end, which I would need to research because I've never done that. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-23 21:32:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31270
[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-03-23 21:28 --- Confirming this as a low-priority enhancement. After all, even though we have historical reasons to implement GETLOG using getlogin(), if the information returned by another scheme is more relevant *in all cases*, we should change it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-23 21:28:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug target/31152] -(x>y) generates wrong code
--- Comment #3 from fb at frank-buss dot de 2007-03-23 21:27 --- I can reproduce the problem on a Linkstation Pro with an ARM926EJ CPU. I compiled GCC SVN revision 123155 from the gcc-4_2-branch on it. Creating wrong assembler code is at least a major bug, even when using the optimizing switch (which many programs do), so please change severity to "major". -- fb at frank-buss dot de changed: What|Removed |Added CC||fb at frank-buss dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug libfortran/31297] Use of uninitialized variables in libgfortran's I/O
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-23 21:21:25 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
[Bug libfortran/31296] Uninitialized variable in libgfortran's _gfortran_unpack0_char
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-23 21:21:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31296
[Bug libfortran/31286] cshift uses uninitialized variables
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-23 21:20:08 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31286
[Bug c/31331] New: ICE on invalid function attribute syntax for main()
Program:
__attribute__ ((naked)) int main(void)
{
return 0;
}
Compiled with 4.1.1 for the AVR target:
Compiling C: test.c
avr-gcc -c -mmcu=atmega128 -I. -gdwarf-2 -DF_CPU=800UL -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes
-Wa,-adhlns=./test.lst -std=gnu99 -Wundef -MMD -MP -MF .dep/test.o.d test.c -o
test.o
test.c:2: internal compiler error: in start_function, at c-decl.c:6014
Please submit a full bug report,
A program with the proper syntax, compiles without error:
int main(void) __attribute__ ((naked));
int main(void)
{
return 0;
}
--
Summary: ICE on invalid function attribute syntax for main()
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eweddington at cso dot atmel dot com
GCC build triplet: mingw
GCC host triplet: mingw
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #32 from janis at gcc dot gnu dot org 2007-03-23 21:15 --- Manuel, I'm starting to clean up tests so they can be used with or without the patch, like the fixes you've been posting. First I'm doing tests in gcc.dg/dfp. Let me know if there's an area you're not already looking at that I can do next. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug libfortran/31295] Uninitialized variable in libgfortran's _gfortran_eoshift0_4
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed|0 |1 Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-23 21:14:33 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31295
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #31 from janis at gcc dot gnu dot org 2007-03-23 20:51 ---
As for the puzzle in comment #30, I don't understand it either, but didn't try
very hard. This works for the current testsuite and the patch:
struct g g2 = { { 0, { 1 } } }; /* { dg-error "nested context.*g2.f.x" "nested"
} */
struct h { int x[0]; int y; };
struct h h1 = { { 0 }, 1 }; /* { dg-warning "excess elements.*h1.x" "before
end" } */
If you think it's important, Manuel, I'll try to figure out what was happening.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/31295] Uninitialized variable in libgfortran's _gfortran_eoshift0_4
--- Comment #1 from tkoenig at alice-dsl dot net 2007-03-23 20:14 --- The eoshift.f90 case is 'mostly harmless'. We are doing calculations with the value, but don't actually use this for anything. We can "fix" this (cosmetic fix for valgrind, really) by setting sstride[0] to an arbitray value that would cause a segfault if the value was actually used for anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31295
[Bug c++/31330] New: small template-use example crashes g++ w/internal error
/*
the following example crashes g++:
4:13pm [EMAIL PROTECTED] /wga/dev/ilya > g++ -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../configure --prefix=/wga1/gcc-4.1.1
Thread model: posix
gcc version 4.1.1
4:13pm [EMAIL PROTECTED] /wga/dev/ilya > echo $OSTYPE
linux
4:13pm [EMAIL PROTECTED] /wga/dev/ilya > echo $MACHTYPE
ia64
4:13pm [EMAIL PROTECTED] /wga/dev/ilya > g++ t2.cc
t2.cc:8: internal compiler error: in is_ancestor, at cp/name-lookup.c:
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
4:13pm [EMAIL PROTECTED] /wga/dev/ilya >
*/
class A {
template void foo(B b) {
}
};
template
void SubOfB::bar(A a) {
a.foo(*this);
}
--
Summary: small template-use example crashes g++ w/internal error
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ilya at broad dot mit dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31330
[Bug java/31325] gcj support for ARM EABI
--- Comment #9 from tromey at gcc dot gnu dot org 2007-03-23 19:32 --- I didn't read the patches yet. Do you have a copyright assignment? That is a prerequisite for getting these changes in. Once that is resolved we can proceed with the normal patch review process. If you don't have one, send me email and I will get you started. It doesn't take long, usually. If you do have one, the best thing to do is send each patch as a separate email (with ChangeLog entry & other stuff documented in the submission docs) to the java-patches list. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-23 19:32:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug c++/31326] data members in multiple inheritance
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-23 18:33 --- Subject: Re: data members in multiple inheritance "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Maybe this is not obvious to me why this is valid code, why is this | valid code? paragrpah 10.2/2 from the C++ standard. d->x should resolve unambiously to d->C::x, because C::x hides A::x and B::x. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31326
[Bug libgcj/24154] Make requires too much memory building libjava
--- Comment #7 from s_j_newbury at yahoo dot co dot uk 2007-03-23 18:16 --- make version 3.81 on Gentoo (ARM EABI) needs 712MB at this point with gcc-4.2-20070307. I've had to use a CF disk to add enough swapspace :(. make 3.80-r4 (Gentoo includes a memory usage patch) uses even more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
[Bug target/31242] Problem while compiling gcc for bfin-elf
--- Comment #2 from mstein at phenix dot rootshell dot be 2007-03-23 17:24 --- The Revision 123136 no longer has the reported problem. -- mstein at phenix dot rootshell dot be changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31242
[Bug target/31255] host gcc segfaults
--- Comment #4 from mstein at phenix dot rootshell dot be 2007-03-23 17:19 --- The Revision 123119 no longer has the reported problem. -- mstein at phenix dot rootshell dot be changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31255
[Bug target/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #10 from rth at gcc dot gnu dot org 2007-03-23 16:31 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug fortran/31199] write with "t1" + nonadvancing transfer format gives wrong output
--- Comment #10 from patchapp at dberlin dot org 2007-03-23 16:20 --- Subject: Bug number PR31199 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-03/msg01554.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug c++/31328] Temporary object incorrectly parsed as confilcint declaration
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-23 16:17 --- IIRC this is what the C++ standard says this is parsed as. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
[Bug c++/31328] Temporary object incorrectly parsed as confilcint declaration
--- Comment #3 from danq at acacetus dot com 2007-03-23 16:14 --- Created an attachment (id=13270) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13270&action=view) The preprocessed output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
[Bug c++/31328] Temporary object incorrectly parsed as confilcint declaration
--- Comment #2 from danq at acacetus dot com 2007-03-23 16:14 --- Created an attachment (id=13269) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13269&action=view) The compiler output and error messages -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
[Bug c++/31328] Temporary object incorrectly parsed as confilcint declaration
--- Comment #1 from danq at acacetus dot com 2007-03-23 16:13 --- Created an attachment (id=13268) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13268&action=view) Example C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
[Bug c++/31328] New: Temporary object incorrectly parsed as confilcint declaration
The C++ code below demonstrates how gcc treats an instance of a temporary as a
variable declaration instead. Without ugly syntax work-arounds, it is not
possible to instantiate the temporary.
[ Code Begins ]
struct Obj
{
int a ;
} ;
typedef Obj * Obj_P ;
class Foo
{
public :
inline Foo (Obj_P obj_p) : obj_p (obj_p)
{
}
private :
Obj_P obj_p ;
} ;
//--//
int main (void)
{
Obj_P obj_p = 0 ;
Foo (obj_p) ;// Error - Attempts to re-declare 'obj_p'
0,Foo (obj_p) ; // Ok - Comma operator
Foo ((0,obj_p)) ;// Ok - Comma operator
Foo (Obj_P(obj_p)) ; // Ok - Explicit type case
return 0 ;
}
[ Code Ends ]--
[ Compile Info Starts ]
Compiled with: gcc -v -save-temps main.cpp
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure
--verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs --without-x
--enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter
--disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm
--disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization
--enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -E -quiet -v -D__CYGWIN32__
-D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api
main.cpp -mtune=pentiumpro -o main.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include
/usr/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api
End of search list.
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=pentiumpro -auxbase main -version -o main.s
GNU C++ version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
(i686-pc-cygwin)
compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd
0.125).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
main.cpp: In function `int main()':
main.cpp:28: error: conflicting declaration 'Foo obj_p'
main.cpp:26: error: 'obj_p' has a previous declaration as `Obj*obj_p'
main.cpp:28: error: declaration of `Foo obj_p'
main.cpp:26: error: conflicts with previous declaration `Obj*obj_p'
main.cpp:28: error: no matching function for call to `Foo::Foo()'
main.cpp:10: note: candidates are: Foo::Foo(const Foo&)
main.cpp:13: note: Foo::Foo(Obj*)
[ Compile Info Ends ]-
[ Preprocessed Output Begins ]
# 1 "main.cpp"
# 1 ""
# 1 ""
# 1 "main.cpp"
struct Obj
{
int a ;
} ;
typedef Obj * Obj_P ;
class Foo
{
public :
inline Foo (Obj_P obj_p) : obj_p (obj_p)
{
}
private :
Obj_P obj_p ;
} ;
int main (void)
{
Obj_P obj_p = 0 ;
Foo (obj_p) ;
0,Foo (obj_p) ;
Foo ((0,obj_p)) ;
Foo (Obj_P(obj_p)) ;
return 0 ;
}
[ Preprocessed Output Ends ]
--
Summary: Temporary object incorrectly parsed as confilcint
declaration
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danq at acacetus dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
[Bug tree-optimization/26719] [4.1 Regression] Computed (integer) table changes with -O
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-03-23 15:54 --- > In regards to comment #13: In what tarball is this defect fixed? The 4.1.2 release as indicated by the target milestone and the known to work field. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.3 4.2.0 |4.0.3 4.2.0 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug tree-optimization/26719] [4.1 Regression] Computed (integer) table changes with -O
--- Comment #15 from thutt at vmware dot com 2007-03-23 15:51 --- In regards to comment #13: In what tarball is this defect fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug c++/31326] data members in multiple inheritance
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-23 15:48 --- Maybe this is not obvious to me why this is valid code, why is this valid code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31326
[Bug tree-optimization/26719] [4.1 Regression] Computed (integer) table changes with -O
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-23 15:37 --- *** Bug 31327 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||thutt at vmware dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug c/31327] Cast on expression using induction variable not honored at O1 and O2
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-23 15:37 --- *** This bug has been marked as a duplicate of 26719 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
[Bug c++/19351] operator new[] can return heap blocks which are too small
--- Comment #12 from fw at deneb dot enyo dot de 2007-03-23 15:23 --- Subject: Re: operator new[] can return heap blocks which are too small * mmitchel at gcc dot gnu dot org: > What does the C standard say about calloc? That's a similar case; the > multiplication is in calloc. Does it have to report an error? My interpretation is that it must return NULL. (This was fixed in GNU libc years ago.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
[Bug java/31325] gcj support for ARM EABI
--- Comment #8 from s_j_newbury at yahoo dot co dot uk 2007-03-23 15:20 --- I've now hit: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154 I only have 64M RAM + 256M swap, make is running out of memory and getting killed. Maybe I can add some more swap over NFS...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug c++/19351] operator new[] can return heap blocks which are too small
--- Comment #11 from schwab at suse dot de 2007-03-23 15:09 --- "The calloc function allocates space for an array of nmemb objects, each of whose size is size." There is no mentioning of overflow, but the allocated space must surely be big enough to hold the array, and calloc shall fail if it cannot fulfill the request. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
[Bug c/31327] Cast on expression using induction variable not honored at O1 and O2
--- Comment #3 from thutt at vmware dot com 2007-03-23 15:03 --- Created an attachment (id=13267) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13267&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
[Bug c/31327] Cast on expression using induction variable not honored at O1 and O2
--- Comment #2 from thutt at vmware dot com 2007-03-23 15:03 --- Created an attachment (id=13266) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13266&action=view) Simple source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
[Bug c/31327] Cast on expression using induction variable not honored at O1 and O2
--- Comment #1 from thutt at vmware dot com 2007-03-23 15:02 --- Created an attachment (id=13265) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13265&action=view) Simple script to build test program at all optimization levels -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
[Bug c/31327] New: Cast on expression using induction variable not honored at O1 and O2
gcc information:
Using built-in specs.
Target: i686-linux
Configured with: ../gcc-4.1.1/configure
--prefix=/build/toolchain/lin32/gcc-4.1.1 --disable-nls --enable-shared
--enable-threads=posix --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--target=i686-linux
--with-as=/build/toolchain/lin32/binutils-2.16.1-vt/bin/i686-linux-as
--with-ld=/build/toolchain/lin32/binutils-2.16.1-vt/bin/i686-linux-ld
--enable-__cxa_atexit --with-sysroot=/build/toolchain/lin32/glibc-2.2.5-44
--disable-tls
Thread model: posix
gcc version 4.1.1
When using the following script (which is probably only suitable for
my work environment):
#!/bin/bash
SRCDIR="/tmp/gcc4-error";
GCC4="/build/toolchain/lin32/gcc-4.1.1/bin/i686-linux-gcc
--sysroot=/build/toolchain/lin32/glibc-2.2.5-44";
${GCC4} -v
for OPT in $(seq 0 3) ; do
OUTPUT="${SRCDIR}/error-O${OPT}";
GCC_OPT="-Wall -Werror -O${OPT} -g3 --save-temps";
echo "Executing with optimization -O${OPT}"
rm -f ${OUTPUT};
${GCC4} ${GCC_OPT} -o ${OUTPUT} ${SRCDIR}/error.c
${OUTPUT}
done;
to compile the following source:
#include
static const int loop_start = 118;
static const int loop_end = 127;
void fails_0_at_O1_O2(char *arr, int l)
{
int i;
for (i = loop_start; i < loop_end; ++i) {
printf("%s: arr[%3d] = %4d\t(char)(i + 5) = %3d\n",
__PRETTY_FUNCTION__, i, arr[i], (char)(i + 5));
}
printf("\n");
}
void fails_1_at_O1_O2(char *arr, int l)
{
int i;
for (i = loop_start; i < loop_end; ++i) {
char v = i + 5;
printf("%s: arr[%3d] = %4d\tv = %3d\n",
__PRETTY_FUNCTION__, i, arr[i], v);
}
printf("\n");
}
void works_at_all_O_levels(char *arr, int l)
{
int i;
for (i = loop_start; i < loop_end; ++i) {
volatile char v = i + 5;
printf("%s: arr[%3d] = %4d\tv = %3d\n",
__PRETTY_FUNCTION__, i, arr[i], v);
}
printf("\n");
}
int main(void)
{
const int l = 190;
char arr[256];
int i;
for (i = 0; i < l; ++i) {
arr[i] = (char)(i + 5);
}
fails_0_at_O1_O2(arr, l);
fails_1_at_O1_O2(arr, l);
works_at_all_O_levels(arr, l);
return 0;
}
At optimization levels {0..3}, the compiler does not honor the cast of
the 'i + 5' at levels O1 and O2.
The output for all optimization levels, around the boundary case, is
shown below. Notice how the value based on the induction variable
does not wrap to -128 in O1 and O2.
Executing with optimization -O0
fails_0_at_O1_O2: arr[118] = 123 (char)(i + 5) = 123
fails_0_at_O1_O2: arr[119] = 124 (char)(i + 5) = 124
fails_0_at_O1_O2: arr[120] = 125 (char)(i + 5) = 125
fails_0_at_O1_O2: arr[121] = 126 (char)(i + 5) = 126
fails_0_at_O1_O2: arr[122] = 127 (char)(i + 5) = 127
fails_0_at_O1_O2: arr[123] = -128 (char)(i + 5) = -128
fails_0_at_O1_O2: arr[124] = -127 (char)(i + 5) = -127
fails_0_at_O1_O2: arr[125] = -126 (char)(i + 5) = -126
fails_0_at_O1_O2: arr[126] = -125 (char)(i + 5) = -125
fails_1_at_O1_O2: arr[118] = 123 v = 123
fails_1_at_O1_O2: arr[119] = 124 v = 124
fails_1_at_O1_O2: arr[120] = 125 v = 125
fails_1_at_O1_O2: arr[121] = 126 v = 126
fails_1_at_O1_O2: arr[122] = 127 v = 127
fails_1_at_O1_O2: arr[123] = -128 v = -128
fails_1_at_O1_O2: arr[124] = -127 v = -127
fails_1_at_O1_O2: arr[125] = -126 v = -126
fails_1_at_O1_O2: arr[126] = -125 v = -125
works_at_all_O_levels: arr[118] = 123v = 123
works_at_all_O_levels: arr[119] = 124v = 124
works_at_all_O_levels: arr[120] = 125v = 125
works_at_all_O_levels: arr[121] = 126v = 126
works_at_all_O_levels: arr[122] = 127v = 127
works_at_all_O_levels: arr[123] = -128v = -128
works_at_all_O_levels: arr[124] = -127v = -127
works_at_all_O_levels: arr[125] = -126v = -126
works_at_all_O_levels: arr[126] = -125v = -125
Executing with optimization -O1
fails_0_at_O1_O2: arr[118] = 123 (char)(i + 5) = 123
fails_0_at_O1_O2: arr[119] = 124 (char)(i + 5) = 124
fails_0_at_O1_O2: arr[120] = 125 (char)(i + 5) = 125
fails_0_at_O1_O2: arr[121] = 126 (char)(i + 5) = 126
fails_0_at_O1_O2: arr[122] = 127 (char)(i + 5) = 127
fails_0_at_O1_O2: arr[123] = -128 (char)(i + 5) = 128
fails_0_at_O1_O2: arr[124] = -127 (char)(i + 5) = 129
fails_0_at_O1_O2: arr[125] = -126 (char)(i + 5) = 130
fails_0_at_O1_O2: arr[126] = -125 (char)(i + 5) = 131
fails_1_at_O1_O2: arr[118] = 123 v = 123
fails_1_at_O1_O2: arr[119] = 124 v = 124
fails_1_at_O1_O2: arr[120] = 125 v = 125
fails_1_at_O1_O2: arr[121] = 126 v = 126
fails_1_at_O1_
[Bug c++/19351] operator new[] can return heap blocks which are too small
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-03-23 15:00 --- What does the C standard say about calloc? That's a similar case; the multiplication is in calloc. Does it have to report an error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
[Bug c++/31315] internal compiler error on mis-spelled syntax
--- Comment #3 from bangerth at dealii dot org 2007-03-23 14:09 --- Confirmed, but this has already been fixed after release 3.4.4 and before release 3.4.5. None of the newer releases are affected. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31315
[Bug c++/31326] data members in multiple inheritance
--- Comment #1 from gdr at gcc dot gnu dot org 2007-03-23 13:45 --- . -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-23 13:45:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31326
[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
--- Comment #11 from joseph at codesourcery dot com 2007-03-23 13:41 --- Subject: Re: [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation On Fri, 23 Mar 2007, pinskia at gmail dot com wrote: > No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its That depends on an analysis of every caller of STRIP_SIGN_NOPS to work out what semantics they require and whether removing conversions changing the value is correct in that case. Only then can you determine whether STRIP_SIGN_NOPS should have the present semantics and some subset of callers should be changed to work with those semantics, or whether the semantics of STRIP_SIGN_NOPS would better be changed. On the whole I think that references to the mode in STRIP_NOPS and STRIP_SIGN_NOPS are rather doubtful - mode should not be of relevance at this level of tree optimizations - and mode is probably being used as a proxy for precision. The general sequence of integer type conversions can be represented in the form "truncate to M bits, sign-extend to N bits and then zero-extend to the width of the outer type", maybe this should be represented somehow; then it would be defined exactly what such conversions can be removed by these macros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug c++/31326] New: data members in multiple inheritance
G++ incorrectly rejects the following valid code
struct A { int x; };
struct B { int x; };
struct C : virtual A, virtual B { int x; };
struct D : virtual A, virtual B, virtual C { };
int main()
{
D* d = new D();
d->x = 42;
}
--
Summary: data members in multiple inheritance
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gdr at gcc dot gnu dot org
GCC host triplet: platform independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31326
[Bug java/31325] gcj support for ARM EABI
--- Comment #7 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:22 --- Created an attachment (id=13264) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13264&action=view) arm-iwmmxt-linux-gnueabi platform support I'm using arm-iwmmxt-linux-gnueabi instead of arm-none-linux-gnueabi which needs this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug java/31325] gcj support for ARM EABI
--- Comment #6 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:13 --- I have encountered a strange build failure with classpath. It is somehow getting the build order wrong resulting in this error: /home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/gcc/gcj -B/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/arm-iwmmxt-linux-gnueabi/libjava/ -B/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/gcc/ -Wno-deprecated --encoding=UTF-8 --bootclasspath '' --classpath ..:/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava:/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/arm-iwmmxt-linux-gnueabi/libjava:/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath:/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath/external/w3c_dom:/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath/external/sax:/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath/external/relaxngDatatype:.:: -C -d . -MD -MF lists/gnu-CORBA-DynAn.deps -MT lists/gnu-CORBA-DynAn.stamp -MP @lists/gnu-CORBA-DynAn.list /home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath/java/lang/Throwable.java:44: error: Class or interface 'java.io.Serializable' not found in import. import java.io.Serializable; ^ /home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/gcc-4.2-20070307/libjava/classpath/java/lang/Throwable.java:107: error: Superinterface 'Serializable' of class 'java.lang.Throwable' not found. public class Throwable implements Serializable ^ Manually building java.io.Serializable allows the build to continue. Why is this happening? It doesn't happen with i686 or x86_64 with the same snapshot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug java/31325] gcj support for ARM EABI
--- Comment #5 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:11 --- --disable-sjlj-exceptions needs to be supplied to configure since it is not automatically detected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug java/31325] gcj support for ARM EABI
--- Comment #4 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:08 --- Created an attachment (id=13263) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13263&action=view) enable the libgcj interpreter for arm platforms -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug java/31325] gcj support for ARM EABI
--- Comment #3 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:03 --- Created an attachment (id=13262) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13262&action=view) EABI can't implement _Unwind_Backtrace This patch is from this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug fortran/31306] ICE with implicit character variables
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-23 12:55 --- This is a case of cyclic specification so I have changed the keyword to ice-on-ivalid. Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|ice-on-valid-code |ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2007-03-23 12:55:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31306
[Bug java/31325] gcj support for ARM EABI
--- Comment #2 from s_j_newbury at yahoo dot co dot uk 2007-03-23 12:55 --- Created an attachment (id=13261) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13261&action=view) add softfloat support to libffi for ARM EABI -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug java/31325] gcj support for ARM EABI
--- Comment #1 from s_j_newbury at yahoo dot co dot uk 2007-03-23 12:53 --- Created an attachment (id=13260) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13260&action=view) libffi completion support for ARM EABI -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug java/31325] New: gcj support for ARM EABI
Currently there is no gcj support on the ARM EABI platform. I have gathered together a number of patches that allow it to build and will be attaching them to this bug. I would like to see this moving forward and getting support into mainline, there are inevitably going to be issues. -- Summary: gcj support for ARM EABI Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: s_j_newbury at yahoo dot co dot uk GCC build triplet: arm-*-linux-gnueabi GCC host triplet: arm-*-linux-gnueabi GCC target triplet: arm-*-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug target/31319] Make big alignment for structs/arrays configurable
--- Comment #3 from vda dot linux at googlemail dot com 2007-03-23 12:00
---
You are right, in current svn it is fixed.
BTW I think I see a bug created by this change: with -Os x86_86 ABI will be
violated - arrays larger than 16 bytes will still be aligned only to 4 bytes
because if's are in wrong order. shouldn't they be swapped?
(nitpicking: if comment is true, then second if should check that object is an
*array*, not a *struct*, but it doesn't seem to do it)
int max_align = optimize_size ? BITS_PER_WORD : 256;
if (AGGREGATE_TYPE_P (type)
&& TYPE_SIZE (type)
&& TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
&& (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= (unsigned) max_align
|| TREE_INT_CST_HIGH (TYPE_SIZE (type)))
&& align < max_align)
align = max_align;
/* x86-64 ABI requires arrays greater than 16 bytes to be aligned
to 16byte boundary. */
if (TARGET_64BIT)
{
if (AGGREGATE_TYPE_P (type)
&& TYPE_SIZE (type)
&& TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
&& (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 128
|| TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < 128)
return 128;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31319
[Bug fortran/31234] Thread-safety of random_number should be documented.
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-03-23 10:05 --- > I'll run some tests as soon as possible and report back to the mailing list. See http://gcc.gnu.org/ml/fortran/2007-03/msg00440.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31234
[Bug c++/31315] internal compiler error on mis-spelled syntax
--- Comment #2 from ahmadyan at gmail dot com 2007-03-23 09:46 ---
Created an attachment (id=13259)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13259&action=view)
the ii file of the problem.
the following code can trigger the bug in g++ version 4.2 with the following
specs:
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable
-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared
--e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x
--enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
=
#include
#include
#include
using namespace std;
int main(){
vector v ;
v.reserve(10);
v.push_back(1); v.push_back(2);
copy( v.begin() , v.end(). ostream_iterator(cout, "\n") );
return 0 ;
}
==
P.S. again, the above code has a syntax error, just after the v.end() there
should be a "," not "."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31315
[Bug c/31324] Building libgcc2 on x86_64 for m68k-elf: internal compiler error: in do_SUBST, at combine.c:462
--- Comment #4 from zdenekjs at sarpeidon dot net 2007-03-23 08:52 --- only occurs on x86_64 host. If I switch machines to a i686 and compile, error does not occur. Error still occurs even if I configure with --host=i686-linux on the x86_64-unknown-linux-gnu machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31324
[Bug c/31324] Building libgcc2 on x86_64 for m68k-elf: internal compiler error: in do_SUBST, at combine.c:462
--- Comment #3 from zdenekjs at sarpeidon dot net 2007-03-23 08:50 --- Same internal error appears to happen in 4.1.2 and 3.4.6 as well -- zdenekjs at sarpeidon dot net changed: What|Removed |Added CC||zdenekjs at sarpeidon dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31324
[Bug c/31324] Building libgcc2 on x86_64 for m68k-elf: internal compiler error: in do_SUBST, at combine.c:462
--- Comment #2 from zdenekjs at sarpeidon dot net 2007-03-23 08:48 --- Created an attachment (id=13258) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13258&action=view) Assembly output saved with -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31324
[Bug c/31324] Building libgcc2 on x86_64 for m68k-elf: internal compiler error: in do_SUBST, at combine.c:462
--- Comment #1 from zdenekjs at sarpeidon dot net 2007-03-23 08:47 --- Created an attachment (id=13257) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13257&action=view) preprocessed file saved with -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31324
[Bug c/31324] New: Building libgcc2 on x86_64 for m68k-elf: internal compiler error: in do_SUBST, at combine.c:462
Compiling gcc 4.0.4 with a target of m68k-elf on a x86_64 Linux architecture (SuSE 10.1), an internal error is generated when compiling libgcc2.c: Command line that generated internal error: /home/zdenekjs/68k/gcc-4.0.4-build/gcc/xgcc -B/home/zdenekjs/68k/gcc-4.0.4-build/gcc/ -nostdinc -B/home/zdenekjs/68 k/gcc-4.0.4-build/m68k-elf/newlib/ -isystem /home/zdenekjs/68k/gcc-4.0.4-build/m68k-elf/newlib/targ-include -isyste m /home/zdenekjs/68k/gcc-4.0.4/newlib/libc/include -B/usr/local/m68k-elf/m68k-elf/bin/ -B/usr/local/m68k-elf/m68k-e lf/lib/ -isystem /usr/local/m68k-elf/m68k-elf/include -isystem /usr/local/m68k-elf/m68k-elf/sys-include -O2 -DIN_G CC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isy stem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-4.0.4/gcc -I../../gcc -4.0.4/gcc/. -I../../gcc-4.0.4/gcc/../include -I../../gcc-4.0.4/gcc/../libcpp/include -m68000 -DL_fixdfdi -c ../.. /gcc-4.0.4/gcc/libgcc2.c -o libgcc/m68000/_fixdfdi.o Output: ./../gcc-4.0.4/gcc/libgcc2.c: In function â__fixdfdiâ: ../../gcc-4.0.4/gcc/libgcc2.c:1256: internal compiler error: in do_SUBST, at combine.c:462 Please submit a full bug report, -- Summary: Building libgcc2 on x86_64 for m68k-elf: internal compiler error: in do_SUBST, at combine.c:462 Product: gcc Version: 4.0.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zdenekjs at sarpeidon dot net GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: m68k-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31324
[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-23 08:17 --- The good question is why does FRE not do anything on the trunk: s.b6 = 31; D.1597_1 = s.b6; that really should be optimized at the FRE level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
--- Comment #9 from pinskia at gmail dot com 2007-03-23 08:01 --- Subject: Re: [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation On 3/23/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org > <[EMAIL PROTECTED]> wrote: > > The problematic STRIP_SIGN_NOPS() call is from fold_unary() > > which is called from try_combine_conversion() in tree-ssa-pre.c. > > > > STRIP_SIGN_NOPS() is called with the expression: > > No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its > folding. It should have called fold_convert on the expression if the > types are different and it is a constant. Ok, the real issue is that we call fold with NOP_EXPR> instead of just NOP_EXPR so you have to figure out where we should fold the first NOP_EXPR instead of that patch. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
Re: [Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
On 3/23/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > The problematic STRIP_SIGN_NOPS() call is from fold_unary() > which is called from try_combine_conversion() in tree-ssa-pre.c. > > STRIP_SIGN_NOPS() is called with the expression: No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its folding. It should have called fold_convert on the expression if the types are different and it is a constant. Ok, the real issue is that we call fold with NOP_EXPR> instead of just NOP_EXPR so you have to figure out where we should fold the first NOP_EXPR instead of that patch. -- Pinski
