[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory

[charlet at gcc dot gnu dot org]

--- Comment #7 from charlet at gcc dot gnu dot org  2008-04-10 06:21 ---
reopening


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-10 06:21:40
   date||


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

[Bug preprocessor/35326] [4.2/4.3/4.4 regression] ICE with stray digraph token

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2008-04-10 06:16 
---
I can still reproduce it with trunk, 4.3 branch and 4.2 branch from 2008-04-07.
I can't reproduce it on x86_64, though (no segfault, no valgrind error).

Did you try adding random characters before %:%: ?
Maybe this changes memory layout so much that you see the segfault, too.

Concerning comment #3: I cannot imagine that pfile->buffer was 0 from the
beginning. It looks as if something trampled on the memory later. (I'd have
to check that, though.) That would also explain the totally different error
in the original report (and why you don't run into trouble with the same
testcase).


-- 


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

[Bug tree-optimization/35821] Internal compiler error: segmentation fault

[irar at gcc dot gnu dot org]

--- Comment #9 from irar at gcc dot gnu dot org  2008-04-10 05:52 ---
Subject: Bug 35821

Author: irar
Date: Thu Apr 10 05:51:59 2008
New Revision: 134162

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134162
Log:
PR tree-optimization/35821
* tree-vect-transform.c (vect_create_data_ref_ptr): Add check that
NEW_STMT_LIST is not NULL.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr35821-altivec.c
trunk/gcc/testsuite/gcc.dg/vect/pr35821-spu.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-transform.c


-- 


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

[Bug c++/35898] C++ exception bug at run time when mutually recursive functions

[vania at liama dot ia dot ac dot cn]

--- Comment #1 from vania at liama dot ia dot ac dot cn  2008-04-10 03:34 
---
I have a simplified version of this program that works fine however !!!
When the exception thrown is an int instead of a class instance, everything
works fine!


-- 

vania at liama dot ia dot ac dot cn changed:

   What|Removed |Added

 CC||vania at liama dot ia dot ac
   ||dot cn
  Alias||C++exception_catch
   Keywords||sjlj-eh


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

[Bug c++/35898] New: C++ exception bug at run time when mutually recursive functions

[vania at liama dot ia dot ac dot cn]

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

The following is a C++ program that shows the problem.
It is a program that always end up with an exception sooner or later
based on the input value...

Compilation with -ansi -Wall works fine and report no errors and warning.
First run the program with input '1000' (argument on command line). 
It works fine. The exception is caught properly.
Run the program with input 1. The program aborts because the exception
is thrown but not caught.

The program has 4 functions which can be mutually recursive based on the input
value. When there is mutual recursion between only 2 functions it works fine,
the exception is thrown and the appropriate catch clause operates.
When there is mutual recursion between more than 2 functions, when the
exception
is thrown, it not caught as it should and it goes into terminate...

#include 
#include 

using namespace std;

unsigned int seed;

unsigned int my_random() {
  unsigned int low = 16807 * (seed & 0x);
  unsigned int high = 16807 * (seed >> 16);
  low += (high &0x7FFF) << 16;
  low += high >> 15;
  if (low > 0x7FFF)
low -= 0x7FFF;
  return (seed = low);
}

const unsigned int small_max = 0xFFF;
const unsigned int medium_max = 0xF;

unsigned int small_size = 0;
unsigned int medium_size = small_max;
unsigned int large_size = medium_max;

void dummy_test();

class MyException {
public:
  const char *msg;
  MyException(const char * s):msg(s){};

};
// MyException::MyException(const char *s):msg(s){};

class SmallException: public MyException {
public:
  SmallException(const char *s, int r);
  int small;
};
SmallException::SmallException(const char * s, int r): MyException(s)
{
  small = r;
}

class MediumException: public MyException {
public:
  MediumException(const char * s, int r);
  int medium;
};
MediumException::MediumException(const char * s, int r): MyException(s) {
  medium = r;
}

class LargeException: public MyException {
public:
  LargeException(const char *s, int r);
  int large;
};
LargeException::LargeException(const char *s, int r): MyException(s) {
  large = r;
}

void small(unsigned int v) throw (SmallException &) {
  small_size = small_size << 1;
  cout << "small ? " << v << endl;
  if (small_size >= v)
throw SmallException("small test fails : ", v);
  else
dummy_test();
}

void medium(unsigned int v) throw (MediumException &) {
  medium_size = medium_size << 1;
  cout << "medium ? " << v << endl;
  if (medium_size >= v)
throw MediumException("medium test fails : ", v);
  else
dummy_test();
}

void large(unsigned int v) throw (LargeException &) {
  large_size =  large_size << 1;
  cout << "large ? " << v << endl;
  if (large_size >= v)
throw LargeException("large test fails : ", v);
  else
dummy_test();
}

void dummy_test() {
  unsigned int v = my_random();

  if (v < small_max)
small(v);
  else if (v > medium_max)
large(v);
  else
medium(v);
}

void test_exception(){
  try {
dummy_test();
  }
  catch ( SmallException &e) {
cout << "Exception -- " << e.msg << e.small 
 << endl;
  } 
  catch ( MediumException &e ) {
cout << "Exception -- " << e.msg << e.medium
 <<  endl;
  } 
  catch ( LargeException &e) {
cout << "Exception -- " << e.msg << e.large 
 << endl;
  } 
  catch (...) {
cout << "Unspecified exception type\n" << endl;
  };
}

int main(int argc, char* argv[]) {

  if (argc < 2 || (seed = atoi(argv[1])) == 0) {
cout << "Must have valid number argument" << endl;
return 0;
  }

  cout << "start test with seed " << seed << endl;
  test_exception();
  cout << "test ending normally " << endl;
  return 0;
}


-- 
   Summary: C++ exception bug at run time when mutually recursive
functions
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vania at liama dot ia dot ac dot cn
  GCC host triplet: x86_64 GNU/Linux 2.6.22-14-


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

[Bug middle-end/35897] DSE doesn't support targets with wide registers

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2008-04-10 00:53 ---
Subject: Bug 35897

Author: hjl
Date: Thu Apr 10 00:53:04 2008
New Revision: 134160

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134160
Log:
2008-04-09  H.J. Lu  <[EMAIL PROTECTED]>

PR middle-end/35897
* dse.c (store_info): Use long long on positions_needed.

Added:
branches/ix86/avx/gcc/ChangeLog.avx
Modified:
branches/ix86/avx/gcc/dse.c


-- 


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

[Bug middle-end/35897] DSE doesn't support targets with wide registers

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-10 00:41 ---
Well first it should be made HOST_WIDE_INT and x86 should move over to 64bit
HWI.


-- 


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

[Bug middle-end/35897] New: DSE doesn't support targets with wide registers

[hjl dot tools at gmail dot com]

dse.c has

struct store_info
{
...
  /* An bitmask as wide as the number of bytes in the word that
 contains a 1 if the byte may be needed.  The store is unused if
 all of the bits are 0.  */
  long positions_needed;
};

...

record_store ()
{
...
 gcc_assert ((unsigned) width < sizeof (store_info->positions_needed) *
CHAR_BIT);
...
}

AVX register is 32byte wide. On ia32, since width is 32 and long is 4 byte,
assert fails. This scheme doesn't work. How should it be fixed?


-- 
   Summary: DSE doesn't support targets with wide registers
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug target/35866] Vector load/store from a packed struct does not work (without -mstrict-align)

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2008-04-10 00:15 ---
Subject: Re:  Vector load/store from a packed struct does
 not work (without -mstrict-align)

On Tue, 8 Apr 2008, pinskia at gcc dot gnu dot org wrote:

> With -mstrict-align, we get the correct (but suboptimal) answer as the
> middle-end knows that load and stores cannot handled unaligned addresses.
> 
> I think we need more flexible TARGET_STRICT_ALIGN which is based on a mode
> rather than just true or false.

E500 has much the same problem and so is treated as a -mstrict-align CPU, 
with all the associated suboptimal code generation (strict alignment only 
being required for E500 instructions, not for most core instructions).


-- 


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

