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

[pinskia at gcc dot gnu dot org]

--- 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.  I don't see your
point at saying this is an extension because it is not an extension, just
behaving differently in different cases.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750

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

[pinskia at gcc dot gnu dot org]

--- 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 the string for
embedded quotes, but neither does it process backslash escapes in the string.
Therefore
 #define HEADER "a\"b"
 #include HEADER
looks for a file named a\"b. CPP searches for the file according to the rules
for double-quoted includes.

So in the second case it looks for a file called a"b and not a\"b.  This is not
a bug.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26897

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

[sabre at nondot dot org]

--- 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.  I realize that GCC need not support
the extension.  If the extension is removed, this bug can be closed.

> so ...  The standard requires that to be an backslash-newline even without 
> thecomment there.

I fail to see your point.

-Chris


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750

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

[pinskia at gcc dot gnu dot org]

--- 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 pedwarn.

It is not really an extension, just undefined at compile time which is
diffferent than supporting.

> 
> > I don't think that warning is that bogus.  It is true too.
> 
> Huh?  The backslash-newline occur in the middle of a comment, not at the end 
> of
> a file.
so ...  The standard requires that to be an backslash-newline even without the
comment there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750

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

[sabre at nondot dot org]

--- 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 that bogus.  It is true too.

Huh?  The backslash-newline occur in the middle of a comment, not at the end of
a file.

-Chris


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750

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

[pinskia at gcc dot gnu dot org]

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

[pinskia at gcc dot gnu dot org]

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

[sabre at nondot dot org]

--- 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=27750

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

[sabre at nondot dot org]

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.c:2:1: warning: multi-line comment
bug.c:1: warning: ISO C forbids an empty source file

A couple of issues.  First, the diagnostics are not sorted.  The last one
should be issued first.  Second, more importantly, the 2nd diagnostic is
incorrect.  There is no backslash-newline at the end of the file.  The first
and third diagnostics are accurate.

Again, note that there should be *no* newline after the x to reproduce this.

-Chris


-- 
   Summary: bogus 'backslash-newline at end of file' warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27750

[Bug fortran/27683] Many new GFORTRAN testsuite failures

[fxcoudert at gcc dot gnu dot org]

--- 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, 0);
  _gfortran_copy_string (1, &b, 0, "");
  {
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = "write_logical.f90";
dt_parm.0.common.line = 3;
dt_parm.0.common.unit = 6;
dt_parm.0.format = "()";
dt_parm.0.format_len = 2;
dt_parm.0.common.flags = 4096;
_gfortran_st_write (&dt_parm.0);
_gfortran_st_write_done (&dt_parm.0);
  }
}

but, when setting a breakpoint in _gfortran_st_write, we can see that the
format is wrong:

(gdb) p dtp->format
$4 = 0x2ffc ""

and I think it's an alignment issue, because the "real" format is just a bit
further down the dtp:

(gdb) p dtp->format+1
$5 = 0x2ffd "()"


Jerry, which of your patches has been commited on mainline but not on 4.1?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org, fxcoudert at gcc dot
   ||gnu dot org, pinskia at gcc
   ||dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-05-24 06:14:52
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683

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

[steven at gcc dot gnu dot org]

--- 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 association status of associated, disassociated,
or undefined. Its association status may change during execution of a program.
Unless a pointer is initialized (explicitly or by default), it has an initial
association status of undefined. A pointer may be initialized to have an
association status of disassociated.

5.1.2.7 POINTER attribute
An object with the POINTER attribute shall neither be referenced nor defined
unless, as a result of executing a pointer assignment (7.5.2) or an ALLOCATE
statement (6.3.1), it becomes pointer associated with a target object that may
be referenced or defined.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662

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

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-05-24 05:49:50
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27745

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

[pinskia at gcc dot gnu dot org]

--- 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 a standard feature
in C99 and I can report that it ICEs in C99 mode also.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746

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

[bowie dot owens at csiro dot au]

--- 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
macros, there are cases where it would be very useful. In my case I would
really like to be able to control the OpenMP directives that get included at a
fine grained level without littering my code with #ifdef's.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746

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

[pinskia at gcc dot gnu dot org]

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

   What|Removed |Added

OtherBugsDependingO||27747, 27748
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746

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

[pinskia at gcc dot gnu dot org]

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

[pinskia at gcc dot gnu dot org]

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

