Re: GCC-4.0.4 release status
Hi, > There were over 250 PRs open against GCC-4.0.4. Almost all of > them are "benign" in the sense that we can leave without fixing them > in GCC-4.0.4 -- many are already fixed in more recent versions. > I'm now giving attention only to those PRs marked as blocker or > critical. I've identified three: Well, there's another serious (wrong-code) bug which should be fixed IMHO: PR c++/29106 is a C++ front-end issue. It has a one-line fix (plus comment) on the 4.1 branch. Well, actually one should also backport the fix for PR c++/28284 then, which is a two-liner. Unfortunately, I didn't find the time to test the patch myself. Regards, Volker
Re: GCC-4.0.4 release status
Hi, > | Well, there's another serious (wrong-code) bug which should be fixed IMHO: > | > | PR c++/29106 is a C++ front-end issue. > | It has a one-line fix (plus comment) on the 4.1 branch. > | Well, actually one should also backport the fix for PR c++/28284 then, > | which is a two-liner. > I was primarily looking at the PRs that marked in the bugzilla > database blocker or critical. As there were over 256 PRs open, and > the idea is to get GCC-4.0.4 out of the door as soon as possible, I'm > not trying to fix everything; just those that are critical or > blockers. This is based on the fact that most distros have moved to > GCC-4.1.x or higher. GCC-4.0.x has been since GCC-4.0.0 to contain > major shortcomings. Well, the severity status of the bugs is not very well maintained. Mark e.g. only sets the prioriy field (P1 - P5) of the bugs. And PR 29106 bug is one of the 37 P1 bugs. And one from three wrong-code P1 bugs. So this is not like every simple error-recovery problem. In addition this is a regression from GCC 4.0.2, i.e. a regression on the 4.0 branch. Which makes this bug even worse, IMHO. (This infromation seems to be missing in bugzilla, though.) Considering how much dispute there is on the mailing list about how to handle undefined behaviour correctly ;-), it bothers me more that we ignore one-lines fixes for wrong-code bugs. Regards, Volker
Bootstrap failure with Objective-C++
Hi, bootstrap with Objective-C++ seems to be broken on mainline (rev. 122792): /gccbuild/src-4.3/build/./prev-gcc/xgcc -B/gccbuild/src-4.3/build/./prev-gcc/ -B/GCC/FARM/gcc-4.3-20070310/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -DOBJCPLUS -I../../gcc/gcc/objc -I../../gcc/gcc/cp -fno-common -DHAVE_CONFIG_H -I. -Iobjcp -I../../gcc/gcc -I../../gcc/gcc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/Pakete/GMP/include -I/Pakete/MPFR-2.2.1/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber-I. -Iobjcp -I../../gcc/gcc -I../../gcc/gcc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/Pakete/GMP/include -I/Pakete/MPFR-2.2.1/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/objc/objc-act.c -o objcp/objcp-act.o cc1: warnings being treated as errors ../../gcc/gcc/objc/objc-act.c: In function 'lookup_method_in_protocol_list': ../../gcc/gcc/objc/objc-act.c:570: error: comparison is always false due to limited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'lookup_protocol_in_reflist': ../../gcc/gcc/objc/objc-act.c:598: error: comparison is always false due to limited range of data type ../../gcc/gcc/objc/objc-act.c:605: error: comparison is always false due to limited range of data type ../../gcc/gcc/objc/objc-act.c: In function 'generate_protocol_references': ../../gcc/gcc/objc/objc-act.c:4443: error: comparison is always false due to limited range of data type [snip] ../../gcc/gcc/objc/objc-act.c: In function 'objc_lookup_ivar': ../../gcc/gcc/objc/objc-act.c:9428: error: comparison is always false due to limited range of data type ../../gcc/gcc/objc/objc-act.c:9440: error: comparison is always false due to limited range of data type make[3]: *** [objcp/objcp-act.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcj-dbtool.pod grmiregistry.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gfdl.pod cpp.pod gij.pod gpl.pod gc-analyze.pod gfortran.pod gcc.pod make[3]: Leaving directory `/gccbuild/src-4.3/build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/gccbuild/src-4.3/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/gccbuild/src-4.3/build' make: *** [bootstrap-lean] Error 2 Is anybody else seeing this? Regards, Volker
GCC 4.0.1 Status (2005-06-13)
Hi Mark, you wrote > Those who have been watching carefully will note that there is no sign of an > actual > 4.0.1 release. since the branch has been frozen for quite sime time now, a lot of patches for the 4.0 branch have piled up. Given the facts that a) we'll have another relaese candidate anyway b) many of these patches have seen some testing on mainline (and some even on the 3.4 branch) c) they fix regressions (some of them are even wrong-code like PR 21850) d) the release would already be outdated otherwise e) if problems showed up with the patches for users we could address them in 4.0.2 and not just 4.0.3 wouldn't it make sense to commit the pending patches? It would be as if you froze the branch a week later ;-) Regards, Volker
Re: Bootstrap Failure (i686-pc-linux-gnu, --with-arch=pentium4)
> Hi,
>
> For two consecutive days, I have been unable to
> build GCC mainline on i686-pc-linux-gnu:
> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c: In function
> 'ix86_expand_vector_init':
> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17080:
> error: insn does not satisfy its constraints:
> (insn 367 343 378 4
> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17047 (set
> (reg:QI 138)
> (const_int 0 [0x0])) 45 {*movqi_1} (nil)
> (expr_list:REG_EQUIV (const_int 0 [0x0])
> (nil)))
> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17080:
> 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.
> - 8<
> -
>
> I build with "--with-arch=pentium4 --disable-checking" and that
> might explain why no one has apparently reported it yet.
It has already been reported, it's PR22089 ;-)
http://gcc.gnu.org/PR22089
Nobody patches reload without causing regressions.
Sometimes even looking hard at the code can cause failures. ;-)
> Thanks,
> Ranjit.
Regards,
Volker
Re: Merged CVS repository of gcc and old-gcc
Ian Lance Taylor wrote in http://gcc.gnu.org/ml/gcc/2005-07/msg00625.html: > In preparation for the future transition to subversion, I've written > some code to merge the old-gcc repository into current mainline. I > would like to see this merged repository used as the basis for the > conversion to subversion. The advantage is that it provides revision > history back to 1992, when the gcc sources were first put into a > source code control system. (At the time, it was RCS. Before 1992 > the source code control system was emacs numbered backup files.) > > Since I just wrote this code, I'd like any feedback that people care > to give on the correctness and usability of the generated repository. > People with SSH access to sourceware should be able to access the > temporary merged repository by doing > cvs -d :ext:gcc.gnu.org:/pool/ian/repo co gcc [snip] > By the way, in case anybody asks, I will not be doing this merge > before the subversion conversion, because it changes all the CVS > revision numbers and thus breaks all existing working directories. What will happen to the (revision number based) hyperlinks to patches in Bugzilla and the gcc-cvs mailing list archive like the following: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reg-stack.c.diff?cvsroot=gcc&r1=1.188&r2=1.189 Will they still point to something useful? If not, that would render the whole gcc-cvs archive list useless. :-( Well, this is a question for the cvs to svn conversion in general, but gets more complicated with your merge of the cvs repositories. Regards, Volker
Re: Need help creating a small test case for g++ 4.0.0 bug
Paul Leopardi wrote: > I have now downloaded, bootstapped and installed gcc 4.0.1. The bug in g++ > optimization is still there. I've made an attempt to follow the instructions > on minimizing test cases and have so far accomplished: > wc of old preprocessed source: > 99412 260586 2965538 peg01.ii > wc of new preprocessed source: > 69309 241979 2668391 peg01.ii > As you can see, this is not much of a reduction. The bug I'm seeing keeps > disappearing as I try to reduce the source code. It seems to be a subtle > interaction between the Barton-Nackman trick, Boost uBLAS, GNU hash_map and > the g++ flags -fstrict-aliasing and -finline-functions. If I try to eliminate > any of these, the bug disappears. You might want to try a recent snapshot of gcc 4.0.2, first. Two aliasing bugs got fixed after the 4.0.1 release: http://gcc.gnu.org/PR22591 http://gcc.gnu.org/PR23192 The first even caused std::list::swap to be miscompiled. Regards, Volker
Re: GCC-3.4.5 status report
Just to let you know (to avoid duplicate work): There are several C++ bugs assigned to Mark which he already fixed on mainline and the 4.0 branch. Since he's busy with 4.0/4.1 regressions, I'll try to backport (at least some of) the patches back to the 3.4 branch. (He agreed to that plan in private mail.) Regards, Volker
rsync access seems to be broken
Hi, since two days I cannot synchronize my gcc repository using rsync anymore. Nothing happens and after a some time I get the following error message: rsync: read error: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(584) Could somebody please have a look? Regards, Volker
Re: rsync access seems to be broken
On 12 Oct, Jonathan Larmour wrote: > Volker Reichelt wrote: >> >> since two days I cannot synchronize my gcc repository using rsync >> anymore. Nothing happens and after a some time I get the following >> error message: > > Some stale connections were clogging up the rsync port - there's a > connection limit of 16. Nearly all of them were from AMD. > > I expunged the dead connections and it should work better now. Indeed, it's working again. Thanks! Btw, I get no response for ping gcc.gnu.org Is this intended? Or does this also need fixing? Regards, Volker > Jifl
[gomp] Does it make sense to post bug reports already?
Hi,
I just wanted to know what's the state of the gomp branch w.r.t
bug reports. Does it make sense to already send bug reports to
you or even add them to bugzilla?
We've got a large C++ application that uses OpenMP and we are really
interested in getting gomp work.
Here's one bug for starters:
void foo()
{
int i;
#pragma omp parallel for
for ( i=0; i<10; ++i )
continue;
}
With the C frontend I get:
gbug.c: In function '__omp_fn.1':
gbug.c:6: error: invalid exit from OpenMP structured block
With the C++ frontend I get:
gbug.cc: In function 'void foo()':
gbug.cc:6: error: continue statement not within loop or switch
Regards,
Volker
Renaming build_function_call_expr?
Hi, back in August I removed a call to fold after build_function_call_expr, since build_function_call_expr already does the folding. In a follow-up mail Richard Guenther raised the following point ( see http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01466.html ): > Following precedence and to avoid such issue in future should we rename > this to fold_build_function_call_expr? Or build_fold_function_call_expr. The problem is that there are about 113 occurrences of build_function_call_expr in the GCC tree. I wonder whether renaming them would be a too big change with too little benefit. Would it be more appropriate to just change the comment on top of the function (in builtins.c, line ~8760) from /* Conveniently construct a function call expression. */ to /* Conveniently construct and fold a function call expression. */ ? Any preferences? Regards, Volker
C++ parser: Should we get rid of cp_parser_declarator_id?
The C++ parser contains the static function cp_parser_declarator_id (cp_parser* parser) which consists of a lot of comments and a single statement return cp_parser_id_expression (parser, /*template_keyword_p=*/false, /*check_dependency_p=*/false, /*template_p=*/NULL, /*declarator_p=*/true); and which has a single caller. Shouldn't we fold cp_parser_declarator_id into the caller and call cp_parser_id_expression directly? But what about the comments then? (Are they still accurate, btw.?) Or should we leave the function intact just to preserve the comments? Regards, Volker
Re: C++ parser: Should we get rid of cp_parser_declarator_id?
On 7 Dec, Nathan Sidwell wrote: > Gabriel Dos Reis wrote: > >> If we make it "static inline", would not we gain the same efficiency >> and preserve the comments and all that? In general, the methodoly >> seems to have a function for each non-terminal -- following a long >> tradition of recursive descent parser -- and maintaining that >> principle is helpful for code clarity. Ok. I thought less indirection would make the code more readable, but you've got a point here. > There's no need to make it inline. The optimizers are now smart enough to > inline a static function into its only caller. That's what I thought. I'll leave the code as is, then. Regards, Volker
Re: Add revision number to gcc version?
> 1. contrib/gcc_update creates gcc/REVISION with branch name and > revision number. > 2. If gcc/REVISION exists, it will be used in gcc/version.c. > > With those 2 patches, I got > > [EMAIL PROTECTED] gcc]$ ./xgcc --version > xgcc (GCC) 4.1.0 (gcc-4_1-branch revision 108596) 20051215 (prerelease) [snip] > xgcc (GCC) 4.2.0 (trunk revision 108596) 20051215 (experimental) IMHO we should change the current naming system as little as possible for those who run scripts to extract the information from the compiler automatically. (Maybe I'm the only one, but I do.) Therefore I'd like to suggest to add the new stuff at the end and with brackets instead of parentheses to make that information easily extractable as well. xgcc (GCC) 4.1.0 20051215 (prerelease) [gcc-4_1-branch revision 108596] xgcc (GCC) 4.2.0 20051215 (experimental) [trunk revision 108596] Somebody on this thread also suggested to skip the date and only use the revision number. I don't think that this is a good idea, because 1.) there are scripts out there that rely on the date (OK, maybe I'm the only one) 2.) if we ever change the revision control system again, these numbers are probably obsolete 3.) the date carries a lot of information for humans (oh, this snapshot is already two month old, I should get a new one) without having to consult a database (for those who only download snapshots). And this info is available offline, too. Regards, Volker
Errors in pairs
Hi everybody,
while bug-hunting I noticed that we emit lots of erros in pairs in
check_final_overrider (cp/search.c), e.g.:
error ("invalid covariant return type for %q+#D", overrider);
error (" overriding %q+#D", basefn);
I would expect the second line to be emitted as a note (using inform).
Is there a reason for this or should that be changed?
Regards,
Volker
Re: Errors in pairs
On 03/24/2018 10:35 PM, Paolo Carlini wrote:
Hi,
On 24/03/2018 21:06, Volker Reichelt wrote:
Hi everybody,
while bug-hunting I noticed that we emit lots of erros in pairs in
check_final_overrider (cp/search.c), e.g.:
error ("invalid covariant return type for %q+#D", overrider);
error (" overriding %q+#D", basefn);
I would expect the second line to be emitted as a note (using inform).
Is there a reason for this or should that be changed?
IMHO that should be changed. As you may or may not have noticed,
personally I took care of many of such issues, but obviously not of
this one (I'm not surprised, I remember thinking a few times "I should
come back to this one too..."). I encourage you to send patches!
Paolo.
OK, here we go:
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01364.html
Regards,
Volker
Re: cp/do_poplevel
On 25 Jan, Marcin Dalecki wrote: > The following: > > 2006-01-23 Volker Reichelt <[EMAIL PROTECTED]> > > * cp-tree.h (do_poplevel): Remove prototype. > * semantics.c (do_poplevel): Add prototype. Make static. > > > Is a plain mistake due to: > > ../.././gcc/objcp/objcp-decl.c: In function 'tree_node* > objcp_end_compound_stmt(tree_node*, int)': > ../.././gcc/objcp/objcp-decl.c:114: error: 'do_poplevel' was not > declared in this scope > ../.././gcc/objcp/objcp-decl.c:118: error: 'do_poplevel' was not > declared in this scope Since Objective-C++ isn't built by default I didn't see that. I just reverted the patch, see http://gcc.gnu.org/ml/gcc-cvs/2006-01/msg01012.html Sorry for the inconvenience! Regards, Volker
Re: cp/default_conversion
On 25 Jan, Marcin Dalecki wrote: > The following removal of global default_conversion inside the C++ > frontend: > > 2006-01-25 Volker Reichelt <[EMAIL PROTECTED]> > > (default_conversion): Likewise. > > Is junk due to the fact that it gets used for example in rs6000/rs6000.c > The results in *actual* build failure on Darwin/PowerPC. I reverted the patch to cure the bootstrap-failure, but there are some things that make me wonder: The function default_conversion is used in rs6000/rs6000-c.c. The first line of the file reads: /* Subroutines for the C front end on the POWER and PowerPC architectures. The file doesn't include cp-tree.h, but only c-tree.h. But nevertheless the function default_conversion from the C++ frontend is linked and not the one from the C frontend. Is that intentional or a bug? Do we need a langhook to get the right function? Regards, Volker
.cvsignore in libjava/classpath
In libjava/classpath there are two .cvsignore files which haven't been deleted yet: native/jni/midi-alsa/.cvsignore native/jni/midi-dssi/.cvsignore Should they go, too? They are also in GCC 4.1.0 RC1. Regards, Volker
Re: .cvsignore in libjava/classpath
On 20 Feb, Andrew Haley wrote: > Andrew Pinski writes: > > > > > > In libjava/classpath there are two .cvsignore files which haven't been > > > deleted yet: > > > > > > native/jni/midi-alsa/.cvsignore > > > native/jni/midi-dssi/.cvsignore > > > > > > Should they go, too? > > > They are also in GCC 4.1.0 RC1. > > > > They are imported from upstream :). > > Yeah. Don't delete *anything* in libjava/classpath: instead go to > :ext:cvs.savannah.gnu.org:/sources/classpath. > > Andrew. I didn't want to delete it myself, since I suspected something like this. Would somebody of the libjava maintainers take care of this? Thanks, Volker
[gomp] EH problems with OpenMP
Hi, OpenMP is currently more or less unusable with the C++ front-end because of EH issues (see PR26823). This unfortunate situation is dragging on for more than two months now and makes further testing impossible. Some of the problems were fixed in PR26084, some still remain: The original (unreduced) testcase from PR26084 still causes an ICE. This is probably the same problem as in PR26823. We also have a third PR about an EH problem (PR26913) which has probably the same cause. Alas there seems to be no activity in that direction since PR26084 was closed. Could somebody of the gomp-maintainers please have a look? Thanks a lot in advance, Volker
New testsuite failures with -fprofile-use
Hi, since a couple of days we have the following new failures on mainline: FAIL: gcc.dg/tree-prof/inliner-1.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/inliner-1.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-1.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-1.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-2.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-2.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-3.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-3.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-4.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-4.c execution,-fprofile-use FAIL: gcc.dg/tree-prof/val-prof-5.c compilation, -fprofile-use (internal compiler error) UNRESOLVED: gcc.dg/tree-prof/val-prof-5.c execution,-fprofile-use See for example: http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg01139.html The testresults of 2006-07-24 seem to be clean, though. Here's one of the failures: % gcc -O2 -fprofile-generate val-prof-1.c % a.out % gcc -O2 -fprofile-use val-prof-1.c val-prof-1.c: In function 'main': val-prof-1.c:17: internal compiler error: in set_bb_for_stmt, at tree-cfg.c:2775 Please submit a full bug report, [etc.] Is anybody looking into this? Regards, Volker
Bootstrap failure caused by jvmti additions
Hi Tom, your patch http://gcc.gnu.org/ml/java-patches/2006-q3/msg00264.html broke bootstrap (at least on x86_64-unknown-linux-gnu): ranlib .libs/libgij.a creating libgij.la ./.libs/libgcj.so: undefined reference to `JvNumMethods(java::lang::Class*)' ./.libs/libgcj.so: undefined reference to `JvGetFirstMethod(java::lang::Class*)' collect2: ld returned 1 exit status make[5]: *** [jv-convert] Error 1 Regards, Volker
C++ function pointer weirdness
Yesterday the output of the following program changed
(probably due to the fix for PR19076):
==
template int ref (T&){ return 0; }
template int ref (const T&) { return 1; }
template int ref (const volatile T&) { return 2; }
template int ref (volatile T&) { return 4; }
template int ptr (T*){ return 0; }
template int ptr (const T*) { return 8; }
template int ptr (const volatile T*) { return 16; }
template int ptr (volatile T*) { return 32; }
void foo() {}
int main()
{
return ref(foo) + ptr(&foo);
}
==
GCC 2.95.3 - 3.4.0 return 0, GCC 3.4.1 - 3.4.4-20050222 return 2,
and now mainline again returns 0.
So the question is: What is the correct return value?
Btw, we really should have this in the testsuite.
In any case, we have a wrong-code regression here, either on the
3.4 branch or on mainline. But before I open a PR I'd like to sort
out which is the correct behavior.
When the result changed in 3.4.1 I bugged Nathan (who caused this
change) about it, and he claimed that '2' is the correct result.
Intel's compiler indeed returns 2.
Regards,
Volker
Suggestion: Different exit code for ICE
Regressions that cause ICE's on invalid code often go unnoticed in the
testsuite, since regular errors and ICE's both match { dg-error "" }.
See for example g++.dg/parse/error16.C which ICE's since yesterday,
but the testsuite still reports "PASS":
Executing on host: /Work/reichelt/gccbuild/src-4.0/build/gcc/testsuite/../g++
-B/Work/reichelt/gccbuild/src-4.0/build/gcc/testsuite/../
/Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C
-nostdinc++
-I/home/reichelt/Work/gccbuild/src-4.0/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/home/reichelt/Work/gccbuild/src-4.0/build/i686-pc-linux-gnu/libstdc++-v3/include
-I/home/reichelt/Work/gccbuild/src-4.0/gcc/libstdc++-v3/libsupc++
-I/home/reichelt/Work/gccbuild/src-4.0/gcc/libstdc++-v3/include/backward
-I/home/reichelt/Work/gccbuild/src-4.0/gcc/libstdc++-v3/testsuite
-fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -S -o error16.s
(timeout = 300)
/Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
error: redefinition of 'struct A::B'
/Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:5:
error: previous definition of 'struct A::B'
/Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
internal compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in cp_parser_class_specifier, at cp/parser.c:12407
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
output is:
/Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
error: redefinition of 'struct A::B'
/Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:5:
error: previous definition of 'struct A::B'
/Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
internal compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in cp_parser_class_specifier, at cp/parser.c:12407
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
PASS: g++.dg/parse/error16.C (test for errors, line 5)
PASS: g++.dg/parse/error16.C (test for errors, line 8)
PASS: g++.dg/parse/error16.C (test for excess errors)
(Btw, Mark, I think the regression was caused by your patch for
PR c++/20152, could you please have a look?)
The method used right now is to not use "" in the last error message,
but that's forgotten too often.
This calls for a more robust method IMHO.
One way would be to make the testsuite smarter and make it recognize
typical ICE patterns itself. This can indeed be done (I for example
use it to monitor the testcases in Bugzilla, Phil borrowed the patterns
for his regression tester).
An easier way IMHO would be to return a different error code when
encountering an ICE. That's only a couple of places in diagnostic.c
and errors.c where we now have "exit (FATAL_EXIT_CODE);".
We could return an (appropriately defined) ICE_ERROR_CODE instead.
The testsuite would then just have to check the return value.
What do you think?
Regards,
Volker
C++ warnings vs. errors
Hi,
since Manuel's patch http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00962.html
a lot of C++ code is now accepted on mainline (when compiling without
special flags like -fpermissive and -pedantic), that used to be rejected.
Instead of getting closer to the standard we get away from it, which is a
bad idea IMHO - especially since the standard should be widely adopted by
now, given that it's about 10 years old. So here's a collection of some
warnings that I'd rather see as errors:
* Scopes in for-loops:
void foo()
{
for (int i=0; i<10; ++i) {}
i = 0;
}
warn.cc: In function 'void foo()':
warn.cc:4: warning: name lookup of 'i' changed for new ISO 'for' scoping
warn.cc:3: warning: using obsolete binding at 'i'
Btw, because the compiler tries to be smart to track new scoping and old
scoping at once it rejects valid code, accepts invalid code and even
generates wrong code in some cases (see PR10852).
* Declaration with no type:
foo() {}
warn.cc:1: warning: ISO C++ forbids declaration of 'foo' with no type
Or even worse IMHO:
struct A
{
i;
};
warn.cc:3: warning: ISO C++ forbids declaration of 'i' with no type
* Invalid use of 'template':
struct A
{
static void foo();
};
template void bar()
{
A::template foo();
}
warn.cc: In function 'void bar()':
warn.cc:8: warning: 'A::foo()' is not a template
Btw, I don't know why we should accept this even with -fpermissive.
* Using 'struct' for a union:
union A {};
struct A a;
warn.cc:2: warning: 'struct' tag used in naming 'union A'
* Static members of local classes:
void foo()
{
struct A
{
static int i;
};
}
warn.cc: In function 'void foo()':
warn.cc:5: warning: local class 'struct foo()::A' shall not have static data
member 'int foo()::A::i'
* Return without value:
int foo()
{
return;
}
warn.cc: In function 'int foo()':
warn.cc:1: warning: return-statement with no value, in function returning
'int'
* Definition in wrong namespace:
struct A
{
void foo();
};
namespace N
{
void A::foo() {}
}
warn.cc:8: warning: definition of 'void A::foo()' is not in namespace
enclosing 'A'
* Operator new:
struct A
{
void* operator new(char);
};
warn.cc:3: warning: 'operator new' takes type 'size_t' ('unsigned int') as
first parameter
* Sizeof for function types:
void foo() { sizeof(foo); }
warn.cc: In member function 'void A::foo()':
warn.cc:1: warning: ISO C++ forbids applying 'sizeof' to an expression of
function type
What do you think?
Regards,
Volker
Re: gcc-4.2.1 pointer questions?
Hi Brian, > This: > > /* Internal convenience typedefs */ > typedef GLvoid (*_GLUfuncptr)(GLvoid); > > Produces this: > > ../.././include/libinc/GL/glu.h:259: error: '' has incomplete type > ../.././include/libinc/GL/glu.h:259: error: invalid use of 'GLvoid' > > What am I missing??? See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32364 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278 Regards, Volker
Semicolons at the end of member function definitions
Hi,
I just stumbled over the patch
2007-03-26 Dirk Mueller <[EMAIL PROTECTED]>
* parser.c (cp_parser_member_declaration): Pedwarn
about stray semicolons after member declarations.
which was approved by Gaby here:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01456.html
and made it into the trunk here:
http://gcc.gnu.org/ml/gcc-cvs/2007-03/msg00841.html
It makes
struct A
{
void foo() {};
}
a hard error with -pedantic.
The 1998 version of the standard (sorry, I don't have the 2003 version
available) contains in [class.mem]:
member-declaration:
...
function-definition ;opt
...
Therefore, IMHO the patch is wrong and should be reverted.
Or am I missing something?
Regards,
Volker
September entry on mailing list pages broken
Hi, the starting pages for the mailing lists like http://gcc.gnu.org/ml/gcc or http://gcc.gnu.org/ml/gcc-patches are broken. To be more precise, the entry generated for September is corrupted: It shows a strange size, and the link points to a wrong location. * October, 2007 * September, 2007 [mbox-formatted archive (/pub/gcc/mail-archives bytes)] * August, 2007 [mbox-formatted archive (510.0 Kbytes)] * July, 2007 [mbox-formatted archive (783.5 Kbytes)] [etc.] Can anybody fix this? Regards, Volker