[Bug tree-optimization/35629] [4.4 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2008-04-10 00:03 ---
(In reply to comment #6)
> I am discussing with Zdenek the proper fix.

Any conclusion in sight?  If not, I'll xfail this as per protocol.


-- 


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

[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2008-04-10 00:00 ---
I haven't tried it myself, but since we're in voodoo-debug mode, try
"--enable-checking=yes,valgrind".


-- 


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

[Bug testsuite/34894] Some compile tests require trampolines even when the target sets no_trampolines

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #2 from hutchinsonandy at gcc dot gnu dot org  2008-04-09 23:59 
---
Subject: Bug 34894

Author: hutchinsonandy
Date: Wed Apr  9 23:58:39 2008
New Revision: 134153

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134153
Log:
2008-04-09  Andy Hutchinson  <[EMAIL PROTECTED]>

PR testsuite/34894
PR testsuite/33782
* lib/target-supports.dg: Add check_effective_target_trampolines.
Disable profiling for avr-*-*.
* gcc.c-torture/compile/pr27889.c: dg-requires trampolines.
* gcc.c-torture/compile/nested-1.c: Ditto.
* gcc.c-torture/compile/20050122-2.c: Ditto.
* gcc.c-torture/compile/20010226-1.c: Ditto.
* gcc.c-torture/compile/20010327-1.c:  Skip for avr-*-*.
* gcc.c-torture/compile/980506-1.c: Ditto.
* gcc.c-torture/compile/20020604-1.c: Ditto.
* gcc.c-torture/compile/limits-stringlit.c: Ditto
* gcc.c-torture/compile/20001226-1.c: Ditto

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/20010226-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/20010327-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/20020604-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/20050122-2.c
trunk/gcc/testsuite/gcc.c-torture/compile/980506-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/limits-stringlit.c
trunk/gcc/testsuite/gcc.c-torture/compile/nested-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr27889.c
trunk/gcc/testsuite/lib/target-supports.exp


-- 


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

[Bug testsuite/33782] FAIL: gcc.c-torture/compile/limits-stringlit.c (test for excess errors)

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #2 from hutchinsonandy at gcc dot gnu dot org  2008-04-09 23:59 
---
Subject: Bug 33782

Author: hutchinsonandy
Date: Wed Apr  9 23:58:39 2008
New Revision: 134153

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134153
Log:
2008-04-09  Andy Hutchinson  <[EMAIL PROTECTED]>

PR testsuite/34894
PR testsuite/33782
* lib/target-supports.dg: Add check_effective_target_trampolines.
Disable profiling for avr-*-*.
* gcc.c-torture/compile/pr27889.c: dg-requires trampolines.
* gcc.c-torture/compile/nested-1.c: Ditto.
* gcc.c-torture/compile/20050122-2.c: Ditto.
* gcc.c-torture/compile/20010226-1.c: Ditto.
* gcc.c-torture/compile/20010327-1.c:  Skip for avr-*-*.
* gcc.c-torture/compile/980506-1.c: Ditto.
* gcc.c-torture/compile/20020604-1.c: Ditto.
* gcc.c-torture/compile/limits-stringlit.c: Ditto
* gcc.c-torture/compile/20001226-1.c: Ditto

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/20010226-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/20010327-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/20020604-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/20050122-2.c
trunk/gcc/testsuite/gcc.c-torture/compile/980506-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/limits-stringlit.c
trunk/gcc/testsuite/gcc.c-torture/compile/nested-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr27889.c
trunk/gcc/testsuite/lib/target-supports.exp


-- 


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

[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2008-04-09 23:57 ---
Try what?  I always start with a clean slate; an empty build directory!
Perhaps you mean something else?


-- 


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

[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3

[hp at gcc dot gnu dot org]

--- Comment #9 from hp at gcc dot gnu dot org  2008-04-09 23:57 ---
(In reply to comment #8)
> Try what?  I always start with a clean slate; an empty build directory!
> Perhaps you mean something else?

Oops, replied in wrong PR... please ignore.


-- 


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

[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2008-04-09 23:56 ---
Try what?  I always start with a clean slate; an empty build directory!
Perhaps you mean something else?


-- 


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

[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2008-04-09 23:49 ---
For cris-elf, this graduated to a runtime error equivalent to SEGV (no
valgrind); worked with 134139, failed from 134147.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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

[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-04-09 23:47 
---
After a clean bootstrap (empty build directory) I get a pass.  I suspect we
have a dependency somewhere not getting taken car of.  Hans-Peter can you try
this and see whta happends.


-- 


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

[Bug debug/35896] [4.4 Regression] gfortran TLS symbols broken with debug info

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-04-09 22:54 ---
Actually we just don't take into account  TLSness of the decl/RTL.


-- 


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

[Bug debug/35896] [4.4 Regression] gfortran TLS symbols broken with debug info

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-04-09 22:51 ---
Before:
.quad   [EMAIL PROTECTED]

After:
.8byte  testcom_


-- 


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

[Bug target/34916] [4.3/4.4 Regression] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #12 from hutchinsonandy at gcc dot gnu dot org  2008-04-09 
22:51 ---
Subject: Bug 34916

Author: hutchinsonandy
Date: Wed Apr  9 22:50:42 2008
New Revision: 134152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134152
Log:
2008-04-09 Andy Hutchinson <[EMAIL PROTECTED]>

PR rtl-optimization/34916
PR middle-end/35519
* combine.c (create_log_links): Do not create duplicate LOG_LINKS
between instruction pairs

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/combine.c


-- 


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

[Bug middle-end/35519] COMBINE repeating same matches and can SEG fault

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #6 from hutchinsonandy at gcc dot gnu dot org  2008-04-09 22:51 
---
Subject: Bug 35519

Author: hutchinsonandy
Date: Wed Apr  9 22:50:42 2008
New Revision: 134152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134152
Log:
2008-04-09 Andy Hutchinson <[EMAIL PROTECTED]>

PR rtl-optimization/34916
PR middle-end/35519
* combine.c (create_log_links): Do not create duplicate LOG_LINKS
between instruction pairs

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/combine.c


-- 


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

[Bug debug/35896] [4.4 Regression] gfortran TLS symbols broken with debug info

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-04-09 22:50 ---
I think we are emitting the debug info too early for _testcom before we marked
it as a TLS.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|gfortran TLS symbols broken |[4.4 Regression] gfortran
   |with debug info |TLS symbols broken with
   ||debug info


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

[Bug debug/35896] gfortran TLS symbols broken with debug info

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||openmp
   Target Milestone|--- |4.4.0


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

[Bug debug/35896] gfortran TLS symbols broken with debug info

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2008-04-09 22:47 ---
Created an attachment (id=15463)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15463&action=view)
generated code after patch


-- 


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

[Bug debug/35896] gfortran TLS symbols broken with debug info

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2008-04-09 22:46 ---
Created an attachment (id=15462)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15462&action=view)
generated code before patch


-- 


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

[Bug debug/35896] New: gfortran TLS symbols broken with debug info

[janis at gcc dot gnu dot org]

Four tests in libgomp.fortran (omp_parse3.f90, pr25162.f, and
threadprivate[23].f90 started failing with this patch:

  http://gcc.gnu.org/viewcvs?view=rev&rev=133801
  r133801 | george | 2008-04-01 17:23:36 -0400 (Tue, 01 Apr 2008)

This small testcase fails in the same way when compiled with "-m64 -g
-fopenmp":

  program test
  call foo
  end
  subroutine foo
  real testvar
  common /testcom/ testvar
c$omp threadprivate(/testcom/)
  testvar = 1.0
  return
  end

Output:

elm3b145% /opt/gcc-nightly/trunk-20080406/bin/gfortran -g -m64 -fopenmp tls1.f
-lgomp
/opt/gcc-nightly/binutils-2.18/bin/ld: /tmp/cc0dFrjq.o(.debug_info+0x74):
R_PPC64_ADDR64 used with TLS symbol testcom_

I'll attach the .s files for revisions 133800 and 133801 for the same source
but without the first three lines.


-- 
   Summary: gfortran TLS symbols broken with debug info
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug c/35895] gcc puts code in rodata section with -Os -g -funit-at-a-time

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-09 22:34 ---
The toplevel asm has:
asm("\t.section .rodata, \"a\"\nintelnops: "
 ".byte 0x90\n" ".byte 0x89,0xf6\n" ".byte 0x8d,0x76,0x00\n" ".byte
0x8d,0x74,0x26,0x00\n" ".byte 0x90\n" ".byte 0x8d,0x74,0x26,0x00\n" ".byte
0x8d,0xb6,0x00,0x00,0x00,0x00\n"
 ".byte 0x8d,0xb4,0x26,0x00,0x00,0x00,0x00\n" ".byte 0x90\n" ".byte
0x8d,0xb4,0x26,0x00,0x00,0x00,0x00\n");

GCC assumes the toplevel asm will not change the section, you need to use
.previous or what ever other method to push/pop the section.


-- 

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

[Bug c/35895] gcc puts code in rodata section with -Os -g -funit-at-a-time

[rostedt at goodmis dot org]

--- Comment #1 from rostedt at goodmis dot org  2008-04-09 22:20 ---
Created an attachment (id=15461)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15461&action=view)
alternative.c file compiled with -E and with some stipping

This is a gzipped version that shows the problem.

Do the following:

gcc -fno-strict-aliasing -Os -m64 -funit-at-a-time  -g -c -o alt.o alt.c

And examine the alt.o to see that several functions are in the .rodata section.

use: objdump -Dra alt.o | less
and search for 'Disassembly of section .rodata:'


-- 


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

[Bug c/35895] New: gcc puts code in rodata section with -Os -g -funit-at-a-time

[rostedt at goodmis dot org]

gcc can place code into the .rodata section. I found this while debugging a
crash in Ingo Molnar's sched-devel kernel. In the kernel code
arch/x86/kernel/alternative.c the static inline function costant_test_bit was
placed into the rodata. Later on in the kernel boot up sequence, the rodata
section is protected with the NX bit in the page tables. The next time the code
in the rodata is executed we get a crash.

I'll attach a file that shows this behaviour. I tried to strip it down but too
many modifications to the file makes the issue disappear. I compiled the code
with the -E option and saved that file to get rid of any header information
that would prevent you from seeing the issue.

I have also trimmed down the arguments that I pass in to :

[EMAIL PROTECTED]:~/gcc$ gcc -fno-strict-aliasing -Os -m64 -funit-at-a-time  -g
-c -o alt.o alt.c 
[EMAIL PROTECTED]:~/gcc$ nm alt.o | grep constant_test_bit
0090 r constant_test_bit
[EMAIL PROTECTED]:~/gcc$ gcc -v 
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2.2/configure --prefix=/usr/local/dist
--program-prefix=dist- --without-doc --enable-bootstrap --enable-64-bit-bfd
Thread model: posix
gcc version 4.2.2


I've compiled this version of gcc myself, but I have also seen this issue in
the  Red Hat Enterprise Linux version of gcc: 

[EMAIL PROTECTED] linux-x86-sched-devel.git]# gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)


Also note that the call is in fact to the .rodata as seen with:

objdump -Dra alt.o :

  8e:   e8 00 00 00 00  callq  93 
8f: R_X86_64_PC32   .rodata+0x8c

Disassembly of section .rodata:
[...]
0090 :
  90:   89 f9   mov%edi,%ecx
  92:   bf 40 00 00 00  mov$0x40,%edi
  97:   89 c8   mov%ecx,%eax
  99:   99  cltd   
  9a:   f7 ff   idiv   %edi
  9c:   89 d1   mov%edx,%ecx
  9e:   48 63 d0movslq %eax,%rdx
  a1:   48 8b 04 d6 mov(%rsi,%rdx,8),%rax
  a5:   48 d3 e8shr%cl,%rax
  a8:   83 e0 01and$0x1,%eax
  ab:   c3  retq   
  ac:   00 00   add%al,(%rax)


-- 
   Summary: gcc puts code in rodata section with -Os -g -funit-at-a-
time
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rostedt at goodmis dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/35860] [avr] code bloat caused by -fsplit-wide-types

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2008-04-09 22:09 
---
Confirmed.
Andy's fwprop patch from bug #35542 did not solve this.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
  Known to fail||4.3.0
  Known to work||4.1.2
   Last reconfirmed|-00-00 00:00:00 |2008-04-09 22:09:01
   date||
Summary|code bloat caused by -  |[avr] code bloat caused by -
   |fsplit-wide-types   |fsplit-wide-types


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

[Bug c/35894] ICE in calc_dfs_tree, at dominance.c:393

[marcus at jet dot franken dot de]

--- Comment #1 from marcus at jet dot franken dot de  2008-04-09 21:53 
---
Created an attachment (id=15460)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15460&action=view)
ati_fragment_shader.i

gcc -c -O3 ati_fragment_shader.i


-- 


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

[Bug c/35894] New: ICE in calc_dfs_tree, at dominance.c:393

[marcus at jet dot franken dot de]

/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c-O3  
ati_fragment_shader.i

ati_fragment_shader.i: In function 'g':
ati_fragment_shader.i:39: internal compiler error: in calc_dfs_tree, at
dominance.c:393


-- 
   Summary: ICE in calc_dfs_tree, at dominance.c:393
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at jet dot franken dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error

[sam at gcc dot gnu dot org]

--- Comment #8 from sam at gcc dot gnu dot org  2008-04-09 20:40 ---
Yes, the bug manifests when the view on the type is limited at this point *but*
we know the underlying type (because of a non-limited with for example). This
triggers it if you compile p2.adb:

package P1 is
   type T is null record;
end P1;
limited with P1;
package P2 is
   pragma Elaborate_Body;
   generic
  type T is private;
   package G is end G;
   package I1 is new G (P1.T);
end P2;
with P1;
package body P2 is end P2;

I'm testing a fix.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-12-07 14:01:58 |2008-04-09 20:40:46
   date||


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

[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error

[ludovic at ludovic-brenta dot org]

--- Comment #7 from ludovic at ludovic-brenta dot org  2008-04-09 20:25 
---
Further reduced test case: replace observers.ads with:

package Observers is
   type Observer is new Integer;
   type Observer_Access is access Observer;
end Observers;

and the bug is still there.


-- 


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

[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error

[ludovic at ludovic-brenta dot org]

--- Comment #6 from ludovic at ludovic-brenta dot org  2008-04-09 20:10 
---
Reduced test case:

package Observers is
  type Observer is tagged null record;
  type Observer_Access is access all Observers.Observer'Class;
end Observers;

limited with Observers;
with Ada.Containers.Doubly_Linked_Lists;
package Subjects is
  function Equals(Left, Right : access Observers.Observer) return Boolean;
  package Observer_Lists is new
Ada.Containers.Doubly_Linked_Lists(Observers.Observer_Access, Equals);
end Subjects;

with Observers; -- this line triggers the bug
package body Subjects is
   function Equals(Left, Right : access Observers.Observer) return Boolean is
   begin
  return False;
   end Equals;
end Subjects;

With the line that triggers the bug:

gcc-4.1 -c -gnat05 subjects.adb
+===GNAT BUG DETECTED==+
| 4.1.3 20070518 (prerelease) (Debian 4.1.2-8) (x86_64-pc-linux-gnu)   |
| Assert_Failure atree.adb:812 |
| Error detected at subjects.ads:8:3   |

gcc-4.3 -c -gnat05 subjects.adb
+===GNAT BUG DETECTED==+
| 4.3.1 20080401 (prerelease) (x86_64-pc-linux-gnu) Assert_Failure
atree.adb:886|
| Error detected at subjects.ads:8:3   |


Without the line that triggers the bug:

gcc-4.1 -c -gnat05 subjects.adb
subjects.ads:9:49: premature use of incomplete type
subjects.ads:9:49: instantiation abandoned

gcc-4.3 -c -gnat05 subjects.adb
subjects.ads:9:49: premature use of incomplete type
subjects.ads:9:49: instantiation abandoned


-- 


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

[Bug c++/35708] jump to label enters catch block

[jason at gcc dot gnu dot org]

--- Comment #10 from jason at gcc dot gnu dot org  2008-04-09 20:10 ---
Fixed for 4.3.1 and 4.4.0.  Patch seems risky for 4.2 at this point.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.1.3   |4.1.3 4.3.1 4.4.0


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

[Bug c++/35708] jump to label enters catch block

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2008-04-09 19:58 ---
Subject: Bug 35708

Author: jason
Date: Wed Apr  9 19:57:19 2008
New Revision: 134151

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134151
Log:
PR c++/35708
* semantics.c (finish_compound_literal): Return a TARGET_EXPR,
not a pushed variable.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/complit9.C
  - copied unchanged from r134146,
trunk/gcc/testsuite/g++.dg/ext/complit9.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/semantics.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error

[laguest at archangeli dot demon dot co dot uk]

--- Comment #5 from laguest at archangeli dot demon dot co dot uk  
2008-04-09 19:45 ---
This is still a problem on 4.4.0 trunk.

Luke.


-- 


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

[Bug c/35893] ice for legal code

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-04-09 19:40 ---
Created an attachment (id=15459)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15459&action=view)
C source code


-- 


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

[Bug c/35893] New: ice for legal code

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package smalltalk-2.1.12
with the GNU C compiler version 4.4 snapshot 20080404

The compiler said

 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib-src -I../lightning
-I../lightning -I../snprintfv -I../snprintfv
-DKERNEL_PATH=\"/usr/share/smalltalk/kernel\" -Wall
-DIMAGE_PATH=\"/usr/share/smalltalk\" -DMODULE_PATH=\"/usr/lib64/smalltalk\"
-O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -Wall
-Wdeclaration-after-statement -Wno-format -Wno-parentheses -Wpointer-arith
-Wno-pointer-sign -Wno-strict-aliasing -Wno-switch -fno-gcse
-fno-strict-aliasing -MT oop.lo -MD -MP -MF .deps/oop.Tpo -c oop.c -o oop.o
oop.c: In function '_gst_mark_an_oop_internal':
oop.c:2060: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -Wall required

Here is some additional help from valgrind

==2919== Invalid read of size 2
==2919==at 0x42588E: emit_side_effect_warnings (c-typeck.c:7522)
==2919==by 0x42DB50: c_finish_stmt_expr (c-typeck.c:7670)
==2919==by 0x47ACB7: c_parser_postfix_expression (c-parser.c:5230)
==2919==by 0x47AEEE: c_parser_unary_expression (c-parser.c:4982)
==2919==by 0x47B91C: c_parser_cast_expression (c-parser.c:4857)
==2919==by 0x47B9A4: c_parser_cast_expression (c-parser.c:4850)
==2919==by 0x47BA6D: c_parser_conditional_expression (c-parser.c:4687)
==2919==by 0x47C254: c_parser_expr_no_commas (c-parser.c:4448)
==2919==by 0x47C441: c_parser_expression (c-parser.c:5695)
==2919==by 0x47A42D: c_parser_postfix_expression (c-parser.c:5257)
==2919==by 0x47AEEE: c_parser_unary_expression (c-parser.c:4982)
==2919==by 0x47B91C: c_parser_cast_expression (c-parser.c:4857)
==2919==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


-- 
   Summary: ice for legal code
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug target/35860] code bloat caused by -fsplit-wide-types

[hutchinsonandy at aim dot com]

--- Comment #3 from hutchinsonandy at aim dot com  2008-04-09 19:24 ---
Subject: Re:  code bloat caused by -fsplit-wide-types

Try fwprop patch it might well help.

I can't tell from report where the oppertunities are missed.

But anything split at combine/split won't get any benefit as fwprop 
passes only occur before (much to my dismay).

Register allocation has a more  limited forward propagtion ability (it 
does not simplify for one) and simplistical will remove one level of 
redundant moves.

If we try split before combine (expanded RTL), then combine does work 
so well and it's a net loss.

Combine on split types does not work well as it is not possible to all 
instructions  (like compare, add).

We can't split due to use of CC0. We use CC0 because I cant figure out 
how to prevent reloads destroying status.

Dang it!



-Original Message-
From: eric dot weddington at atmel dot com <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Wed, 9 Apr 2008 3:04 pm
Subject: [Bug target/35860] code bloat caused by -fsplit-wide-types




--- Comment #2 from eric dot weddington at atmel dot com  
2008-04-09 19:04
---
I'll see about testing with Andy Hutchinson's fwprop patch at bug 
#35542.


--

eric dot weddington at atmel dot com changed:

   What|Removed |Added
-
---
  CC||hutchinsonandy at aim 
dot
||com, eric dot 
weddington at
   ||atmel dot com
   GCC host triplet|winavr 20080402 release |mingw


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 


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

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

[fche at redhat dot com]

--- Comment #32 from fche at redhat dot com  2008-04-09 19:15 ---
The patch has been committed for some time, and this test case passes.


-- 

fche at redhat dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/35860] code bloat caused by -fsplit-wide-types

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2008-04-09 19:04 
---
I'll see about testing with Andy Hutchinson's fwprop patch at bug #35542.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 CC||hutchinsonandy at aim dot
   ||com, eric dot weddington at
   ||atmel dot com
   GCC host triplet|winavr 20080402 release |mingw


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

[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-04-09 18:49 ---
> In this test case both arrays are explicit-sized, and even have the same size,
> but their upper and lower bounds are shifted. gfortran currently does not even
> check if both arrays have the same size, only their ranks are compared.

I think procedures with explicit-shape arguments with the same shape/size but
only different bounds should be conformable.

The only real problem is assumed-shape vs. the rest (explict, assumed-size,
...). Ok, if an explicit size is given, the sizes should match, but arguments
of the dummy/actual function like "integer :: foo(*)" and bar(1:2) and
foobar(3000:3001) should all be conformable.
Similarly, I think, also foo(1:), bar(:) and foobar(-300:) should be
conformable.

(I cannot really pinpoint it in the standard, but I'm convinced that this is
the case; when I have time, I will re-read the standard and try to produce a
proper reference.)
* I use "manner" as "kind" and "type" have a special Fortran meaning.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-09 18:49:31
   date||


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

[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments

[jaydub66 at gmail dot com]

--- Comment #5 from jaydub66 at gmail dot com  2008-04-09 18:48 ---
(In reply to comment #4)
> If we are lucky this fixes PR 35831.

Actually it does not, but I think I know how to fix it.


-- 


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

[Bug fortran/35892] [4.4 regression] gfortran dies on file containing module and common

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-04-09 18:31 ---
Confirm. Seems to be introduced between 2008-04-03-r133863 and
2008-03-27-r133632. I tried to reduce the test case -- and I failed. I think
somewhere the memory gets corrupted.


==1454== Invalid read of size 2
==1454==at 0x5CEB69: fold_binary (fold-const.c:9920)
==1454==by 0x5D8188: fold_build2_stat (fold-const.c:13441)
==1454==by 0x4A7752: gfc_conv_expr_op (trans-expr.c:1229)
==1454==by 0x4A6117: gfc_conv_expr_val (trans-expr.c:3612)
==1454==by 0x4A986B: gfc_conv_intrinsic_function_args
(trans-intrinsic.c:193)
==1454==by 0x4B13A0: gfc_conv_intrinsic_minmax (trans-intrinsic.c:1442)
==1454==by 0x4B27F0: gfc_conv_intrinsic_function (trans-intrinsic.c:4309)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|i386-apple-darwin9.2.2  |
 GCC target triplet|i386-apple-darwin9.2.2  |
   Keywords||ice-on-valid-code
  Known to fail||4.4.0
  Known to work||4.3.0 4.2.3
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2008-04-09 18:31:35
   date||
Summary|gfortran dies on file   |[4.4 regression] gfortran
   |containing module and common|dies on file containing
   ||module and common
   Target Milestone|--- |4.4.0


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

[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument

[jaydub66 at gmail dot com]

--- Comment #2 from jaydub66 at gmail dot com  2008-04-09 18:23 ---
Here is a modified version of the original test case, which is also accepted by
gfortran, while it is rejected by ifort:


module m

contains

subroutine one(a)
  integer a(1:2)
end subroutine one

subroutine two(a)
  integer a(2:3)
end subroutine two

end module

program test
  use m
  implicit none

  ! PROCEDURE dummy
  !call foo(two)

  ! Interface dummy
  call bar(two)

contains

!   subroutine foo(f)
! procedure(one) :: f
!   end subroutine foo

  subroutine bar(f)
interface
  subroutine f(a)
integer a(1:2)
  end subroutine f
end interface
  end subroutine bar

end program test


In this test case both arrays are explicit-sized, and even have the same size,
but their upper and lower bounds are shifted. gfortran currently does not even
check if both arrays have the same size, only their ranks are compared.
ifort gives the following error message:

fortcom: Error: test35831.f90, line 23: The characteristics of dummy argument 1
of the associated actual procedure differ from the characteristics of dummy
argument 1 of the dummy procedure. (12.2)   [TWO]
  call bar(two)
---^

I would change this bug's status from UNCONFIRMED to NEW, but apparently I
don't have the "canconfirm" permission.


-- 


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

[Bug testsuite/35868] Errors with hard_float

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-09 18:10 ---


*** This bug has been marked as a duplicate of 35843 ***


-- 

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

[Bug middle-end/35843] [4.4 Regression]: gcc.dg/pr30957-1.c and gcc.dg/var-expand1.c don't work

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-04-09 18:10 ---
*** Bug 35868 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dominiq at lps dot ens dot
   ||fr


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

[Bug testsuite/35868] Errors with hard_float

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-04-09 18:08 ---
honza's bug; cc:ed.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org


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

[Bug c++/35876] Exceptions not working on FreeBSD

[yuri at tsoft dot com]

--- Comment #1 from yuri at tsoft dot com  2008-04-09 18:06 ---
After further investigation it appears to be some issue with exceptions in
FreeBSD-STABLE-7.0 system g++ compiler. Exceptions don't work on FreeBSD with
system compiler at all.

System compiler is a version of gcc-4.2.1 tweaked by FreeBSD folks in some way
so let's leave it alone.

But gcc-4.3.0 was freshly compiled by me.

And with gcc-4.3.0 exceptions only work when -pthread flag is set (on FreeBSD
only).

Without -pthread flag gcc-4.3.0 has a problem with exceptions (using it's own
gcc-4.3.0 shared libraries).

Error is:
Abort trap: 6


-- 


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

[Bug fortran/35892] gfortran dies on file containing module and common

[KnowlesPJ at Cardiff dot ac dot uk]

--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk  2008-04-09 17:24 
---
Created an attachment (id=15458)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15458&action=view)
Fortran source code


-- 


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

[Bug fortran/35892] New: gfortran dies on file containing module and common

[KnowlesPJ at Cardiff dot ac dot uk]

Compilation with -O0 -g causes the compiler to crash:

/opt/gcc/bin/gfortran -c -fno-second-underscore -fdefault-integer-8 -m64 -g -O0
--save-temps f12_integrals.f
f12_integrals.f: In function 'f12_integrals_raw':
f12_integrals.f:980: internal compiler error: in expand_expr_real_1, at
expr.c:7258
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../configure --prefix=/opt/gcc --enable-languages=c,fortran :
(reconfigured) ../configure --prefix=/opt/gcc --enable-languages=c,fortran
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20080409 (experimental) (GCC) 

Although gcc -v reports 'i386' this is in fact an x86_64. But compiling on a
true ia32 (and omitting -m64) produces the same crash.

With -g removed or -O1 the compiler completes. However we are getting wrong
results, so perhaps the place to start is with the crash and then try again?


-- 
   Summary: gfortran dies on file containing module and common
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: KnowlesPJ at Cardiff dot ac dot uk
  GCC host triplet: i386-apple-darwin9.2.2
GCC target triplet: i386-apple-darwin9.2.2


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

[Bug libstdc++/35588] [parallel mode] parallel std::sort and bind()

[singler at gcc dot gnu dot org]

--- Comment #5 from singler at gcc dot gnu dot org  2008-04-09 17:03 ---
Fixed for mainline and gcc-4_3-branch.


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug objc++/35891] New: wrong pointer type in build_module_initializer_routine?

[johannes dot fortmann at gmail dot com]

I'm in the process of merging ObjC 2.0 Apple stuff into gcc 4.3.0 for the
cocotron project; we build a cross-compiler to build Windows/Linux binaries
from Darwin.
In the progress we got an ICE when compiling any ObjC++ code that would cause
an __objc_gnu_init constructor to be emitted with optimizations:
"internal compiler error: tree check: expected class 'type', have 
'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c: 
1535".

While trying to fix this problem, I noticed that
build_module_initializer_routine contains the line
objc_push_parm (build_decl (PARM_DECL, NULL_TREE, void_type_node));
Replacing this with
#ifdef OBJCPLUS
  objc_push_parm (build_decl (PARM_DECL, NULL_TREE, ptr_type_node));
#else
objc_push_parm (build_decl (PARM_DECL, NULL_TREE, void_type_node));
#endif
fixed the problem. 
I don't have the first idea on why; maybe this is just masking a deeper
problem. It certainly seems wrong somehow (the __objc_gnu_init should take a
void, shouldn't it?)...

Maybe someone with more knowledge on gcc stuff could shed a little light on
this?


-- 
   Summary: wrong pointer type in build_module_initializer_routine?
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: johannes dot fortmann at gmail dot com
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i386-mingw32msvc


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

[Bug libstdc++/35588] [parallel mode] parallel std::sort and bind()

[singler at gcc dot gnu dot org]

--- Comment #4 from singler at gcc dot gnu dot org  2008-04-09 16:47 ---
Subject: Bug 35588

Author: singler
Date: Wed Apr  9 16:47:00 2008
New Revision: 134148

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134148
Log:
2008-04-09  Johannes Singler  <[EMAIL PROTECTED]>

 * include/parallel/multiway_merge.h:
   Moved decisions to compiletime instead of runtime.
 * include/parallel/losertree.h:
   Removed obsolete variants, added variant that uses pointers
   in the loser tree.
 * include/parallel/types.h:
   Remove obsolete settings options from enum.
 * include/parallel/features.h:
   Remove obsolete compile-time switches.
 * include/parallel/compiletime_settings.h:
   Remove obsolete variant that copies back *after* sorting.
 * include/parallel/tags.h:
   Add one new tag for compile-time switch.
 * include/parallel/merge.h:
   Adapt to changes in multiway_merge.h.
 * include/parallel/multiway_mergesort.h:
   Adapt to changes in multiway_merge.h.
   Factor out splitting variants.
   Remove obsolete variant that copies back *after* sorting.
 * include/parallel/sort.h:
   Adapt to changes in multiway_mergesort.h.
 * testsuite/25_algorithms/sort/35588.cc:
   Added test case from / for PR 35588.


Added:
branches/gcc-4_3-branch/libstdc++-v3/testsuite/25_algorithms/sort/35588.cc
Modified:
branches/gcc-4_3-branch/libstdc++-v3/ChangeLog
   
branches/gcc-4_3-branch/libstdc++-v3/include/parallel/compiletime_settings.h
branches/gcc-4_3-branch/libstdc++-v3/include/parallel/features.h
branches/gcc-4_3-branch/libstdc++-v3/include/parallel/losertree.h
branches/gcc-4_3-branch/libstdc++-v3/include/parallel/merge.h
branches/gcc-4_3-branch/libstdc++-v3/include/parallel/multiway_merge.h
branches/gcc-4_3-branch/libstdc++-v3/include/parallel/multiway_mergesort.h
branches/gcc-4_3-branch/libstdc++-v3/include/parallel/sort.h
branches/gcc-4_3-branch/libstdc++-v3/include/parallel/tags.h
branches/gcc-4_3-branch/libstdc++-v3/include/parallel/types.h


-- 


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

[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory

[knoxj at att dot net]

--- Comment #6 from knoxj at att dot net  2008-04-09 16:19 ---
Thank you for your comments. This is my first free software bug report, so I'm
still learning the ropes. I have been submitting commercial vendor bug reports
for several decades, and old habits die hard.

README file contents :

The files listed below demonstrate the GNAT Ada compiler not generating 'gdb'
debug information correctly for shared memory. 

'gdb' says
"No definition of "pacs_cp" in current context."

NightView says
"Identifier "pacs_cp" is not visible in the given context."

Problem first found on 2.6.18.8-RedHawk-4.2.2-trace
   gdb Concurrent RedHawk Linux (6.3.0.0-1.63rh)
   gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)

Problem verified on2.6.15.4-RedHawk-4.1-debug
   gdb Concurrent RedHawk Linux (6.3.0.0-1.63rh)
   gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)

Problem verified on2.6.9-RedHawk-2.3.5-debug
   gdb 6.0
   gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

Problem verified on2.6.9-42.0.3.EL (Red Hat EL WS 4 update 4)   
   gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
   gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)

Problem verified on2.6.23.1-42.fc8
   gdb Fedora (6.8-1.fc9)
   gcc version 4.3.0 20080326 (Red Hat 4.3.0-5) (GCC)

===

makefile - build rules

ada_proclock.ads - Ada interface
proclock.h   - C interface
proclock.c   - C implementation

f15_shm.ld   - 'ld' commands for shared memory layout
f15_shm.h- C interface
f15_shm.c- C implementation
f15_shm_tables.c - shared memory data tables

nh_base_types.ads- hardware representation
test_pacs_cp_package.ads - Ada data description
testshm.adb  - Ada test program

pacs_cp.h  - C data description
testshmc.c - C test program

===

Follow the steps below to reproduce the problem :

1. make clean

2. make

3. gdb testshma
'tb main'
'r'
'n' 7 times to get to "Ada_Main_Program"
's'
'n' 4 times
'ptype pacs_cp' to get "No definition of "pacs_cp" in current context."

4. gdb testshmc
'tb main'
'r'
'n' 4 times
'ptype pacs_cp' to get type = volatile struct PACS_CP {
   short int word[8192];
   }

5. edit test_pacs_cp_package.ads
comment "pragma IMPORT" line

6. make

7. gdb testshma
'tb main'
'r'
'n' 7 times to get to "Ada_Main_Program"
's'
'n' 4 times
'ptype pacs_cp' to get type = record
   word: array (1 .. 8192) of 
   nh_base_types.signed_half_word_type;
   end record


-- 


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

[Bug c++/35708] jump to label enters catch block

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2008-04-09 16:16 ---
Subject: Bug 35708

Author: jason
Date: Wed Apr  9 16:15:53 2008
New Revision: 134146

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134146
Log:
PR c++/35708
* semantics.c (finish_compound_literal): Return a TARGET_EXPR,
not a pushed variable.

Added:
trunk/gcc/testsuite/g++.dg/ext/complit9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35546] [4.3/4.4 Regression] __attribute__(format...) broken for members of template classes?

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-04-09 15:53 ---
*** Bug 35890 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||zak at transversal dot com


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

[Bug c++/35890] __attribute__((format)) fails for methods of template classes

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-09 15:53 ---


*** This bug has been marked as a duplicate of 35546 ***


-- 

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

[Bug c++/35890] New: __attribute__((format)) fails for methods of template classes

[zak at transversal dot com]

The following code, which compiles cleanly in gcc 4.2.3, produces an error with
4.3.0:


template< typename T >
struct X {
void f(const char *fmt, ...)
__attribute__((format (printf, 2, 3) ));
};

template class X< void >;


fmt_et.cc: In instantiation of 'X':
fmt_et.cc:7:   instantiated from here
fmt_et.cc:4: error: 'printf' was not declared in this scope
fmt_et.cc:4: error: unrecognized format specifier


The error occurs both with explicit instantiation of the class (as above) and
with implicit instantiation via an invocation of the method X::f.  It
does not occur either for a non-template class or if the template is never
instantiated.


-- 
   Summary: __attribute__((format)) fails for methods of template
classes
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
 GCC build triplet: x86_64_pc_linux_gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64_pc_linux_gnu


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

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[bergner at gcc dot gnu dot org]

--- Comment #53 from bergner at gcc dot gnu dot org  2008-04-09 15:38 
---
Author: bergner
Date: Wed Apr  9 13:42:43 2008
New Revision: 134139

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134139
Log:
PR middle-end/PR28690
* explow.c (break_out_memory_refs): Use simplify_gen_binary rather
than gen_rtx_fmt_ee to perform more canonicalizations.

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


-- 

bergner at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug c/35885] unsigned long long and while loop evaluation regression?

[wilbert at jdg dot info]

--- Comment #2 from wilbert at jdg dot info  2008-04-09 15:36 ---
I just did a fresh build of gcc 4.1.3 from the ports collection under freebsd
6.1

And got this (incorrect) result again:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 9afa246709018f48, testu32a = 0506f85f


-- 


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

[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted

[rguenther at suse dot de]

--- Comment #13 from rguenther at suse dot de  2008-04-09 15:26 ---
Subject: Re:  [4.1/4.2/4.3/4.4 Regression] operand of
 pre-/postin-/decrement not promoted

On Wed, 9 Apr 2008, jakub at gcc dot gnu dot org wrote:

> --- Comment #12 from jakub at gcc dot gnu dot org  2008-04-09 14:32 
> ---
> Created an attachment (id=15455)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455&action=view)
> gcc43-pr35634.patch
> 
> Here is the updated FE only patch.  One change is that it avoids
> P{RE,OST}{IN,DE}CREMENT_EXPR only for the promoting types, and has some
> (admittedly very ugly) OpenMP parsing changes to counter that.  Unfortunately
> unlike #pragma omp for increment, #pragma omp atomic can have some_lvalue++
> , not necessarily a variable_name++, so I have no idea how to handle that.
> 
> On x86_64 with this patch I get 3 omp failures (2 in libgomp atomic-10.c, one
> in gcc/testsuite atomic-1.c) and:
> FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect "vectorized 1 loops" 1
> FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vect "vectorized 1 loops" 1
> FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect "vectorized 1 loops" 
> 1
> FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect "vectorized 1
> loops" 2
> so (depending on where the other patch was tested) doing this in the FE 
> doesn't
> help much or at all.

Thanks!

I will try doing the P{RE,OST}{IN,DE}CREMENT_EXPR semantic change and
handling it in the gimplifier.  Just because I am curious how much
I break the frontends...

After the summit paper deadline is over ;)

Richard.


-- 


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

[Bug c++/35889] spu_check_builtin_parm function fails on templates.

[rbertran at ac dot upc dot edu]

--- Comment #3 from rbertran at ac dot upc dot edu  2008-04-09 15:25 ---
Created an attachment (id=15457)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15457&action=view)
Temp file generated when -save-temps flag is set