[pinskia at gcc dot gnu dot org]

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

 CC||janis at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27747

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

[pinskia at gcc dot gnu dot org]

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

 CC||janis at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27748

[Bug rtl-optimization/27661] ICE in subst_reloads

[patchapp at dberlin dot org]

--- 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.gnu.org/bugzilla/show_bug.cgi?id=27661

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

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.0
  Known to work||4.1.0
   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27748

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

[pinskia at gcc dot gnu dot org]

--- 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 think this change in the
behavior of Pragmas are documented.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746

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

[pinskia at gcc dot gnu dot org]

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 unqualified-id before ‘)’ token
t.c:4: error: expected declaration before end of line

I want to say this is valid


-- 
   Summary: [4.2 Regression] rejects _Pragma with macros
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27748

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

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.0
  Known to work||4.1.0
   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27747

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

[pinskia at gcc dot gnu dot org]

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 full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

I will file a different bug for C++ since it is rejected there instead.


-- 
   Summary: [4.2 Regression] ice _Pragma and macros
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27747

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

[pinskia at gcc dot gnu dot org]

--- 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=27746

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

[pinskia at gcc dot gnu dot org]

--- 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 openmp testcase that fails currently but it ICEs
differently:
#define push _Pragma ("pack(push)")
#define push1 _Pragma ("pack(push)")

push1


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |preprocessor
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-05-24 03:23:55
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746

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

[pinskia at gcc dot gnu dot org]

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

  Component|c++ |c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746

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

[pinskia at gcc dot gnu dot org]

--- 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 abort ()
#1  0x00b6a898 in _cpp_backup_tokens (pfile=0x43805200, count=2) at
../../libcpp/macro.c:1206
#2  0x00b62ce4 in do_pragma (pfile=0x43805200) at
../../libcpp/directives.c:1321
#3  0x00b640fc in destringize_and_run (pfile=0x43805200, in=0x2) at
../../libcpp/directives.c:1508
#4  0x00b6ab38 in builtin_macro (pfile=0x43805200, node=0x434e6290) at
../../libcpp/macro.c:295
#5  0x00b6b990 in cpp_get_token (pfile=0x43805200) at ../../libcpp/macro.c:784
#6  0x00296038 in c_lex_with_flags (value=0xd410bc, loc=0xd410c0,
cpp_flags=0xd410b6 "?B") at ../../gcc/c-lex.c:340
#7  0x00137034 in cp_lexer_get_preprocessor_token (lexer=0x434e86c0,
token=0xd410b4) at ../../gcc/cp/parser.c:394
#8  0x00136cd4 in cp_lexer_new_main () at ../../gcc/cp/parser.c:295
#9  0x0013a630 in cp_parser_new () at ../../gcc/cp/parser.c:2478
#10 0x0015d444 in c_parse_file () at ../../gcc/cp/parser.c:19140
#11 0x002a79c0 in c_common_parse_file (set_yydebug=0) at
../../gcc/c-opts.c:1164
#12 0x00540260 in compile_file () at ../../gcc/toplev.c:999
#13 0x00542b3c in do_compile () at ../../gcc/toplev.c:1970


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746

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

[bowie dot owens at csiro dot au]

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

[bowie dot owens at csiro dot au]

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 parallel_for _Pragma("omp parallel for") for
#define parallel _Pragma("omp parallel")
int
main()
{
parallel {
}

parallel_for (int i = 0; i < 1000; ++i) {
}

return 0;
}


-- 
   Summary: ICE on openmp code when using _Pragma from macro
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bowie dot owens at csiro dot au
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746

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

[janis at gcc dot gnu dot org]

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 + A(I,J)
 100CONTINUE
B(I,I) = B(I,I) * I
 200  CONTINUE
  STOP
  END

The output is:

elm3b11% /opt/gcc-nightly/trunk/bin/gfortran -c -O2 -ftree-loop-linear bug.f
bug.f: In function ‘bug’:
bug.f:1: internal compiler error: in execute_todo, at passes.c:714
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

A regression hunt identified this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=113862

r113862 | spop | 2006-05-17 14:25:59 + (Wed, 17 May 2006)

The same patch also introduces memory exhaustion failures when compiling equake
or ammp from SPEC CPU2000 on powerpc64-linux with "-O2 -ftree-loop-linear" and
either -m32 or -m64, and for applu with those options and -m64.  I don't have a
minimized testcase for any of those.


