PATCH: DWARF2 macinfo-related fixes for gdb and gcc
[skip to the end if you just want the patches without the storyline]
Jochen Voss writes the following:
>
>when trying to debug one of my programs I encountered a case where gdb
>crashed on the command "break main" before my programm was even
>started. The problem occurs on a powerpc machine.
After investigating, I don't see anything ppc-specific about this bug.
The actual occurrence of the segfault may vary between architectures, but
that's just because some may get lucky when dereferencing the bad pointer.
>http://seehuhn.de/data/gdb-bug - the binary
>http://seehuhn.de/data/gdb-bug.i - the preprocessed source
[...]
>(gdb) break main
>Segmentation fault
It also has nothing to do with setting a breakpoint, or with your main
function. You can also try "print main", "break load_matrix", ... the key is
convincing gdb that it needs to parse the debugging symbols.
>2) Regenerating the binary. The binary gdb-bug was compiled from
>gdb-bug.i using the following two commands:
>
>[EMAIL PROTECTED] [~/y] gcc -ggdb3 -c gdb-bug.i
>[EMAIL PROTECTED] [~/y] gcc -ggdb3 -o gdb-bug gdb-bug.o -lm -llapack
> -lblas -lg2c
When done with gcc 3.3 or 3.4, the resulting executable does not segfault
gdb. I can see from your binary that you were using Debian's gcc 4.0.1-1. I
can also reproduce the bug with the current upstream source, 4.0.2. (gcc 4.0
hasn't made it into Debian stable yet).
Also, your use of -ggdb3 is an important part of reproducing the bug. Normal
-g doesn't include debugging information for macros, and that's where the
problem is. (-gdwarf-2 -g3 is also sufficient, or just -g3 since DWARF2 seems
to be the default format now)
To see what is going wrong, do a "readelf -w gdb-bug.o" and look at the
.debug_macinfo section. You'll see that it references sources files by
number, starting at 1 and ending at 47:
...
DW_MACINFO_start_file - lineno: 21 filenum: 46
DW_MACINFO_end_file
DW_MACINFO_start_file - lineno: 22 filenum: 47
Those filenums refer to "The File Name Table" (located earlier in the
readelf -w output). If you take a look at The File Name Table, you'll see
that it has only 46 entries. And that's why gdb segfaults. Now we know how to
fix gdb: make it check that filenum is in the proper range.
But we want to fix the bad debugging information, not just the segfault. Go
back to the .debug_macinfo section, look closer, and you'll see that there
are no references to filenum 16. It goes 1,2,3,...15,17,18,...47 (some
numbers are repeated because files get #included more than once, but if you
look just at the first appearance of each number, they are in order.)
When gcc was building this table of #included files, it was also keeping
track of #includes for error reporting purposes. There are 2 lists of
#included files: one for errors and warnings, and the other for DWARF2
debugging information. The missing file number 16 corresponds to the special
pseudo-file "" in the list of source files. "" is omitted
from the DWARF2 file table because it's not an actual file.
There is a function called maybe_emit_file() in gcc, which assigns the
filenums, and takes care of mapping the file numbers in the main file list
to the file numbers in the DWARF2 list. Someone forgot to use the return
value of maybe_emit_file() when creating the DW_MACINFO_start_file record, so
what should be a reference to file number 16 comes out instead as a reference
to file number 17. After the 16th entry, every filenum is 1 larger than it
should be. The reference to file number 47 should really be a reference to
file number 46.
Because all file numbers after the missing one are off by 1, most of the
macro debugging information is going to be referring to the wrong file. So
even if gdb doesn't segfault, it's still going to report the wrong origin for
macros defined after the bug's trigger point (file 16 in the sample).
It would be possible to make gdb detect an out-of-sequence filenum and
automatically adjust it and all of the following filenums, with a warning
message like "Detected GCC 4.0.<=2 macinfo breakage, working around it". My
patch doesn't go that far; it just prevents the segfault.
Here are the patches. In case of mail corruption, they're also here:
http://world.std.com/~pacman/gcc4-dwarf-macinfo.diff
http://world.std.com/~pacman/gdb-macinfo-segfault.diff
--- gdb-6.3.orig/gdb/dwarf2read.c 2005-10-17 23:22:46.0 -0500
+++ gdb-6.3/gdb/dwarf2read.c2005-10-18 00:38:48.0 -0500
@@ -9087,9 +9087,14 @@
file = read_unsigned_leb128 (abfd, mac_ptr, &bytes_read);
mac_ptr += bytes_read;
-current_file = macro_start_file (file, line,
- current_file, comp_dir,
- lh, cu->objfile);
+if (file > lh->num_file_names)
+ warning ("macro debug info references file %d, "
+ "but file table only contains %u
[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP
--- Comment #18 from bonzini at gcc dot gnu dot org 2005-10-18 08:36 --- Steven, how does your df.c-based cprop fare on this testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug fortran/24424] New: Equivalence broken since 20051013
This test, which is reduced from a test that Jakub reduced from the Polyhedron
test_fpu.f90, segfaults in execution.
integer, dimension (8388608) :: i, j, k
equivalence (i(1), j(10))
i = 5
k = i
end
$ /irun/bin/gfortran -fmax-stack-var-size=100 JAKUBS_TEST.f90
[EMAIL PROTECTED] /cygdrive/d/gfortran/pb04/lin/f90
$ ./a
Segmentation fault (core dumped)
It does this for any optimization/options that I have tried.
The code produced is
MAIN__ ()
{
static union
{
int4 j[8388608];
int4 i[8388608];
} equiv.0;
static int4 j[8388608];
static int4 i[8388608];
static int4 k[8388608];
{
int4 S.0;
S.0 = 1;
while (1)
{
if (S.0 > 8388608) goto L.1; else (void) 0;
i[NON_LVALUE_EXPR + -1] = 5;
S.0 = S.0 + 1;
}
L.1:;
}
{
int4 S.1;
S.1 = 1;
while (1)
{
if (S.1 > 8388608) goto L.2; else (void) 0;
k[NON_LVALUE_EXPR + -1] = i[NON_LVALUE_EXPR + -1];
S.1 = S.1 + 1;
}
L.2:;
}
}
whereas a working version of gfortran produces
MAIN__ ()
{
static union
{
int4 j[8388608];
int4 i[8388608];
} equiv.0;
static int4 k[8388608];
{
int4[8388608] * D.481;
D.481 = &equiv.0.i;
{
int4 S.0;
S.0 = 1;
while (1)
{
if (S.0 > 8388608) goto L.1; else (void) 0;
(*D.481)[NON_LVALUE_EXPR + -1] = 5;
S.0 = S.0 + 1;
}
L.1:;
}
}
{
int4[8388608] * D.484;
D.484 = &equiv.0.i;
{
int4 S.1;
S.1 = 1;
while (1)
{
if (S.1 > 8388608) goto L.2; else (void) 0;
k[NON_LVALUE_EXPR + -1] = (*D.484)[NON_LVALUE_EXPR + -1];
S.1 = S.1 + 1;
}
L.2:;
}
}
}
Notice the appearance in the broken version of non-union static arrays for i
and j, which are what the subsequent code refers to. I understand from the
list that this is not what it appears to be but looks, walks and squits
like a duck to me!
Paul T
--
Summary: Equivalence broken since 20051013
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paul dot richard dot thomas at cea dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24424
[Bug target/19672] [3.4/4.0/4.1 Regression] Performance regression in simple loop code
--- Comment #9 from bonzini at gcc dot gnu dot org 2005-10-18 09:48 --- Can anybody try killloop-branch? Just a wild guess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug fortran/24424] Equivalence broken since 20051013
--- Comment #1 from rth at gcc dot gnu dot org 2005-10-18 09:48 --- So, when was your last update? AFAIK this was fixed 3 days ago. I've just now tested again on amd64-linux and see MAIN__: .LFB2: movl$equiv.0.898, %eax movl$equiv.0.898+33554432, %edx .L2: movl$5, 36(%rax) addq$4, %rax cmpq%rdx, %rax jne .L2 movl$0, %edx .L4: movlequiv.0.898+36(,%rdx,4), %eax movl%eax, k.901(,%rdx,4) incq%rdx cmpq$8388608, %rdx jne .L4 ret No stack allocation at all. No references to I or J, only equiv.0.898. The data segment contains .local k.901 .comm k.901,33554432,32 .local equiv.0.898 .comm equiv.0.898,33554468,32 which looks correct as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24424
[Bug target/19672] [3.4/4.0/4.1 Regression] Performance regression in simple loop code
--- Comment #10 from bonzini at gcc dot gnu dot org 2005-10-18 09:55 --- There is also a (minor) register allocation problem in both outputs: 8048392: 0f be 01movsbl (%ecx),%eax! | 8048395: 0f be 13movsbl (%ebx),%edx! | 8048398: 29 c2 sub%eax,%edx ! | 804839a: 89 d0 mov%edx,%eax ! | 804839c: 74 e2 je 8048380! --+ This could obviously become 8048392: 0f be 11movsbl (%ecx),%edx 8048395: 0f be 03movsbl (%ebx),%eax 8048398: 2b c2 sub%edx,%eax 804839c: 74 e2 je 8048380 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug fortran/24424] Equivalence broken since 20051013
--- Comment #2 from prthomas at drfccad dot cea dot fr 2005-10-18 09:59 --- Subject: RE: Equivalence broken since 20051013 Richard, > > --- Comment #1 from rth at gcc dot gnu dot org > 2005-10-18 09:48 --- > So, when was your last update? AFAIK this was fixed 3 days ago. > I've just now tested again on amd64-linux and see > On the system that I am working upon 4 days ago. I will update right now! The odd thing is that I updated on my system at home and the fault was still there. I will check that the update worked correctly. If, as it looks like, I am wrong about this, please accept my profuse apologies. Regards Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24424
[Bug c++/24425] New: [4.0/4.1 Regression] Rejects code from kdegraphics3
kdegraphics3 contains auto-generated code that fails to build with recent
4.0/4.1
while it worked at least with
g++ (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)
Testcase:
class QString;
namespace DOM {
class __attribute__ ((visibility("default"))) DomShared {};
class NodeImpl;
class __attribute__ ((visibility("default"))) Node {
Node firstChild() const;
Node nextSibling() const;
bool hasChildNodes ( );
bool isNull() const { return !impl; }
NodeImpl *impl;
};
class __attribute__ ((visibility("default"))) Element : public Node {};
}
namespace KSVG {
class SVGDOMNodeBridge {};
class SVGDOMElementBridge : public SVGDOMNodeBridge {};
class SVGDocumentImpl;
class SVGElementImpl : virtual public DOM::DomShared, public DOM::Element,
public SVGDOMElementBridge
{
SVGDocumentImpl *ownerDoc() const;
};
class SVGHelperImpl {
template
static void applyContainer(T *obj, int token, const QString &value)
{
SVGElementImpl *element = dynamic_cast(obj);
for(DOM::Node node = element->firstChild(); !node.isNull(); node =
node.nextSibling())
T *cast = dynamic_cast(element->ownerDoc()->getElementFromHandle(node));
}
};
}
SVGLengthImpl.min.ii: In static member function static void
KSVG::SVGHelperImpl::applyContainer(T*, int, const QString&):
SVGLengthImpl.min.ii:28: error: invalid use of undefined type struct
KSVG::SVGDocumentImpl
SVGLengthImpl.min.ii:17: error: forward declaration of struct
KSVG::SVGDocumentImpl
--
Summary: [4.0/4.1 Regression] Rejects code from kdegraphics3
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24425
[Bug target/19672] [3.4/4.0/4.1 Regression] Performance regression in simple loop code
--- Comment #11 from bonzini at gcc dot gnu dot org 2005-10-18 10:07 --- The code I get from -mbranch-cost=1 is extremely similar to what 3.2.2 produced: .L7: cmpl%ebx, %edi jae .L2 cmpl%ecx, %esi jae .L2 decl%ebx movsbl -1(%ecx),%eax decl%ecx movsbl (%ebx),%edx subl%eax, %edx movl%edx, %eax je .L7 .L2: The front-end is correctly producing a TRUTH_AND_EXPR, i.e. the short-circuiting is not required. RTL expansion will use jae (short-circuited evaluation) or seta, depending on the branch cost. However, the tuning here is wrong because on a pentium4 I do get a 40% speedup from -mbranch-cost=1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug c++/24425] [4.0/4.1 Regression] Rejects code from kdegraphics3
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-18 10:22 --- I guess before we treated the whole expression T *cast = dynamic_cast(element->ownerDoc()->getElementFromHandle(node)); as dependent on T, while afterwards we try to resolve everything for the argument of the dynamic_cast<>. Whether the one or the other is the correct behavior is beyond my current knowledge. EDG accepts the testcase in non-strict mode, but rejects it with -strict_ansi. Maybe we can do the same with -fpermissive? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24425
[Bug fortran/24426] New: gfortran ICE for valid derived type definition with default initialization
The following testcase gives an internal compiler error with both gfortran 4.0.2 and gfortran 4.1.0 20051015: module crash implicit none type foo integer :: i = 0 type (foo), pointer :: next end type foo type (foo), save :: bar end module crash Remove the default initialization with 0 and it compiles just fine. (Remove the pointer declaration in the derived type and it compiles fine. Remove the declaration of variable bar and it compiles fine.) It reminds me a bit of bug 16606, but is different as the compiler crashes. Test case compiles fine with ifort Version 9.0 Build 20050809Z, G95 (GCC 4.0.1 (g95!) Oct 16 2005). -- gfortran 4.1 20051015 output: -- % /usr/local/gcc-4.1-20051015/bin/gfortran -v -save-temps -c bug-gfortran-4.1.f90 Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1-20051015/configure --enable-shared --prefix=/usr/local/gcc-4.1-20051015 --enable-languages=c,c++,fortran --enable-threads --enable-__cxa_atexit Thread model: posix gcc version 4.1.0 20051015 (experimental) /usr/local/gcc-4.1-20051015/libexec/gcc/i686-pc-linux-gnu/4.1.0/f951 bug-gfortran-4.1.f90 -quiet -dumpbase bug-gfortran-4.1.f90 -mtune=pentiumpro -auxbase bug-gfortran-4.1 -version -o bug-gfortran-4.1.s GNU F95 version 4.1.0 20051015 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20051015 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 bug-gfortran-4.1.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- gfortran 4.0.2 output: -- /usr/local/gcc-4.0.2/bin/gfortran -v -save-temps -c bug-gfortran-4.1.f90 Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.2/configure --enable-shared --prefix=/usr/local/gcc-4.0.2 --enable-languages=c,c++,f95 --enable-threads --enable-__cxa_atexit Thread model: posix gcc version 4.0.2 /usr/local/gcc-4.0.2/libexec/gcc/i686-pc-linux-gnu/4.0.2/f951 bug-gfortran-4.1.f90 -quiet -dumpbase bug-gfortran-4.1.f90 -mtune=pentiumpro -auxbase bug-gfortran-4.1 -version -o bug-gfortran-4.1.s GNU F95 version 4.0.2 (i686-pc-linux-gnu) compiled by GNU C version 4.0.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 bug-gfortran-4.1.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Environment: System: Linux antares 2.6.8-24.17-bigsmp #1 SMP Tue Jul 19 08:56:33 UTC 2005 i686 unknown unknown GNU/Linux Architecture: i686 Linux 2.6.8-24.17-bigsmp glibc 2.3.4 SuSE 9.2 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu % cat /proc/cpuinfo | grep "model name" model name : AMD Opteron(tm) Processor 250 -- Summary: gfortran ICE for valid derived type definition with default initialization Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sven dot buijssen at math dot uni-dortmund dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24426
[Bug target/19672] [3.4/4.0/4.1 Regression] Performance regression in simple loop code
--- Comment #12 from bonzini at gcc dot gnu dot org 2005-10-18 11:41 --- Created an attachment (id=10016) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10016&action=view) patch to fix the bug Indeed, RTL expansion will use jae (short-circuited evaluation) or seta, depending on the branch cost, but in a very involuted way which screws up the tuning. This patch makes it more direct. -- bonzini at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug fortran/24424] Equivalence broken since 20051013
--- Comment #3 from prthomas at drfccad dot cea dot fr 2005-10-18 11:54 --- Subject: RE: Equivalence broken since 20051013 Richard, Yes indeed - it is fixed. >From my log, I see that last night I only updated fortran and gfortran, thereby missing your patch. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24424
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
--- Comment #11 from simon dot strandman at telia dot com 2005-10-18 12:21 --- I'm using gcc 4.0.2 with patches for gcc pr19664, pr20297 and pr19520. The testcase from this bug passes without problems. Still firefox beta2 and current CVS fails to build. I talked to the mozilla guys and they asked me to report it here. Any ideas what might be wrong? x86_64-pc-linux-gnu-gcc -DGENTOO_NSPLUGINS_DIR=\"/usr/lib64/nsplugins\" -DGENTOO_NSBROWSER_PLUGINS_DIR=\"/usr/lib64/nsbrowser/plugins\" -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -march=athlon64 -pipe -fPIC -Wno-return-type -w -pthread -pipe -DNDEBUG -DTRIMMED -ffunction-sections -Os -fPIC -shared -Wl,-h -Wl,libmozjs.so -Wl,-R/usr/lib64/mozilla-firefox -o libmozjs.so jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jslock.o jslog2.o jslong.o jsmath.o jsnum.o jsobj.o jsopcode.o jsparse.o jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o jsxdrapi.o jsxml.o prmjtime.o-Wl,-O1 -Wl,-R/usr/lib64/mozilla-firefox -lm -ldl -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld: jsapi.o: relocation R_X86_64_PC32 against `memcpy@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status gmake[3]: *** [libmozjs.so] Error 1 gmake[3]: Leaving directory `/var/tmp/portage/mozilla-firefox-/work/mozilla/js/src' gmake[2]: *** [libs] Error 2 gmake[2]: Leaving directory `/var/tmp/portage/mozilla-firefox-/work/mozilla/js' gmake[1]: *** [tier_2] Error 2 gmake[1]: Leaving directory `/var/tmp/portage/mozilla-firefox-/work/mozilla' make: *** [default] Error 2 The version means that it's a CVS build in gentoo. Binutils is version 2.16.1 and glibc is 2.3.5. -- simon dot strandman at telia dot com changed: What|Removed |Added CC||simon dot strandman at telia ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP
--- Comment #19 from amacleod at redhat dot com 2005-10-18 12:25 --- Created an attachment (id=10017) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10017&action=view) patch for operand scan Now that correct_use_link is *only* used for real uses, it is no longer profitable to try to "shortcut" the search for the owner of a use list. The shortcut use to look at each previous node as the list was traversed, and check to see if the stmt was modified. If it wasn't, we knew that node was in the correct list and wouldnt have to scan all the way back to the owner. well, this testcase was spending almost all its time checking for stmt_modified_p something like 250,000,000 checks on 50,000 calls. I've removed the no longer useful shortcut, and the results are as follows: bootstrapped and no new regressions on i686-pc-linux-gnu. Andrew x86-64: -O1 on testcase: before patch tree operand scan : 8.00 (36%) TOTAL : 22.18 after patch: tree operand scan : 1.41 ( 9%) TOTAL : 15.62 -O2 on testcase: before patch tree operand scan : 7.88 (15%) TOTAL : 53.08 after patch: tree operand scan : 1.42 ( 3%) TOTAL : 46.94 x86: -O1 on testcase: before patch tree operand scan : 2.54 (17%) TOTAL : 14.60 after patch: tree operand scan : 1.01 ( 8%) TOTAL : 12.51 -O2 on testcase: before patch tree operand scan : 2.95 ( 8%) TOTAL : 39.20 after patch: tree operand scan : 1.06 ( 3%) TOTAL : 38.03 pretty much a wash on cc1-i and cpgram.cc testcases on both targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug c++/22604] [4.0/4.1 Regression] ICE after invalid covariant return
--- Comment #13 from cvs-commit at gcc dot gnu dot org 2005-10-18 12:30 --- Subject: Bug 22604 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-18 12:30:33 Modified files: gcc/cp : ChangeLog cp-tree.h class.c semantics.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/overload: error2.C gcc/testsuite/g++.dg/inherit: covariant14.C Log message: cp: PR c++/22604 * class.c (update_vtable_entry_for_fn): Don't process invalid covariant overriders. PR c++/23118 * cp-tree.h (add_method): Add return value. * class.c (add_method): Return success indicator. * semantics.c (finish_member_declaration): Don't add an invalid method to the method list. testsuite: PR c++/23118 * g++.dg/overload/error2.C: New. PR c++/22604 * g++.dg/inherit/covariant14.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4944&r2=1.4945 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1168&r2=1.1169 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.737&r2=1.738 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&r1=1.493&r2=1.494 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6207&r2=1.6208 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/overload/error2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/covariant14.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug c++/23118] [3.4/4.0/4.1 Regression] Another segmentation fault after improper overloading (BootView)
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-18 12:30 --- Subject: Bug 23118 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-18 12:30:33 Modified files: gcc/cp : ChangeLog cp-tree.h class.c semantics.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/overload: error2.C gcc/testsuite/g++.dg/inherit: covariant14.C Log message: cp: PR c++/22604 * class.c (update_vtable_entry_for_fn): Don't process invalid covariant overriders. PR c++/23118 * cp-tree.h (add_method): Add return value. * class.c (add_method): Return success indicator. * semantics.c (finish_member_declaration): Don't add an invalid method to the method list. testsuite: PR c++/23118 * g++.dg/overload/error2.C: New. PR c++/22604 * g++.dg/inherit/covariant14.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4944&r2=1.4945 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1168&r2=1.1169 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.737&r2=1.738 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&r1=1.493&r2=1.494 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6207&r2=1.6208 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/overload/error2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/covariant14.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23118
[Bug c++/22604] [4.0/4.1 Regression] ICE after invalid covariant return
--- Comment #14 from cvs-commit at gcc dot gnu dot org 2005-10-18 12:34 --- Subject: Bug 22604 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-18 12:34:30 Modified files: gcc/cp : ChangeLog cp-tree.h class.c semantics.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/overload: error2.C gcc/testsuite/g++.dg/inherit: covariant14.C Log message: cp: PR c++/22604 * class.c (update_vtable_entry_for_fn): Don't process invalid covariant overriders. PR c++/23118 * cp-tree.h (add_method): Add return value. * class.c (add_method): Return success indicator. * semantics.c (finish_member_declaration): Don't add an invalid method to the method list. testsuite: PR c++/23118 * g++.dg/overload/error2.C: New. PR c++/22604 * g++.dg/inherit/covariant14.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.142&r2=1.4648.2.143 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1106.2.17&r2=1.1106.2.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.707.2.8&r2=1.707.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.463.2.12&r2=1.463.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.466&r2=1.5084.2.467 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/overload/error2.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/covariant14.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug c++/23118] [3.4/4.0/4.1 Regression] Another segmentation fault after improper overloading (BootView)
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-18 12:34 --- Subject: Bug 23118 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-18 12:34:30 Modified files: gcc/cp : ChangeLog cp-tree.h class.c semantics.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/overload: error2.C gcc/testsuite/g++.dg/inherit: covariant14.C Log message: cp: PR c++/22604 * class.c (update_vtable_entry_for_fn): Don't process invalid covariant overriders. PR c++/23118 * cp-tree.h (add_method): Add return value. * class.c (add_method): Return success indicator. * semantics.c (finish_member_declaration): Don't add an invalid method to the method list. testsuite: PR c++/23118 * g++.dg/overload/error2.C: New. PR c++/22604 * g++.dg/inherit/covariant14.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.142&r2=1.4648.2.143 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1106.2.17&r2=1.1106.2.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.707.2.8&r2=1.707.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.463.2.12&r2=1.463.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.466&r2=1.5084.2.467 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/overload/error2.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/covariant14.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23118
[Bug c++/23118] [3.4/4.0/4.1 Regression] Another segmentation fault after improper overloading (BootView)
--- Comment #9 from nathan at gcc dot gnu dot org 2005-10-18 12:39 --- fixed mainline & 4.0 2005-10-18 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/22604 * class.c (update_vtable_entry_for_fn): Don't process invalid covariant overriders. PR c++/23118 * cp-tree.h (add_method): Add return value. * class.c (add_method): Return success indicator. * semantics.c (finish_member_declaration): Don't add an invalid method to the method list. wont fix 3.4 -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23118
[Bug c++/22604] [4.0/4.1 Regression] ICE after invalid covariant return
--- Comment #15 from nathan at gcc dot gnu dot org 2005-10-18 12:40 --- fixed mainline and 4.0 2005-10-18 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/22604 * class.c (update_vtable_entry_for_fn): Don't process invalid covariant overriders. PR c++/23118 * cp-tree.h (add_method): Add return value. * class.c (add_method): Return success indicator. * semantics.c (finish_member_declaration): Don't add an invalid method to the method list. wont fix 3.4 -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug fortran/22306] [4.0 only] ICE: segmentation fault
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-10-18 12:42 --- This bug disappeared in mainline CVS. However, with gfortran version 4.0.3 20051018 (prerelease), it is still there: $ ./bin/gfortran -c a.f90 a.f90:0: internal compiler error: Segmentation fault Backtrace: #0 gfc_resolve_expr (e=0xa44c488) at ../../gcc/gcc/fortran/resolve.c:551 #1 0x0807bb2d in gfc_resolve_expr (e=0xa44c260) at ../../gcc/gcc/fortran/resolve.c:557 #2 0x0807f328 in resolve_values (sym=0xa44c2f8) at ../../gcc/gcc/fortran/resolve.c:4071 #3 0x0808a154 in traverse_ns (st=0xa44c2d8, func=0x807f310 ) at ../../gcc/gcc/fortran/symbol.c:2328 #4 0x0807fcdf in gfc_resolve (ns=0xa44bef0) at ../../gcc/gcc/fortran/resolve.c:5287 #5 0x0807fc05 in gfc_resolve (ns=0xa44b818) at ../../gcc/gcc/fortran/resolve.c:5269 #6 0x080769e9 in gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:2622 #7 0x0808bd2a in gfc_be_parse_file (set_yydebug=0) at ../../gcc/gcc/fortran/f95-lang.c:265 #8 0x082d3fa5 in toplev_main (argc=2, argv=0xbf891f74) at ../../gcc/gcc/toplev.c:1010 #9 0x00861d5f in __libc_start_main () from /lib/libc.so.6 #10 0x0804aba1 in _start () -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.3 Known to work||4.1.0 Summary|ICE: segmentation fault |[4.0 only] ICE: segmentation ||fault Version|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22306
[Bug c++/24421] #pragma interface and warning about undefined synthesized operator=
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 12:43 --- *** This bug has been marked as a duplicate of 22252 *** -- 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=24421
[Bug c++/22252] [4.0 Regression] pragma interface/implementation still break synthesized methods
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-18 12:43 --- *** Bug 24421 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||das at cs dot ucla dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
[Bug c++/24248] [4.0 Regression] Segmentation fault on valid code w/ -O2 -finline-functions
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-18 12:43 --- *** This bug has been marked as a duplicate of 22252 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24248
[Bug c++/22252] [4.0 Regression] pragma interface/implementation still break synthesized methods
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-18 12:43 --- *** Bug 24248 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||halcy0n at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
[Bug c++/24425] [4.0/4.1 Regression] Rejects code from kdegraphics3
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-18 12:56 ---
Reduced testcase:
class SVGDocumentImpl;
class SVGElementImpl
{
SVGDocumentImpl *ownerDoc() const;
};
template
void applyContainer(SVGElementImpl *element)
{
dynamic_cast(element->ownerDoc()->getElementFromHandle());
}
I don't think we should allow this at all even in premissive mode because it
does not make sense at all that the expression
"element->ownerDoc()->getElementFromHandle()" is dependent at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24425
[Bug fortran/24424] Equivalence broken since 20051013
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-18 13:06 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24424
[Bug tree-optimization/24427] New: missing optimization opportunity with binary operators
In the code below, the test is always true and could be found as such by using
distributivity on binary operators to factor out constant values. This is not
currently done, by looking at the assembly code produced.
extern int f(unsigned);
int f(unsigned u)
{
if( (u|4) & 6 ) /* could be tested as (u&6) || (4&6), always true */
return 5;
else
return 10;
}
--
Summary: missing optimization opportunity with binary operators
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P4
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dvilleneuve at kronos dot com
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24427
[Bug target/24428] New: [4.1 regression] TLS miscompilation on x86_64
Following testcase (distilled from Fortran test in openmpbench_F_v2):
extern __thread double thrtest[81];
int main (void)
{
int i;
for (i = 0; i < 81; i++)
thrtest[i] = 1.0;
}
is miscompiled at -O2 on x86_64:
movq[EMAIL PROTECTED](%rip), %rax
addq%fs:0, %rax
.L2:movabsq $4607182418800017408, %rdx
movq%rdx, (%rax)
addq$8, %rax
cmpq$thrtest+648, %rax
jne .L2
rep ; ret
Note $thrtest+648 which is wrong for __thread variables.
The i386 backend (but it seems other backends as well) legitimize TLS
addresses either when LEGITIMIZE_ADDRESS, or when expanding a move
(ix86_expand_move). But in this case the middle-end created
(const:DI (plus:DI (symbol_ref:DI ("thrtest") [flags 0x58]) (const_int 648)))
and passed it to gen_movdi, which doesn't do any legitimization.
Adding calls to a legitimization function for TLS addresses to (almost) every
expander is certainly not going to work, so I wonder if either
expand_expr_addr_expr shouldn't notice addresses of TLS variables and force_reg
them, or if general_operand and other routines shouldn't check for this and
reject it (which I guess would cause it to be forced to register and therefore
ix86_expand_move etc. could do its job).
--
Summary: [4.1 regression] TLS miscompilation on x86_64
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-*-linux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24428
[Bug middle-end/24429] New: Remove unnecessary lhd_* hooks where a corresponding hook_* exists
I'll attach a patch, that should be queued for 4.2 once 4.1 branches. -- Summary: Remove unnecessary lhd_* hooks where a corresponding hook_* exists Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24429
[Bug middle-end/24429] Remove unnecessary lhd_* hooks where a corresponding hook_* exists
--- Comment #1 from jakub at gcc dot gnu dot org 2005-10-18 13:36 --- Created an attachment (id=10018) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10018&action=view) pr24429.patch As per http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01040.html request, I'm enqueueing this cleanup for 4.2. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24429
[Bug middle-end/24429] Remove unnecessary lhd_* hooks where a corresponding hook_* exists
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24429
[Bug target/24428] [4.1 regression] TLS miscompilation on x86_64
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 13:40 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-10-18 13:40:44 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24428
[Bug middle-end/24427] missing optimization opportunity with binary operators
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 13:42 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19987 nThis|| Status|UNCONFIRMED |NEW Component|tree-optimization |middle-end Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-10-18 13:42:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24427
[Bug fortran/24426] gfortran ICE for valid derived type definition with default initialization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24426
[Bug fortran/22306] [4.0 only] ICE: segmentation fault
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22306
[Bug c++/21383] [3.4/4.0/4.1 Regression] Crash when finding &a_templated_func<>
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-18 13:45 --- Subject: Bug 21383 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-18 13:45:23 Modified files: gcc/cp : ChangeLog name-lookup.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/overload: koenig2.C Log message: cp: PR c++/21383 * name-lookup.c (arg_assoc): Template args can be null in a template-id-expr. testsuite: PR c++/21383 * g++.dg/overload/koenig2.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4945&r2=1.4946 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.143&r2=1.144 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6208&r2=1.6209 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/overload/koenig2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
[Bug fortran/24426] gfortran ICE for valid derived type definition with default initialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 13:46 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2005-10-18 13:46:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24426
[Bug c++/21383] [3.4/4.0/4.1 Regression] Crash when finding &a_templated_func<>
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-18 13:49 --- Subject: Bug 21383 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-18 13:49:17 Modified files: gcc/cp : ChangeLog name-lookup.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/overload: koenig2.C Log message: cp: PR c++/21383 * name-lookup.c (arg_assoc): Template args can be null in a template-id-expr. testsuite: PR c++/21383 * g++.dg/overload/koenig2.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.143&r2=1.4648.2.144 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.109.4.10&r2=1.109.4.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.467&r2=1.5084.2.468 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/overload/koenig2.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
[Bug c++/21383] [3.4 Regression] Crash when finding &a_templated_func<>
--- Comment #8 from nathan at gcc dot gnu dot org 2005-10-18 13:49 --- fixed mainline, 4.0 2005-10-18 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/21383 * name-lookup.c (arg_assoc): Template args can be null in a template-id-expr. leaving open for 3.4 backport -- nathan at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1 Regression]|[3.4 Regression] Crash when |Crash when finding |finding &a_templated_func<> |&a_templated_func<> | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
[Bug c++/21383] [3.4 Regression] Crash when finding &a_templated_func<>
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
[Bug c++/21908] [3.4 Regression] poor diagnostic with vitrual base classes
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21908
[Bug c++/22352] [3.4 Regression] ICE in lookup_member
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22352
[Bug c++/22464] [3.4 Regression] ICE on classes in template functions which attempt closure
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22464
[Bug c++/23307] [3.4 Regression] ICE in cp_parser_template_id, at cp/parser.c:8564 with Boost remote_call_manager
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23307
[Bug c++/23797] [3.4 Regression] ICE on typename outside template
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23797
[Bug libmudflap/24420] mudflap doesnt work with DSOs?
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 14:16 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-18 14:16:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24420
[Bug libmudflap/24420] mudflap doesnt work with DSOs?
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-18 14:18 --- extern char _end[]; extern char ENTRY_POINT[]; Maybe they should be made to be pointers and weak. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24420
[Bug fortran/20837] public accepted outside modules
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-18 14:20 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20837
[Bug fortran/20853] assumed-size array with default initialization and derived type
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-18 14:21 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20853
[Bug fortran/20849] EXTERNAL and default initialization conflict
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-18 14:21 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20849
[Bug fortran/23446] Valid internal subprogram array argument declaration is not accepted.
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-18 14:21 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23446
[Bug fortran/21459] strings of different length in a single character(len=*) declaration
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-18 14:21 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21459
[Bug fortran/20866] recursively defined statement function
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-18 14:21 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20866
Compiler bug report
Hello, For my project, i am using Altera Excalibur EPXA1 board. i got Linux2.4.21 with patch-2.4.21-rmk2, which support EXPA1 board for ARM. I am using Altera provided Quartus II 4.0 tools. this tools also provide the arm-gnupro tool. which has arm-elf- cross-compiler. i config the kernel, build the dependencies and at time of building the kernel image it give the 'compiler cpp fatal signal 13 error' make epxa1db_config make oldconfig make dep make zImage ormake vmlinux now i am stuck here. please! anyone suggest me the bug fix for this problem... now i am pasting the error report which i got while building the kernel image. make[2]: Entering directory `/home/goutam/Dump-2.4.21/linux-2.4.21/fs' /home/mitul/arm_cross/bin/arm-elf-gcc -D__KERNEL__ -I/home/goutam/Dump-2.4.2 1/linux-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -Uarm -fno-common -pipe -g -mapcs-32 -D__LINUX_ARM_ARCH__=4 -march=armv4 -mtune=arm9tdmi -mshort-load-bytes -msoft-float -Uarm -nostdinc -iwithprefix include -DKBUILD_BASENAME=locks -c -o locks.o locks.c In file included from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/string.h:25, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/fs.h:23, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/capability.h:17, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/binfmts.h:5, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/sched.h:9, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/mm.h:4, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/slab.h:14, from locks.c:118: /home/goutam/Dump-2.4.21/linux-2.4.21/include/asm/string.h:16: warning: conflicting types for built-in function `memcpy' /home/goutam/Dump-2.4.21/linux-2.4.21/include/asm/string.h:26: warning: conflicting types for built-in function `memset' In file included from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/fs.h:23, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/capability.h:17, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/binfmts.h:5, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/sched.h:9, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/mm.h:4, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/slab.h:14, from locks.c:118: /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/string.h:77: warning: conflicting types for built-in function `memcmp' In file included from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/fs.h:703, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/capability.h:17, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/binfmts.h:5, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/sched.h:9, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/mm.h:4, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/slab.h:14, from locks.c:118: /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/udf_fs_sb.h:21: warning: ignoring pragma: /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/udf_fs_sb.h:76: warning: ignoring pragma: locks.c: In function `flock_make_lock': locks.c:239: Internal compiler error in `output_move_double', at config/arm/arm.c:5125 Please submit a full bug report. See http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. arm-elf-gcc: Internal compiler error: program cpp got fatal signal 13 make[2]: *** [locks.o] Error 1 make[2]: Leaving directory `/home/goutam/Dump-2.4.21/linux-2.4.21/fs' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/home/goutam/Dump-2.4.21/linux-2.4.21/fs' make: *** [_dir_fs] Error 2 [EMAIL PROTECTED] linux-2.4.21]# i am attached the error report. kindly view, if make[2]: Entering directory `/home/goutam/Dump-2.4.21/linux-2.4.21/fs' /home/mitul/arm_cross/bin/arm-elf-gcc -D__KERNEL__ -I/home/goutam/Dump-2.4.21/linux-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -Uarm -fno-common -pipe -g -mapcs-32 -D__LINUX_ARM_ARCH__=4 -march=armv4 -mtune=arm9tdmi -mshort-load-bytes -msoft-float -Uarm -nostdinc -iwithprefix include -DKBUILD_BASENAME=locks -c -o locks.o locks.c In file included from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/string.h:25, from /home/goutam/Dump-2.4.21/linux-2.4.21/include/linux/fs.h:23, from /home/goutam/Dump-2.4.21/linux-2.4.21/include
Compiler bug report
Hello, For my project, i am using Altera Excalibur EPXA1 board. i got Linux2.4.21 with patch-2.4.21-rmk2, which support EXPA1 board for ARM. I am using Altera provided Quartus II 4.0 tools. this tools also provide the arm-gnupro tool. which has arm-elf- cross- compiler. i config the kernel, build the dependencies and at time of building the kernel image it give the 'compiler cpp fatal signal 13 error' make epxa1db_config make oldconfig make dep make zImage ormake vmlinux now i am stuck here. please! anyone suggest me the bug fix for this problem... now i am pasting the error report which i got while building the kernel image. make[2]: Entering directory `/home/goutam/Dump-2.4.21/linux- 2.4.21/fs' /home/mitul/arm_cross/bin/arm-elf-gcc -D__KERNEL__ - I/home/goutam/Dump-2.4.21/linux-2.4.21/include -Wall -Wstrict- prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -Uarm - fno-common -pipe -g -mapcs-32 -D__LINUX_ARM_ARCH__=4 - march=armv4 -mtune=arm9tdmi -mshort-load-bytes -msoft-float -Uarm - nostdinc -iwithprefix include -DKBUILD_BASENAME=locks -c -o locks.o locks.c In file included from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/string.h:25, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/fs.h:23, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/capability.h:17, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/binfmts.h:5, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/sched.h:9, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/mm.h:4, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/slab.h:14, from locks.c:118: /home/goutam/Dump-2.4.21/linux- 2.4.21/include/asm/string.h:16: warning: conflicting types for built-in function `memcpy' /home/goutam/Dump-2.4.21/linux- 2.4.21/include/asm/string.h:26: warning: conflicting types for built-in function `memset' In file included from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/fs.h:23, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/capability.h:17, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/binfmts.h:5, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/sched.h:9, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/mm.h:4, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/slab.h:14, from locks.c:118: /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/string.h:77: warning: conflicting types for built-in function `memcmp' In file included from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/fs.h:703, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/capability.h:17, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/binfmts.h:5, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/sched.h:9, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/mm.h:4, from /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/slab.h:14, from locks.c:118: /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/udf_fs_sb.h:21: warning: ignoring pragma: /home/goutam/Dump-2.4.21/linux- 2.4.21/include/linux/udf_fs_sb.h:76: warning: ignoring pragma: locks.c: In function `flock_make_lock': locks.c:239: Internal compiler error in `output_move_double', at config/arm/arm.c:5125 Please submit a full bug report. See http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. arm-elf-gcc: Internal compiler error: program cpp got fatal signal 13 make[2]: *** [locks.o] Error 1 make[2]: Leaving directory `/home/goutam/Dump-2.4.21/linux- 2.4.21/fs' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/home/goutam/Dump-2.4.21/linux- 2.4.21/fs' make: *** [_dir_fs] Error 2 [EMAIL PROTECTED] linux-2.4.21]# i am attached the error report. kindly view, if The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or [EMAIL PROTECTED]
[Bug ada/20042] [4.0/4.1 regression] ACATS cxaca01 assembler Bad Absolute Expression error on
--- Comment #4 from charlet at gcc dot gnu dot org 2005-10-18 14:49 --- Geert is no longer working on this PR for the time being, so changing assignment. -- charlet at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|bosch at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20042
[Bug ada/20012] 'pragma Compile_Time_Warning' adds quotation marks to warning text
--- Comment #1 from charlet at gcc dot gnu dot org 2005-10-18 14:51 --- Geert is no longer working on this PR for the time being, so changing assignment. -- charlet at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|bosch at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20012
[Bug fortran/24430] New: internal compiler error: in convert_move, at expr.c:362
I get internal compiler error trying to compile this routine on windows (no problem on the Macintosh) - $ gfortran -c stress.f stress.f: In function 'stress1': stress.f:44: internal compiler error: in convert_move, at expr.c:362 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/Visual Studio Projects/tests $ gfortran --v Using built-in specs. Target: i686-pc-mingw32 Configured with: ../gcc/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-mpfr=/home/FX/local --disable-libssp --disable-libmudflap --disable-nls : (reconfigured) ../gcc/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-mpfr=/home/FX/local --disable-libssp --disable-libmudflap --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as Thread model: win32 gcc version 4.1.0 20051015 (experimental) [EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/Visual Studio Projects/tests $ cat stress.f SUBROUTINE STRESS1(N,SIG,ORD,KODE,MTYPE) IMPLICIT REAL*8 (A-H,O-Z) COMPLEX UD,UDX,UR,UK,WK,TK,UI,UJ,WI,WJ,TI,TJ,TRR,TZZ,TRZ,TZT,TRT, *ERR,EZZ,ERZ,ERT,EZT, ER,EZ,ET,SIG,FORCD COMMON/STITER/ 1 UD(690),UD1(690),UD2(690),FORCD(690),R(230),Z(230), 2 RO(10),E(12,10),NODDIS(50),NODFRC(20), 3 NUMNP,NUMEL,NDGREE,MUD,NUMDIS,NUMFRC,IX(5,355) COMMON/TEMPFD/ 1 TO,T(230) COMMON/FOURER/ 1 NUMFOU,NFOUR,NF,NF2 DIMENSION 1 EE(12),SIG(6),UR(1),ORD(2) EQUIVALENCE 1 (UD(1),UR(1)) REAL*8 1 NF, NF2 DIMENSION UDX(3,230) EQUIVALENCE (UDX(1,1),UD(1)) C C SET U-THETA= -U-R FOR ALL NODES ON Z-AXIS IF NFOUR=2 C IF(NFOUR.NE.2) GO TO 55 50 DO 54 I=1,4 J=IX(I,N) IF ( ABS(R(J)).LT.1.E-4) UDX(3,J)=-UDX(1,J) 54 CONTINUE 55 MPRINT=0 C C*CALCULATION OF CENTER NODE VARIABLES C I=IX(1,N) J=IX(2,N) K=IX(3,N) L=IX(4,N) II=3*I JJ=3*J KK=3*K LL=3*L IF(K.EQ.L) GO TO 60 NM=4 C=0.25 UK=C*(UR(II-2)+UR(JJ-2)+UR(KK-2)+UR(LL-2)) WK=C*(UR(II-1)+UR(JJ-1)+UR(KK-1)+UR(LL-1)) TK=C*(UR(II)+UR(JJ)+UR(KK)+UR(LL)) TEMP=C*(T(I)+T(J)+T(K)+T(L)) RK=C*(R(I)+R(J)+R(K)+R(L)) ZK=C*(Z(I)+Z(J)+Z(K)+Z(L)) GO TO 70 60 C=1./3. NM=1 UK=UR(KK-2) WK=UR(KK-1) TK=UR(KK) TEMP=C*(T(I)+T(J)+T(K)) RK=R(K) ZK=Z(K) C=1. 70 CONTINUE C C*CALCULATION OF ELEMENT PROPERTIES C DO 90 M=1,9 90 EE(M)=E(M,MTYPE) TEMP=TEMP-TO DO 100 M=10,12 100 EE(M)=E(M,MTYPE)*TEMP C C*CALCULATION OF STRESSES AT CENTER NP C ERR=(0.0,0.0) EZZ=(0.0,0.0) ETT=(0.0,0.0) ERZ=(0.0,0.0) ERT=(0.0,0.0) EZT=(0.0,0.0) C C*COMPUTE STRESS AT NODE K OF TRIANGLE C DO 200 M=1,NM MM=M+1 IF(M.EQ.4) MM=1 I=IX(M,N) J=IX(MM,N) II=3*I JJ=3*J UI=UR(II-2) UJ=UR(JJ-2) WI=UR(II-1) WJ=UR(JJ-1) TI=UR(II) TJ=UR(JJ) RI=R(I) RJ=R(J) ZI=Z(I) ZJ=Z(J) AJ=RJ-RI AK=RK-RI BJ=ZJ-ZI BK=ZK-ZI X=AJ-AK Y=BJ-BK D=AJ*BK-AK*BJ TRR=Y*UI+BK*UJ-BJ*UK TZZ=-X*WI-AK*WJ+AJ*WK TRZ=-X*UI+Y*WI-AK*UJ+BK*WJ+AJ*UK-BJ*WK TZT=-X*TI-AK*TJ+AJ*TK IF(ABS(RK).LT.1.E-4)TRT=+ZJ*TI-ZI*TJ C BYPASS OIRGIN SINGULARITY IF(ABS(RK).LT.1.E-4) GO TO 355 TRT=-((RJ*ZK-RK*ZJ)*TI+(RK*ZI-RI*ZK)*TJ+(RI*ZJ-RJ*ZI)*TK+ZK*TZT)/ 1 RK 355 CONTINUE ERR=TRR/D+ERR EZZ=TZZ/D+EZZ ERZ=TRZ/D+ERZ ERT=TRT/D+ERT EZT=TZT/D+EZT 200 CONTINUE C CFOR COMPUTATION OF ETT IN TRIANGLES, LET UK,TK,RK CTAKE ON AVERAGE VALUES IF (NM.NE.1) GO TO 205 CC=1./3. RK=CC*(RI+RJ+RK) TK=CC*(TI+TJ+TK) UK=CC*(UI+UJ+UK) 205 CONTINUE ERR=C*ERR EZZ=C*EZZ ETT=(UK+NF*TK)/RK ERZ=C*ERZ ERT=C*ERT-NF*UK/RK EZT=C*EZT-NF*WK/RK C C*CALCULATE STRESSES C ER=ERR-EE(10) EZ=EZZ-EE(11) ET=ETT-EE(12) C CKODE .EQ. 0 OR 2 CALCULATE STRESSES C KODE.NE.0 OR 2 CALCULATE STRAINS C IF(KODE.EQ.0.OR.KODE.EQ.2) GO TO 300 DO 310 I=1,9 EE(I)=1. 310 IF(I.EQ.2.OR.I.EQ.3.OR.I.EQ.5) EE(I)=0. 300 CONTINUE SIG(1)=EE(1)*ER+EE(2)*EZ+EE(3)*ET SIG(2)=EE(2)*ER+EE(4)*EZ+EE(5)*ET SIG(3)=EE(3)*ER+EE(5)*EZ+EE(6)*ET SIG(4)=EE(7)*ERZ SIG(5)=EE(8)*ERT SIG(6)=EE(9)*EZT ORD(1)=RK ORD(2)=ZK RETURN END -- Summary: internal compiler error: in convert_move, at expr.c:362 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lan
[Bug c++/23293] [3.4/4.0/4.1 Regression] Misleading names in diagnostics for typedefs in functions
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-18 15:25 --- Subject: Bug 23293 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-18 15:24:57 Modified files: gcc/cp : pt.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: error19.C Log message: PR c++/23293 * pt.c (convert_template_argument): Use canonical type variants in template specializations. PR c++/23293 * g++.dg/template/error19.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/error19.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.978.2.34&r2=1.978.2.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.144&r2=1.4648.2.145 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.468&r2=1.5084.2.469 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23293
[Bug middle-end/15855] [3.4/4.0/4.1 Regression] g++ crash with -O2 and -O3 on input file
--- Comment #54 from dnovillo at gcc dot gnu dot org 2005-10-18 15:32 --- Closing. As discussed earlier, for all intents and purposes this is fixed. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug c++/23293] [3.4/4.0/4.1 Regression] Misleading names in diagnostics for typedefs in functions
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-18 15:39 --- Subject: Bug 23293 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED]2005-10-18 15:39:13 Modified files: gcc/cp : pt.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: error19.C Log message: PR c++/23293 * pt.c (convert_template_argument): Use canonical type variants in template specializations. PR c++/23293 * g++.dg/template/error19.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/error19.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.1050&r2=1.1051 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4946&r2=1.4947 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6209&r2=1.6210 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23293
[Bug c++/23293] [3.4 Regression] Misleading names in diagnostics for typedefs in functions
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-18 15:39 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1 Regression]|[3.4 Regression] Misleading |Misleading names in |names in diagnostics for |diagnostics for typedefs in |typedefs in functions |functions | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23293
[Bug c/24431] New: include header file search order issue: broken `-I' and `-isystem' command line options behavior
br
$ which cc
/usr/local/bin/cc
$ cc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.1/configure --enable-languages=all
Thread model: posix
gcc version 4.0.1
$ cc main.c
$ cc -I/usr/local/include -I/usr/X11R6/include main.c
main.c: In function 'main':
main.c:3: error: 'my_type' undeclared (first use in this function)
main.c:3: error: (Each undeclared identifier is reported only once
main.c:3: error: for each function it appears in.)
main.c:3: error: syntax error before 'i'
$ cat main.c
#include
int main(){
my_type i;
return 0;
}
$ cat /usr/local/include/my_header.h
#define my_type int
$ cat /usr/X11R6/include/my_header.h
$ cc -I/usr/local/include -I/usr/X11R6/include main.c -Wall -save-temps
main.c: In function 'main':
main.c:3: error: 'my_type' undeclared (first use in this function)
main.c:3: error: (Each undeclared identifier is reported only once
main.c:3: error: for each function it appears in.)
main.c:3: error: syntax error before 'i'
$ cat main.i
# 1 "main.c"
# 1 ""
# 1 ""
# 1 "main.c"
# 1 "/usr/X11R6/include/my_header.h" 1
# 2 "main.c" 2
int main(){
my_type i;
return 0;
}
[EMAIL PROTECTED]:~/gcc-bug$ cat main.c
#include
int main(){
my_type i;
return 0;
}
--
Summary: include header file search order issue: broken `-I' and
`-isystem' command line options behavior
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nyvsld at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24431
[Bug c++/17763] [3.4/4.0/4.1 Regression] Wrong context in error message for template parameter
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-18 15:44 --- The confusing use of typedefs is now corrected. The spurious space after the "." remains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17763
[Bug preprocessor/24431] include header file search order issue: broken `-I' and `-isystem' command line options behavior
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 15:56 --- do a cc -v main.cc and see what is the order of include directories. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |preprocessor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24431
[Bug target/19672] [3.4/4.0/4.1 Regression] Performance regression in simple loop code
--- Comment #13 from bonzini at gcc dot gnu dot org 2005-10-18 16:04 --- The patch is not good because I forgot to check fallthrough edges. The code I added goes above, just before "case CALL_EXPR:". Restarting a bootstrap with a correct patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug preprocessor/24431] include header file search order issue: broken `-I' and `-isystem' command line options behavior
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-18 16:04 --- Oh. this is not a bug. -I/usr/local/include does nothing as it is already included.. You want -idirafter. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24431
[Bug c++/23293] [3.4 Regression] Misleading names in diagnostics for typedefs in functions
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23293
[Bug rtl-optimization/24075] Destructor called with wrong argument after exception with -fcse-follow-jumps -O1
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-10-18 16:13 --- Confirmed still fails on the 3.4 branch (arm-elf cross). The failure mode is that we have virtual_frame_pointer <= hard_frame_pointer ... cond_jump somewhere var <= virtual_frame_pointer The initial assignment is special since the assignment will be adjusted once the offset between the virtal and hard frame pointers is known. However, when cse-follow-jumps is enabled the second assignment is replaced with var <= hard_frame_pointer This second assignment is not special so it remains this way after the virtual->hard addressing is crystalized. This means that we have the wrong value in var at this point. Note that it's not surprising that you can't reproduce this with a series of -f options, since -O is needed to turn on GCC's optimization framework: without it cse isn't run at all! IMO we probably shouldn't be recording a cse for a set of the virtual frame pointer. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.5 Last reconfirmed|-00-00 00:00:00 |2005-10-18 16:13:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24075
[Bug ada/24415] [4.1 regression] [powerpc] ada bootstrap failure
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 16:15 --- On PPC-darwin, I just get (which is a dup of bug 22533): | tree check: expected class expression, have exceptional | |(constructor) in get_base_var, at ipa-utils.c:224 | How did you configure gcc? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24415
[Bug c++/22293] [4.0/4.1 regression] ICE declaring destructor as friend
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-18 16:21 --- Subject: Bug 22293 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED]2005-10-18 16:20:55 Modified files: gcc/cp : ChangeLog decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: friend3.C Log message: PR c++/22293 * decl.c (grokdeclarator): Reject unqualified destructors in friend declarations. * g++.dg/other/friend3.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4947&r2=1.4948 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1437&r2=1.1438 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6210&r2=1.6211 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/friend3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22293
[Bug c++/22293] [4.0/4.1 regression] ICE declaring destructor as friend
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-18 16:26 --- Subject: Bug 22293 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-18 16:26:02 Modified files: gcc/cp : ChangeLog decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: friend3.C Log message: PR c++/22293 * decl.c (grokdeclarator): Reject unqualified destructors in friend declarations. * g++.dg/other/friend3.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.145&r2=1.4648.2.146 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1371.2.29&r2=1.1371.2.30 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.469&r2=1.5084.2.470 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/friend3.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22293
[Bug c++/22293] [4.0/4.1 regression] ICE declaring destructor as friend
--- Comment #8 from reichelt at gcc dot gnu dot org 2005-10-18 16:26 --- Fixed on mainline and the 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22293
[Bug libgcj/17021] libgcj verifier resolves classes too eagerly
--- Comment #7 from thebohemian at gmx dot net 2005-10-18 16:38 --- Created an attachment (id=10019) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10019&action=view) new version of compatible I added a check which looks whether the LHS of an expression is java.lang.Object. If this is the case we do not have to look what the RHS actually is. (This change will be part of the final patch.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021
[Bug c++/22147] [4.0 regression] ICE in get_bindings
--- Comment #13 from cvs-commit at gcc dot gnu dot org 2005-10-18 16:39 --- Subject: Bug 22147 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-18 16:39:07 Modified files: gcc/cp : ChangeLog pt.c name-lookup.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/parse: crash28.C Added files: gcc/testsuite/g++.dg/template: friend37.C Log message: cp: PR c++/22147 Backport 2005-09-27 Mark Mitchell <[EMAIL PROTECTED]> * name-lookup.c (maybe_process_template_type_declaration): Don't treat forward declarations of classes as templates just because we're processing_template_decl. * pt.c (tsubst_decl): Clear DECL_TEMPLATE_INFO for friend functions. testsuite: PR c++/22147 Backport 2005-09-27 Mark Mitchell <[EMAIL PROTECTED]> * g++.dg/template/friend37.C: New test. * g++.dg/parse/crash28.C: Adjust error markers. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.146&r2=1.4648.2.147 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.978.2.35&r2=1.978.2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.109.4.11&r2=1.109.4.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.470&r2=1.5084.2.471 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/friend37.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.14.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/crash28.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1.2.1&r2=1.1.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
[Bug libgcj/17021] libgcj verifier resolves classes too eagerly
--- Comment #8 from thebohemian at gmx dot net 2005-10-18 16:40 --- Created an attachment (id=10020) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10020&action=view) assignments to object This test class does all kinds of assignments to java.lang.Object variables. If you remove the class files for Stuff1 and Stuff2 this will work with the changes made to compatible(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021
[Bug ada/24415] [4.1 regression] [powerpc] ada bootstrap failure
--- Comment #2 from debian-gcc at lists dot debian dot org 2005-10-18 16:40 --- (In reply to comment #1) > On PPC-darwin, I just get (which is a dup of bug 22533): > | tree check: expected class expression, have exceptional | > |(constructor) in get_base_var, at ipa-utils.c:224 | > > > How did you configure gcc? Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.1.0 20051018 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24415
[Bug c++/22147] [4.0 regression] ICE in get_bindings
--- Comment #14 from nathan at gcc dot gnu dot org 2005-10-18 16:41 --- fixed on 4.0 branch 2005-10-18 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/22147 Backport 2005-09-27 Mark Mitchell <[EMAIL PROTECTED]> * name-lookup.c (maybe_process_template_type_declaration): Don't treat forward declarations of classes as templates just because we're processing_template_decl. * pt.c (tsubst_decl): Clear DECL_TEMPLATE_INFO for friend functions. PR c++/22147 Backport 2005-09-27 Mark Mitchell <[EMAIL PROTECTED]> * g++.dg/template/friend37.C: New test. * g++.dg/parse/crash28.C: Adjust error markers. -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
[Bug libgcj/17021] libgcj verifier resolves classes too eagerly
--- Comment #9 from thebohemian at gmx dot net 2005-10-18 17:01 --- Created an attachment (id=10021) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10021&action=view) new version of to_array method This is the lazyfied version of the to_array method which is uses for the aanewarray opcode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021
[Bug libgcj/17021] libgcj verifier resolves classes too eagerly
--- Comment #10 from thebohemian at gmx dot net 2005-10-18 17:09 --- Created an attachment (id=10022) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10022&action=view) a test class for the aanewarray lazyfication This tests lazy array instantiation which was not possible before. Need to check whether one of my changes fixed the "dontKnowIfThisCouldWork" method or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021
[Bug libfortran/24432] New: [4.1 regression] Missing symbols
The patch 2005-10-03 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR libfortran/19308 PR libfortran/22437 * Makefile.am: Add generated files for large real and integers kinds. Add a rule to create the kinds.inc c99_protos.inc files. Use kinds.inc to preprocess Fortran generated files. * libgfortran.h: Add macro definitions for GFC_INTEGER_16_HUGE, GFC_REAL_10_HUGE and GFC_REAL_16_HUGE. Add types gfc_array_i16, gfc_array_r10, gfc_array_r16, gfc_array_c10, gfc_array_c16, gfc_array_l16. * mk-kinds-h.sh: Define macros HAVE_GFC_LOGICAL_* and HAVE_GFC_COMPLEX_* when these types are available. * intrinsics/ishftc.c (ishftc16): New function for GFC_INTEGER_16. * m4/all.m4, m4/any.m4, m4/count.m4, m4/cshift1.m4, m4/dotprod.m4, m4/dotprodc.m4, m4/dotprodl.m4, m4/eoshift1.m4, m4/eoshift3.m4, m4/exponent.m4, m4/fraction.m4, m4/in_pack.m4, m4/in_unpack.m4, m4/matmul.m4, m4/matmull.m4, m4/maxloc0.m4, m4/maxloc1.m4, m4/maxval.m4, m4/minloc0.m4, m4/minloc1.m4, m4/minval.m4, m4/mtype.m4, m4/nearest.m4, m4/pow.m4, m4/product.m4, m4/reshape.m4, m4/set_exponent.m4, m4/shape.m4, m4/specific.m4, m4/specific2.m4, m4/sum.m4, m4/transpose.m4: Protect generated functions with appropriate "#if defined (HAVE_GFC_type_kind)" preprocessor directives. * Makefile.in: Regenerate. * all files in generated/: Regenerate. has introduced a bunch of regressions on non-C99 SPARC/Solaris platforms: http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00785.html http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00786.html http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00787.html http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00788.html while SPARC/Solaris 10 is OK: http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00789.html All almost the failures are: FAIL: gfortran.dg/fold_nearest.f90 -Os (test for excess errors) Excess errors: Undefined first referenced symbol in file _gfortran_nearest_r4/var/tmp//cckqXPiC.o ld: fatal: Symbol referencing errors. No output written to ./fold_nearest.exe _gfortran_nearest_r4 is missing because it is now guarded with: #if defined (HAVE_GFC_REAL_4) && defined (HAVE_COPYSIGNF) && defined (HAVE_NEXTAFTERF) [...] #endif and neither HAVE_COPYSIGNF nor HAVE_NEXTAFTERF is defined; but of course intrinsics/c99_functions.c provides copysignf and nextafterf. [FX, please make sure your email address as recorded in the ChangeLog file is registered with Bugzilla; same for [EMAIL PROTECTED] Thanks in advance.] -- Summary: [4.1 regression] Missing symbols Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: link-failure Severity: critical Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org GCC build triplet: *-*-solaris2.* GCC host triplet: *-*-solaris2.* GCC target triplet: *-*-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24432
[Bug target/24419] [3.4/4.0/4.1 Regression]: ix86 prologue puts values beyond stack
--- Comment #6 from jh at suse dot cz 2005-10-18 17:22 --- Subject: Re: [3.4/4.0/4.1 Regression]: ix86 prologue puts values beyond stack > > > --- Comment #5 from hjl at lucon dot org 2005-10-18 04:37 --- > >From bar.i.26.flow2: > > (insn/f 51 11 52 0 (set (mem:DI (plus:DI (reg/f:DI 7 sp) > (const_int -16 [0xfff0])) [0 S8 A8]) > (reg:DI 3 bx)) -1 (nil) > (expr_list:REG_DEAD (reg:DI 3 bx) > (nil))) > > (insn/f 52 51 53 0 (set (mem:DI (plus:DI (reg/f:DI 7 sp) > (const_int -8 [0xfff8])) [0 S8 A8]) > (reg:DI 6 bp)) -1 (nil) > (expr_list:REG_DEAD (reg:DI 6 bp) > (nil))) > > (insn/f 53 52 54 0 (parallel [ > (set (reg/f:DI 7 sp) > (plus:DI (reg/f:DI 7 sp) > (const_int -16 [0xfff0]))) > (clobber (reg:CC 17 flags)) > (clobber (mem:BLK (scratch) [0 A8])) > ]) -1 (nil) > (expr_list:REG_UNUSED (reg:CC 17 flags) > (nil))) > > Gcc doesn't tell the truth here since memory isn't/shouldn't be clobber > when adjusting SP. The transformation to push is probably valid only on x86 where any data on opposite side of stack pointer is implicitly clobbered (for signal handers stacks or whatever), so conversion of sub to push is safe. This is not very well modelled by RTL and ineed was problem few times in past (where scheduler overactively moved the stuff resulting in kernel crashes if I remember right) On x86-64 we probably should conditionalize this and use only for functions not using red zone or avoid the red zone usage for argument area when we are going to produce push instead of sub (the reason for that optimization is to reduce dependency chain that is more important that push conversion for Athlon, not sure what is the case for Nocona) Honza > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug target/24428] [4.1 regression] TLS miscompilation on x86_64
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-10-18 13:40:44 |2005-10-18 17:27:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24428
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #7 from hjl at lucon dot org 2005-10-18 17:33 --- We are working on ix86 optimization and run into this problem. -- hjl at lucon dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1 Regression]: |ix86 prologue clobbers |ix86 prologue puts values |memory when it shouldn't |beyond stack| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #8 from jh at suse dot cz 2005-10-18 17:41 --- Subject: Re: ix86 prologue clobbers memory when it shouldn't > > > --- Comment #7 from hjl at lucon dot org 2005-10-18 17:33 --- > We are working on ix86 optimization and run into this problem. The patch quoted on begining of thread should affect compilation with -mred-zone enabled only and that one is off for ix86. Can I see 32bit testcase? In general it is wrong on x86 to put data on unallocated stack at first place... Honza > > > -- > > hjl at lucon dot org changed: > >What|Removed |Added > > Summary|[3.4/4.0/4.1 Regression]: |ix86 prologue clobbers >|ix86 prologue puts values |memory when it shouldn't >|beyond stack| > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug rtl-optimization/23812] swapping DImode halves produces poor x86 register allocation
--- Comment #3 from michael dot meissner at amd dot com 2005-10-18 17:44 --- Note, since this is a rotate, the patches I proposed in 17886 will generate much better code for this one case (basically mov/mov/xchgl -- it could be improved by a peephole to do the moves directly instead of xchgl). However, the more general subreg problem needs to be looked at. -- michael dot meissner at amd dot com changed: What|Removed |Added CC||michael dot meissner at amd ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23812
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #9 from hjl at lucon dot org 2005-10-18 17:50 --- We only run into the problem with red zone enabled, which is x86-64. We have 2 issues: 1. When prologue uses mov, memory shouldn't be clobbered. But ix86_expand_prologue calls pro_epilogue_adjust_stack which clobbers memory. 2. We convert stack pointer subtractions to push even when memory isn't clobbered with patterns like ;; Convert esp subtractions to push. (define_peephole2 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -4))) (clobber (reg:CC FLAGS_REG))])] "optimize_size || !TARGET_SUB_ESP_4" [(clobber (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) I don't think we can do that since push will clobber memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug libfortran/24432] [4.1 regression] Missing symbols
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 18:05 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-18 18:05:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24432
[Bug ada/24415] [4.1 regression] [powerpc] ada bootstrap failure
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-18 18:07 --- (In reply to comment #2) > --with-cpu=default32 --disable-werror --enable-checking=release So maybe this is the error message we get with checking disabled (release checking). I will double check later today if that is the case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24415
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #10 from jh at suse dot cz 2005-10-18 18:17 --- Subject: Re: ix86 prologue clobbers memory when it shouldn't > > > --- Comment #9 from hjl at lucon dot org 2005-10-18 17:50 --- > We only run into the problem with red zone enabled, which is x86-64. We have > 2 issues: > > 1. When prologue uses mov, memory shouldn't be clobbered. But > ix86_expand_prologue calls pro_epilogue_adjust_stack which clobbers > memory. > 2. We convert stack pointer subtractions to push even when memory isn't > clobbered with patterns like > > ;; Convert esp subtractions to push. > (define_peephole2 > [(match_scratch:SI 0 "r") >(parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int > -4))) > (clobber (reg:CC FLAGS_REG))])] > "optimize_size || !TARGET_SUB_ESP_4" > [(clobber (match_dup 0)) >(set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) > > I don't think we can do that since push will clobber memory. Without red zone this is safe, but I see we do the conversion on 64bit too that definitly is unsafe. What about this patch? Index: i386.md === RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.md,v retrieving revision 1.655 diff -c -3 -p -r1.655 i386.md *** i386.md 24 Sep 2005 15:47:57 - 1.655 --- i386.md 18 Oct 2005 18:16:00 - *** *** 19306,19316 (clobber (mem:BLK (scratch)))])]) ;; Convert esp subtractions to push. (define_peephole2 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -4))) (clobber (reg:CC FLAGS_REG))])] ! "optimize_size || !TARGET_SUB_ESP_4" [(clobber (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) --- 19306,19320 (clobber (mem:BLK (scratch)))])]) ;; Convert esp subtractions to push. + ;; This conversion is safe only under assumption that unallocated stack is + ;; implicitly clobbered as specified by 32bit ABI (for signal handlers and such). + ;; This is not valid with red zone, but we can work harder and enable the + ;; optimization for functions that are not using it. (define_peephole2 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -4))) (clobber (reg:CC FLAGS_REG))])] ! "(optimize_size || !TARGET_SUB_ESP_4) && !TARGET_RED_ZONE" [(clobber (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) *** *** 19318,19324 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -8))) (clobber (reg:CC FLAGS_REG))])] ! "optimize_size || !TARGET_SUB_ESP_8" [(clobber (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) --- 19322,19328 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int -8))) (clobber (reg:CC FLAGS_REG))])] ! "(optimize_size || !TARGET_SUB_ESP_8) && !TARGET_RED_ZONE" [(clobber (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0)) (set (mem:SI (pre_dec:SI (reg:SI SP_REG))) (match_dup 0))]) *** *** 19438,19448 (clobber (mem:BLK (scratch)))])]) ;; Convert esp subtractions to push. (define_peephole2 [(match_scratch:DI 0 "r") (parallel [(set (reg:DI SP_REG) (plus:DI (reg:DI SP_REG) (const_int -8))) (clobber (reg:CC FLAGS_REG))])] ! "optimize_size || !TARGET_SUB_ESP_4" [(clobber (match_dup 0)) (set (mem:DI (pre_dec:DI (reg:DI SP_REG))) (match_dup 0))]) --- 19442,19456 (clobber (mem:BLK (scratch)))])]) ;; Convert esp subtractions to push. + ;; This conversion is safe only under assumption that unallocated stack is + ;; implicitly clobbered as specified by 32bit ABI (for signal handlers and such). + ;; This is not valid with red zone, but we can work harder and enable the + ;; optimization for functions that are not using it. (define_peephole2 [(match_scratch:DI 0 "r") (parallel [(set (reg:DI SP_REG) (plus:DI (reg:DI SP_REG) (const_int -8))) (clobber (reg:CC FLAGS_REG))])] ! "(optimize_size || !TARGET_SUB_ESP_4) && !TARGET_RED_ZONE" [(clobber (match_dup 0)) (set (mem:DI (pre_dec:DI (reg:DI SP_REG))) (match_dup 0))]) *** *** 19450,19456 [(match_scratch:DI 0 "r") (parallel [(set (reg:DI SP_REG) (plus:DI (reg:DI SP_REG) (const_int -16))) (clobber (reg:CC FLAGS_REG))])] ! "optimize_size || !TARGET_SUB_ESP_8" [(clobber (match_dup 0)) (set (mem:DI (pre_dec:DI (reg:DI SP_REG))) (match_dup 0)) (set (mem:DI (pre_dec:DI (reg:DI SP_REG))) (match_dup 0))]) --- 19458,19464 [(match_scratch:DI 0 "r") (parallel [(set (reg:DI SP_REG) (plus
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #11 from hjl at lucon dot org 2005-10-18 18:23 ---
The change looks reasonable. I will check it out. But I still don't
like pro_epilogue_adjust_stack doesn't tell the truth about if memory is
clobbered. Why not do something like
--- gcc/config/i386/i386.c.stack2005-10-18 10:08:25.0 -0700
+++ gcc/config/i386/i386.c 2005-10-18 10:11:45.0 -0700
@@ -4323,22 +4323,40 @@ ix86_emit_save_regs_using_mov (rtx point
otherwise. */
static void
-pro_epilogue_adjust_stack (rtx dest, rtx src, rtx offset, int style)
+pro_epilogue_adjust_stack (rtx dest, rtx src, rtx offset, int style,
+ bool clobber_memory)
{
rtx insn;
if (! TARGET_64BIT)
-insn = emit_insn (gen_pro_epilogue_adjust_stack_1 (dest, src, offset));
+{
+ if (clobber_memory)
+ insn = emit_insn (gen_pro_epilogue_adjust_stack_1 (dest, src,
+ offset));
+ else
+ insn = emit_insn (gen_addsi3 (stack_pointer_rtx,
+ stack_pointer_rtx, offset));
+}
else if (x86_64_immediate_operand (offset, DImode))
-insn = emit_insn (gen_pro_epilogue_adjust_stack_rex64 (dest, src,
offset));+{
+ if (clobber_memory)
+insn = emit_insn (gen_pro_epilogue_adjust_stack_rex64 (dest,
+ src,
+ offset));
+ else
+ insn = emit_insn (gen_adddi3 (stack_pointer_rtx,
+ stack_pointer_rtx, offset));
+}
else
{
rtx r11;
/* r11 is used by indirect sibcall return as well, set before the
epilogue and used after the epilogue. ATM indirect sibcall
shouldn't be used together with huge frame sizes in one
-function because of the frame_size check in sibcall.c. */
- if (style == 0)
+function because of the frame_size check in sibcall.c. If
+huge frame size is used, memory should always be clobbered
+when stack is adjusted. */
+ if (style == 0 || !clobber_memory)
abort ();
r11 = gen_rtx_REG (DImode, FIRST_REX_INT_REG + 3 /* R11 */);
insn = emit_insn (gen_rtx_SET (DImode, r11, offset));
@@ -4360,6 +4378,7 @@ ix86_expand_prologue (void)
bool pic_reg_used;
struct ix86_frame frame;
HOST_WIDE_INT allocate;
+ bool using_mov;
ix86_compute_frame_layout (&frame);
@@ -4384,7 +4403,8 @@ ix86_expand_prologue (void)
/* When using red zone we may start register saving before allocating
the stack frame saving one cycle of the prologue. */
- if (TARGET_RED_ZONE && frame.save_regs_using_mov)
+ using_mov = TARGET_RED_ZONE && frame.save_regs_using_mov;
+ if (using_mov)
ix86_emit_save_regs_using_mov (frame_pointer_needed ?
hard_frame_pointer_rtx
: stack_pointer_rtx,
-frame.nregs * UNITS_PER_WORD);
@@ -4393,7 +4413,7 @@ ix86_expand_prologue (void)
;
else if (! TARGET_STACK_PROBE || allocate < CHECK_STACK_LIMIT)
pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
- GEN_INT (-allocate), -1);
+ GEN_INT (-allocate), -1, !using_mov);
else
{
/* Only valid for Win32. */
@@ -4572,7 +4592,7 @@ ix86_expand_epilogue (int style)
emit_move_insn (hard_frame_pointer_rtx, tmp);
pro_epilogue_adjust_stack (stack_pointer_rtx, sa,
-const0_rtx, style);
+const0_rtx, style, true);
}
else
{
@@ -4586,7 +4606,7 @@ ix86_expand_epilogue (int style)
pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
GEN_INT (frame.to_allocate
+ frame.nregs * UNITS_PER_WORD),
- style);
+ style, true);
/* If not an i386, mov & pop is faster than "leave". */
else if (TARGET_USE_LEAVE || optimize_size
|| !cfun->machine->use_fast_prologue_epilogue)
@@ -4595,7 +4615,7 @@ ix86_expand_epilogue (int style)
{
pro_epilogue_adjust_stack (stack_pointer_rtx,
hard_frame_pointer_rtx,
-const0_rtx, style);
+const0_rtx, style, true);
if (TARGET_64BIT)
emit_insn (gen_popdi1 (hard_frame_pointer_rtx));
else
@@ -4612,11 +4632,12 @@ ix86_expand_epilogue (int style)
abort ();
pro_epilogue_adjust_stack (stack_pointer_rtx,
hard_frame_pointer_rtx,
-GEN_INT (offset), style);
+GEN_
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #12 from hjl at lucon dot org 2005-10-18 18:26 --- There is another issue when converting stack additions to pop: (define_peephole2 [(match_scratch:SI 0 "r") (parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int 4))) (clobber (reg:CC FLAGS_REG))])] "" [(parallel [(set (match_dup 0) (mem:SI (reg:SI SP_REG))) (set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int 4)))])] "") Is that 100% safe with red zone? In theory, compiler can adjust stack, but not clobber memory since there is a red zone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #13 from jh at suse dot cz 2005-10-18 18:29 --- Subject: Re: ix86 prologue clobbers memory when it shouldn't > > > --- Comment #12 from hjl at lucon dot org 2005-10-18 18:26 --- > There is another issue when converting stack additions to pop: > > (define_peephole2 > [(match_scratch:SI 0 "r") >(parallel [(set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int 4))) > > (clobber (reg:CC FLAGS_REG))])] > "" > [(parallel [(set (match_dup 0) (mem:SI (reg:SI SP_REG))) > (set (reg:SI SP_REG) (plus:SI (reg:SI SP_REG) (const_int 4)))])] > "") > > Is that 100% safe with red zone? In theory, compiler can adjust stack, but not > clobber memory since there is a red zone. It is reading memory here, not writting so it should be safe... Honza > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug libgcj/24433] New: GIJ interprets null too eagerly
public class Explain4
{
static Stuff1[] foo1;
static Stuff1[][] foo2;
static Stuff1[][][] foo3;
Stuff1[] foo4;
Stuff1[][] foo5;
Stuff1[][][] foo6;
public static void main(String[] args)
{
System.out.println(foo1);
System.out.println(foo2);
System.out.println(foo3);
Explain4 e = new Explain4();
System.out.println(e.foo4);
System.out.println(e.foo5);
System.out.println(e.foo6);
}
}
class Stuff1 extends Thread {}
If you compile this, remove the Stuff1.class file and run it the JDK will print
null 6 times.
GIJ however tries to resolve the Stuff1 class, fails and throws a
ClassNotFoundException.
--
Summary: GIJ interprets null too eagerly
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thebohemian at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24433
[Bug libgcj/24433] GIJ interprets null too eagerly
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 18:47 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-18 18:47:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24433
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #14 from hjl at lucon dot org 2005-10-18 19:38 --- Created an attachment (id=10023) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10023&action=view) A patch This is the patch I am testing. It seems to fix my problem. I am running the full bootstrap and check on Linux/i686 and Linux/x86-64 now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug middle-end/24434] New: [4.0/4.1 Regression] get_varargs_alias_set returns 0 always
With the following change: 2004-06-08 Jason Merrill <[EMAIL PROTECTED]> Gimplify VA_ARG_EXPR into simpler forms. get_varargs_alias_set will always return 0, which causes us to miss some loads/store elimination and such at the rtl level (and tree level also). The comment in alias.c is: /* We now lower VA_ARG_EXPR, and there's currently no way to attach the varargs alias set to an INDIRECT_REF (FIXME!), so we can't consistently use the varargs alias set for loads from the varargs area. So don't use it anywhere. */ -- Summary: [4.0/4.1 Regression] get_varargs_alias_set returns 0 always Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: missed-optimization, alias Severity: minor Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24434
[Bug middle-end/24434] [4.0/4.1 Regression] get_varargs_alias_set returns 0 always
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-18 19:56 --- Setting target milestone to 4.2 so we don't forget about this since it is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24434