-- 


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

[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory

[charlet at adacore dot com]

--- Comment #5 from charlet at adacore dot com  2008-04-09 15:25 ---
Subject: Re:  GNAT (GCC) Ada does not generate symbolic debug for shared memory

> The application is an aircraft simulation by stimulating avionics black boxes.
> We use a debugger to examine state information while the simulation is running
> to try to determine problem causes.

Note that the GCC project is based on volunteers, so your PR may never
get the high priority attention that you apparently require.

For such critical usage, you may consider getting support for your compiler
(or get familiar with the compiler to investigate this issue yourself).

> I thought I read in the submission guidelines that an attachment was 
> acceptable in a case like this. If I should submit the file contents as a
> large file, please point me to a sample so I know how to format the various
> individual file contents.

Having a tar file for sources is certainly fine. Having all the instructions
and explanation inside a README in a tarball is an unnecessary indirection
which can only delay review of your PR.

Arno


-- 


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

[Bug c++/35889] spu_check_builtin_parm function fails on templates.

[rbertran at ac dot upc dot edu]

--- Comment #2 from rbertran at ac dot upc dot edu  2008-04-09 15:24 ---
Command executed:

spu-g++ -ffreestanding -Wall -ffast-math -fno-rtti -fno-exceptions
--function-sections --data-sections -fsigned-char -I -I../.. -I../../include
-I./org -I. `pkg-config --cflags opencv` -I/usr/spu/include
-I../../cellsdk/spu/include -c cvHaarDetectObjects_spu.cpp -o
obj/cvHaarDetectObjects_spu.ospu -save-temps


-- 


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

[Bug c++/35889] spu_check_builtin_parm function fails on templates.

[rbertran at ac dot upc dot edu]

--- Comment #1 from rbertran at ac dot upc dot edu  2008-04-09 15:20 ---
Created an attachment (id=15456)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15456&action=view)
Temp file generated when -save-temps flag is set