-- 
   Summary: ICE in execute_todo with -O2 -ftree-loop-linear
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27745

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

[gdr at cs dot tamu dot edu]

--- 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
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 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.  Positive quiet
| > > NaNs range between 0x7f81 and 0x7fbf.
| > 
| > Incorrect.  The canonical QNaN on x86 (and most other targets) is
| > 0x7fc0.  It would seem that PA has the same reversed quiet bit
| > as MIPS.  See real_format->qnan_msb_set and mips_ieee_single.
| 
| Interesting.  The HP architecture docments for PA 1.1 and 2.0
| state that PA-RISC fully conforms to ANSI/IEEE Std 754-1985, so
| I presume that this isn't specified (don't have a copy of the
| spec handy), so there's no actual canonical format.  I see this
| was something of a point of contention in 754R meetings.

The IEEE--754 specification is a *conceptual model*, not a "physical"
wired format.  As long as the units behave functionally as required,
it should be fine.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627

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

[pinskia at physics dot uc dot edu]

--- 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 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 desperate to get his stuff to compile with -Werror
> without having to fix the cause.

Well it is undefined for non-PODs to do offsetof which is why GCC warns.

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724

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

[Andrew Pinski]

> 
> 
> 
> --- 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 desperate to get his stuff to compile with -Werror
> without having to fix the cause.

Well it is undefined for non-PODs to do offsetof which is why GCC warns.

-- Pinski

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

[bero at arklinux dot org]

--- 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() to non-POD object or calculating
//   offset directly when base address is NULL. Use 16 to get around the
//   warning. gcc-3.4 has an option -Wno-invalid-offsetof to suppress
//   this warning.
#define offset_of(klass,field) (size_t)((intx)&(((klas*)16)->field) - 16)



Looks like someone was desperate to get his stuff to compile with -Werror
without having to fix the cause.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724

[Bug fortran/23375] show location for runtime errors

[tkoenig at gcc dot gnu dot org]

--- 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 previous statement, not the one that errors.  

runtime_error is also called from lots of places from within libgfortran,
and there is currently no way to pass line number information to intrinsics.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375

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

[geoffk at gcc dot gnu dot org]

--- 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 resolved with Xcode 2.3, just released. 
However -force_flat_namespace still doesn't work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27408

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

[tkoenig at gcc dot gnu dot org]

--- 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 +2424,12 @@
   dt->io_unit = default_unit (k);
   goto get_io_list;
 }
+  else
+{
+  /* print (*,*) is invalid.  */
+  if (k == M_PRINT)
+   goto syntax;
+}

   /* Match a control list */
   if (match_dt_element (k, dt) == MATCH_YES)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23151

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

[tkoenig at gcc dot gnu dot org]

--- 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 @@
   dt->io_unit = default_unit (k);
   goto get_io_list;
 }
+  else
+{
+  /* print (*,*) is invalid.  */
+  if (gfc_match_char ('('))
+   goto syntax;
+}

   /* Match a control list */
   if (match_dt_element (k, dt) == MATCH_YES)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23151

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

[mmitchel at gcc dot gnu dot org]

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

Summary|[4.0/4.1/4.2 regression] gcc|[4.0/4.1 regression] gcc
   |accepts invalid partial |accepts invalid partial
   |specialization attempt of   |specialization attempt of
   |member function |member function


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173

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

[mmitchel at gcc dot gnu dot org]

--- 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_specialization): Disallow partial
specializations of templates.
PR c++/20173
* g++.dg/template/error21.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/error21.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173

[Bug c/21920] alias violating

[pinskia at gcc dot gnu dot org]

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

 CC||orion at cora dot nwra dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920

[Bug c/27744] Optimized code gives incorrect result

[pinskia at gcc dot gnu dot org]

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

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27744

[Bug c/27744] Optimized code gives incorrect result

[pinskia at gcc dot gnu dot org]

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

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27744

[Bug c/27744] Optimized code gives incorrect result

[falk at debian dot org]

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

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27744

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

[orion at cora dot nwra dot com]

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 compiled optimization of -O or less.  When compiled with -O2, it produces:

intpos = 1

on x86 and:

intpos = 2

on x86_64.

Latest gcc tested is gcc version 4.1.0 20060512 (Red Hat 4.1.0-17)

This code is from LAM/MPI.


-- 
   Summary: Optimized code gives incorrect result
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: orion at cora dot nwra dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27744

