[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-01-13 06:50 --- (In reply to comment #1) > One could make the argument that the dllimport specifier is > a storage-class-specifier which, per 11.4/6 is not allowed on > the friend declaration. Since a friend function declaration > needs to be preceded by a declaration of the function itself, > it will always be sufficient if the dllimport specifier is only > on the original function declaration. > MS semantics for dllimport for ordinary file scope functions, is that if a declaration with dllimport attribute is followed by a decl without, the prior dllimport is overriden. Hence, the warning that Stephen shows for df3.cc in comment #3 may make some sense, but I do not have a MS compiler handy to see what MS says for the friend case. The warning does not make sense, if the dllimport attribute is actually honoured (as it should be) in original testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #2 from sldev327 at softmagi dot com 2008-01-13 05:52 ---
I as well will leave the argument about syntax to more knowledgeable people.
As to the validity of this PR, at the very least g++'s behavior is
inconsistent.I suppose a case like df3.cpp is what the warning was intended
for.
g++ warns about __attribute__((dllimport)) not being there on line 7 of df.cpp
(when in truth it is), and then goes on to honor it anyway as you can see
comparing the output df.s and df3.s.
## begin df3.cpp
__attribute__((dllimport)) int bar();
class Foo
{
private:
int foo();
friend int bar(); // dllimport removed
};
int Foo::foo()
{
return bar();
}
# end df3.cpp
D:> g++ -S df3.cpp
df3.cpp:7: warning: 'int bar()' redeclared without dllimport attribute:
previous dllimport ignored
D:> diff -u df.s df3.s
--- df.sSun Jan 13 14:02:58 2008
+++ df3.s Sun Jan 13 14:04:51 2008
@@ -1,4 +1,4 @@
- .file "df.cpp"
+ .file "df3.cpp"
.text
.align 2
.globl __ZN3Foo3fooEv
@@ -11,8 +11,7 @@
LCFI1:
subl$8, %esp
LCFI2:
- movl__imp___Z3barv, %eax
- call*%eax
+ call__Z3barv
leave
ret
LFE2:
@@ -55,3 +54,4 @@
.uleb128 0x5
.align 4
LEFDE1:
+ .def__Z3barv; .scl2; .type 32; .endef
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug fortran/34765] erroneous intrinsic assignment call
--- Comment #2 from kargl at gcc dot gnu dot org 2008-01-13 04:59 --- Does NR/ contain Numerical Recipes code? If so, you've just posted copyrighted code to public database. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34765
[Bug c++/33786] "C" data and static const data members mangled the same
--- Comment #2 from bangerth at dealii dot org 2008-01-13 03:12 --- So fixed. This is the error message one would expect. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33786
[Bug c++/33810] gcc 4.1.2 mangles results on x86_64 in bitfield operations
--- Comment #1 from bangerth at dealii dot org 2008-01-13 03:10 ---
Confirmed. Here's a slightly simplified testcase:
---bar.h
typedef struct {
unsigned : 16;
unsigned : 16;
} foo;
---bar.c
#include
#include
foo bar(unsigned i)
{
printf("bar: i is %u.\n",i);
foo myfoo;
return myfoo;
}
-foo.cc
#include
#include
extern "C" foo bar(unsigned int);
int main(void)
{
foo myfoo;
unsigned i = 3;
printf("foo: i is %u.\n",i);
myfoo = bar(i);
return 0;
}
---
tmp/g> gcc -I. -c bar.c
tmp/g> g++ -I. -o foo foo.c bar.o
tmp/g> ./foo
foo: i is 3.
bar: i is 1289971520.
Something appears to go wrong when calling the extern "C" function...
This is a wrong-code regression on valid code.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org,
||mmitchel at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2008-01-13 03:10:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33810
[Bug middle-end/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-13 02:52 --- Subject: Re: [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958 > Appears to me to be a reload bug. This is totally untested but I believe the attached patch will fix this bug. Dave --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-13 02:52 --- Created an attachment (id=14934) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14934&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug c++/33821] function with ambiguous covariant return-type is not rejected
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:49 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2008-01-13 02:49:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33821
[Bug c++/33885] member reference to a temporary object being deleted too early
--- Comment #3 from bangerth at dealii dot org 2008-01-13 02:45 --- Indeed invalid. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33885
[Bug c++/34021] Segmentation fault in G++ 4.1.3 with -O2
--- Comment #4 from bangerth at dealii dot org 2008-01-13 02:43 --- Confirmed, but fixed in 4.2.x. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34021
[Bug c++/34406] [reject valid?] incomplete type 'Y' used in nested name specifier.
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:33 --- What is the question you want to ask? The first code you show is invalid, the second valid... W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34406
[Bug c++/34531] local typedef conflicts with global definition of a type having the same name
--- Comment #4 from bangerth at dealii dot org 2008-01-13 02:31 ---
(In reply to comment #0)
> template class X {};
>
> class Y {
> typedef X X;
> };
>
>
> produces the following error:
> redef.cpp:4: error: declaration of 'typedef class X Y::X'
> redef.cpp:1: error: changes meaning of 'X' from 'class X'
What the error message says is this: before the typedef declaration,
referring to the name 'X' inside the class refers to the global
template ::X. After the declaration, 'X' inside the class refers
to the typedef. C++ does not allow declarations to change the
meaning of names.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34531
[Bug c++/34550] reference data template args appear to be broken in 4.2.1 ?
--- Comment #3 from bangerth at dealii dot org 2008-01-13 02:29 --- As per Andrew's comment, this is invalid. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34550
[Bug c++/34603] [4.1/4.2/4.3 regression] ICE with broken template declaration
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:25 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-13 02:25:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34603
[Bug c++/34624] valid c++ code doesn't compile for x86_64, but for i386
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:23 --- Can you try to reduce this to something smaller that doesn't require boost? -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34624
[Bug middle-end/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
--- Comment #5 from danglin at gcc dot gnu dot org 2008-01-13 02:21 --- Appears to me to be a reload bug. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug c++/34724] Trouble with friend declaration across namespaces
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:20 --- Confirmed. The code should be rejected since the friend declaration has only one template parameter, whereas the template has two. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-13 02:20:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34724
[Bug c++/34726] explicit specialization in non-namespace scope strange behavior
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:17 --- Explicit specializations of member templates need to be declared outside the declaration of the outer class, as per 14.7.3/2. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34726
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:12 --- One could make the argument that the dllimport specifier is a storage-class-specifier which, per 11.4/6 is not allowed on the friend declaration. Since a friend function declaration needs to be preceded by a declaration of the function itself, it will always be sufficient if the dllimport specifier is only on the original function declaration. I therefore think that the PR is invalid, but leave the final decision to someone with more knowledge. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug c++/34758] [4.1/4.2/4.3 regression] Bad diagnostic for circular dependency in constructor default argument
--- Comment #2 from bangerth at dealii dot org 2008-01-13 02:02 --- If the original warning is ever restored, please make it read circular dependency in default argument instead of the abbreviate language circular dependency in default args W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
[Bug target/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-13
01:52 ---
Subject: Re: [4.2 regression] internal compiler error: in
delete_output_reload, at reload1.c:7958
These are insns 307 and 314 from the greg pass.
> Reloads for insn # 307
(insn 307 280 281 24 (set (reg/v:SI 208 [ freePrefixes ])
(reg:SI 264)) 37 {*pa.md:2484} (nil)
(nil))
> Reloads for insn # 314
(insn 314 313 315 25 (set (reg/v:SI 208 [ freePrefixes ])
(const_int 0 [0x0])) 37 {*pa.md:2484} (nil)
(nil))
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug target/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-13 01:46 --- Subject: Re: [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958 > Probably a dup of PR32889. Agreed but the current 4.2 branch still ICEs. The failure doesn't occur with 4.3. I'm having difficulty understanding why this was classified as target bug. It appears to me to be a middle-end (reload) bug. Before the ICE, we handle a very similar reload: Starting program: /home/dave/gcc-4.2/objdir/stage1-gcc/cc1 -fpreprocessed pr34762.i -dumpbase pr34762.i -auxbase pr34762 -O2 -version -o pr34762.s -fPIC GNU C version 4.2.3 20080106 (prerelease) (hppa-linux) compiled by GNU C version 4.1.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 options passed: -fpreprocessed -auxbase -O2 -fPIC options enabled: -fPIC -falign-loops -fargument-alias -fbranch-count-reg -fcaller-saves -fcommon -fcprop-registers -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks -fdefer-pop -fdelayed-branch -fdelete-null-pointer-checks -fearly-inlining -feliminate-unused-debug-types -fexpensive-optimizations -ffunction-cse -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion -fif-conversion2 -finline-functions-called-once -fipa-pure-const -fipa-reference -fipa-type-escape -fivopts -fkeep-static-consts -fleading-underscore -fmath-errno -fmerge-constants -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls -fpeephole -fpeephole2 -freg-struct-return -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-interblock -fsched-spec -fsched-stalled-insns-dep -fschedule-insns -fschedule-insns2 -fshow-column -fsplit-ivs-in-unroller -fstrict-aliasing -fstrict-overflow -fthread-jumps -ftoplevel-reorder -ftrapping-math -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs -ftree-pre -ftree-salias -ftree-sink -ftree-sra -ftree-store-ccp -ftree-store-copy-prop -ftree-ter -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -fvar-tracking -fzero-initialized-in-bss -mbig-switch -mgas -mglibc -mno-space-regs Compiler executable checksum: 7052689d04078c8c580b43f74ef2f4ae gnu_dev_major gnu_dev_minor gnu_dev_makedev stat lstat fstat fstatat mknod mknodat stat64 lstat64 fstat64 fstatat64 vprintf getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar fputc_unlocked putc_unlocked putchar_unlocked getline feof_unlocked ferror_unlocked __strcspn_c1 __strcspn_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3 __strpbrk_c2 __strpbrk_c3 __strtok_r_1c __strsep_1c __strsep_2c __strsep_3c strtod strtol strtoul strtof strtold strtoq strtouq strtoll strtoull atof atoi atol atoll tolower toupper __sigismember __sigaddset __sigdelset __cmsg_nxthdr xislower xisupper xisalpha xisdigit xisalnum xisblank xisspace xtolower xtoupper headerFreeData h2hv headerNew headerFree headerLink headerUnlink headerSort headerUnsort headerSizeof headerUnload headerReload headerCopy headerLoad headerCopyLoad headerRead headerWrite headerIsEntry headerFreeTag headerGetEntry headerGetEntryMinMemory headerAddEntry headerAppendEntry headerAddOrAppendEntry headerAddI18NStrin! g headerModifyEntry headerRemoveEntry headerSprintf headerCopyTags headerFreeIterator headerInitIterator headerNextIterator _free tag2sln runLuaScript runScript runInstScript start Analyzing compilation unitPerforming interprocedural optimizations Assembling functions: tag2sln headerFreeData runInstScript Breakpoint 1, emit_move_sequence (operands=0xfb6c74cc, mode=SImode, scratch_reg=0x0) at ../../gcc/gcc/config/pa/pa.c:1332 1332 register rtx operand0 = operands[0]; (gdb) p debug_rtx (operands[0]) (reg:SI 21 %r21) $18 = void (gdb) p debug_rtx (operands[1]) (const_int 8252 [0x203c]) $19 = void (gdb) bt #0 emit_move_sequence (operands=0xfb6c74cc, mode=SImode, scratch_reg=0x0) at ../../gcc/gcc/config/pa/pa.c:1332 #1 0x0052d0e4 in gen_movsi (operand0=0x403bed70, operand1=0x403b67a0) at ../../gcc/gcc/config/pa/pa.md:2430 #2 0x003f1354 in emit_move_insn_1 (x=0x403bed70, y=0x403b67a0) at ../../gcc/gcc/expr.c:3225 #3 0x0057a2d4 in gen_move_insn (x=0x403bed70, y=0x403b67a0) at ../../gcc/gcc/optabs.c:4399 #4 0x006096d8 in gen_reload (out=0x403bed70, in=0x403b67a0, opnum=0, type=RELOAD_FOR_OUTPUT_ADDRESS) at ../../gcc/gcc/reload1.c:7839 #5 0x0060934c in gen_reload (out=0x403bed70, in=0x403bed40, opnum=0, type=RELOAD_FOR_OUTPUT_ADDRESS) at ../../gcc/gcc/reload1.c:7746 #6 0x006055ac in emit_input_reload_insns (chain=0xadfdf8, rl=0xa3b00c, old=0x403bed40, j=0) at ../../gcc/gcc/reload1.c:6798 #7 0x006064d8 in do_input_reload (chain=0xadfdf8, rl=0xa3b00c, j=0) at ../../gcc/gcc/reload1.c:7055 #8 0x00606fdc in emit_reload_insns (chain=0xadfdf8) at ../../gcc/gcc/reload1.c:7228 ... (gdb) c Continuing Brea
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #9 from pcarlini at suse dot de 2008-01-13 01:36 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #8 from paolo at gcc dot gnu dot org 2008-01-13 01:35 --- Subject: Bug 34730 Author: paolo Date: Sun Jan 13 01:34:58 2008 New Revision: 131500 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131500 Log: 2008-01-12 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/34730 * include/debug/functions.h (__check_sorted_set, __check_sorted_set_aux): Add. (__check_sorted): Check StrictWeakOrdering. * include/debug/macros.h (__glibcxx_check_strict_weak_ordering, __glibcxx_check_strict_weak_ordering_pred): Remove. (__glibcxx_check_sorted, __glibcxx_check_sorted_pred): Adjust. (__glibcxx_check_sorted_set, __glibcxx_check_sorted_set_pred): Add. * include/debug/debug.h (__glibcxx_requires_sorted_set, __glibcxx_requires_sorted_set_pred): Add. * include/bits/stl_algo.h (merge, includes, set_union, set_intersection, set_difference, set_symmetric_difference): Adjust, use __glibcxx_requires_sorted_set* instead. * testsuite/25_algorithms/set_intersection/34730.cc: New. Added: trunk/libstdc++-v3/testsuite/25_algorithms/set_intersection/34730.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/include/debug/debug.h trunk/libstdc++-v3/include/debug/functions.h trunk/libstdc++-v3/include/debug/macros.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug fortran/34765] erroneous intrinsic assignment call
--- Comment #1 from damian at rouson dot net 2008-01-13 01:24 --- Created an attachment (id=14933) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14933&action=view) Please see the README file in the attached bzipped archive & search the file disperse.out for the text "gfortran_bug". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34765
[Bug fortran/34556] Rejects valid with bogus error message: parameter initalization
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-13 01:24 --- This is similar to 34432 is some ways. I think we are not matching the (\ \) correctly. I don't think gfc_match_expr has the tooling for it yet. Investigating further -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-12-22 21:25:55 |2008-01-13 01:24:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34556
[Bug fortran/34765] New: erroneous intrinsic assignment call
The attached code demonstrates several circumstances wherein gfortran executes an intrinsic assignment of a derived type when a defined (overloaded) assignment is required. Specifically, the subroutines "complex_array_equals_Field()" and "field_equals_Field()" in the Field_Class module (file field.f90) should be called for the assignments near the text "gfortran_bug" in the file statistics.f90. -- Summary: erroneous intrinsic assignment call Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net 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=34765
[Bug fortran/34761] ICE in TRANSFER with pointer mold
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-01-13 00:13 --- Yes, it's fixed now. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34761
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #14 from hp at gcc dot gnu dot org 2008-01-12 23:05 --- (In reply to comment #9) > i personally think that this patch in #8 is not the right way to go. > > unless there is a compelling argument that initializing this is going to have > some negative performance effect, we should properly initialize this > datastructure as we do (or at least try to do) for every other data structure > in the compiler. While the current code that peter has written is correct, it > is quite tricky. This compiler has way too much tricky code, which only adds > to the long term maintainance cost of the compiler. > > the patch in 8 is not acceptable because it requires that the compiler be > built > in a particular way to avoid the valgrind errors. The last thing that you > want > to have to do if you have a heisenbug is to rebuild your compiler in a way > that > will change the layout and alignment of things. You know, that patch *enables*, it does not *require*. Nothing forces it to be the end of the story regarding this code, or that this PR be closed with it applied. It doesn't stop anyone (like you) from actually changing the way that code looks. It does however, enable people to build and test using --enable-checking=valgrind, like it could before (making the current behavior a regression). Other people, in particular, write-privilege maintainers of the code in question, have expressed sentiments that the patch was the way to go. You want to *stop* the patch because it doesn't *help* with an odd special case? Well, it helps with other debug cases, so let's have progress, and not have the perfect stand in way of gradual improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #15 from pcarlini at suse dot de 2008-01-12 22:57 --- (In reply to comment #14) > bg_BG is the only known example on Linux. To be clear, for occasional readers: we are supporting named locales only on GNU / Linux systems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug fortran/34760] PRIVATE variable not allowed as STAT variable in ALLOCATE
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 22:49 --- DEALLOCATE has actually the same problem. Regarding gfc_match_allocate/gfc_match_deallocate: a) "if (stat->symtree->n.sym->attr.flavor != FL_VARIABLE)" is false as the flavor is FL_UNKNOWN. b) ALLOCATE has much more checks for "stat" being a variable than DEALLOCATE, I had expected that they have the same checks for STAT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #14 from sebor at roguewave dot com 2008-01-12 22:45 --- bg_BG is the only known example on Linux. The original bug report we got was for a fr_FR locale on Tru64. I haven't gone through other locales on Tru64 or any other platforms except for Linux to see how pervasive such locales might be. I'll keep you posted once I have more data. I agree that if the locale is buggy and the bug is rare there's not much point in spending time on this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug ada/33788] [4.3 regression] GNAT bug box in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-01-12 22:44 --- This should be OK now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||01/msg00543.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33788
[Bug ada/33788] [4.3 regression] GNAT bug box in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-01-12 22:40 --- Subject: Bug 33788 Author: ebotcazou Date: Sat Jan 12 22:39:49 2008 New Revision: 131493 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131493 Log: PR ada/33788 * fold-const.c (fold_unary) : Fold an existing NOP_EXPR if it is between integral types with the same precision. Added: trunk/gcc/testsuite/gnat.dg/bit_packed_array.adb trunk/gcc/testsuite/gnat.dg/bit_packed_array.ads Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/utils.c trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33788
[Bug target/34764] A Flame About 64-bit Pointers
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-12 22:35 --- Well for PPC64, there is already support for it, just a different option -mpowerpc64 -m32 . For x86_64 you need ABI support which is not going to happen any time soon and partly outside of GCC's control because you need glibc and kernel support. -- 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=34764
[Bug fortran/34763] bare END not allowed in an interface block in a module procedure
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-12 22:35 ---
I believe the following patch is correct.
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 131492)
+++ gcc/fortran/decl.c (working copy)
@@ -4870,12 +4870,11 @@ gfc_match_bind_c (gfc_symbol *sym, bool
static int
contained_procedure (void)
{
- gfc_state_data *s;
+ gfc_state_data *s = gfc_state_stack;
- for (s=gfc_state_stack; s; s=s->previous)
-if ((s->state == COMP_SUBROUTINE || s->state == COMP_FUNCTION)
- && s->previous != NULL && s->previous->state == COMP_CONTAINS)
- return 1;
+ if ((s->state == COMP_SUBROUTINE || s->state == COMP_FUNCTION)
+ && s->previous != NULL && s->previous->state == COMP_CONTAINS)
+return 1;
return 0;
}
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2008-01-12 21:23:52 |2008-01-12 22:35:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34763
[Bug target/34764] A Flame About 64-bit Pointers
--- Comment #3 from pgquiles at elpauer dot org 2008-01-12 22:32 --- Is it technically possible (i. e. does the architecture support this feature) to make mlong32 work on x86-64, Itanium and other 64-bit architectures? If it's possible, it'd make sense to get it to work. -- pgquiles at elpauer dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34764
[Bug fortran/34759] Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-12 22:28 ---
Patch. I think this is the only place to change, interface's
compare_actual_formal is actually ok.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 131492)
+++ gcc/fortran/check.c (working copy)
@@ -2394,7 +2394,7 @@ gfc_check_shape (gfc_expr *source)
ar = gfc_find_array_ref (source);
- if (ar->as && ar->as->type == AS_ASSUMED_SIZE)
+ if (ar->as && ar->as->type == AS_ASSUMED_SIZE && ar->type == AR_FULL)
{
gfc_error ("'source' argument of 'shape' intrinsic at %L must not be "
"an assumed size array", &source->where);
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2008-01-12 21:24:39 |2008-01-12 22:28:20
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34759
[Bug target/34764] A Flame About 64-bit Pointers
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 22:27 --- bla -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34764
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #13 from dcb314 at hotmail dot com 2008-01-12 22:17 --- (In reply to comment #9) > i personally think that this patch in #8 is not the right way to go. > unless there is a compelling argument that initializing this is going to have > some negative performance effect, we should properly initialize this > datastructure as we do (or at least try to do) for every other data structure > in the compiler. While the current code that peter has written is correct, it > is quite tricky. This compiler has way too much tricky code, which only adds > to the long term maintainance cost of the compiler. Well said Sir. If the tricky code bought a 10% speedup, I'd advocate it. No one seems to have measured and documented how much it really saves. Unmeasured claims really don't count. Machines double in performance every few years, hence the prudent engineer codes in the default case for clarity, not performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug target/34764] A Flame About 64-bit Pointers
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-12 22:15 --- Well first Knuth did read full the documentation because -mlong32 is only for MIPS. Second don't post flames. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC target triplet||x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34764
[Bug c/34764] New: A Flame About 64-bit Pointers
(Please note this is a copy & paste from Donald E. Knuth's homepage: http://www-cs-faculty.stanford.edu/~uno/news.html - Given who he is, I think the issue should receive a bit of love) It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache. The gcc manpage advertises an option "-mlong32" that presumably does what I want. Namely, it should compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it should also know that my program is going to live inside a 32-bit virtual address space. Unfortunately, the gcc I got with Ubuntu 7.10 says that -mlong32 is an unknown option. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc. Please, somebody, make that possible. -- Summary: A Flame About 64-bit Pointers Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pgquiles at elpauer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34764
[Bug objc/28050] [4.1/4.2/4.3 regression] ICE on invalid initializer
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-12 22:03 --- Created an attachment (id=14932) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14932&action=view) Robustify C/objC parser Tested (objc only) on cygwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28050
[Bug fortran/34761] ICE in TRANSFER with pointer mold
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-01-12 21:53 --- (In reply to comment #1) > Works for me. I think it is a duplicate of the very recently fixed PR 34537. > Can you check? Bootstrapping right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34761
[Bug target/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 21:44 --- Probably a dup of PR32889. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug fortran/34759] Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-12 21:24:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34759
[Bug fortran/34763] bare END not allowed in an interface block in a module procedure
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 21:23 --- Confirm. (Though you missed "subroutine" for "end subroutine n_interface" in your example.) The Fortran 2003 references are: C1243 (R1230) FUNCTION shall appear in the end-function-stmt of an internal or module function. and C1248 (R1234) SUBROUTINE shall appear in the end-subroutine-stmt of an internal or module subroutine. Seemingly, the contained_procedure() check in decl.c, called by gfc_match_end, does not work properly. Thanks for report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-01-12 21:23:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34763
[Bug fortran/34759] Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 21:13 --- Confirm, though your reduced test case is invalid (the variables k and l need to be arrays. Corrected test case: subroutine j_assumed_size(A,N) dimension A(10,11,12,*), k(3), l(3) k = shape(A(:,:,:,N)) l = shape(A(:,:,:,3)) end "SOURCE may be of any type. It may be a scalar or an array. It shall not be an unallocated allocatable or a pointer that is not associated. It shall not be an assumed-size array." The shall-nots do not apply for the rank-3 arrays A(:,:,:,N) and A(:,:,:,3). Actually, this could be a wider problem, which is not only limited to check.c's gfc_check_shape. (For actual/dummy argument checking, I added a note to PR 34665.) Thanks for the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34759
[Bug fortran/34665] Cannot pass scalar to array argument 'a'
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-12 21:13 --- One has to be careful not to to get the same problem as with SHAPE in PR 34759, i.e. passing a rank-2 array A(:,:,5) defined as rank-3 assumed-shape array A(:,:,*). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34665
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #12 from bonzini at gnu dot org 2008-01-12 21:09 --- well if you can enjoy O(n) initialization (and O(1) clearing as in Peter's code), you had better rewrite the code completely to query an item with one (not two) memory accesses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug fortran/34763] New: bare END not allowed in an interface block in a module procedure
With gfortran 4.3.0 20080109 I get the error message n_interface.f:7.12: END 1 Error: END SUBROUTINE statement expected at (1) with the following program module n contains subroutine n_interface INTERFACE SUBROUTINE NGSXDY(TLS1,TLS2) REAL :: TLS1,TLS2 END END INTERFACE end end module If the n_interface is an external procedure it works fine. A bare END statement is allowed in interface blocks. I'd guess you are misapplying the constraint after R1224 to things inside of interface blocks. But NGSXDY isn't a module subroutine. You'll probably need a similar fix for functions in interface blocks, although I haven't tried that. Dick Hendrickson -- Summary: bare END not allowed in an interface block in a module procedure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34763
[Bug fortran/34760] PRIVATE variable not allowed as STAT variable in ALLOCATE
-- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-01-12 20:59:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
[Bug c/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
--- Comment #1 from tausq at debian dot org 2008-01-12 20:54 --- Created an attachment (id=14931) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14931&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug fortran/34761] ICE in TRANSFER with pointer mold
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 20:53 --- Works for me. I think it is a duplicate of the very recently fixed PR 34537. Can you check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34761
[Bug c/34762] New: [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
While building RPM on hppa with gcc-4.2, build fails with the captioned error. Somewhat reduced testcase attached. Builds fine with -O1 or without -fPIC, or with older compilers. ffmpeg and squashfs also fail to build with a similar error (not always built with -fPIC) -- Summary: [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org GCC build triplet: hppa-linux GCC host triplet: hppa-linux GCC target triplet: hppa-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug fortran/34761] New: ICE in TRANSFER with pointer mold
Extracted from PR 34741 :
$ cat bar.f90
character, pointer :: ptr(:)
allocate(ptr(1))
ptr = transfer('a',ptr)
end
$ gfortran bar.f90
f951: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ gdb ~/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
(gdb) r bar.f90
Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 bar.f90
Program received signal SIGFPE, Arithmetic exception.
0x080b1855 in gfc_simplify_transfer (source=0x89b5478, mold=0x89b54e8,
size=0x0) at ../../../gcc/trunk/gcc/fortran/simplify.c:4140
4140 result_length = source_size / result_elt_size;
(gdb) p result_elt_size
$1 = 0
(gdb) bt
#0 0x080b1855 in gfc_simplify_transfer (source=0x89b5478, mold=0x89b54e8,
size=0x0) at ../../../gcc/trunk/gcc/fortran/simplify.c:4140
#1 0x08071189 in do_simplify (specific=0x899faa0, e=0x89b5408)
at ../../../gcc/trunk/gcc/fortran/intrinsic.c:3191
#2 0x08071f87 in gfc_intrinsic_func_interface (expr=0x89b5408, error_flag=1)
at ../../../gcc/trunk/gcc/fortran/intrinsic.c:3450
#3 0x080a5e3f in gfc_resolve_expr (e=0x89b5408)
at ../../../gcc/trunk/gcc/fortran/resolve.c:1629
#4 0x080a932e in resolve_code (code=0x89b5628, ns=0x89b42b0)
at ../../../gcc/trunk/gcc/fortran/resolve.c:6104
#5 0x080ab29c in resolve_codes (ns=0x89b42b0)
at ../../../gcc/trunk/gcc/fortran/resolve.c:8996
#6 0x080ab2d3 in gfc_resolve (ns=0x89b42b0)
at ../../../gcc/trunk/gcc/fortran/resolve.c:9015
#7 0x0809c4b8 in gfc_parse_file ()
at ../../../gcc/trunk/gcc/fortran/parse.c:3380
#8 0x080c54a5 in gfc_be_parse_file (set_yydebug=0)
at ../../../gcc/trunk/gcc/fortran/f95-lang.c:260
#9 0x0836954c in toplev_main (argc=2, argv=0xbfecab94)
at ../../../gcc/trunk/gcc/toplev.c:1042
#10 0x0811161f in main (argc=Cannot access memory at address 0x0
) at ../../../gcc/trunk/gcc/main.c:35
--
Summary: ICE in TRANSFER with pointer mold
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 31237
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34761
[Bug fortran/34760] New: PRIVATE variable not allowed as STAT variable in ALLOCATE
With gfortran 4.3.0 20080109 I get the error message ALLOCATE (RLA1(NF10), STAT = ISTAT) 1 Error: STAT expression at (1) must be a variable With the following program. MODULE TESTS INTEGER, PRIVATE :: ISTAT !this one FAILS ! INTEGER :: ISTAT !this one works ! PRIVATE :: ISTAT !this one FAILS CONTAINS SUBROUTINE AD0001 REAL RLA1(:) ALLOCATABLE RLA1 ISTAT = -314 ALLOCATE (RLA1(NF10), STAT = ISTAT) END SUBROUTINE END MODULE In the real module there are several subroutines that do similar allocates and they do not generate the error. It looks like it is only the first use of ISTAT in an allocate that triggers the message. Dick Hendrickson -- Summary: PRIVATE variable not allowed as STAT variable in ALLOCATE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
[Bug fortran/34759] New: Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified
With gfortran 4.3.0 20080109 I get an incorrect error message "Error: 'source' argument of 'shape' intrinsic at (1) must not be an assumed size array" with the following little test case subroutine j_assumed_size(A,N) dimension A(10,11,12,*) k = shape(A(:,:,:,N)) l = shape(A(:,:,:,3)) end I believe assumed size arrays are allowed provided the last subscript is specified. Dick Hendrickson -- Summary: Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34759
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-12 19:48 --- Maybe sth for steven, as he was asking for bugs to look at... ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||stevenb dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug c++/34758] [4.1/4.2/4.3 regression] Bad diagnostic for circular dependency in constructor default argument
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:46 --- Confirmed. With the better diagnostic we had accepts-invalid, so lowering priority as regression status is not exactly clear. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:46:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
[Bug c++/34757] [4.3 regression] ICE with invalid parameters in variadic template
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:44 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:44:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34757
[Bug c++/34754] [4.3 regression] ICE with invalid function arguments in variadic template
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:44 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:44:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34754
[Bug c++/34753] [4.3 regression] ICE with invalid template parameter in variadic template
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 19:43 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:43:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
[Bug c++/34751] [4.3 regression] ICE with pointer to member and variadic templates
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:42 --- ICE-after-error for non c++0x mode. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||error-recovery Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-01-12 19:42:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34751
[Bug c++/34752] pointer to member rejected in variadic template
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-12 19:41 --- How is this a regression? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] pointer to |pointer to member rejected |member rejected in variadic |in variadic template |template| Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #6 from dberlin at gcc dot gnu dot org 2008-01-12 19:33 --- Subject: Re: [4.3 Regression] ICE in find_or_generate_expression On 12 Jan 2008 19:13:56 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-12 19:13 > --- > Danny, maybe you mis-understood. We try to generate *VH.98, but VH.98 is > indeed > not in avail_out[19], but created for example as > > So we can in fact not do insertion of *VH.98 in two of the preds of BB. It > looks like we do not do verification for that anywhere? Sure we do. It should never be ANTIC if it is not possible to regenerate the expression. Anything else is a bug in ANTIC calculation or initial exp_gen/tmp_gen/etc set construction. valid_in_sets ensures that SSA_NAME's are either AVAIL_OUT[1], or available in our current ANTIC set. ANTIC propagation subtracts TMP_GEN from ANTIC, which should ensure that values do not get hoisted above the point that creates them. [1] I honestly don't remember why valid_in_sets ensures that SSA_NAME's are AVAIL_OUT when bare. That seems wrong to me. The correct condition is whether they are in our current ANTIC set, just like it does for more complex expressions. I do not remember when or why this got changed, but it seems like a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug c++/34750] [4.1/4.2 Regression] ICE in fold_convert, at fold-const.c:1955
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-01-12 19:23
---
Even further reduced testcase:
=
struct A
{
template A(T);
};
class C;
struct B : A
{
B(const C& c) : A(c) {}
};
struct C
{
C(const C&);
C();
C& operator= (const C&);
};
B b = C();
=
bug.cc: In constructor 'B::B(const C&)':
bug.cc:10: internal compiler error: in cp_expr_size, at
cp/cp-objcp-common.c:100
Please submit a full bug report, [etc.]
This is really invalid code (C is used before it is defined).
The bug was fixed on mainline between 2007-10-13 and 2007-11-13.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||ice-on-invalid-code,
||monitored
Known to fail|4.0.4 4.1.3 4.2.3 |4.0.4 4.1.2 4.1.3 4.2.0
||4.2.1 4.2.2 4.2.3
Known to work|3.4.6 4.3.0 |3.4.6 4.0.0 4.0.3 4.1.0
||4.1.1 4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-12 19:13 ---
Danny, maybe you mis-understood. We try to generate *VH.98, but VH.98 is
indeed
not in avail_out[19], but created for example as
exp_gen[4] := { x_7(D) (VH.72) , D.1661_4 (VH.98) , *VH.74 (VH.75) , a.1_6
(VH.76) , *VH.72 (VH.77) , (unsigned int) VH.77 (VH.78) , VH.76 + VH.78 (VH.79)
, *VH.79 (VH.80) , (unsigned int) VH.80 (VH.81) , VH.81 * 2 (VH.82) , VH.75 +
VH.82 (VH.83) , *VH.83 (VH.84) , (int) VH.84 (VH.85) , VH.85 & 8192 (VH.86) }
tmp_gen[4] := { D.1661_4 (VH.98) , D.1662_5 (VH.75) , a.1_6 (VH.76) , D.1664_8
(VH.77) , D.1665_9 (VH.78) , D.1666_10 (VH.79) , D.1667_11 (VH.80) , D.1668_12
(VH.81) , D.1669_13 (VH.82) , D.1670_14 (VH.83) , D.1671_15 (VH.84) , D.1672_16
(VH.85) , D.1673_17 (VH.86) }
exp_gen[7] := { D.1661_4 (VH.98) , D.1667_34 (VH.97) , *VH.98 (VH.99) ,
(unsigned int) VH.97 (VH.100) , VH.100 * 2 (VH.101) , VH.99 + VH.101 (VH.102) ,
*VH.102 (VH.103) , (int) VH.103 (VH.104) , VH.104 & 8192 (VH.105) }
tmp_gen[7] := { D.1661_35 (VH.98) , D.1662_36 (VH.99) , D.1668_42 (VH.100) ,
D.1669_43 (VH.101) , D.1670_44 (VH.102) , D.1671_45 (VH.103) , D.1672_46
(VH.104) , D.1673_47 (VH.105) }
exp_gen[9] := { D.1661_4 (VH.98) , D.1667_53 (VH.109) , *VH.98 (VH.110) ,
(unsigned int) VH.109 (VH.111) , VH.111 * 2 (VH.112) , VH.110 + VH.112 (VH.113)
, *VH.113 (VH.114) , (int) VH.114 (VH.115) , VH.115 & 8192 (VH.116) }
tmp_gen[9] := { D.1661_54 (VH.98) , D.1662_55 (VH.110) , D.1668_61 (VH.111) ,
D.1669_62 (VH.112) , D.1670_63 (VH.113) , D.1671_64 (VH.114) , D.1672_65
(VH.115) , D.1673_66 (VH.116) }
exp_gen[10] := { D.1661_4 (VH.98) , D.1667_53 (VH.109) , *VH.98 (VH.110) ,
(unsigned int) VH.109 (VH.111) , VH.111 * 2 (VH.112) , VH.110 + VH.112 (VH.113)
, *VH.113 (VH.114) , (int) VH.114 (VH.115) , VH.115 & 8192 (VH.116) }
But all these expressions for VH.98 are plain SSA_NAMEs.
So we can in fact not do insertion of *VH.98 in two of the preds of BB. It
looks like we do not do verification for that anywhere?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug c++/34051] [4.3 regression] ICE in dependent_type_p with variadic templates
--- Comment #7 from andreasmeier80 at gmx dot de 2008-01-12 19:09 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00149.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
[Bug c++/34052] [4.3 regression] Trouble with variadic templates as template-template parameter
--- Comment #6 from andreasmeier80 at gmx dot de 2008-01-12 19:08 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00491.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
[Bug c++/33964] [4.3 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:15319 (vararg templates)
--- Comment #5 from andreasmeier80 at gmx dot de 2008-01-12 19:06 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00482.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33964
[Bug rtl-optimization/31396] Inline code performance much worse than out-of-line
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-01-12 19:00 --- Created an attachment (id=14930) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14930&action=view) tentative fix I am testing the attached patch. It is obvious that we should use profile here. The PR is most likely regression to 2.95 that used to multiply n_refs by 3 inside loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
[Bug c++/34758] [4.1/4.2/4.3 regression] Bad diagnostic for circular dependency in constructor default argument
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
[Bug c++/34758] New: [4.1/4.2/4.3 regression] Bad diagnostic for circular dependency in constructor default argument
The diagnostic for the following invalid code snippet degraded in GCC 3.4.0:
===
struct A
{
A (const A& = A());
};
===
Since GCC 3.4.0 we get:
bug.cc:3: error: the default argument for parameter 0 of 'A::A(const A&)' has
not yet been parsed
But before we got the much clearer diagnostic (although it was just a warning):
bug.cc:3: warning: circular dependency in default args of `A::A(const A&)'
In addition, the counting of the parameters should start with 1.
--
Summary: [4.1/4.2/4.3 regression] Bad diagnostic for circular
dependency in constructor default argument
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
[Bug c++/34757] [4.3 regression] ICE with invalid parameters in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34757
[Bug c++/34757] New: [4.3 regression] ICE with invalid parameters in variadic template
The following invalid code snippet triggers an ICE on mainline:
template struct A {};
A<0> a;
bug.cc:1: error: expected nested-name-specifier before 'int'
bug.cc:1: error: two or more data types in declaration of 'M'
bug.cc:1: error: no default argument for 'N'
bug.cc:1: error: no default argument for 'p'
bug.cc:3: error: '' is not a valid type for a template constant
parameter
bug.cc:3: error: template argument 2 is invalid
bug.cc:3: internal compiler error: tree check: accessed elt 2 of tree_vec with
1 elts in tsubst, at cp/pt.c:8934
Please submit a full bug report, [etc.]
The ICE appeared between 2007-10-13 and 2007-11-13.
Maybe related to PR34751.
--
Summary: [4.3 regression] ICE with invalid parameters in variadic
template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34757
[Bug c++/34756] New: [4.3 regression] ICE with broken specialization of variadic template
The following invalid code snippet triggers an ICE on mainline:
template class A {};
template class A<> {};
template struct A : A
{
A() {}
};
A a;
bug.cc:3: error: template parameters not used in partial specialization:
bug.cc:3: error: ''
bug.cc: In constructor 'A::A() [with T = int, U = ]':
bug.cc:10: instantiated from here
bug.cc:7: internal compiler error: in build_simple_base_path, at cp/class.c:489
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with broken specialization of
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34756
[Bug c++/34750] [4.1/4.2 Regression] ICE in fold_convert, at fold-const.c:1955
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-12 18:24 ---
Reduced testcase:
namespace std {
template
class basic_string {
public:
basic_string(const _CharT* __s);
};
typedef basic_string string;
}
typedef signed long long int int64;
typedef std::string String;
class Array;
class Type {
public:
enum Storage { NUM = 'n', FLOAT = 'f', STRING = 's',
OBJECT = 'O', STRING_VECTOR = 'v', ARRAY = 'A' };
};
class BaseValue {
protected:
explicit BaseValue (Type::Storage value_type);
};
class AnyValue : public BaseValue {
public:
template
explicit AnyValue (Type::Storage strg, V value)
: BaseValue (strg) { }
};
class AutoValue : public AnyValue {
public:
AutoValue (const String &string)
: AnyValue (Type::STRING, string) { }
AutoValue (const Array &array)
: AnyValue (Type::ARRAY, array) { }
};
class Array {
public:
Array (const Array &other);
explicit Array ();
Array& operator= (const Array &other);
void push_tail (const AutoValue &value) {}
};
void test_array ()
{
Array a;
const char *x[][8] = {};
for (int64 i = 0; i < sizeof (x) / sizeof (x[0]); i++)
{
Array b;
for (int64 j = 0; j < sizeof (x[0]) / sizeof (x[0][0]); j++)
b.push_tail (String (x[i][j]));
a.push_tail (b);
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.0.4 4.1.3 4.2.3
Known to work||3.4.6 4.3.0
Last reconfirmed|-00-00 00:00:00 |2008-01-12 18:24:22
date||
Summary|ICE in fold_convert, at |[4.1/4.2 Regression] ICE in
|fold-const.c:1955 |fold_convert, at fold-
||const.c:1955
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug c++/34753] [4.3 regression] ICE with invalid template parameter in variadic template
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-01-12 18:23
---
Here's a similar testcase with a function instead of a nested class
that also segfaults:
template struct A
{
template A();
};
A a;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #7 from pcarlini at suse dot de 2008-01-12 18:23 --- Eh! Interestingly, conceptgcc explicitly enforces the concept that the two value types must equal! Exactly the case that is covered but my almost-ready patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug c++/34755] New: [4.3 regression] ICE with invalid argument in variadic template function
The following invalid code snippet triggers an ICE on mainline:
template struct A {};
template class... T> void foo(T) {}
template void foo(A);
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'template class T'
bug.cc:5: internal compiler error: tree check: expected template_type_parm or
template_template_parm or bound_template_template_parm, have error_mark in
fn_type_unification, at cp/pt.c:11623
Please submit a full bug report, [etc.]
The ICE appeared between 2007-10-13 and 2007-11-13.
Maybe related to PR 34754.
--
Summary: [4.3 regression] ICE with invalid argument in variadic
template function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34755
[Bug c++/34754] [4.3 regression] ICE with invalid function arguments in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34754
[Bug c++/34754] New: [4.3 regression] ICE with invalid function arguments in variadic template
The following invalid code snippet triggers an ICE on mainline:
template class... T> struct A
{
void foo(T<0>);
void bar(T<0>);
};
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'template > class T'
bug.cc:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in bind_template_template_parm, at cp/tree.c:1242
Please submit a full bug report, [etc.]
The ICE appeared between 2007-10-13 and 2007-11-13.
--
Summary: [4.3 regression] ICE with invalid function arguments in
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34754
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #6 from pcarlini at suse dot de 2008-01-12 18:12 --- Thanks for the suggestion, Benjamin. Actually, I don't think we can much better *without* concepts... Anyway, was thinking that the ordering check is already impossible to do in other circumstances, like real (single pass) input iterators, therefore, we have probably to live with that and reconsider the issue together with concepts, as you are saying. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug c++/34750] ICE in fold_convert, at fold-const.c:1955
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-12 18:09 --- Note this may be invalid code, g++ 3.4 reports: gccfolderr.cc: In constructor `Rapicorn0752::Model::AutoValue::AutoValue(const Rapicorn0752::Model::Array&)': gccfolderr.cc:34571: error: invalid use of undefined type `struct Rapicorn0752::Model::Array' gccfolderr.cc:34450: error: forward declaration of `struct Rapicorn0752::Model::Array' gccfolderr.cc:34571: error: initializing argument 2 of `Rapicorn0752::Model::AnyValue::AnyValue(Rapicorn0752::Model::Type::Storage, V) [with V = Rapicorn0752::Model::Array]' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug c++/34753] [4.3 regression] ICE with invalid template parameter in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
[Bug c++/34753] New: [4.3 regression] ICE with invalid template parameter in variadic template
The following invalid code snippet triggers an ICE on mainline:
template struct A
{
template struct B {};
};
A::B<0> b;
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc: In instantiation of 'A':
bug.cc:6: instantiated from here
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The ICE appeared between 2007-11-30 and 2007-12-11.
--
Summary: [4.3 regression] ICE with invalid template parameter in
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
-- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #13 from pcarlini at suse dot de 2008-01-12 18:06 --- Anyway... The issue, after all, seems pretty academic to me, for the simple reason that, per your report, the only known example of a named locale showing '\0' as thousands separator is bg_BG, and most likely the data isn't even ok, per your glibc report. Therefore, unless the data turns out to be ok and the glibc people tell us, contrary to our understanding, that a \0 must be interpreted differently, there is really nothing to do. Let's suspend the PR, in the meantime. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-12 18:06:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-12 18:02 --- Also ICEs cc1plus with plain -O2 the same way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug fortran/34741] Bounds-check of array-pointer == [ constructor ]
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 18:01 --- gfortran does only create a check for ptr itself and not for ptr <-> constructor; the created check looks (with some temporary variables added) as follows: if (prt.lbound < ptr.lbound || ptr.lbound > ptr.ubound) (It were be also great if this would not be written by gfortran as it is rather useless; though the middle end will remove it using -O.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34741
[Bug c++/34752] [4.3 regression] pointer to member rejected in variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
[Bug c++/34752] New: [4.3 regression] pointer to member rejected in variadic template
The following (IMHO valid) code snippet is rejected on mainline:
struct A {};
template struct B1; // OK
template struct B2; // OK
template struct B3; // OK
template struct B4; // error
bug.cc:6: error: expected '>' before '...' token
--
Summary: [4.3 regression] pointer to member rejected in variadic
template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
[Bug regression/33928] [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-01-12 17:56 --- I'm downgrading this to P2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug c++/34751] [4.3 regression] ICE with pointer to member and variadic templates
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34751
[Bug c++/34751] New: [4.3 regression] ICE with pointer to member and variadic templates
The following (IMHO valid) code snippet triggers an ICE on mainline:
struct A {};
template struct B {};
B<0> b;
bug.cc:5: internal compiler error: tree check: accessed elt 2 of tree_vec with
1 elts in tsubst, at cp/pt.c:8934
Please submit a full bug report, [etc.]
A similar testcase just segfaults:
struct A {};
template struct B {};
B<> b;
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The ICE appeared between 2007-10-13 and 2007-11-13.
--
Summary: [4.3 regression] ICE with pointer to member and variadic
templates
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34751
[Bug libgcj/33764] [4.2/4.3 regression] gij is built as 32-bit binary when building multilib gcc
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-12 17:53 --- P2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33764
[Bug c++/34750] ICE in fold_convert, at fold-const.c:1955
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 17:47 --- Can you please retain line directives so we can bring this up to current development versions? Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34750
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #11 from zadeck at naturalbridge dot com 2008-01-12 17:05 --- until someone has the slightest bit of evidence that initializing the datastructure is costly, this is just a waste of time. peter wrote the code this way to be cute, not because there was any reason to believe that getting a zerod data structure was going to be noticeable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #10 from bonzini at gnu dot org 2008-01-12 16:52 --- an alternative is to prepare a suppression file for valgrind, and distribute it with gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #9 from zadeck at naturalbridge dot com 2008-01-12 16:34 --- i personally think that this patch in #8 is not the right way to go. unless there is a compelling argument that initializing this is going to have some negative performance effect, we should properly initialize this datastructure as we do (or at least try to do) for every other data structure in the compiler. While the current code that peter has written is correct, it is quite tricky. This compiler has way too much tricky code, which only adds to the long term maintainance cost of the compiler. the patch in 8 is not acceptable because it requires that the compiler be built in a particular way to avoid the valgrind errors. The last thing that you want to have to do if you have a heisenbug is to rebuild your compiler in a way that will change the layout and alignment of things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