-- 


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

[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory

[knoxj at att dot net]

--- Comment #4 from knoxj at att dot net  2008-04-09 15:19 ---
Print statements work if you know what you want to look at.

The application is an aircraft simulation by stimulating avionics black boxes.
We use a debugger to examine state information while the simulation is running
to try to determine problem causes.

I spent 3 days condensing hundreds of thousands of source lines to the test
case I submitted. I tried to provide a short test case to demonstrate the
problem. I ended up with 14 files consisting of 2226 actual source lines.

I thought I read in the submission guidelines that an attachment was 
acceptable in a case like this. If I should submit the file contents as a
large file, please point me to a sample so I know how to format the various
individual file contents.


-- 


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

[Bug libgomp/29986] testsuite failures

[scovich at gmail dot com]

--- Comment #4 from scovich at gmail dot com  2008-04-09 15:18 ---
If it's any help, adding some inline asm to the file makes the Sun toolchain
croak on my machine.

SunOS 5.10 Generic_118833-23 sun4v sparc SUNW,Sun-Fire-T200
Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
Solaris Link Editors: 5.10-1.482

// begin tls-bug.c
void membar_producer() { asm volatile("membar #StoreStore"); }
static __thread bool val;
int main() { return val; }
// end tls-bug.c

This bug seems to show up in arbitrary ways for each of the three compilers on
my machine:
$ cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
$ ~/apps/gcc/4.3/bin/gcc-4.3 -v
Using built-in specs.
Target: sparc64-sun-solaris2.10
Configured with: ../configure --prefix=/export/home/ryanjohn/apps/gcc/4.3
--build=sparc64-sun-solaris2.10 --program-suffix=-4.3
--with-mpfr=/export/home/ryanjohn/apps --with-gmp=/export/home/ryanjohn/apps
--disable-multilib --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
Thread model: posix
gcc version 4.3.0 (GCC) 

Note that all three use the same copy of ld

$ cc tls-bug.c
$ cc -g tls-bug.c

$ CC tls-bug.c
ld: fatal: relocation error: R_SPARC_TLS_GD_HI22: file tls-bug.o:
symbol: bad symbol type SECT: symbol type must be TLS
$ CC -g tls-bug.c

$ gcc -m64 tls-bug.c
$ gcc -m64 -g tls-bug.c
ld: fatal: relocation error: R_SPARC_TLS_DTPOFF64: file /var/tmp//ccuJHWqp.o:
symbol done: offset 0x7d901c33 is non-aligned
collect2: ld returned 1 exit status

$ gcc-4.3 tls-bug.c
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file /var/tmp//ccUeK1AZ.o:
symbol : bad symbol type SECT: symbol type must be TLS
collect2: ld returned 1 exit status
$ gcc-4.3 tls-bug.c -g
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file /var/tmp//cceRP4ZP.o:
symbol : bad symbol type SECT: symbol type must be TLS
collect2: ld returned 1 exit status


-- 


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

[Bug c++/35889] New: spu_check_builtin_parm function fails on templates.

[rbertran at ac dot upc dot edu]

Hello,

I'm using gcc4.3.0 for compiling cell binaries on a x86 platform.
I've some benchmarks that use c++ templates like:

template < typename T> inline
T rot_veci( T v, int n )
{
return (T) si_rotqbyi( (vector signed char)v, n );
}

When compiling, I get the following error:

error: si_rotqbyi expects an integer literal in the range [-64, 127].

So, I suppose that gcc is not able to know the value of the 'n' parameter.
Then, the builtins intrinsics checks for the literal range and raise the
error.

I've been googling and I found references [1][2] about this problem (or
similar problem). I guess that the problem comes from the
spu_check_builtin_parm function in gcc/config/spu/spu.c . I have reported
the problem to IBM cell forums, too.