[Bug fortran/27683] Many new GFORTRAN testsuite failures

[dir at lanl dot gov]

--- 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 with -O1 the
address that should point to '(L1)' is pointing a null character before the '('
 when it gets to the runtime print routine and so it generates the error.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683

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

[David at ham dot dropbear dot id dot au]

--- 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're just talking about whether:
size(element%numbering%number2count, 1)

Is a legal specification expression. 

Under section 7.1.6 in my draft standard, a specification is a restricted
expression which includes (7) a specification inquiry whose function arguments
are (7)(a) a restricted expression. Now, under specification inquiries, (1) is
an array inquiry function so size is allowed as long as its arguments are
resticted expressions.

Restricted expressions include "(2) An object designator with a base object
that is a dummy argument that has neither the OPTIONAL nor the INTENT (OUT)
attribute," 

Under 2.5.1  "An object designator is a designator for a data object" and  "A
designator is a name followed by zero or more component selectors, array
section selectors, array element selectors, and substring selectors."

So element%numbering%number2count is an object designator. Under 6.1.2 The base
object of a data-ref is the data object whose name is the leftmost part name.
So  element is the base part. Since element is intent(in) (ie not intent(out))
and not optional, element%numbering%number2count is a restricted expression.

So yes, on that basis I think the example is standard conforming.

Cheers,

David


-- 

David at ham dot dropbear dot id dot au changed:

   What|Removed |Added

 CC||David at ham dot dropbear
   ||dot id dot au


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27709

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

[pault at gcc dot gnu dot org]

--- 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 suggest that
we ask Richard Maine on the gfortran list.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-05-23 17:24:01
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27709

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

[hjl at lucon dot org]

--- 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 never called on d before. Tonto compiled by gfortran may return
TRUE and abort. I checked Fortran standard. It isn't very clear if it is valid
Fortran code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662

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

[pault at gcc dot gnu dot org]

--- 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 CPU 2006. I am not 100% sure that if tonto
> in SPEC CPU 2006 conforms to Fortan standard.
> 
HJ, I am puzzled - what do you have to do?  Both Daniel and I find that it
compiles as is.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27662

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

[dave at hiauly1 dot hia dot nrc dot ca]

--- 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 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.  Positive quiet
> > NaNs range between 0x7f81 and 0x7fbf.
> 
> Incorrect.  The canonical QNaN on x86 (and most other targets) is
> 0x7fc0.  It would seem that PA has the same reversed quiet bit
> as MIPS.  See real_format->qnan_msb_set and mips_ieee_single.

Interesting.  The HP architecture docments for PA 1.1 and 2.0
state that PA-RISC fully conforms to ANSI/IEEE Std 754-1985, so
I presume that this isn't specified (don't have a copy of the
spec handy), so there's no actual canonical format.  I see this
was something of a point of contention in 754R meetings.

Google tells me that MIPS didn't discriminant in early processors,
then used the same convention as PA-RISC, and finally switched again.
So, don't much like calling this the "mips" format.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627

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

[tromey at gcc dot gnu dot org]

-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-05-23 16:02:52
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27741

[Bug libfortran/27740] libgfortran should use versioned symbols

[jb at gcc dot gnu dot org]

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

 Status|NEW |ASSIGNED
   Last reconfirmed|2006-05-23 09:37:55 |2006-05-23 15:59:45
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740

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

[pinskia at gcc dot gnu dot org]

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

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-05-23 15:43:50
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742

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

[gcc at pdoerfler dot com]

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742

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

[pinskia at gcc dot gnu dot org]

--- 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"
   "\tincl %0\n"
   :"=r" (res)  : "r" (pi), "m" (*pi)) ;

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27725

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

[pinskia at gcc dot gnu dot org]

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

 Status|UNCONFIRMED |WAITING
   Keywords||GC, ice-on-valid-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742

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

[widman at gimpel dot com]

--- 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 Report 354:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1998.html#354


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27732

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

[rsandifo at gcc dot gnu dot org]

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

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27736

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

[rsandifo at gcc dot gnu dot org]

--- 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 (replaced_rhs_value): New variable.
(combine_instructions): Set it.
(distribute_notes): When distributing a note in replaced_rhs_insn,
check whether the value was used in replaced_rhs_value.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27736

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

[rth at gcc dot gnu dot org]

--- 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.  Positive quiet
> NaNs range between 0x7f81 and 0x7fbf.

