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

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 infor

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

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, 200

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 i

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://gc

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-prototyp

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 wa

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 identifi

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 `JvGe

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

[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 (unredu

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

.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: 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 ex

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: &g

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

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

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_d

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

[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:

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 clogg

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

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 privat

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 peg

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

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 sa

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

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-

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 volat