Thanks in advance,
Salut!

[1] http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00130.html
[2] http://gcc.gnu.org/ml/gcc-patches/2006-12/txt0.txt


-- 
   Summary: spu_check_builtin_parm function fails on templates.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbertran at ac dot upc dot edu
 GCC build triplet: x86-linux-gnu
  GCC host triplet: x86-linux-gnu
GCC target triplet: spu-elf


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

[Bug ada/35888] New: ICE: converting a concrete type into a classwide interface

[sam at gcc dot gnu dot org]

The following package spec

package B is
   type I is Interface;
   type C is new I with null record;
   function M return C;
   X : I'Class := I'Class (M);
end B;

triggers an infinite recursion in GNAT:

+===GNAT BUG DETECTED==+
| 4.4.0 20080409 (experimental) (i686-pc-linux-gnu) Storage_Error stack
overflow (or erroneous memory access)|
| Error detected at b.ads:5:20 |


-- 
   Summary: ICE: converting a concrete type into a classwide
interface
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sam at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug libstdc++/35597] libstdc++ -ffunction-sections -fdata-sections disabled on AIX

[dje at gcc dot gnu dot org]

--- Comment #5 from dje at gcc dot gnu dot org  2008-04-09 14:41 ---
Subject: Bug 35597

Author: dje
Date: Wed Apr  9 14:41:07 2008
New Revision: 134143

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134143
Log:
PR libstdc++/35597
* toplev.c (process_options): Remove -ffunction-sections debugging
warning.

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