Incorrect.  The canonical QNaN on x86 (and most other targets) is
0x7fc0.  It would seem that PA has the same reversed quiet bit
as MIPS.  See real_format->qnan_msb_set and mips_ieee_single.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627

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

[rguenth at gcc dot gnu dot org]

--- 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_OPERAND (arg0, 1), false)
  && TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1)) < TYPE_PRECISION (type))
{

this should read TREE_CODE (op0) == code.  Or

  if (kind == tcc_comparison)
{
  STRIP_SIGN_NOPS (arg0);
  STRIP_SIGN_NOPS (arg1);
}
  else
{
  STRIP_NOPS (arg0);
  STRIP_NOPS (arg1);
}

should use STRIP_SIGN_NOPS for arg0 and shifts.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27743

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

[rguenth at gcc dot gnu dot org]

--- 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||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |middle-end
 Ever Confirmed|0   |1
 GCC target triplet|sparc-sun-solaris2.8|
   Keywords||wrong-code
  Known to work||4.0.3
   Last reconfirmed|-00-00 00:00:00 |2006-05-23 14:17:09
   date||
Summary|Wrong code for ((unsigned)  |[4.1/4.2 Regression] Wrong
   |((a) >> 2)) >> 15   |code for ((unsigned) ((a) >>
   ||2)) >> 15
   Target Milestone|--- |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27743

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

[amacleod at gcc dot gnu dot org]

--- 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++/26757
* tree-ssa-loop-im.c (determine_invariantness_stmt): Use 
add_referenced_var instead of add_referenced_tmp_var.
* tree-complex.c (create_one_component_var): Use add_referenced_var.
* tree-ssa-loop-manip.c (create_iv, tree_unroll_loop): Use
add_referenced_var.
* tree-tailcall.c (adjust_accumulator_values, adjust_return_value,
tree_optimize_tail_calls_1): Use add_referenced_var.
* tree-ssa-loop-ivopts.c (create_new_iv): Use add_referenced_var.
* tree-ssa-alias.c (create_memory_tag, create_global_var, create_sft):
Use add_referenced_var.
* tree-if-conv.c (ifc_temp_var): Use add_referenced_var.
* gimplify.c (force_gimple_operand): Use add_referenced_var.
* tree-ssa-phiopt.c (conditional_replacement, abs_replacement):
Use add_referenced_var.
* tree-dfa.c (struct walk_state): Remove.
(find_referenced_vars): Remove walk state and vars_found hash table.
(make_rename_temp): Use add_referenced_var.
(find_vars_r): Pass less parameters to add_referenced_var.
(referenced_var_p): New.  Is var in referenced_var hash table.
(referenced_var_insert): Assert var isn't already in hash table.
(add_referenced_var): Don't need walk_state parameter.  Add var if it
isn't already in the hash table.
(add_referenced_tmp_var): Remove.
(find_new_referenced_vars_1): Use add_referenced_var.
* tree-ssa-pre.c (create_expression_by_pieces, 
insert_into_preds_of_block, insert_extra_phis, realify_fake_stores):
Use add_referenced_var.
* tree-vect-patterns.c (vect_pattern_recog_1): Use add_referenced_var.
* lambda-code.c (lbv_to_gcc_expression, lle_to_gcc_expression,
lambda_loopnest_to_gcc_loopnest, perfect_nestify): Use 
add_referenced_var.
* tree-vect-transform.c (vect_create_addr_base_for_vector_ref,
vect_create_data_ref_ptr, vect_create_destination_var,
vect_init_vector, vect_build_loop_niters, 
vect_generate_tmps_on_preheader, vect_update_ivs_after_vectorizer,
vect_gen_niters_for_prolog_loop, vect_create_cond_for_align_checks):
Use add_referenced_var.
* tree-outof-ssa.c (create_temp): Use add_referenced_var.
* tree-flow.h (add_referenced_tmp_var): Remove prototype
(add_referenced_var): Add prototype.
* tree-ssa-structalias.c (get_constraint_for, 
intra_create_variable_infos): Use add_referenced_var.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/lambda-code.c
trunk/gcc/tree-complex.c
trunk/gcc/tree-dfa.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-if-conv.c
trunk/gcc/tree-outof-ssa.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-loop-im.c
trunk/gcc/tree-ssa-loop-ivopts.c
trunk/gcc/tree-ssa-loop-manip.c
trunk/gcc/tree-ssa-phiopt.c
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-structalias.c
trunk/gcc/tree-tailcall.c
trunk/gcc/tree-vect-patterns.c
trunk/gcc/tree-vect-transform.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757

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

[dave at hiauly1 dot hia dot nrc dot ca]

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

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27736

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

[dave at hiauly1 dot hia dot nrc dot ca]

--- 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 that this is for a 32 to 64-bit hppa cross.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

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

[Erwin dot Unruh at fujitsu-siemens dot com]

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 conversions that
don't change the mode" is not correct for shifts. The signedness of the left
operand of a right shift is relevant. It determines whether the sign bit or
zero is shifted in.
The problem occurs only if the shifts are within a single expression. Split
accross different expression the behaviour is correct.

Here is a test case showing the different behaviour:

int foo(int a)
{
int t2 = a >> 2;
unsigned t3 = t2;
unsigned t4 = t3 >> 15;
return t4;
}

int bar(int a)
{
return ((unsigned) ((a) >> 2)) >> 15;
}

main()
{
int a = 0x3000;
int b = foo(a);
int c = bar(a);
printf ("%x, %x\n", b, c);
if (b != c)
printf ("failed\n");
}


-- 
   Summary: Wrong code for ((unsigned) ((a) >> 2)) >> 15
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Erwin dot Unruh at fujitsu-siemens dot com
GCC target triplet: sparc-sun-solaris2.8


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27743

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

[rsandifo at gcc dot gnu dot org]

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

[mathieu dot lacage at sophia dot inria dot fr]

--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=27738

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

[gcc at pdoerfler dot com]

/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/gcc/i686-pc-linux-gnu/4.2.0/cc1plus -quiet -v
-I/home/doerfler/ltilib-2/42/linux -I../src/basics -I../src/types -I../src/math
-I../src/imgProc -I../src/ioBasics -I../src/io -I../src/draw -I../src/viewer
-I../src/system -I../src/classifiers -Iworkbench -I../tester
-I/usr/include/cairo -I/usr/include/freetype2 -I/usr/X11R6/include
-I/usr/include/libpng12 -I/opt/gnome/include/gtk-2.0
-I/opt/gnome/lib/gtk-2.0/include -I/opt/gnome/include/atk-1.0
-I/opt/gnome/include/pango-1.0 -I/opt/gnome/include/glib-2.0
-I/opt/gnome/lib/glib-2.0/include -D_GNU_SOURCE -D_REENTRANT -D_BSD_SOURCE
-D_XOPEN_SOURCE=500 -D_REENTRANT -DNDEBUG -D_USE_FIRE_WIRE_DCAM
../src/imgProc/ltiLocalColorDescriptorExtractor.cpp -quiet -dumpbase
ltiLocalColorDescriptorExtractor.cpp -march=pentium-m -msse -msse2 -ansi
-auxbase-strip ../obj/release/ltiLocalColorDescriptorExtractor.o -O3 -Wundef
-Wwrite-strings -Wall -ansi -version -ftree-vectorize
-ftree-vectorizer-verbose=5 -fpic -o /tmp/ccrEtWY9.s

...
../src/imgProc/ltiGridSampling_template.h:227: note: vectorized 0 loops in
function.
../src/imgProc/ltiSliceSampling_template.h: In function ‘void __tcf_15(void*)’:
../src/imgProc/ltiSliceSampling_template.h:82: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Unfortunately, if I use -save-temps the ICE does not occur.
It also goes away without -ftree-vectorizer-verbose

Here is what gdb tells me:

Program received signal SIGSEGV, Segmentation fault.
0x40099d9b in strlen () from /lib/tls/libc.so.6
(gdb) bt
#0  0x40099d9b in strlen () from /lib/tls/libc.so.6
#1  0x4006e3d8 in vfprintf () from /lib/tls/libc.so.6
#2  0x08694581 in __FUNCTION__.28397 ()
#3  0x0001 in ?? ()
#4  0x4072a1b8 in ?? ()
#5  0x in ?? ()
#6  0x4060a898 in ?? ()
#7  0x0813df36 in gt_ggc_mx_lang_tree_node (x_p=0x0) at gt-cp-tree.h:89
#8  0x0813df36 in gt_ggc_mx_lang_tree_node (x_p=0x40494b2c) at gt-cp-tree.h:89
#9  0x in ?? ()
#10 0x0002 in ?? ()
#11 0x in ?? ()
#12 0x in ?? ()
#13 0x0813df36 in gt_ggc_mx_lang_tree_node (x_p=0x8694582) at gt-cp-tree.h:89
#14 0x in ?? ()
(gdb) cont
Continuing.
../src/imgProc/ltiSliceSampling_template.h: In function ‘void __tcf_15(void*)’:
../src/imgProc/ltiSliceSampling_template.h:82: internal compiler error:
Segmentation fault

The source this happens on is a large library (ltilib-2). Here's a snippet

-
  template 
  bool sliceSampling::apply(Acc& acc,
const matrix& img,
const location& loc,
dvector& destv) {

const parameters& par = getParameters();
// interpolation
static const bilinearInterpolation bilin;

//create accumulators
static std::vector accuVec;
-

the last line is the one reported as causing the ICE.
Acc is a template struct with a few member functions and a C array.

When compiled without -ftree-vectorizer-verbose __tcf_15 looks like this:
--
.align 2
.p2align 4,,15
.type   __tcf_15, @function
__tcf_15:
.LFB3101:
pushl   %ebp
.LCFI428:
movl%esp, %ebp
.LCFI429:
pushl   %ebx
.LCFI430:
call__i686.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
subl$4, %esp
.LCFI431:
movl   
[EMAIL PROTECTED](%ebx)
, %eax
movl(%eax), %eax
testl   %eax, %eax
je  .L1085
movl%eax, (%esp)
call[EMAIL PROTECTED]
.L1085:
popl%eax
popl%ebx
popl%ebp
ret
.LFE3101:
.size   __tcf_15, .-__tcf_15


I can post instructions for downloading and reproduction of the ICE if this is
desired. 

I can also perform further analysis if somebody can give instructions what else
I can do.


-- 
   Summary: ICE with -ftree-vectorizer-verbose
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at pdoerfler dot com
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742

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

[rakdver at gcc dot gnu dot org]

-- 

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 |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-05-23 04:12:58 |2006-05-23 10:15:36
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27735

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

[rguenth at gcc dot gnu dot org]

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

 CC||mathieu dot lacage at sophia
   ||dot inria dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815

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

[rguenth at gcc dot gnu dot org]

--- 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 gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27738

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

[rguenth at gcc dot gnu dot org]

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

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||3.4.4
  Known to work||3.4.5
 Resolution||FIXED
   Target Milestone|--- |3.4.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27739

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

[mark at gcc dot gnu dot org]

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 after
the first source->bytecode compilation step. If it is forgotten the native code
generation phase fails.


-- 
   Summary: Automate generation of gcj/javaprims.h
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27741

[Bug libfortran/27740] libgfortran should use versioned symbols

[rguenth at gcc dot gnu dot org]

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

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-05-23 09:37:55
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740

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

[alessandro dot lonardo at roma1 dot infn dot it]

--- 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"
>"\tincl %0\n"
>:"=r" (res), "m"(*pi)"  : "r" (pi));
> 

Yes, I had tried the first, but is the asm really clobbering memory?


-- 

alessandro dot lonardo at roma1 dot infn dot it changed:

   What|Removed |Added

 CC||alessandro dot lonardo at
   ||roma1 dot infn dot it


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27725

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

[rguenth at gcc dot gnu dot org]

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

[jb at gcc dot gnu dot org]

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: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: jb at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740

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

[mathieu dot lacage at sophia dot inria dot fr]

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

and run:
make opti-arc VERBOSE=y

g++ -fprofile-use -Wall -Werror -g3 -O3 -DNDEBUG=1  -DRUN_SELF_TESTS=1
-DINL_EXPE=inline -I./src/simulator -I./src/common -I./src/test -I./src/host
-I./src/ipv4 -I./src/arp  -DDISABLE_IPV4_CHECKSUM=1 -fPIC
-I./build-dir/opti-arc/include 
-Wp,-M,-MP,-MM,-MT,./build-dir/opti-arc/src/common/reference-list-test.o,-MF,./build-dir/opti-arc/src/common/reference-list-test.o.P
-c -o ./build-dir/opti-arc/src/common/reference-list-test.o
src/common/reference-list-test.cc
src/common/reference-list-test.cc: In destructor
‘virtual::RefTest::~RefTest()’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC387RefTestD0Ev’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is 436b0859 instead of
9f668c2a
src/common/reference-list-test.cc: In destructor
‘virtual::RefTest::~RefTest()’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC387RefTestD1Ev’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is 9f0692ee instead of
430b169d
src/common/reference-list-test.cc: In member function ‘void
yans::ReferenceList::insert_self_in_other(const
yans::ReferenceList&) [with OBJ_PTR = ::A*]’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN4yans13ReferenceListIPN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC381AEE20insert_self_in_otherERKS4_’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is 8777197f instead of
45c2bfb1
src/common/reference-list-test.cc: In member function ‘void
yans::ReferenceList::remove_from_list() [with OBJ_PTR =
::A*]’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN4yans13ReferenceListIPN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC381AEE16remove_from_listEv’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is e2240709 instead of
5f1e525e
src/common/reference-list-test.cc: In member function ‘void
yans::ReferenceList::set(OBJ_PTR) [with OBJ_PTR = ::A*]’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN4yans13ReferenceListIPN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC381AEE3setES3_’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is 85fec9cf instead of
59f34dbc
src/common/reference-list-test.cc: In member function
‘yans::ReferenceList& yans::ReferenceList::operator=(const
yans::ReferenceList&) [with OBJ_PTR = ::A*]’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN4yans13ReferenceListIPN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC381AEEaSERKS4_’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is 27f4641 instead of
de72c232
src/common/reference-list-test.cc: In copy constructor
‘yans::ReferenceList::ReferenceList(yans::ReferenceList&)
[with OBJ_PTR = ::A*]’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN4yans13ReferenceListIPN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC381AEEC1ERS4_’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is 5af78fcc instead of
b4d2a5ce
src/common/reference-list-test.cc: In constructor
‘yans::ReferenceList::ReferenceList(const OBJ_PTR&) [with OBJ_PTR =
::A*]’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN4yans13ReferenceListIPN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC381AEEC1ERKS3_’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is 29ef944 instead of
de937d37
src/common/reference-list-test.cc: In destructor
‘yans::ReferenceList::~ReferenceList() [with OBJ_PTR =
::A*]’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN4yans13ReferenceListIPN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC381AEED1Ev’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is 6b1e2081 instead of
b07ef094
src/common/reference-list-test.cc: In constructor
‘yans::ReferenceList::ReferenceList() [with OBJ_PTR = ::A*]’:
src/common/reference-list-test.cc:117: error: coverage mismatch for function
‘_ZN4yans13ReferenceListIPN62_GLOBAL__N_src_common_reference_list_test.cc__168CDC381AEEC1Ev’
while reading counter ‘arcs’
src/common/reference-list-test.cc:117: error: checksum is 466838e6 instead of
9d08e8f3
src/common/reference-list-test.cc: In membe

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

[bugzilla at adamauton dot com]

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 before "double"
main.cpp:3: error: expected `;' before "double"
make: *** [dummy] Error 1


Renaming the variable something other than 'or' fixes the error. Nevertheless,
the error message isn't particularly clear!

Many thanks


-- 
   Summary: "expected primary-expression before double" error caused
by simple varaible name
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla at adamauton dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27739

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

[mathieu dot lacage at sophia dot inria dot fr]

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-end-point.cc:92: error: coverage mismatch for function
‘_ZN55_GLOBAL__N_src_ipv4_ipv4_end_point.cc__D34075F610invoke_nowEN4yans8CallbackIvPNS0_12Ipv4EndPointENS0_5emptyES4_S4_EES3_’
while reading counter ‘arcs’
src/ipv4/ipv4-end-point.cc:92: error: checksum is 1b860dda instead of 69a79691


This obviously happens during the profile-directed optimized rebuild following
a single run of my benchmarking application.

To reproduce:
1) download the code
hg clone  http://yans.inria.fr/code/yans yans-buggy
cd yans-buggy
hg revert -r a0534ece96ea
2) build the code 
make opti-arc

This code relies on gnu make 0.80 at least and mercurial (to download the right
version of the code) 0.8.x. 

I have no idea on how I could reduce this test case.


-- 
   Summary: error: coverage mismatch
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov/profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mathieu dot lacage at sophia dot inria dot fr
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27738

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

[jbglaw at lug-owl dot de]

--- 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 reading
the mailing lists, this also happens for the hppa and ia64 ports.


-- 

jbglaw at lug-owl dot de changed:

   What|Removed |Added

 CC||jbglaw at lug-owl dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25514