[Bug target/21578] New: ICE in reload_cse_simplify_operands for Coldfire.
Compiling RTEMS with -O3 the webserver code with 4.0.0 and 4.1.0 generates the
following ICE:
$ m68k-rtems-gcc -m5200 --pipe -DHAVE_CONFIG_H -I.. -I../../../lib/include
-DWEBS -DUEMF -Wall -fasm -O3 -g -m5200 -MT libhttpd_a-ejlex.o -MD -MP -MF
".deps/libhttpd_a-ejlex.Tpo" -c -o libhttpd_a-ejlex.o `test -f 'ejlex.c' || echo
'../../../../../head/cpukit/httpd/'`ejlex.c -save-temps
../../../../../head/cpukit/httpd/ejlex.c: In function ejLexGetToken:
../../../../../head/cpukit/httpd/ejlex.c:207: error: insn does not satisfy its
constraints:
(insn 3295 1381 1382 98 ../../../../../head/cpukit/httpd/ejlex.c:678 (set
(reg:QI 1 %d1)
(reg:QI 8 %a0)) 34 {*m68k.md:754} (nil)
(nil))
../../../../../head/cpukit/httpd/ejlex.c:207: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ m68k-rtems-gcc -v
Using built-in specs.
Target: m68k-rtems
Configured with: ../cvs/head/configure --target=m68k-rtems
--prefix=/local/tools/head --with-gnu-as --with-gnu-ld --with-newlib
--enable-threads=rtems --enable-languages=c,c++
Thread model: rtems
gcc version 4.1.0 20050515 (experimental)
--
Summary: ICE in reload_cse_simplify_operands for Coldfire.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cjohns at cybertec dot com dot au
CC: corsepiu at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org,joel at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-rtems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21578
[Bug target/21578] ICE in reload_cse_simplify_operands for Coldfire.
--- Additional Comments From cjohns at cybertec dot com dot au 2005-05-15 07:34 --- Created an attachment (id=8890) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8890&action=view) Compressed preprocessed file showing the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21578
[Bug target/21578] ICE in reload_cse_simplify_operands for Coldfire.
--- Additional Comments From cjohns at cybertec dot com dot au 2005-05-15 07:35 --- Compile the patch with: m68k-rtems-gcc -m5200 -fasm -O3 -g ejlex.i -c The ICE only shows with -O3. Using -O2 compiles the file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21578
Trotz Stellenabbau
Lese selbst: http://www.spiegel.de/wirtschaft/0,1518,338652,00.html
Tuerkei in die EU
GEWALTEXZESS: http://www.spiegel.de/politik/ausland/0,1518,345203,00.html Politiker zerreißt Menschenrechtsbericht: http://www.spiegel.de/politik/ausland/0,1518,325983,00.html Schily = Hitler http://www.spiegel.de/politik/deutschland/0,1518,345929,00.html Schily wehrt sich gegen Hitler-Vergleiche: http://www.spiegel.de/politik/deutschland/0,1518,345749,00.html Sie hat ja wie eine Deutsche gelebt: http://www.spiegel.de/panorama/0,1518,342484,00.html http://www.npd.de/npd_info/deutschland/2005/d0205-31.html Parallelgesellschaften - Feind hoerte mit: http://www.npd.de/npd_info/meldungen/2005/m0305-15.html Sie war unerlaubt spazieren: http://www.taz.de/pt/2004/11/25/a0143.nf/text Tiere an Autobahn geschlachtet: http://forum.gofeminin.de/forum/actu1/__f384_actu1-TuRKEI-NEIN-DANKE.html
[Bug libobjc/21579] New: memory overflow
I was compiling kernel on x86 i686 while i had this part going on, the following error stopped the install. CC [M] fs/nfs/pagelist.o In file included from include/linux/mm.h:269, from include/linux/pagemap.h:7, from include/linux/nfs_page.h:14, from fs/nfs/pagelist.c:18: include/linux/page-flags.h:-27821: internal compiler error: Memory Overflow Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . make[2]: *** [fs/nfs/pagelist.o] Error 1 make[1]: *** [fs/nfs] Error 2 make: *** [fs] Error 2 could this be nfs bug instead? -- Summary: memory overflow Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ics at ics-base dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21579
Massenhafter Steuerbetrug durch auslaendische Arbeitnehmer
Lese selbst: http://www.rp-online.de/public/article/nachrichten/wirtschaft/finanzen/deutschland/85815
[Bug c/21580] New: Less-than-ideal code generation for incrementing volatile variables
With gcc 4.0.1, the following code on i386 (using -O3 -fomit-frame-pointer):
int x;
void
foo (void)
{
++x;
}
compiles to:
foo:
incl x
ret
However, when x is changed to a volatile this instead compiles to:
foo:
movlx, %eax
incl%eax
movl%eax, x
ret
Similar degredations in the quality of generated code exists for statements like
--x, x += 2, etc when x is marked volatile. (Somewhat also related, "(void)x;"
still accesses memory when x is volatile -- I suppose this might be desirable,
however.)
--
Summary: Less-than-ideal code generation for incrementing
volatile variables
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrd at alkemio dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21580
Transparenz ist das Mindeste
Lese selbst: http://www.npd.de/npd_info/deutschland/2005/d0405-39.html
Volk wird nur zum zahlen gebraucht!
Lese selbst: http://www.my-rocknord.de/viewtopic.php?t=1018&sid=3ce6385b1dee88cb02447f566a2da68d .. damit Sie nicht als der erste Kanzler in die deutsche Geschichte eingehen, der Untertanen verboten hat, aus ihren Fenstern auf die Strasse zu gucken - selbst Nazis und Stalinisten haben niemals eine aehnliche Anordnung treffen lassen!
[Bug target/21578] ICE in reload_cse_simplify_operands for Coldfire.
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-15 11:06 --- I can reproduce the bug -- What|Removed |Added CC||peter at the-baradas dot com Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 Known to work||3.2.3 Last reconfirmed|-00-00 00:00:00 |2005-05-15 11:06:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21578
[Bug tree-optimization/21448] [4.1 Regression] ICE in estimate_num_insns_1, at tree-inline.c:1433
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-15 11:16 --- Might get fixed by http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01378.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21448
Massenhafter Steuerbetrug durch auslaendische Arbeitnehmer
Lese selbst: http://www.rp-online.de/public/article/nachrichten/wirtschaft/finanzen/deutschland/85815
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-15 11:21 --- >From 14.7.2 [temp.expl.spec] paragraph 2: An explicit specialization shall be declared in the namespace of which the template is a member, or, for member templates, in the namespace of which the enclosing class or enclosing class template is a member. ... -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
Re: [Bug fortran/20178] COMPLEX function returns incompatible with g77
tobi at gcc dot gnu dot org wrote: --- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10 22:23 --- Fixed on the mainline. I will commit this to the branch after the obligatory testing and the necessary changes (unfortunately -fsecond-underscore became the default on the branch). [ Sorry for the late reply ] I wonder if that really means we have to stick to -fsecond-underscore on the 4.0 branch. Only 4.0.0 is out, and it is very probable that *nobody* uses it for any serious work in Fortran anyway. I feel we can safely change the default, even on the branch. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
[Bug middle-end/21546] internal compiler error: in convert_move, at expr.c:339
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-15 11:30 --- Fixed in gcc version 4.0.1 20050510 (prerelease). -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21546
Massenhafter Steuerbetrug durch auslaendische Arbeitnehmer
Lese selbst: http://www.rp-online.de/public/article/nachrichten/wirtschaft/finanzen/deutschland/85815
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-05-15 11:32 --- Subject: Re: COMPLEX function returns incompatible with g77 tobi at gcc dot gnu dot org wrote: > --- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10 > 22:23 --- > Fixed on the mainline. I will commit this to the branch after the obligatory > testing and the necessary changes (unfortunately -fsecond-underscore became > the > default on the branch). [ Sorry for the late reply ] I wonder if that really means we have to stick to -fsecond-underscore on the 4.0 branch. Only 4.0.0 is out, and it is very probable that *nobody* uses it for any serious work in Fortran anyway. I feel we can safely change the default, even on the branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug c++/19073] cp_binding_level::names not returning all decls
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-15 11:46 --- Some comment: This cp_binding_level::names and how it is used are internal to GCC. Too bad -fdump-translation-unit relies on it. Names are placed in cp_binding_level::names only if it may be needed there in the future. Perhaps a solution would be adding every name there when -fdump-translation-unit is given (at the expense of some extra memory consumption, slower compilation). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-15 11:46:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
Dresden 1945
Lese selbst: http://www.kommunisten-online.de/blackchanel/dresden3.htm
Multi-Kulturell = Multi-Kriminell
Lese selbst: http://www.npd.de/npd_info/meldungen/2005/m0105-19.html
[Bug c++/21510] Possible bug
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-15 12:37 --- The code is invalid. In the section 14.8.2 [temp.deduct] paragraph 2 of the standard does not include creating a class with invalid base class. Examples of valid SNINF cases: - Attempting to create an array with an element type that is void, a function type, or a reference type, or attempting to create an array with a size that is zero or negative. - Attempting to use a type that is not a class type in a qualified name. etc. (there are many more they are clearly mentioned in the mentioned part of standard) -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21510
[Bug c++/21555] name lookup / friend function
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-15 12:41 --- Confirmed. I think the declaration int swap(A&, A&); should be accepted. Could be something wrong with the type computation to select overloaded function. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-15 12:41:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21555
The Whore Lived Like a German
Full Article: http://service.spiegel.de/cache/international/0,1518,344374,00.html
[Bug middle-end/21579] memory overflow
-- What|Removed |Added Component|libobjc |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21579
[Bug target/21580] Less-than-ideal code generation for incrementing volatile variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 13:03 --- There is another bug about this around somewhere. -- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21580
Du wirst ausspioniert ....!
und weisst es nicht einmal: http://www.heise.de/newsticker/meldung/58003 http://www.heise.de/newsticker/meldung/59304 http://www.heise.de/newsticker/meldung/58311 http://www.heise.de/newsticker/meldung/58351
Armenian Genocide Plagues Ankara 90 Years On
Full Article: http://service.spiegel.de/cache/international/0,1518,353274,00.html
[Bug target/3506] weird behaviour when incrementing volatile ints
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 13:33 --- Reopen to ... -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
[Bug target/3506] weird behaviour when incrementing volatile ints
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 13:33 --- Mark as invalid. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
[Bug target/21580] Less-than-ideal code generation for incrementing volatile variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 13:34 --- This is invalid, read the comments in PR 3506 which this is a dup of. *** This bug has been marked as a duplicate of 3506 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21580
[Bug target/3506] weird behaviour when incrementing volatile ints
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 13:34 --- *** Bug 21580 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mrd at alkemio dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
Graeberschaendung auf bundesdeutsche Anordnung
Lese selbst: http://www.die-kommenden.net/dk/zeitgeschichte/graeberschaendung.htm
[Bug libstdc++/21577] [3.4 Regression] libstdc++ testsuite broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 13:40 --- Fixed by: 2005-05-15 Andreas Schwab <[EMAIL PROTECTED]> * testsuite/Makefile.am (check-local): Really remove. * testsuite/Makefile.in: Regenerated. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21577
[Bug fortran/21570] Unformatted sequential read/write
--- Additional Comments From blime at cox dot net 2005-05-15 13:59 --- Subject: Re: Unformatted sequential read/write Okay - Its 32 bit -- but sorry I don't understand portable (one computer involved) or target? What I have been doing over the last couple of months is testing the gfortran compiler on a large simulation, and comparing results with those produced by the same inputs and the program compiled with g77 (used for several years). There are four modules involved and I tested the use of the g77 binary output from the first module as input for the second module compiled with gfortran. Thus far he gfortran compiler has identified a couple of bugs - but I could do a lot more testing if bug #20236 (T edit descriptor) were fixed - the code uses this convention in many places, and it is no small task to change to the X edit descriptor. Thanks for responding. blime pinskia at gcc dot gnu dot org wrote: >--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14 >16:34 --- >Is this with a 64bit target? > >I don't think we should consider this a bug because binary files are never >portable between targets. > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21570
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-15
14:03 ---
(In reply to comment #3)
> From 14.7.2 [temp.expl.spec] paragraph 2:
> An explicit specialization shall be declared in the namespace of which the
> template is a member,
> or, for member templates, in the namespace of which the enclosing class or
> enclosing class
> template is a member. ...
Well, the standard seems to be inconsistent and You do not have to implement
all inconsistencies:-( Accept it as a wished extension, please.
After some googling I found some hints to solve this problem at
http://oopweb.com/CPP/Documents/CPPAnnotations/VolumeFrames.html?/CPP/Documents/CPPAnnotations/Volume/cplusplus16.html
Read and done I get the error messages:
test.cpp:27: error: invalid explicit specialization before '>' token
test.cpp:27: error: enclosing class templates are not explicitly specialized
test.cpp:28: error: template parameters not used in partial specialization:
test.cpp:28: error: `_T'
test.cpp:31: error: expected init-declarator before "p"
test.cpp:31: error: expected `;' before "p"
I know that the enclosing class is not explicitely specialized, that's the
intention. Is there any compileable example to solve this problem available in
the net?
And here is the test code:
--- test.cpp
template
class wrapper
{
public:
wrapper(_T t): _M_t(t) {}
operator _T& () { return _M_t; }
private:
_T _M_t;
};
struct container
{
struct pointer {};
struct forward {};
struct backward {};
struct bidirectional {};
struct randomaccess {};
};
template
struct heap: container
{
typedef _T value_type;
template struct iterator;
};
// Who invented this syntax?
template template<>
struct heap<_T>::iterator :
wrapper::value_type *> {}
heap::iterator::pointer> p;
--
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
[Bug c++/21510] Possible bug
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-15 14:08 --- (In reply to comment #3) > The code is invalid. In the section 14.8.2 [temp.deduct] paragraph 2 of the > standard > does not include creating a class with invalid base class. If there is no other way to distinguish reliable between unions and classes, add it into the extension list. Unions should be avoided in object oriented design, anyway, but it is a nice-to-have feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21510
[Bug c++/21491] [4.0/4.1 Regression] crosses initialization of a pointer
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-15 14:11 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-15 14:11:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21491
[Bug target/21551] [4.0 Regression] bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 14:12 --- Created an attachment (id=8891) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8891&action=view) A testcase With the bad compiler, I got [EMAIL PROTECTED] gcc]$ stage1/xgcc -Bstage1/ -O2 -S /tmp/foo.c [EMAIL PROTECTED] gcc]$ grep "insn_data" foo.s addl r34 = @ltoffx(insn_data#+16384), r1 ld8.mov r34 = [r34], insn_data#+16384 addl r34 = @ltoffx(insn_data#+32768), r1 ld8.mov r34 = [r34], insn_data#+32768 I don't see how "insn_data#+32768" can be right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug c++/21510] Possible bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 14:12 --- (In reply to comment #4) > If there is no other way to distinguish reliable between unions and classes, > add it into the extension list. Unions should be avoided in object oriented > design, anyway, but it is a nice-to-have feature. Extensions are bad. Even just bugs in the compiler is a bad thing beause people would think the bug was an extension and start depending on it and then when the bug was fixed, people complain their code no longer compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21510
[Bug c++/21581] New: (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
Functions (and variables I suppose) in an anonymous namespace can't realisitically be used outside the shared library they are part of (due to the mangled name being randomized each compile). This means that they could be of visibility hidden, which 1) Cuts down on the amount of work for the dynamic linker 2) Means that internal calls to these functions can avoid the PLT trampoline (and thus get higher performance) -- Summary: (optimisation) Functions in anonymous namespaces should default to "hidden" visibility Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjanv at redhat dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c/21582] New: (optimisation) VRP pass could/should use non-null function attribute
The nonnull function attribute specifies that certain pointer arguments to said function are not allowed to be NULL. The VRP pass could put this in the possible range for said variables, after which NULL pointer checks inside the function body (or more likely, functions inlined into that function) can be optimized away. -- Summary: (optimisation) VRP pass could/should use non-null function attribute Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjanv at redhat dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21582
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 14:21 --- I don't think this is valid and here is why: anynymous namespace and still be used for templates and export so calling it from another shared library is possible if we (GCC) implements export. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug tree-optimization/21582] (optimisation) VRP pass could/should use non-null function attribute
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 14:22 --- Interesting idea. -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Component|c |tree-optimization Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21582
[Bug target/21551] [4.0 Regression] bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 14:35 --- It seems that "-fgcse -O" will trigger the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-15 14:36 --- Yup, string literal should have type 'const char *'. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-15 14:36:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
Massenhafter Steuerbetrug durch auslaendische Arbeitnehmer
Lese selbst: http://www.rp-online.de/public/article/nachrichten/wirtschaft/finanzen/deutschland/85815
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-15
14:43 ---
And for everyone who have the same problem, here is a workaround. Declare a
template class with a dummy argument (int in this case), partial specialize
this class and derive from the partial specialized template class. Why?
Because the standard says so, there is no other reason (in other words, there
is no reason at all).
--- test.cpp
template
class wrapper
{
public:
wrapper(): _M_t() {}
wrapper(_T t): _M_t(t) {}
operator _T& () { return _M_t; }
private:
_T _M_t;
};
struct container
{
struct pointer {};
struct forward {};
struct backward {};
struct bidirectional {};
struct randomaccess {};
};
template
struct heap: container
{
typedef _T value_type;
template struct _iterator;
private:
// the absolute unnecessary additional template class
template
// partial specialization is allowed
struct _iterator: wrapper {};
public:
template struct iterator: _iterator<_U, 0> {};
};
heap::iterator::pointer> p;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
[Bug c++/21510] Possible bug
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-15 14:46 --- (In reply to comment #5) > Extensions are bad. Even just bugs in the compiler is a bad thing beause > people would think the bug > was an extension and start depending on it and then when the bug was fixed, >people complain their > code no longer compiles. Is there a way to distinguish between unions (which are not usable as base classes) and classes? If not, the standard is incomplete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21510
[Bug c++/21583] New: FAIL: g++.old-deja/g++.eh/badalloc1.C execution test
Executing on host: /xxx/gnu/gcc-3.3/objdir/gcc/testsuite/../g++ -B/xxx/gnu/gcc-3 .3/objdir/gcc/testsuite/../ /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/g++.old-deja/g++. eh/badalloc1.C -nostdinc++ -I/xxx/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libs tdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/xxx/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpu x11.11/libstdc++-v3/include -I/xxx/gnu/gcc-3.3/gcc/libstdc++-v3/libsupc++ -I/xxx /gnu/gcc-3.3/gcc/libstdc++-v3/libsupc++ -I/xxx/gnu/gcc-3.3/gcc/libstdc++-v3/incl ude/backward -I/xxx/gnu/gcc-3.3/gcc/libstdc++-v3/testsuite -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long-L/xxx/gnu/gcc-3.3/objdir/hppa2.0w-hp-h pux11.11/./libstdc++-v3/src/.libs -L/xxx/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.1 1/./libiberty -lm -o ./badalloc1.exe(timeout = 300) PASS: g++.old-deja/g++.eh/badalloc1.C (test for excess errors) Setting LD_LIBRARY_PATH to .:/xxx/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./lib stdc++-v3/src/.libs:/xxx/gnu/gcc-3.3/objdir/gcc:.:/xxx/gnu/gcc-3.3/objdir/hppa2. 0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/xxx/gnu/gcc-3.3/objdir/gcc terminate called recursively FAIL: g++.old-deja/g++.eh/badalloc1.C execution test -- Summary: FAIL: g++.old-deja/g++.eh/badalloc1.C execution test Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa*-hp-hpux11.11 GCC host triplet: hppa*-hp-hpux11.11 GCC target triplet: hppa*-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21583
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From pcarlini at suse dot de 2005-05-15 14:51 --- > ... Why? > Because the standard says so, there is no other reason (in other words, there > is no reason at all). I'm sorry, why this attitude? The standard has been made by people, there are definitely errors in it, that are being corrected, a very hard and prolonged effort. We are not talking about "enemies", we are talking about people like me and you: people like me and you don't like unreasonable choices, I think. Can happen to end up with something that looks unreasonable, in retrospect, but I think we owe respect to that endeavour (I'm not discussing the merit of your problem, just some general considerations) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
[Bug fortran/21570] Unformatted sequential read/write
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-15 15:01 --- (In reply to comment #3) > > There are four modules involved and I > tested the use of the g77 binary output from the first module as input > for the second module compiled with gfortran. > AFAIK, there is no commitment or plans to support compatibility between g77 and gfortran binary file formats. If you absolutely must have this feature, then please submit a seperate bug reports asking for this enhancement. NB: I doubt that this feature would be very high on anyone's list of things to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21570
[Bug c++/21510] Possible bug
--- Additional Comments From pcarlini at suse dot de 2005-05-15 15:03 --- > Is there a way to distinguish between unions (which are not usable as base > classes) and classes? If not, the standard is incomplete. You should know that 10 years ago people didn't even imagine the kind of template usages that you are assuming as obvious. Indeed, everyone wants to tell unions from classes now and you bet, it will be possible sometime in the future, likely not using SFINAE at all. Before posting other messages with this attitude, please, please have a look to the papers available from the ISO Web site: http://www.open-std.org/jtc1/sc22/wg21/ Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21510
S.O.S. Kiez! Polizei schlaegt Alarm
Lese selbst: http://bz.berlin1.de/archiv/041115_pdf/BZ041115_004_GB2IG556.1.htm
Paranoider Deutschenmoerder kommt in Psychiatrie
Lese selbst: http://brandenburg.rz.fhtw-berlin.de/poetschke.html
Auslaender bevorzugt
Lese selbst: http://www.npd.de/npd_info/deutschland/2005/d0305-14.html Jetzt weiss man auch, wie es dazu kommt, dass Drogen, Waffen & Handy's in die Haende der Knacki's gelangen!
Paranoider Deutschenmoerder kommt in Psychiatrie
Lese selbst: http://brandenburg.rz.fhtw-berlin.de/poetschke.html
[Bug target/21551] [4.0 Regression] bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 15:36 ---
The change in ia64_expand_move
if (addend)
{
rtx subtarget = no_new_pseudos ? op0 : gen_reg_rtx (mode);
emit_insn (gen_rtx_SET (VOIDmode, subtarget, op1));
op1 = expand_simple_binop (mode, PLUS, subtarget,
GEN_INT (addend), op0, 1, OPTAB_DIRECT);
if (op0 == op1)
return NULL_RTX;
}
looks strange to me. Isn't addend added twice when addend == 0x4000?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug c++/21584] New: ICE: verify_flow_sensitive_alias_info failed.
G++ at O1 or above aborts with
ps.ii: In function 'void baz()':
ps.ii:24: error: Pointers with a memory tag, should have points-to sets or point
to malloc
p_40, name memory tag: NMT.6, points-to vars: { }
p, UID 0, char *, type memory tag: TMT.3
ps.ii:24: internal compiler error: verify_flow_sensitive_alias_info failed.
--
Summary: ICE: verify_flow_sensitive_alias_info failed.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: graham dot stott at btinternet dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-unknown-gnu
GCC host triplet: i686-pc-unknown-gnu
GCC target triplet: i686-pc-unknown-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21584
[Bug c++/21584] ICE: verify_flow_sensitive_alias_info failed.
--- Additional Comments From graham dot stott at btinternet dot com 2005-05-15 15:42 --- Created an attachment (id=8892) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8892&action=view) C++ testcase which aborts at -O1 or abive -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21584
[Bug tree-optimization/21585] New: FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2
Executing on host: /home/dave/gcc-4.1/objdir/gcc/xgcc -B/home/dave/gcc-4.1/objdi r/gcc/ /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.c -w -O2 -fno-show-column -lm -o /home/dave/gcc-4.1/objdir/gcc/testsuite/2003 1215-1.x2(timeout = 300) /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.c: In func tion 'test1': /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11: erro r: Statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS # VUSE ; ao.ch[2] = 0; /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11: inte rnal compiler error: verify_ssa failed. Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 This occurs at -O2 and above. -- Summary: FAIL: gcc.c-torture/execute/20031215-1.c compilation, - O2 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21585
[Bug tree-optimization/21586] New: FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1
Executing on host: /home/dave/gcc-4.1/objdir/gcc/xgcc -B/home/dave/gcc-4.1/objdi r/gcc/ /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-5.c -O2 -ft ree-loop-linear -fdump-tree-ltrans-all -fno-show-column -S -o ltrans-5.s(ti meout = 300) PASS: gcc.dg/tree-ssa/ltrans-5.c (test for excess errors) FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times Linear expression: consta nt: 1 invariants: denominator: 1 1 FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1 -- Summary: FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21586
[Bug c++/19073] cp_binding_level::names not returning all decls
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-05-15 16:17 --- (In reply to comment #9) > only if it may be needed there in the future. Perhaps a solution would be > adding every name there when -fdump-translation-unit is given (at the expense of > some extra memory consumption, slower compilation). in case you plan to to this: the above mentioned case seems to be the only one. I've fixed this in my project MetaC++ by just commenting out the 4 lines above. which probably introduces other bugs and so is no solution for -fdump..., but what I'm trying to say is that this is the only case where GCC does not add a name to cp_binding_level::names -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug target/21551] [4.0 Regression] ia64 bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 16:41 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01431.html -- What|Removed |Added Summary|[4.0 Regression] bootstrap |[4.0 Regression] ia64 |failed |bootstrap failed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug c++/21587] New: Explicit inlining should never fail
When compiling with -Winline -O[2,3,s], I frequently get errors like: mistream.h:196: warning: called from here mistream.h:174: warning: inlining failed in call to 'bool ustl::istream::aligned(size_t) const': --param large-function-growth limit reached This is understandable, since I use a lot of inlining and inevitably run over this limit or one of the others. Explicitly increasing the --param value solves the problem. However, it bothers me that the compiler requires special flags to inline functions that I have already explicitly declared as inline. When I use the inline keyword in a declaration, I expect the compiler to inline it no matter what, with debug builds being the only exception. So can the optimizer automatically adjust inlining parameters and inline everything I tell it to inline? I suppose it might be a bit of work, since explicit parameter limits should still be honored. -- Summary: Explicit inlining should never fail Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: msharov at hotmail dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21587
[Bug c++/19073] cp_binding_level::names not returning all decls
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-15 16:47 --- Subject: Re: cp_binding_level::names not returning all decls "sstrasser at systemhaus-gruppe dot de" <[EMAIL PROTECTED]> writes: | (In reply to comment #9) | > only if it may be needed there in the future. Perhaps a solution would be | > adding every name there when -fdump-translation-unit is given (at the | expense of | > some extra memory consumption, slower compilation). | | in case you plan to to this: the above mentioned case seems to be the only one. | I've fixed this in my project MetaC++ by just commenting out the 4 lines above. | which probably introduces other bugs and so is no solution for -fdump..., but | what I'm trying to say is that this is the only case where GCC does not add a | name to cp_binding_level::names The more I think about this, the more I'm wondering whether cp_binding_level::names is the proper way to get the real functionality. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug libstdc++/21523] [4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-15 16:54 --- Fixed in 4.0.1. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug tree-optimization/21586] FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-15 17:06 --- Test removed -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21586
[Bug testsuite/21539] [4.1 Regression] gcc.dg/tree-ssa/ltrans-5.c fails
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-15 17:07 --- Test removed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21539
[Bug c++/21583] FAIL: g++.old-deja/g++.eh/badalloc1.C execution test
--- Additional Comments From joseph at codesourcery dot com 2005-05-15 17:19 --- Subject: Re: New: FAIL: g++.old-deja/g++.eh/badalloc1.C execution test On Sun, 15 May 2005, danglin at gcc dot gnu dot org wrote: > FAIL: g++.old-deja/g++.eh/badalloc1.C execution test FWIW, the IA64 version of this was bug 19888. Backporting the testsuite patch for that to 4.0 branch is on my TODO list; I don't know whether it would also address the PA issue on 3.4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21583
[Bug tree-optimization/21585] FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2
--- Additional Comments From joseph at codesourcery dot com 2005-05-15 17:20 --- Subject: Re: New: FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2 On Sun, 15 May 2005, danglin at gcc dot gnu dot org wrote: > Executing on host: /home/dave/gcc-4.1/objdir/gcc/xgcc > -B/home/dave/gcc-4.1/objdi > r/gcc/ /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.c > -w -O2 -fno-show-column -lm -o > /home/dave/gcc-4.1/objdir/gcc/testsuite/2003 > 1215-1.x2(timeout = 300) > /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.c: In > func > tion 'test1': > /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11: > erro > r: Statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS > # VUSE ; > ao.ch[2] = 0; > /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11: > inte > rnal compiler error: verify_ssa failed. > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > compiler exited with status 1 I already filed this as bug 21541 when it started failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21585
[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-15 17:21 --- No, these should be getting may-defs in either form, so someting is not going right :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug tree-optimization/21586] FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1
--- Additional Comments From joseph at codesourcery dot com 2005-05-15 17:21 --- Subject: Re: New: FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1 On Sun, 15 May 2005, danglin at gcc dot gnu dot org wrote: > Executing on host: /home/dave/gcc-4.1/objdir/gcc/xgcc > -B/home/dave/gcc-4.1/objdi > r/gcc/ /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-5.c -O2 > -ft > ree-loop-linear -fdump-tree-ltrans-all -fno-show-column -S -o ltrans-5.s > (ti > meout = 300) > PASS: gcc.dg/tree-ssa/ltrans-5.c (test for excess errors) > FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times Linear expression: > consta > nt: 1 invariants: denominator: 1 1 > FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1 Bug 21539 (fixed by removing the test). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21586
[Bug tree-optimization/21584] [4.1 Regression] ICE: verify_flow_sensitive_alias_info failed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 17:23 --- Confirmed. -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed||1 GCC build triplet|i686-pc-unknown-gnu | GCC host triplet|i686-pc-unknown-gnu | GCC target triplet|i686-pc-unknown-gnu | Keywords||ice-on-valid-code Known to fail||4.1.0 Known to work||4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-05-15 17:23:21 date|| Summary|ICE:|[4.1 Regression] ICE: |verify_flow_sensitive_alias_|verify_flow_sensitive_alias_ |info failed.|info failed. Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21584
[Bug tree-optimization/21584] [4.1 Regression] ICE: verify_flow_sensitive_alias_info failed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 17:25 --- This worked with "4.1.0 20050420", I think the patch which moved tree-loop-CH around exposed a latent bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21584
Du wirst ausspioniert ....!
und weisst es nicht einmal: http://www.heise.de/newsticker/meldung/58003 http://www.heise.de/newsticker/meldung/59304 http://www.heise.de/newsticker/meldung/58311 http://www.heise.de/newsticker/meldung/58351
[Bug tree-optimization/21585] FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 17:26 --- *** This bug has been marked as a duplicate of 21541 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21585
[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 17:26 --- *** Bug 21585 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug c++/21587] Explicit inlining should never fail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 17:33 --- inline is always been just a hint to the compiler, sorry, this is how the standard is worded (or very close). For 4.1.0, we should have optimization before inlining and should be better at estimating the size of the function. The params are there so we can tune GCC, if you instead supply a testcase to a new bug where we don't inline fully, that would be better than changing how this works. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21587
[Bug target/21552] ia64 bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 17:35 --- This may be the same as bug 21551. After applying the patch http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01431.html the stage 2 build passed ia64.o. -- What|Removed |Added Summary|Bootstrap failed|ia64 bootstrap failed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21552
[Bug target/21552] ia64 bootstrap failed
-- What|Removed |Added CC||rth at gcc dot gnu dot org Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21552
[Bug c++/21583] FAIL: g++.old-deja/g++.eh/badalloc1.C execution test
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-05-15 17:38 --- Subject: Re: FAIL: g++.old-deja/g++.eh/badalloc1.C execution test > > FAIL: g++.old-deja/g++.eh/badalloc1.C execution test > > FWIW, the IA64 version of this was bug 19888. Backporting the testsuite > patch for that to 4.0 branch is on my TODO list; I don't know whether it > would also address the PA issue on 3.4 branch. This test doesn't fail on 4.0, so there's a good chance that increasing arena_size would fix this fail on the PA. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21583
[Bug tree-optimization/21585] FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-05-15 17:45 --- Subject: Re: FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2 > I already filed this as bug 21541 when it started failing. Forgot. Bug 21541 isn't tagged to the hppa target. Generally, I find target searches the easiest way to find target related bugs. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21585
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-15 17:46 --- (In reply to comment #6) > > ... Why? > > Because the standard says so, there is no other reason (in other words, there > > is no reason at all). > > I'm sorry, why this attitude? The problem with _any_ ISO standardized programming language is, that they tend to be inconsistence and incomplete because of political decisions of the standardization comitee members (the same appears in C and SQL). Take this problem for example. It is absolutely incomprehensivly that partial specialization is allowed, but full specialization is not (explicit specialzation is a misnomer, any specialization is explicit to some degree). Speculating about the reason, I would say that seven years ago a compiler vendor had problems to implement full specialization (and I would not wonder, if the same vendor implements it as an extension, nowadays). To make matters worse, You have a small chance to influence the comitee without being a member. And becoming a member costs money -- as getting the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
Massenhafter Steuerbetrug durch auslaendische Arbeitnehmer
Lese selbst: http://www.rp-online.de/public/article/nachrichten/wirtschaft/finanzen/deutschland/85815
[Bug target/21588] New: x86 machine builtins do not have any const/pure attributes set
Consider this snippet:
typedef float v4sf __attribute__ ((vector_size (16)));
float global;
float
waste_global (float p[4])
{
__builtin_ia32_loadups (p);
global += 1.0;
}
GCC now thinks __builtin_ia32_loadups clobbers global:
waste_global (pD.1564)
{
floatD.28 D.1568;
floatD.28 global.0D.1567;
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
# globalD.1563_6 = V_MAY_DEF ;
__builtin_ia32_loadups (pD.1564_1);
# VUSE ;
global.0D.1567_3 = globalD.1563;
D.1568_4 = global.0D.1567_3 + 1.0e+0;
# globalD.1563_5 = V_MUST_DEF ;
globalD.1563 = D.1568_4;
return;
# SUCC: EXIT [100.0%]
}
This is a bit silly, if we encourage people to use builtins instead
of inline assembly.
--
Summary: x86 machine builtins do not have any const/pure
attributes set
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,hubicka at gcc dot gnu
dot org,rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21588
[Bug fortran/16898] Aliasing problem with array descriptors
--- Additional Comments From aj at gcc dot gnu dot org 2005-05-15 17:50 --- I have on Linux/x86-64 these passes - which means all of them pass: XPASS: gfortran.dg/ret_pointer_1.f90 -O0 execution test XPASS: gfortran.dg/ret_pointer_1.f90 -O1 execution test XPASS: gfortran.dg/ret_pointer_1.f90 -O2 execution test XPASS: gfortran.dg/ret_pointer_1.f90 -O3 -fomit-frame-pointer execution test XPASS: gfortran.dg/ret_pointer_1.f90 -O3 -fomit-frame-pointer -funroll-loops e xecution test XPASS: gfortran.dg/ret_pointer_1.f90 -O3 -fomit-frame-pointer -funroll-all-loop s -finline-functions execution test XPASS: gfortran.dg/ret_pointer_1.f90 -O3 -g execution test XPASS: gfortran.dg/ret_pointer_1.f90 -Os execution test On Linux/i686 I get less passes: XPASS: gfortran.dg/ret_pointer_1.f90 -O0 execution test XPASS: gfortran.dg/ret_pointer_1.f90 -O1 execution test XPASS: gfortran.dg/ret_pointer_1.f90 -O3 -fomit-frame-pointer execution test XPASS: gfortran.dg/ret_pointer_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test XPASS: gfortran.dg/ret_pointer_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test So, -Os and -O2 are broken on i686. -- What|Removed |Added CC||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16898
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 17:54 --- Let me say this, the standard is needed otherwise, there is no language defined as C, just like there phython is not really defined. Oh, and people who write GCC are both on the C and C++ ISO committees. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
[Bug tree-optimization/21585] FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2
--- Additional Comments From joseph at codesourcery dot com 2005-05-15 17:55 --- Subject: Re: FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2 On Sun, 15 May 2005, dave at hiauly1 dot hia dot nrc dot ca wrote: > Subject: Re: FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2 > > > I already filed this as bug 21541 when it started failing. > > Forgot. > > Bug 21541 isn't tagged to the hppa target. Generally, I find target > searches the easiest way to find target related bugs. The bug didn't seem target-specific so I didn't enter target fields. Normally I search for the testcase name (actually, in my GCC list folders so as to locate any recent discussion of it other than in Bugzilla as well as gcc-bugs traffic) when entering new bugs for testsuite regressions; this also shows if other targets have results on gcc-testresults with the test failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21585
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-15
17:58 ---
This is the last try. First I wonder who has invented the strange syntax for
defining template member classes outside. C++ is still an imperative
programming language, not a functional. A straightforward syntax would be
template
struct heap<_T>::template<>
struct iterator: wrapper::pointer> {};
But that is not Your concern (unless You are a member of the standardization
comitee). The errors I get now is:
test.cpp:32: error: aggregate `heap::iterator p' has
incomplete type and cannot be defined
test.cpp:32: error: storage size of `p' isn't known
Simply untrue.
If You replace line 29 with
struct heap<_T>::iterator:
the errors are
test.cpp:29: error: template parameters not used in partial specialization:
test.cpp:29: error: `_T'
test.cpp:32: error: aggregate `heap::iterator p' has
incomplete type and cannot be defined
test.cpp:32: error: storage size of `p' isn't known
Anyway, the workaround posted earlier is much more comprehensive and easier to
read.
--- test.cpp
template
class wrapper
{
public:
wrapper(): _M_t() {}
wrapper(_T t): _M_t(t) {}
operator _T& () { return _M_t; }
private:
_T _M_t;
};
struct container
{
struct pointer {};
struct forward {};
struct backward {};
struct bidirectional {};
struct randomaccess {};
};
template
struct heap: container
{
typedef _T value_type;
template struct iterator;
};
template<> template
struct heap<_T>::iterator::pointer>: // line 29
wrapper::value_type *> {};
heap::iterator::pointer> p;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
[Bug target/21588] x86 machine builtins do not have any const/pure attributes set
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 18:05 --- Confirmed, I cannot remember or not if the rs6000/altivec builtins were fixed or not. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet||i?86-*-*, x86_64-*-* Last reconfirmed|-00-00 00:00:00 |2005-05-15 18:05:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21588
[Bug tree-optimization/21584] [4.1 Regression] ICE: verify_flow_sensitive_alias_info failed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15
18:07 ---
Here is as reduced as I could get it:
extern char *strcpy (char *__restrict __dest, __const char *__restrict __src);
extern char *foo (void);
extern void *malloc(__SIZE_TYPE__) __attribute__((malloc));
char v[100];
void baz()
{
char *vec;
char buf[512];
char *p = buf;
while (v[(*p)])
p++;
if (*p != '#' && (p = foo()) != 0) {
strcpy ((char*)malloc(10), p);
}
}
Note it works with the C front-end but that is only because of the difference
in the trees which are
produced (stupid C++ front-end produces more trees for the if statement).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21584
[Bug c++/21543] Full specialization of templates not supported in classes
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-15 18:20 --- (In reply to comment #8) > Let me say this, the standard is needed otherwise, there is no language > defined as C, just like there phython is not really defined. Did You know that You can not write a C preprocessor in ANSI C (at least none, You want to work with)? ANSI C lacks the necessary standardization of the underlying file system, thus, You do not know how to combine a path with an include file enclosed in brackets (#include ). Python is defined. There is only one Python interpreter and Python is, what the interpreter does. It has the advantage, that it is not standardized but developed by the comunity. Compared to C (which has beside ANSI the POSIX, XOPEN, BSD and what not as a library 'standard') I see this aproach as an advantage. I do not think that there is any C compiler which implements _only_ the ANSI/ISO standard. Of course, ANSI/ISO C is underdefined (as far as I know) because the standardization comitee does not publish a test suite for standard conformance (unlike Python, Perl, Java, PHP). > Oh, and people who write GCC are both on the C and C++ ISO committees. Sorry, if You feel personal insulted. It was not intended. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21543
[Bug java/21519] ICE in generate_bytecode_conditional, at java/jcf-write.c:1337
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-15 18:28 --- Subject: Bug 21519 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-15 18:28:30 Modified files: gcc/java : ChangeLog expr.c jcf-write.c libjava: ChangeLog Added files: libjava/testsuite/libjava.compile: pr21519.java pr21519.no-link Log message: gcc/java: PR java/21519: * jcf-write.c (generate_bytecode_insns) : Don't call NOTE_PUSH. libjava: PR java/21519: * testsuite/libjava.compile/pr21519.java: New file. * testsuite/libjava.compile/pr21519.no-link: New file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1610&r2=1.1611 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.225&r2=1.226 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/jcf-write.c.diff?cvsroot=gcc&r1=1.162&r2=1.163 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3612&r2=1.3613 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/pr21519.java.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/pr21519.no-link.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21519
[Bug target/21552] ia64 bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 18:45 --- *** This bug has been marked as a duplicate of 21551 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21552
[Bug target/21551] [4.0 Regression] ia64 bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 18:45 --- *** Bug 21552 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug target/21551] [4.0 Regression] ia64 bootstrap failed
--- Additional Comments From hjl at lucon dot org 2005-05-15 18:45 --- *** Bug 21556 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug bootstrap/21556] [4.0/4.1 Regression] ia64-hpux bootstrap fails on mainline, TLS failures on 4.0 branch
--- Additional Comments From hjl at lucon dot org 2005-05-15 18:45 --- *** This bug has been marked as a duplicate of 21551 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21556
Re: [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
corsepiu at gcc dot gnu dot org wrote: Joel, do you recall the target in RTEMS which has 4-byte floats only? (We recently had an issue with it floating point context sizes related to it? IIRC, it had been a powerpc variant and we were forced to drop it because GCC doesn't support it. BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't have 8byte floats. RTEMS doesn't support them, so I've never tried to build fortran for then. Note that the major demand the Fortran Standard places on DOUBLE PRECISION is that it takes up twice the amount of storage. It also is supposed to be of "higher precision", but that is a QOI issue. Cheers, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-05-15 18:49 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org wrote: > Joel, do you recall the target in RTEMS which has 4-byte floats only? > (We recently had an issue with it floating point context sizes related to it? > IIRC, it had been a powerpc variant and we were forced to drop it because GCC > doesn't support it. > > BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't > have 8byte floats. RTEMS doesn't support them, so I've never tried to build > fortran for then. Note that the major demand the Fortran Standard places on DOUBLE PRECISION is that it takes up twice the amount of storage. It also is supposed to be of "higher precision", but that is a QOI issue. Cheers, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