-- 


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

[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2008-04-09 14:32 ---
Created an attachment (id=15455)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455&action=view)
gcc43-pr35634.patch

Here is the updated FE only patch.  One change is that it avoids
P{RE,OST}{IN,DE}CREMENT_EXPR only for the promoting types, and has some
(admittedly very ugly) OpenMP parsing changes to counter that.  Unfortunately
unlike #pragma omp for increment, #pragma omp atomic can have some_lvalue++
, not necessarily a variable_name++, so I have no idea how to handle that.

On x86_64 with this patch I get 3 omp failures (2 in libgomp atomic-10.c, one
in gcc/testsuite atomic-1.c) and:
FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect "vectorized 1
loops" 2
so (depending on where the other patch was tested) doing this in the FE doesn't
help much or at all.


-- 


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

[Bug c++/35734] [4.3/4.4 regression] ICE with copy constructor in derived class

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-04-09 14:25 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/35887] New: stl parallel includes installed for --disable-libgomp

[pluto at agmk dot net]

with --disable-libgomp buildsystem omits omp.h installation
but installs libstdc++/parallel stuff which depends on it.
this won't work.


-- 
   Summary: stl parallel includes installed for --disable-libgomp
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net


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

[Bug ada/28305] GNAT bug when inlining instance of a generic subprogram

