[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning

--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-24 06:42 --- it is not really an extension in the normal way. Since the standard says this is undefined behavior at compile time, we can do different things in different situtations dealing with no return at the end of the file.

[Bug preprocessor/26897] character \ in #include directive

--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-24 06:37 --- http://gcc.gnu.org/onlinedocs/cpp/Computed-Includes.html#Computed-Includes If the line expands to a single string constant, the contents of that string constant are the file to be included. CPP does not re-examine t

[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning

--- Comment #6 from sabre at nondot dot org 2006-05-24 06:36 --- > It is not really an extension, just undefined at compile time which > isdiffferent than supporting. It's marked as a pedwarn. That's a pretty clear demonstration that this is a feature, and that it's a known extension.

[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-24 06:33 --- (In reply to comment #4) > > This might be why it is undefined at compile time if the file does not end > > in a > > new-line or not :). > > However, GCC *does* supports this as an extension, hence the expected ped

[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning

--- Comment #4 from sabre at nondot dot org 2006-05-24 06:26 --- > This might be why it is undefined at compile time if the file does not end in > a > new-line or not :). However, GCC *does* supports this as an extension, hence the expected pedwarn. > I don't think that warning is tha

[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-24 06:25 --- bug.c:2:9: warning: backslash-newline at end of file I don't think that warning is that bogus. It is true too. Maybe misleading. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750

[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-24 06:23 --- This might be why it is undefined at compile time if the file does not end in a new-line or not :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750

[Bug preprocessor/27750] bogus 'backslash-newline at end of file' warning

--- Comment #1 from sabre at nondot dot org 2006-05-24 06:21 --- I guess I should have been more specific. Instead of "backslash-newline at end of file", I'd expect to get "no newline at end of file", which is also missing. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=277

[Bug preprocessor/27750] New: bogus 'backslash-newline at end of file' warning

Consider this reduced translation unit: --- // foo ??/ x --- ... where there is no newline after the X. Compiled like so: $ gcc bug.c -Wall -pedantic -fsyntax-only -trigraphs -std=c99 yields: bug.c:2:9: warning: trigraph ??/ converted to \ bug.c:2:9: warning: backslash-newline at end of file

[Bug fortran/27683] Many new GFORTRAN testsuite failures

--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-24 06:14 --- Reduced testcase (fails at -O1 and higher): character*1 b b = '' write (*, '()') end is compiled into (-gfump-original-tree): MAIN__ () { char b[1:1]; _gfortran_set_std (70, 127

[Bug fortran/27662] [4.1 only]: Transpose doesn't work on function return

--- Comment #13 from steven at gcc dot gnu dot org 2006-05-24 06:08 --- Re. comment #12, my copy of the June 1997 Fortran 95 draft is very clear assuming we agree that there is no default initialization for this pointer. 14.6.2.1 Pointer association status A pointer may have a pointer a

[Bug tree-optimization/27745] ICE in execute_todo with -O2 -ftree-loop-linear

-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfir

[Bug preprocessor/27746] ICE on openmp code when using _Pragma from macro

--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-24 03:45 --- (In reply to comment #8) > I found out about _Pragma from the following page (at the bottom): You can work around this bug by using the -save-temps option. Even though _Pragma is an extension to C++ and C89/90, it is

[Bug preprocessor/27746] ICE on openmp code when using _Pragma from macro

--- Comment #8 from bowie dot owens at csiro dot au 2006-05-24 03:42 --- I found out about _Pragma from the following page (at the bottom): http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Function-Attributes.html While it is not essential behaviour to allow _Pragma's to be generated from

[Bug preprocessor/27746] ICE on openmp code when using _Pragma from macro

--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-24 03:33 --- I should note this is accepted with -save-temps so the preprocessor is doing the correct thing at least to a point. I bet PR 27747 and 27748 are really all the same issue. -- pinskia at gcc dot gnu dot org chang

[Bug c/27747] [4.2 Regression] ice _Pragma and macros

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-24 03:33 --- I should note this is accepted with -save-temps so the preprocessor is doing the correct thing at least to a point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27747

[Bug c++/27748] [4.2 Regression] rejects _Pragma with macros

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-24 03:33 --- I should note this is accepted with -save-temps so the preprocessor is doing the correct thing at least to a point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27748

[Bug c/27747] [4.2 Regression] ice _Pragma and macros

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-24 03:31 --- Janis, could you do a regression hunt on this bug? (This is the C version of PR 27748). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/27748] [4.2 Regression] rejects _Pragma with macros

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-24 03:30 --- Janis, could you do a regression hunt on this bug? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug rtl-optimization/27661] ICE in subst_reloads

--- Comment #4 from patchapp at dberlin dot org 2006-05-24 03:30 --- Subject: Bug number PR rtl-optimization/27661 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01175.html -- http://gcc.g

[Bug c++/27748] [4.2 Regression] rejects _Pragma with macros

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.1.0 Target

[Bug preprocessor/27746] ICE on openmp code when using _Pragma from macro

--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-24 03:29 --- (In reply to comment #4) > The question is does macros allow to stuff in #pragmas. > I want to say yes. I changed my mind, no it should not be except for some cases. Or at least the documented ones. I don't even th

[Bug c++/27748] New: [4.2 Regression] rejects _Pragma with macros

Testcase: #define push _Pragma ("pack(push)") #define push1 _Pragma ("pack(push)") push1 -- In 4.1.0, this is accpeted and in 4.2.0, this is rejected: t.c:4: warning: malformed ‘#pragma pack’ - ignored t.c:4: error: expected unqualifi

[Bug c/27747] [4.2 Regression] ice _Pragma and macros

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.1.0 Target

[Bug c/27747] New: [4.2 Regression] ice _Pragma and macros

Testcase: #define push _Pragma ("pack(push)") #define push1 _Pragma ("pack(push)") push1 -- This ICEs like: pc64:~> ~/newtest/bin/gcc t.c t.c:4: internal compiler error: in c_parser_consume_token, at c-parser.c:639 Please submit a f

[Bug preprocessor/27746] ICE on openmp code when using _Pragma from macro

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-24 03:24 --- (In reply to comment #4) > Anyways here is a non openmp testcase that fails currently but it ICEs > differently: And I am going to file a different bug about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug preprocessor/27746] ICE on openmp code when using _Pragma from macro

--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-24 03:23 --- Here is a reduced testcase: #define parallel _Pragma("omp parallel") int main() { #pragma omp parallel {} } The question is does macros allow to stuff in #pragmas. I want to say yes. Anyways here is a non open

[Bug c/27746] ICE on openmp code when using _Pragma from macro

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-24 03:10 --- C also has the same issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/27746] ICE on openmp code when using _Pragma from macro

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-24 03:08 --- The ICE: t1.cc:9: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. The backtrace: #0 0x90128b54 in ab

[Bug c++/27746] ICE on openmp code when using _Pragma from macro

--- Comment #1 from bowie dot owens at csiro dot au 2006-05-24 01:47 --- Created an attachment (id=11502) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11502&action=view) c++ file which causes ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746

[Bug c++/27746] New: ICE on openmp code when using _Pragma from macro

Using gcc 4.2 from SVN: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/local_scratch/owe043/gcc_svn Thread model: posix gcc version 4.2.0 20060523 (experimental) I get an ICE when when compiling (g++ -fopenmp omp.cc) the following program: #define

[Bug tree-optimization/27745] New: ICE in execute_todo with -O2 -ftree-loop-linear

GNU Fortran fails on powerpc-linux with "-O2 -ftree-loop-linear" with an ICE for this testcase, minimized from swim.f in SPEC CPU2000: SUBROUTINE BUG INTEGER I, J, M REAL V COMMON A(100,100), B(100,100), M, V DO 200 I = 1, M DO 100 J = 1, M V = V +

[Bug target/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc

--- Comment #8 from gdr at cs dot tamu dot edu 2006-05-23 21:58 --- Subject: Re: __builtin_nanf("") doesn't return a _quiet_ nan on parisc "dave at hiauly1 dot hia dot nrc dot ca" <[EMAIL PROTECTED]> writes: | --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-23

[Bug c++/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer

--- Comment #7 from pinskia at physics dot uc dot edu 2006-05-23 21:42 --- Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer > > > > --- Comment #6 from bero at arklinux dot org 2006-05-23 21:41 --- > It is creative o

Re: [Bug c++/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer

> > > > --- Comment #6 from bero at arklinux dot org 2006-05-23 21:41 --- > It is creative offsetof indeed -- this a "explanation" from a bit of code > referenced to this one [while it isn't free yet, its license does allow > posting > bits of it online]: > Looks like someone was despe

[Bug c++/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer

--- Comment #6 from bero at arklinux dot org 2006-05-23 21:41 --- It is creative offsetof indeed -- this a "explanation" from a bit of code referenced to this one [while it isn't free yet, its license does allow posting bits of it online]: // HACK: gcc warns about applying offsetof()

[Bug fortran/23375] show location for runtime errors

--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-23 21:41 --- (In reply to comment #3) > So in GCC 4.1.0, the only problem seems to be that _gfortran_runtime_error is > not printing the filename and the line number and the line number seems to be > the line number of the previ

[Bug target/27408] [4.2 Regression] g++ -force_flat_namespace fails due to crt3.o multiply defined symbols

--- Comment #3 from geoffk at gcc dot gnu dot org 2006-05-23 21:21 --- (In reply to comment #2) > Can we then have a new cctools which includes a newer ld64 also since right > now > powerpc-darwin is broken on a G5 without using --disable-multilib. This specific problem should be resol

[Bug fortran/23151] print (buf, format), expression should be invalid

--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-23 21:17 --- The previous patch was bogus. This one actually works: Index: io.c === --- io.c(revision 113958) +++ io.c(working copy) @@ -2424,6 +24

[Bug fortran/23151] print (buf, format), expression should be invalid

--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-23 20:48 --- This patch looks as if it could do the job: Index: io.c === --- io.c(revision 113958) +++ io.c(working copy) @@ -2424,6 +2424,12 @@

[Bug c++/20173] [4.0/4.1 regression] gcc accepts invalid partial specialization attempt of member function

--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-05-23 20:47 --- Fixed in 4.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summar

[Bug c++/20173] [4.0/4.1/4.2 regression] gcc accepts invalid partial specialization attempt of member function

--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-05-23 20:45 --- Subject: Bug 20173 Author: mmitchel Date: Tue May 23 20:45:44 2006 New Revision: 114023 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114023 Log: PR c++/20173 * pt.c (determine_specializat

[Bug c/21920] alias violating

--- Comment #97 from pinskia at gcc dot gnu dot org 2006-05-23 20:42 --- *** Bug 27744 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c/27744] Optimized code gives incorrect result

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-23 20:41 --- Reopening to -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Statu

[Bug c/27744] Optimized code gives incorrect result

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-23 20:42 --- to mark this as a dup of bug 21920. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c/27744] Optimized code gives incorrect result

--- Comment #1 from falk at debian dot org 2006-05-23 19:40 --- This code accesses v, which is of type void*, via an lvalue of type int. This is not allowed by C aliasing rules. Use -fno-strict-aliasing or a union to express this operation. -- falk at debian dot org changed:

[Bug c/27744] New: Optimized code gives incorrect result

The following code: #include int main(int argc, char **argv) { void *v = (void*) 1; int *i = (int*) &v; int intpos; for (intpos = 0; intpos < (sizeof(void*) / sizeof(int)); intpos++) if (i[intpos] == 1) break; printf("intpos = %d\n",intpos); } Produces: intpos = 0 when c

[Bug fortran/27683] Many new GFORTRAN testsuite failures

--- Comment #5 from dir at lanl dot gov 2006-05-23 19:16 --- Has anybody else with a powerPC Macintosh tried the testsuite recently ? I down loaded and rebuild 4.1.1 and 4.2.0 today. 4.1.1 is Ok. 4.2.0 has the same errors. The test problem in comment #3 works with -g, but when complied

[Bug fortran/27709] Using size of array pointer component as dimension of function result causes gfortran internal error.

--- Comment #2 from David at ham dot dropbear dot id dot au 2006-05-23 18:18 --- (In reply to comment #1) > Is this standard conforming? I've got the May 2004 draft Fortran 2003 standard from the WG5 archive. Hopefully it says the same thing as F95 and final F2003. I presume that we'r

[Bug fortran/27709] Using size of array pointer component as dimension of function result causes gfortran internal error.

--- Comment #1 from pault at gcc dot gnu dot org 2006-05-23 17:24 --- Is this standard conforming? I just re-read the section on specification expressions for the unmpteenth time and have not clarified it in my mind! If you cannot point to the bit of the standard that allows it, I sugg

[Bug fortran/27662] [4.1 only]: Transpose doesn't work on function return

--- Comment #12 from hjl at lucon dot org 2006-05-23 17:15 --- Are you using Tonto in SPEC CPU 2006? It is slightly different from Tonto 1.0 on SF. The problem in Tonto in SPEC CPU 2006 is it uses something like integer, pointer :: d ... if (associated(d)) call abort() But nullify is

[Bug fortran/27662] [4.1 only]: Transpose doesn't work on function return

--- Comment #11 from pault at gcc dot gnu dot org 2006-05-23 16:28 --- (In reply to comment #10) > I applied the same patch to gcc 4.1 redhat. Now I can build and run SPEC CPU > 2006 successfully with gcc for the first time. The only issue is I have to > apply 2 patches to tonto in SPEC

[Bug target/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc

--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-23 16:28 --- Subject: Re: __builtin_nanf("") doesn't return a _quiet_ nan on parisc > --- Comment #6 from rth at gcc dot gnu dot org 2006-05-23 15:00 --- > (In reply to comment #4) > > This isn't a target bug

[Bug libgcj/27741] Automate generation of gcj/javaprims.h

-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfir

[Bug libfortran/27740] libgfortran should use versioned symbols

--- Comment #2 from jb at gcc dot gnu dot org 2006-05-23 15:59 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01186.html -- jb at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug tree-optimization/27742] ICE with -ftree-vectorizer-verbose

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-23 15:43 --- Reducing, this is a GC issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/27742] ICE with -ftree-vectorizer-verbose

--- Comment #2 from gcc at pdoerfler dot com 2006-05-23 15:38 --- Created an attachment (id=11501) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11501&action=view) gzipped prepocessed source code Please note again that the preprocessed source code does *not* trigger the ICE. --

[Bug tree-optimization/27725] error in loop invariant motion tranformation

--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-23 15:36 --- Actually Loop invariant motion is still doing its job even if the asm does not clober memory, it does read memory and you did not record that. The correct way to fix this is: asm volatile("\tmovl (%1), %0\n"

[Bug tree-optimization/27742] ICE with -ftree-vectorizer-verbose

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-23 15:27 --- Read . We need the preprocessed source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/27732] Parentheses elicit spurious error: "missing '>' to terminate the template argument list"

--- Comment #2 from widman at gimpel dot com 2006-05-23 15:10 --- By the way: whoever tackles this may also want to take a look at: template< int* p> struct A { }; template<> struct A<(int*)0>; ...which was made permissible by the recently-adopted wording that was proposed for Defect

[Bug middle-end/27736] [4.2 Regression] unwind-dw2-fde.c:833: fatal error: internal consistency failure

--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-05-23 15:08 --- Patch applied. (Thanks to Roger for the quick review.) -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added --

[Bug middle-end/27736] [4.2 Regression] unwind-dw2-fde.c:833: fatal error: internal consistency failure

--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-05-23 15:07 --- Subject: Bug 27736 Author: rsandifo Date: Tue May 23 15:07:00 2006 New Revision: 114019 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114019 Log: PR rtl-optimization/27736 * combine.c (rep

[Bug target/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc

--- Comment #6 from rth at gcc dot gnu dot org 2006-05-23 15:00 --- (In reply to comment #4) > This isn't a target bug as far as I can tell. The value generated > by __builtin_nanf("") as shown by Nan2.c is 0x7fc0. The same > value is printed on x86. This is a signaling NaN. Posi

[Bug middle-end/27743] [4.1/4.2 Regression] Wrong code for ((unsigned) ((a) >> 2)) >> 15

--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-23 14:27 --- /* Turn (a OP c1) OP c2 into a OP (c1+c2). */ if (TREE_CODE (arg0) == code && host_integerp (arg1, false) && TREE_INT_CST_LOW (arg1) < TYPE_PRECISION (type) && host_integerp (TREE_OPE

[Bug middle-end/27743] [4.1/4.2 Regression] Wrong code for ((unsigned) ((a) >> 2)) >> 15

--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-23 14:17 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|

[Bug c++/26757] [4.2 regression] C++ front-end producing two DECLs with the same UID

--- Comment #25 from amacleod at redhat dot com 2006-05-23 14:07 --- Subject: Bug 26757 Author: amacleod Date: Tue May 23 14:07:21 2006 New Revision: 114018 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114018 Log: 2006-05-23 Andrew MacLeod <[EMAIL PROTECTED]> PR c+

[Bug middle-end/27736] [4.2 Regression] unwind-dw2-fde.c:833: fatal error: internal consistency failure

--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-23 13:51 --- Subject: Re: [4.2 Regression] unwind-dw2-fde.c:833: fatal error: internal consistency failure > Patch posted: > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01169.html So far, this fix is looking good. D

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-23 13:49 --- Subject: Re: [4.1/4.2 Regression] Large compile time regression > This is not the first time multiply expand is taking this long. > > There was another bug about something like this but for alpha. Note t

[Bug tree-optimization/27743] New: Wrong code for ((unsigned) ((a) >> 2)) >> 15

A double shift with both constants and cast in between is illegally folded into a single shift. My first checks indicate that the change made for PR tree-optimization/14796 on 2005-06-12 clashes with a piece of code earlier in the function fold_binary. The comment starting with "Strip any conversio

[Bug middle-end/27736] [4.2 Regression] unwind-dw2-fde.c:833: fatal error: internal consistency failure

--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-05-23 13:06 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01169.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27736

[Bug gcov/profile/27738] error: coverage mismatch

--- Comment #3 from mathieu dot lacage at sophia dot inria dot fr 2006-05-23 12:05 --- yes, the -frandom-seed thing fixes the build. The speedup I get out of profile-drive optimization of the code for a static link is: no profile: 14.76s +/- 0.07 profile: 14.44s +/- 0.06 -- http://

[Bug tree-optimization/27742] New: ICE with -ftree-vectorizer-verbose

/usr/local/4.2/bin/g++4.2.0 -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-svn/configure --enable-languages=c,c++ --prefix=/usr/local/4.2 --program-suffix=4.2.0 Thread model: posix gcc version 4.2.0 20060523 (experimental) Revision: 114016 /usr/local/4.2/libexec

[Bug rtl-optimization/27735] [4.2 Regression] ice with -O3 on legal code [unswitch]

-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org

[Bug gcov/profile/20815] -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."

--- Comment #13 from rguenth at gcc dot gnu dot org 2006-05-23 09:47 --- *** Bug 27738 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug gcov/profile/27738] error: coverage mismatch

--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-23 09:47 --- This is fixed in 4.2.0 I believe. Try using -frandom-seed=0 for both the -fprofile-generate and -fprofile-use compilations as workaround. *** This bug has been marked as a duplicate of 20815 *** -- rguenth at g

[Bug c++/27739] "expected primary-expression before double" error caused by simple varaible name

--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-23 09:44 --- 4.0.3 has t.C: In function 'int main(int, char**)': t.C:3: error: expected unqualified-id before '||' token which is hinting at the problem. Same for 3.4.5. -- rguenth at gcc dot gnu dot org changed:

[Bug libgcj/27741] New: Automate generation of gcj/javaprims.h

gcj/javaprims.h has to be regenerated by hand using the classes.pl script whenever you add a class to java.lang, java.io, or java.util (including sub-packages, like java.lang.ref). The procedure is described in the HACKING file. It would be nice to automate this process since it can only be done af

[Bug libfortran/27740] libgfortran should use versioned symbols

--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-23 09:37 --- Nice. Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Statu

[Bug tree-optimization/27725] error in loop invariant motion tranformation

--- Comment #3 from alessandro dot lonardo at roma1 dot infn dot it 2006-05-23 09:22 --- (In reply to comment #2) > Use: > asm volatile("\tmovl (%1), %0\n" >"\tincl %0\n" >:"=r" (res) : "r" (pi): "memory"); > > or > asm volatile("\tmovl (%2), %0\n"

[Bug c++/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer

--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-23 09:02 --- looks like creative offsetof -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724

[Bug libfortran/27740] New: libgfortran should use versioned symbols

Gfortran is slowly growing up. As part of that process, as of gcc 4.2 we should IMHO be more serious about ABI compatibility. I have a patch forthcoming that bumps the so version and introduces symbol versioning. -- Summary: libgfortran should use versioned symbols Product

[Bug gcov/profile/27738] error: coverage mismatch

--- Comment #1 from mathieu dot lacage at sophia dot inria dot fr 2006-05-23 08:56 --- hrm, ok, I tried to reproduce the bug with less code involved. If you pull changeset 020b7defcc5f instead: hg clone http://yans.inria.fr/code/yans yans-buggy cd yans-buggy hg revert -r 020b7defcc5f a

[Bug c++/27739] New: "expected primary-expression before double" error caused by simple varaible name

Hello, I have tried to compile the following simple code using g++ version 3.4.4. int main(int argc, char *argv[]) { double or; return 1; } The compiler returns the following errors: main.cpp: In function `int main(int, char**)': main.cpp:3: error: expected primary-expression

[Bug gcov/profile/27738] New: error: coverage mismatch

I work on a small c++ project named yans (http://yans.inria.fr). Whenever I try to perform a profile-directed optimized build, I get the following errors with the FC5-provided compiler: src/ipv4/ipv4-end-point.cc: In function ‘void::invoke_now(yans::Callback, yans::Ipv4EndPoint*)’: src/ipv4/ipv4-e

[Bug target/25514] [4.0, 4.1 regression] [m68k] internal consistency failure

--- Comment #9 from jbglaw at lug-owl dot de 2006-05-23 07:54 --- Bisected down to r113983 (which was ment to fix this problem for m68k), I'm getting exactly this "internal consistency failure" when compiling parts of uClibc for vax-linux-uClibc. (That is, starting with r113981:-) From