[sam at gcc dot gnu dot org]

--- Comment #4 from sam at gcc dot gnu dot org  2008-04-09 14:22 ---
Fixed in SVN trunk.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug ada/28305] GNAT bug when inlining instance of a generic subprogram

[sam at gcc dot gnu dot org]

--- Comment #3 from sam at gcc dot gnu dot org  2008-04-09 14:22 ---
Subject: Bug 28305

Author: sam
Date: Wed Apr  9 14:21:18 2008
New Revision: 134142

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134142
Log:
gcc/ada/
PR ada/28305
* sem_ch6.adb (Build_Body_To_Inline): Do not save and restore
environment if generic instance is a top-level one.

gcc/testsuite/
PR ada/28305
* gnat.dg/specs/fe_inlining.ads, gnat.dg/specs/fe_inlining_helper.ads,
gnat.dg/specs/fe_inlining_helper.adb: New test.


Added:
trunk/gcc/testsuite/gnat.dg/specs/fe_inlining.ads
trunk/gcc/testsuite/gnat.dg/specs/fe_inlining_helper.adb
trunk/gcc/testsuite/gnat.dg/specs/fe_inlining_helper.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/sem_ch6.adb
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35838] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2008-04-09 14:13 ---
This was introduced in revision 133452.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org


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

[Bug ada/35792] Illegal program not detected, RM 3.10.1(4/2)

[sam at gcc dot gnu dot org]

--- Comment #1 from sam at gcc dot gnu dot org  2008-04-09 13:38 ---
Confirmed on GCC 4.4.0 20080409.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-09 13:38:24
   date||


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

[Bug libgomp/35881] OMP wrong results for omp_get_max_threads

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2008-04-09 13:31 ---
I decided to ask, and maybe it is correct anyway, even though I have not fully
followed the bit on 'nthreads-var'

http://www.openmp.org/forum/viewtopic.php?f=3&t=100


-- 


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

[Bug ada/35886] Bad location of error message

[sam at gcc dot gnu dot org]

-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-09 13:27:49
   date||


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

[Bug ada/35886] New: Bad location of error message

[sam at gcc dot gnu dot org]

GNAT switches the location of the full type and the incomplete type when a
tagged type is completed with a non-tagged record:

% gcc -gnatv -c p.ads
GNAT 4.4.0 20080409 (experimental)
Copyright 1992-2008, Free Software Foundation, Inc.

Compiling: p.ads (source file time stamp: 2008-04-09 13:15:07)

 3.type T is tagged;
|
>>> full declaration of type "T" defined at line 4 must be tagged

 6 lines: 1 error

-- 
package P is

   type T is tagged;
   type T is null record;

end P;


-- 
   Summary: Bad location of error message
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ada
AssignedTo: sam at gcc dot gnu dot org
ReportedBy: sam at gcc dot gnu dot org


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

[Bug c/35885] unsigned long long and while loop evaluation regression?

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-09 13:05 ---
This works for me.


-- 


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

[Bug c++/35883] Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-09 13:01 ---
Sorry, but the oldest GCC version still maintained is GCC 4.1.2 though I
suggest
to at least try GCC 4.2.x which will even get further updates.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-04-09 11:46 ---
> I see it on x86-64 Linux clearly enough and with -m32 and -m64.  I think Paul
> removed a check that we have to put back in.

Whereas I do not see it, neither with -m32 nor -m64 on x86-64-linux (openSUSE
Factory); not even using valgrind. This is with
gfortran 4.4.0 20080409 (experimental) [trunk revision 134131]


-- 


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

[Bug c++/35884] defining __need_size_t before including causes error

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2008-04-09 11:22 ---
Names starting with __ and _ (see 17.4.3.1 for details) are reserved. That's
exactly the reason why the library uses everywhere and only such names (why,
otherwise?)


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libgomp/35881] OMP wrong results for omp_get_max_threads

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2008-04-09 10:58 ---
also confirmed for trunk


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to fail|4.2.3 4.3.0 |4.2.3 4.3.0 4.4.0


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

[Bug tree-optimization/35821] Internal compiler error: segmentation fault

[irar at gcc dot gnu dot org]

--- Comment #8 from irar at gcc dot gnu dot org  2008-04-09 10:55 ---
Subject: Bug 35821

Author: irar
Date: Wed Apr  9 10:55:11 2008
New Revision: 134136

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134136
Log:
PR tree-optimization/35821
* tree-vect-transform.c (vect_create_data_ref_ptr): Add check that
NEW_STMT_LIST is not NULL.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/pr35821-altivec.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/pr35821-spu.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-vect-transform.c


-- 


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

[Bug c/35885] New: unsinged long long and while loop evaluation regression?

[wilbert at jdg dot info]

The following program:
#include 

int main(int argc, char **argv) {
unsigned inttestu32a = 0x506f85f;
unsigned long long  testu64a = 0x9afa246709018f48ULL;

printf("before: testu64a = %08x%08x, testu32a = %08x\n", (unsigned
int)( testu64a >> 32 ), (unsigned int)( testu64a & 0x ), testu32a );

while ((unsigned long long)testu32a * (unsigned long long)0x <
testu64a)
testu64a /= 2;

printf("after: testu64a = %08x%08x, testu32a = %08x\n", (unsigned int)(
testu64a >> 32 ), (unsigned int)( testu64a & 0x ), testu32a );

return 0;
}


When compiled under freebsd 6 using "gcc -o test test.c" gives different
results when using gcc 3.4.4 or gcc 4.2.4:

Using 3.4.4:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 04d7d12338480c7a, testu32a = 0506f85f

Using 4.2.4:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 9afa246709018f48, testu32a = 0506f85f


The behavior of 4.2.4 has also been seen on a linux gentoo machine running gcc
4.1.2, a 64bit xp machine running gcc 4.2.1, and a regular xp machine running
gcc 4.2.1.


-- 
   Summary: unsinged long long and while loop evaluation regression?
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilbert at jdg dot info
 GCC build triplet: several
  GCC host triplet: several
GCC target triplet: several


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

[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-04-09 10:32 ---
This fails actually since:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132282
AKA PR34824.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c++/35884] New: defining __need_size_t before including causes error

[stdin at stdin dot me dot uk]

When you define __need_size_t before including  it only pulls in
size_t, but the cstddef header expects ptrdiff_t there too and fails.
sample code:
--
#define __need_size_t
#include 
main() {}
--
error message produced by g++:
$ g++ main.cpp
In file included from main.cpp:2:
/usr/include/c++/4.3/cstddef:55: error: ‘::ptrdiff_t’ has not been declared


-- 
   Summary: defining __need_size_t before including  causes
error
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stdin at stdin dot me dot uk
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c++/35883] Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067

[bachlipp at web dot de]

--- Comment #3 from bachlipp at web dot de  2008-04-09 10:05 ---
Created an attachment (id=15454)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15454&action=view)
Preprocessed source file, third chunk


-- 


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

[Bug c++/35883] Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067

[bachlipp at web dot de]

--- Comment #2 from bachlipp at web dot de  2008-04-09 10:05 ---
Created an attachment (id=15453)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15453&action=view)
Preprocessed source file, second chunk


-- 


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

[Bug c++/35883] Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067

[bachlipp at web dot de]

--- Comment #1 from bachlipp at web dot de  2008-04-09 10:04 ---
Created an attachment (id=15452)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15452&action=view)
Preprocessed source file, first chunk

Generated from original log4cplus-1.0.2 distribution, configured using just
"./configure", copying and modifying the g++ call originating from the call to
"make" like this:
cd src
g++ -DHAVE_CONFIG_H -I. -I. -I../include/log4cplus -I../include -Wall
-D_REENTRANT -g -O2 -c appender.cxx -DDLL_EXPORT -DPIC -save-temps -o
.libs/appender.o

Then splitted using
split --bytes=70 appender.li


-- 


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

[Bug c++/35883] New: Similar to #23589: Internal compiler error: in rest_of_handle_final, at toplev.c:2067

[bachlipp at web dot de]

I tried to compile log4cplus-1.0.2 with the latest stable GCC distributed with
MinGW (gcc-*-3.4.5-20060117-2). This failed. So I compiled GCC 3.4.6 myself:

export PATH=/mingw/bin:$PATH
export GCC_EXEC_PREFIX=/mingw/lib/gcc/
cd ..
mkdir mingw32
cd mingw32
mkdir /usr/include
../gcc-3.4.6/configure --with-gcc --with-gnu-ld --with-gnu-as \
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads \
--disable-nls --enable-languages=c,c++,f77,ada,objc,java \
--disable-win32-registry --disable-shared --enable-sjlj-exceptions \
--enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm \
--disable-libgcj-debug --enable-interpreter --enable-hash-synchronization \
--enable-libstdcxx-debug --enable-languages=c,c++
make BOOT_CFLAGS="-O2 -fomit-frame-pointer -D__USE_MINGW_ACCESS" \
BOOT_CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" \
BOOT_LDFLAGS=-s \
bootstrap
make install

Now I have
$ g++ --version
g++.exe (GCC) 3.4.6
[...]

$ uname -a
MINGW32_NT-5.1 [hostname] 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown

Updating the compiler didn't solve the problem. It still says:

appender.cxx:245: warning: function 'virtual log4cplus::tstring
log4cplus::Appender::getName()' is defined after prior declaration as
dllimport: attribute ignored
appender.cxx:253: warning: function 'virtual void
log4cplus::Appender::setName(const log4cplus::tstring&)' is defined after prior
declaration as dllimport: attribute ignored
appender.cxx:268: warning: function 'virtual void
log4cplus::Appender::setErrorHandler(std::auto_ptr)'
is defined after prior declaration as dllimport: attribute ignored
appender.cxx:260: warning: function 'virtual log4cplus::ErrorHandler*
log4cplus::Appender::getErrorHandler()' is defined after prior declaration as
dllimport: attribute ignored
appender.cxx:284: warning: function 'virtual void
log4cplus::Appender::setLayout(std::auto_ptr)' is defined
after prior declaration as dllimport: attribute ignored
appender.cxx:294: warning: function 'virtual log4cplus::Layout*
log4cplus::Appender::getLayout()' is defined after prior declaration as
dllimport: attribute ignored
appender.cxx:95: warning: function 'virtual void
log4cplus::OnlyOnceErrorHandler::error(const log4cplus::tstring&)' is defined
after prior declaration as dllimport: attribute ignored
appender.cxx:84: warning: function 'virtual
log4cplus::ErrorHandler::~ErrorHandler()' is defined after prior declaration as
dllimport: attribute ignored
appender.cxx:84: warning: function 'virtual
log4cplus::ErrorHandler::~ErrorHandler()' is defined after prior declaration as
dllimport: attribute ignored
appender.cxx: In destructor `log4cplus::ErrorHandler::~ErrorHandler()':
appender.cxx:85: internal compiler error: in rest_of_handle_final, at
toplev.c:2067
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

The command line used was:
g++ -DHAVE_CONFIG_H -I. -I. -I../include/log4cplus -I../include -Wall
-D_REENTRANT -g -O2 -c appender.ii -DDLL_EXPORT -DPIC -o .libs/appender.o
This is similar to what a simple "./configure" yielded.

Please find the lengthy preprocessed source attached.


-- 
   Summary: Similar to #23589: Internal compiler error: in
rest_of_handle_final, at toplev.c:2067
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bachlipp at web dot de
 GCC build triplet: *-*-*
  GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32


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

[Bug fortran/35882] Miscounted continuation lines when interspersed with data

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-04-09 09:19 ---
> We found the bug when using a very long write statement, with alternating
> continuation lines of string literals and data. The bug does not appear if
> only string literals are used.

I forget to say thank you for the bug report.

The problem that the number miscounts for comment/empty lines should be fixed
by the following patch (untested), but I did not see the actual problem.
... I think it is caused by repeatedly parsing the same line; one could try to
fix it as follows:

Index: scanner.c
===
--- scanner.c   (revision 134131)
+++ scanner.c   (working copy)
@@ -811,18 +811,19 @@ restart:

   /* We've got a continuation line.  If we are on the very next line after
 the last continuation, increment the continuation line count and
 check whether the limit has been exceeded.  */
-  if (gfc_linebuf_linenum (gfc_current_locus.lb) == continue_line + 1)
+  if (gfc_linebuf_linenum (gfc_current_locus.lb) > continue_line)
{
  if (++continue_count == gfc_option.max_continue_free)
{
  if (gfc_notification_std (GFC_STD_GNU) || pedantic)
gfc_warning ("Limit of %d continuations exceeded in "
 "statement at %C", gfc_option.max_continue_free);
}
+
+ continue_line = gfc_linebuf_linenum (gfc_current_locus.lb);
}
-  continue_line = gfc_linebuf_linenum (gfc_current_locus.lb);

   /* Now find where it continues. First eat any comment lines.  */
   openmp_cond_flag = skip_free_comments ();


-- 


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

[Bug fortran/35882] Miscounted continuation lines when interspersed with data

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-04-09 09:05 ---
Confirm.

The problem is not the settings, but that the counting goes wrong. This can
also be seen if one adds comment or empty lines in between. One would expect
that this should not affect the line count (i.e. error still in line 15) or
that the number decreases, however, it increases.

There is also another bug: The default value for -std=gnu/legacy should be 255
(Fortran 2003) and not 39 (Fortran 95). Currently, "-std=gnu -pedantic" warns
for >39 continuation lines but with "-std=f2003 -pedantic" only for >255
continuation lines!

Note: For fixed form source it actually works, even if one adds empty
lines/comment lines.

The additional bug is fixed by the following patch. The reported bug needs some
studying of scanner.c

Index: options.c
===
--- options.c   (revision 134131)
+++ options.c   (working copy)
@@ -61,2 +61,2 @@ gfc_init_options (unsigned int argc ATTR
-  gfc_option.max_continue_fixed = 19;
-  gfc_option.max_continue_free = 39;
+  gfc_option.max_continue_fixed = 255;
+  gfc_option.max_continue_free = 255;
@@ -736,0 +737,2 @@ gfc_handle_option (size_t scode, const c
+  gfc_option.max_continue_fixed = 19;
+ gfc_option.max_continue_free = 39;
@@ -745,2 +746,0 @@ gfc_handle_option (size_t scode, const c
-  gfc_option.max_continue_fixed = 255;
-  gfc_option.max_continue_free = 255;
@@ -756,2 +755,0 @@ gfc_handle_option (size_t scode, const c
-  gfc_option.max_continue_fixed = 255;
-  gfc_option.max_continue_free = 255;


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|x86_64-unknown-linux-gnu|
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2008-04-09 09:05:55
   date||


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

[Bug other/35858] time/memory hog for large c++ source.

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2008-04-09 08:08 ---
Subject: Re:  time/memory hog for large c++ source.

On Tue, 8 Apr 2008, pluto at agmk dot net wrote:

> --- Comment #7 from pluto at agmk dot net  2008-04-08 16:50 ---
> (In reply to comment #6)
> > We'll not be able to fix this for 4.3 (the regression is caused by a
> > correctness
> > fix), but 4.4 will have this param setting as default.
> 
> Can i safely set this parameter to zero for vendor gcc package?
> Does the non-zero value fix some bugs or sth?

In principle you can set it to zero, but you will lose optimization
opportunities in the areas of PRE/FRE, loop invariant and store motion
(to name the probably most important ones).

Richard.


-- 


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