Strange array limitations

[Andreas Klein]

Dear developers.

I guess it is gcc bug. But for the case that it a libary bug can any one 
forward it to the boost develops, because I do not understand how to use 
their bug tracking system.


I have found a strange limitation for the size of an array. The error
is the same both for boost 1.36 and for the array in gcc 4.3.2 (and in
the gcc 4.4 snapshot I use). I am almost sure that it is a bug of gcc
and not of the array implementation.

Here is the code.

#include
using namespace std;


int main () {
  array a; // Create a big array

  a[(1<<22)-13]=0;  // This give a segmantation fault
}

In contrast a C-array works fine.

int main () {
  unsigned int  a[1<<22];

  a[(1<<22)-13]=0;  // This give a segmantation fault
}

Since the naturale implementation of the array class is just a wrapper
around the C-style array this is very strange.

I tryed to track down the bug. You use the following implementation:

  template class array {
T C[n];

  public:
typedef unsigned int size_type;
T& operator[](size_type p) {
  return C[p];
}
  };

If we change the C[n] to an explicite new it works fine.

  template class array {
T* C;

  public:
typedef unsigned int size_type;
array() {
  C = new T[n];
}
T& operator[](size_type p) {
  return C[p];
}
  };

It seams that this resolves the bug. But I can not explain why.
I tested the code with the intel compiler and it works fine for both
implementations. So it seams that it is a gcc bug, that the first
solution do not work. What happens here?

Kind regards
 Andreas Klein

[Bug libstdc++/37958] num_get<>::do_get(bool) sets eofbit flag incorrectly when boolalpha == true

[tsyvarev at ispras dot ru]

--- Comment #19 from tsyvarev at ispras dot ru  2008-11-06 07:16 ---
Created an attachment (id=16627)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16627&action=view)
Analogue of basic_istringstream with (in == end) catching

Using basic_istringstream1 class instead basic_istringstream one can count
symbols, which implementation is really read. These symbols are those, for
which (in == end) or/and (*in) was performed (++in operation does not affect on
this counter).

Test testsuite/22_locale/num_get/get/char/37958.cc may be extend as:

- istringstream iss0, iss1, iss2, iss3;
+ basic_istringstream1 iss0, iss1, iss2, iss3;
...
  iss0.str("true");
  iss0.setf(ios_base::boolalpha);
  err = ios_base::goodbit;
  end = ng0.get(iss0.rdbuf(), 0, iss0, err, b0);
  VERIFY( err == ios_base::goodbit );
  VERIFY( b0 == true );
+ VERIFY( iss0.rdbuf()->chars_read() == 4);//after character 'e' (in == end)
should not be performed

  iss0.str("false");
  iss0.clear();
  err = ios_base::goodbit;
  end = ng0.get(iss0.rdbuf(), 0, iss0, err, b0);
  VERIFY( err == ios_base::goodbit );
  VERIFY( b0 == false );
+ VERIFY( iss0.rdbuf()->chars_read() == 5);
...
  iss2.str("1");
  iss2.setf(ios_base::boolalpha);
  err = ios_base::goodbit;
  end = ng2.get(iss2.rdbuf(), 0, iss2, err, b2);
  VERIFY( err == ios_base::goodbit );
  VERIFY( b2 == true );
+ VERIFY( iss2.rdbuf()->chars_read() == 1);
...
  iss3.str("");
  iss3.clear();
  b3 = true;
  err = ios_base::goodbit;
  end = ng3.get(iss3.rdbuf(), 0, iss3, err, b3);
  VERIFY( err == ios_base::failbit );
  VERIFY( b3 == false );
+ VERIFY( iss3.rdbuf()->chars_read() == 0);//stream should not be readed at all


-- 


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

[Bug c++/38022] [4.4 regression, g++] Incorrect warning with -Wshadow

[martin at mpa-garching dot mpg dot de]

--- Comment #4 from martin at mpa-garching dot mpg dot de  2008-11-06 06:59 
---
Thanks a lot for the explanation! I wasn't aware that things like
  int func (long foo, int (*fn)(int foo, char (*bar)[sizeof (foo)]));
were even allowed.


-- 


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

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[pault at gcc dot gnu dot org]

--- Comment #8 from pault at gcc dot gnu dot org  2008-11-06 06:24 ---
Wait until 4.5.0 since it needs the array descriptor reform to be fixed.

Unassigning self for present until we decide who will be responsible for the
work.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|pault at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[pault at gcc dot gnu dot org]

--- Comment #9 from pault at gcc dot gnu dot org  2008-11-06 06:26 ---
It helps to mark it correctly!


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED


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

[Bug fortran/35718] deallocating non-allocated pointer target does not fail

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2008-11-06 06:23 ---
Hold this one to 4.5 since it needs the array descriptor reform.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED


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

[Bug fortran/35820] internal compiler error with nested FORALL

[pault at gcc dot gnu dot org]

--- Comment #11 from pault at gcc dot gnu dot org  2008-11-06 06:19 ---
Mikael,

I'll assign this to you, since it needs to be marked as fixed or applied to 4.3
and marked as fixed - I forget which was agreed.

If you do not have a 4.3 tree up and running, I could do the honours for you.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mikael at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug rtl-optimization/38026] Miscompilation for CRIS of gfortran.dg/char_result_5.f95 with -fno-gcse

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-11-06 03:05 ---
Sure, it's fill_eager_delay_slots that moved the insn, but it's only acting on
a stray REG_DEAD note left over from cprop_hardreg.


-- 


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

[Bug rtl-optimization/38026] Miscompilation for CRIS of gfortran.dg/char_result_5.f95 with -fno-gcse

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-11-06 02:06 ---
No, it looks like (sigh) a delayed-branch bug; a delay-slot is filled with a
value from a forward branch clobbering the return value from a call. 


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |rtl-optimization


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

[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer

[linuxl4 at sohu dot com]

--- Comment #15 from linuxl4 at sohu dot com  2008-11-06 01:23 ---
really ?

my gcc is r141610

[~/tmp]$gcc -O2 -march=pentium4 -ftree-vectorize opsum.c 
../../../../src/mpi/coll/opsum.c: In function 'MPIR_SUM':
../../../../src/mpi/coll/opsum.c:21: internal compiler error: in
vectorizable_load, at tree-vect-transform.c:6675
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

linuxl4 at sohu dot com changed:

   What|Removed |Added

 CC||linuxl4 at sohu dot com


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

[Bug testsuite/38025] [4.4 Regression] gcc.target/spu/intrinsics-1.c test fails

[meissner at gcc dot gnu dot org]

--- Comment #3 from meissner at gcc dot gnu dot org  2008-11-05 23:47 
---
Subject: Bug 38025

Author: meissner
Date: Wed Nov  5 23:45:36 2008
New Revision: 141628

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141628
Log:
Fix PR 38025

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c


-- 


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

[Bug fortran/37992] ICE while resolving charlen for rejected statements

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2008-11-05 22:29 ---
The patch in http://gcc.gnu.org/ml/fortran/2008-11/msg00032.html works as
advertised without regression on i686-apple-darwin9 (note that it is not a
review!-).

Note also that there are other similar instances for which gfortran gives an
ICE after error messages and that are not fixed by the patch, see:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192#c6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744#c1


-- 


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

[Bug c++/38022] [4.4 regression, g++] Incorrect warning with -Wshadow

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-11-05 22:01 ---
I don't see any difference.  int (*fn) (int foo); declares a function pointer,
doesn't define a function, and how the argument is named also doesn't matter
much.  Only for:
int foo;
int baz (int foo)
{
  foo++;
}
the shadowing matters, but -Wshadow always warned even about parameter names
in prototypes and parameters of function pointers.  Actually, if you look at
PR37302, you can see that the warning might still make some sense when using
late return type or sizeof, typeof, alignof etc.
Consider:
int func (long foo, auto (*fn)(int foo) -> decltype (foo)); 
int bar (int);
void baz ()
{
  func(2, bar);
}
Here the shadowing, even inside of a prototype, matters a lot, if you change
int foo to int bar, then suddenly it won't compile, as bar doesn't return long.
And it makes sense to warn the user that he is shadowing the variable, because
it is unclear which foo was meant.
Or consider:
int func (long foo, int (*fn)(int foo, char (*bar)[sizeof (foo)]));
The same thing.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/38022] [4.4 regression, g++] Incorrect warning with -Wshadow

[martin at mpa-garching dot mpg dot de]

--- Comment #2 from martin at mpa-garching dot mpg dot de  2008-11-05 21:37 
---
> Why do you think this is a bug?

> -Wshadow warns even for:
> int foo;
> int (*fn) (int foo);

I'm probably missing something obvious here...

The first line in your example defines an integer variable called "foo"
The second line defines a function called "fn", which takes an integer argument
and returns an integer. The name of the integer argument of "fn" should have no
significance at all in the current scope, but only inside the body of "fn"
itself, correct?

In short, whether I write
int (*fn)(int foo);
or
int (*fn)(int bar);
or
int (*fn)(int);
should make no difference (as far as I understand C++, and I could certainly be
wrong ...)


-- 


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

[Bug c++/38022] [4.4 regression, g++] Incorrect warning with -Wshadow

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-11-05 21:28 ---
Why do you think this is a bug?

-Wshadow warns even for:
int foo;
int (*fn) (int foo);
and this is pretty much the same thing.
Before PR37302 G++ has been buggy and didn't declare parameters where it was
supposed to do.


-- 


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

[Bug c++/38022] [4.4 regression, g++] Incorrect warning with -Wshadow

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.4.0


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

[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-11-05 20:50 ---
Fixed on the trunk so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.2.4   |4.2.4 4.4.0
Summary|[4.3/4.4 Regression] Bogus  |[4.3 Regression] Bogus array
   |array bounds warning|bounds warning


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

[Bug middle-end/38028] [4.4 Regression] eh failures on spu-elf

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug testsuite/38025] [4.4 Regression] gcc.target/spu/intrinsics-1.c test fails

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug middle-end/37858] [4.3 Regression] ICE when "-fdump-ipa-all -dv" is used

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-11-05 20:40 ---
Subject: Bug 37858

Author: jakub
Date: Wed Nov  5 20:38:46 2008
New Revision: 141619

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141619
Log:
PR middle-end/37858
* passes.c (execute_one_pass): Don't look at cfun->curr_properties
for ipa and simple ipa passes.

* gcc.dg/pr37858.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr37858.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/passes.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/37924] [4.2/4.3 Regression] ice in smallest_mode_for_size, at stor-layout.c:219

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-11-05 20:46 ---
Fixed on 4.3 branch as well.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
  Known to work|4.1.2 4.4.0 |4.1.2 4.4.0 4.3.3


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

[Bug tree-optimization/37879] [4.3 Regression] ICE with "wrong" use of noreturn attribute and optimization

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-11-05 20:46 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37858] [4.3 Regression] ICE when "-fdump-ipa-all -dv" is used

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-11-05 20:45 ---
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=37858

[Bug middle-end/37870] [4.3 Regression] ICE in extract_bit_field_1

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-11-05 20:45 ---
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=37870

[Bug c/37924] [4.2/4.3 Regression] ice in smallest_mode_for_size, at stor-layout.c:219

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-11-05 20:44 ---
Subject: Bug 37924

Author: jakub
Date: Wed Nov  5 20:42:43 2008
New Revision: 141621

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141621
Log:
PR c/37924
* combine.c (make_compound_operation): Don't call make_extraction with
non-positive length.
(simplify_shift_const_1): Canonicalize count even if complement_p.

* gcc.c-torture/execute/pr37924.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr37924.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/combine.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/37879] [4.3 Regression] ICE with "wrong" use of noreturn attribute and optimization

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-11-05 20:41 ---
Subject: Bug 37879

Author: jakub
Date: Wed Nov  5 20:39:50 2008
New Revision: 141620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141620
Log:
PR tree-optimization/37879
* predict.c (tree_estimate_probability): Check if last_stmt is
non-NULL before dereferencing it.

* gcc.dg/pr37879.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr37879.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/predict.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug ada/37945] GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2008-11-05 20:38 ---
Please commit to 4.3 branch.  Not needed on trunk since it uses a different
implementation of these files.

2008-11-05  Joel Sherrill <[EMAIL PROTECTED]>

  * g-socthi-rtems.ad[sb]: New files.
  * Makefile.in: Add RTEMS specific files.


-- 

joel 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-11-05 20:38:03
   date||


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

[Bug ada/37945] GNAT Sockaddr and Sockaddr_In does not match c-structures on RTEMS

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2008-11-05 20:35 ---
Created an attachment (id=16626)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16626&action=view)
adds RTEMS specific g-socthi*

Fixes issue.  Not needed on head.


-- 


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

[Bug middle-end/37870] [4.3 Regression] ICE in extract_bit_field_1

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-11-05 20:35 ---
Subject: Bug 37870

Author: jakub
Date: Wed Nov  5 20:33:54 2008
New Revision: 141618

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141618
Log:
PR middle-end/37870
* expmed.c (extract_bit_field_1): If int_mode_for_mode returns
BLKmode for non-memory, convert using a wider MODE_INT mode
or through memory.

* gcc.target/i386/pr37870.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr37870.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/expmed.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug testsuite/38025] [4.4 Regression] gcc.target/spu/intrinsics-1.c test fails

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-11-05 20:31 ---
Yes this is only a testcase issue.  The new note was introduced by PR 30949.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|target  |testsuite
 Ever Confirmed|0   |1
   GCC host triplet|powerpc64-unknown-linux-gnu |
   Last reconfirmed|-00-00 00:00:00 |2008-11-05 20:31:29
   date||
Summary|gcc.target/spu/intrinsics-  |[4.4 Regression]
   |1.c test fails  |gcc.target/spu/intrinsics-
   ||1.c test fails
   Target Milestone|--- |4.4.0


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

[Bug middle-end/38028] [4.4 Regression] eh failures on spu-elf

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/38028] New: [4.4 Regression] eh failures on spu-elf

[pinskia at gcc dot gnu dot org]

Between revision 141329 and 141589, we are getting some eh failures on spu-elf:

+FAIL: g++.dg/compat/eh/ctor1 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
+FAIL: g++.dg/compat/eh/ctor2 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
+FAIL: g++.dg/compat/eh/new1 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
+FAIL: g++.dg/compat/init/array5 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
+FAIL: g++.dg/eh/ctor1.C execution test
+FAIL: g++.dg/eh/ctor2.C execution test
+FAIL: g++.dg/eh/new1.C execution test
+FAIL: g++.dg/eh/spbp.C execution test
+FAIL: g++.dg/init/array5.C execution test
+FAIL: g++.dg/init/ctor1.C execution test
+FAIL: g++.old-deja/g++.eh/fntry1.C execution test
+FAIL: g++.old-deja/g++.eh/rethrow3.C execution test
+FAIL: g++.old-deja/g++.eh/vbase1.C execution test
+FAIL: g++.old-deja/g++.eh/vbase2.C execution test
+FAIL: g++.old-deja/g++.mike/eh16.C execution test
+FAIL: g++.old-deja/g++.mike/eh17.C execution test
+FAIL: g++.old-deja/g++.mike/eh39.C execution test
+FAIL: g++.old-deja/g++.mike/eh40.C execution test
+FAIL: g++.old-deja/g++.mike/eh41.C execution test
+FAIL: g++.old-deja/g++.other/new7.C execution test
+FAIL: g++.old-deja/g++.other/vbase2.C execution test

But the eh tests for Objective-C work ...


-- 
   Summary: [4.4 Regression] eh failures on spu-elf
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: spu-elf


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

[Bug other/32263] Document the required versions of glibc and binutils

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2008-11-05 20:11 ---
(In reply to comment #7)
> A "known working version" list seems very simple to maintain.
Again this is not really a GCC question.  As mentioned before the requirements
of GCC itself is almost nothing.  It is question for glibc to keep the list of
required versions of GCC which can compile that version of glibc and not really
up to us to keep that list.


-- 


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

[Bug fortran/38024] possibly syntax erros with Fortran 95

[kargl at gcc dot gnu dot org]

--- Comment #6 from kargl at gcc dot gnu dot org  2008-11-05 19:49 ---
Yang has acknowledge that a syntax error was present in the code.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/35769] inappropriate FORALL error

[mikael at gcc dot gnu dot org]

--- Comment #2 from mikael at gcc dot gnu dot org  2008-11-05 19:43 ---
This was fixed by Paul in his patch for PR37445. 
Assigning to him.


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c++/38027] bitfields and -O2 or greater

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-11-05 19:36 ---
Works with 4.3.2.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.3.0 4.3.1
  Known to work||4.2.4 4.3.2
 Resolution||FIXED
   Target Milestone|--- |4.3.2


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

[Bug fortran/38024] possibly syntax erros with Fortran 95

[successful dot jiang at gmail dot com]

--- Comment #5 from successful dot jiang at gmail dot com  2008-11-05 19:34 
---
hi there,

thanks for your reply.
i just solve it out as kargl said.

DATA is a type of pointer that points to my defined TYPE data structure.

thanks


-- 


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

[Bug c++/38027] New: bitfields and -O2 or greater

[john dot spelis at 3dlabs dot com]

The following program when compiled with gcc 4.1.2 works but with 4.3.0 it 
produces incorrect output at optimisation level O2 or greater.

 / * -- */

#include 
#include 
using namespace std;

typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;

class CColourARGB;

class CColourARGB
{
public :
union
{
struct
{
uint32_t mBlue  : 8;
uint32_t mGreen : 8;
uint32_t mRed   : 8;
uint32_t mAlpha : 8;
} mBits;
uint32_t mWord;
} mCol;
CColourARGB(const CColourARGB &rhs);
};

class CColourARGB
{
public :
union
{
struct
{
uint16_t mBlue  : 4;
uint16_t mGreen : 4;
uint16_t mRed   : 4;
uint16_t mAlpha : 4;
} mBits;

uint16_t mWord;
} mCol;

public :
/// CColourARGB constructor
CColourARGB(const uint8_t &alpha, const uint8_t &red, const uint8_t
&green, const uint8_t &blue)
{ mCol.mBits.mAlpha = alpha; mCol.mBits.mRed = red; mCol.mBits.mGreen =
green; mCol.mBits.mBlue = blue; }

};

__inline CColourARGB::CColourARGB(const CColourARGB &rhs)
{
mCol.mBits.mRed   = ((rhs.mCol.mBits.mRed << 4) & 0xF0) |
rhs.mCol.mBits.mRed;
mCol.mBits.mGreen = ((rhs.mCol.mBits.mGreen << 4) & 0xF0) |
rhs.mCol.mBits.mGreen;
mCol.mBits.mBlue  = ((rhs.mCol.mBits.mBlue << 4) & 0xF0) |
rhs.mCol.mBits.mBlue;
mCol.mBits.mAlpha = ((rhs.mCol.mBits.mAlpha << 4) & 0xF0) |
rhs.mCol.mBits.mAlpha;
printf("Constructing CColourARGB %x from CColourARGB %x\n",
mCol.mWord, rhs.mCol.mWord);
}

void broken()
{
for (uint8_t y = 0; y < 4; ++y) {
for (uint8_t x = 0; x < 4; ++x) {
CColourARGB c4(0xF, x, y, 0);
CColourARGB c8(c4);
}
}
}

CColourARGB myfoo(uint8_t XT, uint8_t YT) {
return CColourARGB(0xF, XT, YT, 0);
}

void ok()
{
for (uint8_t y = 0; y < 4; ++y) {
for (uint8_t x = 0; x < 4; ++x) {
CColourARGB c4 = myfoo(x, y);
CColourARGB c8(c4);
}
}
}

int main()
{
printf("this\n");
ok();
printf("that\n");
broken();
}

/* --- end --- */

When not working the bit fields have not been updated, e.g. a broken case
output is;

Constructing CColourARGB ff00 from CColourARGB f330

When working the output has updated bitfields, e.g.

Constructing CColourARGB ff00 from CColourARGB f330


-- 
   Summary: bitfields and -O2 or greater
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug fortran/38024] possibly syntax erros with Fortran 95

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2008-11-05 18:57 ---
(In reply to comment #2)
> Data is a fortran keyword.

Fortran has no reserved keyword system like C, you can happily define variables
with names such as PRINT, INTEGER, DO, etc. (Though I suggest not to name a
variable [e.g.] INTEGER as this can cause a lot of confusion.)

(In reply to comment #0)
> what is the syntax from? is it wrong usage of continuation '&'??

It is difficult to tell without more information. It depends

a) On the definition of DATA
b) It might depend on the next line

I think that your are missing a line such as

   TYPE(my_type) DATA

But without having more information, it is impossible to tell whether that is
the problem or not.


-- 


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

[Bug fortran/37992] ICE while resolving charlen for rejected statements

[mikael at gcc dot gnu dot org]

--- Comment #8 from mikael at gcc dot gnu dot org  2008-11-05 18:47 ---
Patch here:
http://gcc.gnu.org/ml/fortran/2008-11/msg00032.html


-- 


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

[Bug target/38016] [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.2.5   |4.3.3


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

[Bug target/38016] [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2008-11-05 18:30 ---
Fixed, see .


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/37971] [4.2/4.3/4.4 Regression] Rejects default argument that is a template via access failure

[mmitchel at gcc dot gnu dot org]

--- Comment #5 from mmitchel at gcc dot gnu dot org  2008-11-05 18:28 
---
The problem is this:

* We cannot do the full conversion at the point of parsing the default argument
because that may require creation of temporary variables and such.  So, in
check_default_arg we call can_convert.  But, whether a conversion is possible
or not does not check access because the standard says that access control has
no affect on conversion.

* Later, in covert_default_arg, we do the actual conversion, which triggers an
access-control check.

For default arguments, we need to perform the check in the first case, but not
the second.  So, we will need an additional flag to the conversion routines to
indicate that.


-- 


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

[Bug target/38026] Miscompilation for CRIS of gfortran.dg/char_result_5.f95 with -fno-gcse

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-11-05 18:27:32
   date||


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

[Bug target/38026] New: Miscompilation for CRIS of gfortran.dg/char_result_5.f95 with -fno-gcse

[hp at gcc dot gnu dot org]

To repeat, run gfortran.dg/char_result_5.f95 from th 4.3-branch with -fno-gcse.
In the gcc objdir:
make check-fortran 'RUNTESTFLAGS=--target_board=cris-sim/-fno-gcse
dg.exp=char_result_5.f90'

Observe:
Using /tmp/hpautotest-gcc43/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /tmp/hpautotest-gcc43/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/char_result_5.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/char_result_5.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test

with gfortran.log saying for both FAILs:
PASS: gfortran.dg/char_result_5.f90  -O3 -fomit-frame-pointer -funroll-loops 
(test for excess errors)
Operating system error: Illegal seek^M
Memory allocation failed^M
FAIL: gfortran.dg/char_result_5.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test

I'm guessing a target-bug, exposed by -fno-gcse.


-- 
   Summary: Miscompilation for CRIS of gfortran.dg/char_result_5.f95
with -fno-gcse
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug target/38016] [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse

[hp at gcc dot gnu dot org]

--- Comment #5 from hp at gcc dot gnu dot org  2008-11-05 18:12 ---
Subject: Bug 38016

Author: hp
Date: Wed Nov  5 18:11:15 2008
New Revision: 141617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141617
Log:
PR target/38016
* gcc.c-torture/execute/ieee/pr38016.c,
gcc.c-torture/execute/ieee/pr38016.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/ieee/pr38016.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/ieee/pr38016.x
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/38016] [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2008-11-05 18:11 ---
Subject: Bug 38016

Author: hp
Date: Wed Nov  5 18:10:36 2008
New Revision: 141616

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141616
Log:
PR target/38016
* config/cris/cris.c (cris_order_for_addsi3): Test for !REG_P, not
just MEM_P.

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


-- 


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

[Bug target/38016] [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2008-11-05 18:08 ---
Subject: Bug 38016

Author: hp
Date: Wed Nov  5 18:06:45 2008
New Revision: 141615

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141615
Log:
PR target/38016
* gcc.c-torture/execute/ieee/pr38016.c,
gcc.c-torture/execute/ieee/pr38016.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/ieee/pr38016.c
trunk/gcc/testsuite/gcc.c-torture/execute/ieee/pr38016.x
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/38016] [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-11-05 18:06 ---
Subject: Bug 38016

Author: hp
Date: Wed Nov  5 18:04:36 2008
New Revision: 141614

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141614
Log:
PR target/38016
* config/cris/cris.c (cris_order_for_addsi3): Test for !REG_P, not
just MEM_P.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/cris/cris.c


-- 


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

[Bug target/38025] gcc.target/spu/intrinsics-1.c test fails

[uweigand at gcc dot gnu dot org]

--- Comment #1 from uweigand at gcc dot gnu dot org  2008-11-05 18:04 
---
The test case tests for expected failures.  It seems there is now an additional
message being output:

/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:13:
warning: passing argument 2 of ‘__builtin_spu_cmpgt_11’ makes integer from
pointer without a cast
/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:13:
note: expected ‘int’ but argument is of type ‘int *’

The testcase checks for the "makes integer from pointer" error, but does not
expect the additional "note".


-- 


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

[Bug target/38025] New: gcc.target/spu/intrinsics-1.c test fails

[gnu at the-meissners dot org]

The testsuite gcc.target/spu/intrinsics-1.c fails with a compilation error:
/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c: In
function ‘f’:
/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:12:
error: parameter list does not match a valid signature for spu_cmpgt()
/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:13:
warning: passing argument 2 of ‘__builtin_spu_cmpgt_11’ makes integer from
pointer without a cast
/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:13:
note: expected ‘int’ but argument is of type ‘int *’
/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:14:
error: parameter list does not match a valid signature for spu_cmpgt()
/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:16:
note: use -flax-vector-conversions to permit conversions between vectors with
differing element types or numbers of subparts
/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:16:
error: incompatible types when assigning to type ‘int __vector__’ from type
‘unsigned int __vector__’


-- 
   Summary: gcc.target/spu/intrinsics-1.c test fails
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at the-meissners dot org
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: spu-elf


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

[Bug fortran/38024] possibly syndax erros with Fortran 95

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2008-11-05 17:26 ---
(In reply to comment #2)
> (In reply to comment #1)
> > what is the syntax from? is it wrong usage of continuation '&'??
> The error position is signaled by the <1> marker. 
> Data is a fortran keyword. 
> I suggest you change your variable name. 

I doubt that that is the problem because Fortran (as you know)
does not have reserved keywords.  

Yang, we need to know the version of gfortran that you are using.
Try 'gfortran --version'.  It would also be helpful if you can
attach either a reduced testcase or the code that demonstrates
the problem.

I suspect that the file is using fixed-form source code and the
& is beyond column 72.

Hmmm, on closer inspection it appears you have a missing /).
You have (/D1, but no closing /). 

NODE(ATAN2(VA,VB),(/D1/(VB*V),-VA/(VB**2*V),(/Y%P,X%P/))


-- 


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

[Bug c/10676] Using unnamed fields in initializers

[josh at freedesktop dot org]

--- Comment #8 from josh at freedesktop dot org  2008-11-05 17:21 ---
How can I update the "last confirmed" date to today?


-- 


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

[Bug c/10676] Using unnamed fields in initializers

[josh at freedesktop dot org]

--- Comment #7 from josh at freedesktop dot org  2008-11-05 17:20 ---
Still happens with GCC 4.3.2:

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --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.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1) 


-- 


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

[Bug c/10676] Using unnamed fields in initializers

[josh at freedesktop dot org]

--- Comment #6 from josh at freedesktop dot org  2008-11-05 17:19 ---
*** Bug 38019 has been marked as a duplicate of this bug. ***


-- 

josh at freedesktop dot org changed:

   What|Removed |Added

 CC||josh at freedesktop dot org


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

[Bug c/38019] Cannot use nested designated initializer with unnamed inner aggregate

[josh at freedesktop dot org]

--- Comment #3 from josh at freedesktop dot org  2008-11-05 17:19 ---
Sigh.  Yes, I get the same set of errors.  I seem to have managed to copy and
paste the wrong set of messages.

This does indeed look like a duplicate of bug 10676.  Marking as such.

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


-- 

josh at freedesktop dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/38024] possibly syndax erros with Fortran 95

[mikael at gcc dot gnu dot org]

--- Comment #2 from mikael at gcc dot gnu dot org  2008-11-05 17:17 ---
(In reply to comment #1)
> what is the syntax from? is it wrong usage of continuation '&'??
The error position is signaled by the <1> marker. 
Data is a fortran keyword. 
I suggest you change your variable name. 


-- 


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

[Bug fortran/38024] New: possibly syndax erros with Fortran 95

[successful dot jiang at gmail dot com]

Hi there,

what is the syntax from? is it wrong usage of continuation '&'??

[EMAIL PROTECTED]:~/HSL$ gfortran HSL_AD02_FORWARD_DOUBLE.F95
HSL_AD02_FORWARD_DOUBLE.F95:5594.12:

DATA%GRAPH(DATA%NUM_NODES) = NODE(ATAN2(VA,VB),(/D1/(VB*V),-VA/(VB**2 & 
   1
Error: Syntax error in DATA statement at (1)



The original source code is that,

DATA%GRAPH(DATA%NUM_NODES) = NODE(ATAN2(VA,VB),(/D1/(VB*V),-VA/(VB**2 & 
  *V),(/Y%P,X%P/))

It is F95 free format file, and do I use the continuation '&' in a wrong way??

THanks a lot.
cheers.


-- 
   Summary: possibly syndax erros with Fortran 95
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: successful dot jiang at gmail dot com
  GCC host triplet: possibly syndax erros with Fortran 95(gfortran)


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

[Bug fortran/37992] ICE while resolving charlen for rejected statements

[mikael at gcc dot gnu dot org]

--- Comment #7 from mikael at gcc dot gnu dot org  2008-11-05 17:02 ---
(In reply to comment #6)
> It should not be necessary to do anything to the cl_list.  As long as nothing
> points to a member, it can do nothing and gets cleaned up at the end of
> compilation. The reason for this is that any number, including zero, of
> typespecs can point to it, so it is very risky to delete a cl_list member.
Yes, but as we remove elements in the reject_statement function, any typespec
pointing to it should have been released already (as long as we remove new
elements only).
Patch coming. I don't know why it didn't work the first time. 
> 
> Paul
> 
> Paul
> 
No need to insist, we know it's you :p

This is not a regression, I have this failing as well with 4.3.2:
 function foo(x)
   integer :: x
   character(len=10) :: y
   character(len=len(y)) :: foo,x
 end function foo

Changing summary, from:
[4.4 Regression] ICE segfault for "character(len=len(x)) :: foo,x"
to:
ICE while resolving charlen for rejected statements


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4 Regression] ICE|ICE while resolving charlen
   |segfault for|for rejected statements
   |"character(len=len(x)) ::   |
   |foo,x"  |


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

[Bug c/38023] isinfl(-inf) returns 1

[grxnprzn at gmx dot net]

--- Comment #2 from grxnprzn at gmx dot net  2008-11-05 17:02 ---
(In reply to comment #1)
> NOTE
>Note  that these functions are obsolete. C99 defines macros isfinite(),
>isinf() and isnan() (for all types) replacing them.  Further note  that
>the C99 isinf() has weaker guarantees on the return value.
> 
> 
> *** This bug has been marked as a duplicate of 31175 ***
> 

Ok, I can use isinf() on the systems that support it and use isinfl() on the
others.

But, IMHO, "obsolete" does not mean "may be broken by the compiler". GCC4.0
calls the system's isinfl(), which works, while GCC 4.3 provides an inlined
version of isinfl() which returns wrong results. That's a bug, isn't it?


-- 


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

[Bug fortran/38024] possibly syndax erros with Fortran 95

[successful dot jiang at gmail dot com]

--- Comment #1 from successful dot jiang at gmail dot com  2008-11-05 16:58 
---
Hi there,

what is the syntax from? is it wrong usage of continuation '&'??

[EMAIL PROTECTED]:~/HSL$ gfortran HSL_AD02_FORWARD_DOUBLE.F95
HSL_AD02_FORWARD_DOUBLE.F95:5594.12:

DATA%GRAPH(DATA%NUM_NODES) = NODE(ATAN2(VA,VB),(/D1/(VB*V),-VA/(VB**2 & 
   1
Error: Syntax error in DATA statement at (1)



The original source code is that,

DATA%GRAPH(DATA%NUM_NODES) = NODE(ATAN2(VA,VB),(/D1/(VB*V),-VA/(VB**2 & 
  *V),(/Y%P,X%P/))

It is F95 free format file, and do I use the continuation '&' in a wrong way??

THanks a lot.
cheers.


-- 


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

[Bug c/38023] isinfl(-inf) returns 1

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-11-05 16:20 ---
NOTE
   Note  that these functions are obsolete. C99 defines macros isfinite(),
   isinf() and isnan() (for all types) replacing them.  Further note  that
   the C99 isinf() has weaker guarantees on the return value.


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


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/31175] isinf incorrectly expanded

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2008-11-05 16:20 ---
*** Bug 38023 has been marked as a duplicate of this bug. ***


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||grxnprzn at gmx dot net


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

[Bug fortran/37644] compiler Segmentation fault

[rlnaff at usgs dot gov]

--- Comment #6 from rlnaff at usgs dot gov  2008-11-05 16:14 ---
Subject: Re:  compiler Segmentation fault

I installed version 4.3.2  for this test; it was what was available at 
the time:

(bash) stoch.pts/10% ls -l /z/stoch/home/rlnaff/usr/local/bin/gfortran4.3.2
-rwxr-xr-x 2 rlnaff users 473210 2008-09-24 13:05 
/z/stoch/home/rlnaff/usr/local/bin/gfortran4.3.2*

(bash) stoch.pts/10% export 
LAMHF77=/z/stoch/home/rlnaff/usr/local/bin/gfortran4.3.2
(bash) stoch.pts/10% mpif77 -c -fopenmp reorder_parent.f90
reorder_parent.f90:470: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


I didn't have access to 4.4.0

R. Naff

burnus at gcc dot gnu dot org wrote:
> --- Comment #4 from burnus at gcc dot gnu dot org  2008-11-05 07:03 
> ---
> I can reproduce the ICE (seg. fault) with 4.3.x, but not with 4.4.0
>
>
>   


-- 


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

[Bug fortran/37644] compiler Segmentation fault

[rlnaff at usgs dot gov]

--- Comment #5 from rlnaff at usgs dot gov  2008-11-05 16:08 ---
Subject: Re:  compiler Segmentation fault

Compiled with gfortran 4.3.2


(bash) stoch.pts/10% export 
LAMHF77=/z/stoch/home/rlnaff/usr/local/bin/gfortran4.3.2
(bash) stoch.pts/10% mpif77 -c -fopenmp reorder_parent.f90
reorder_parent.f90:470: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



kargl at gcc dot gnu dot org wrote:
> --- Comment #3 from kargl at gcc dot gnu dot org  2008-11-05 04:10 ---
> Can you attach the code instead of embedded in a message?  
>
> It's a PITA to strip out HTML from your code when I save it as a file.
>
>
>   

module common_parameters
  implicit none
  ! OMPI? include '/usr/include/mpif.h'
  ! include 'mpif.h'
  ! ... kv: precision of variables used in assembly
  integer, parameter :: kv=selected_real_kind(p=10)
  ! ... common numbers
  real(kind=kv), parameter :: n0=0.0_kv, n1=1.0_kv, n2=2.0_kv, n3=3.0_kv, &
   n4=4.0_kv, n5=5.0_kv, n6=6.0_kv, n7=7.0_kv, n8=8.0_kv, n9=9.0_kv, &
   n10=10.0_kv, n100=100.0_kv
  ! ... common fractions
  real(kind=kv), parameter :: f2=0.5_kv, f3=n1/n3, f4=0.25_kv, f5=0.2_kv, &
   f6=n1/n6, f7=n1/n7, f8=0.125_kv, f9=n1/n9, f10=0.1_kv
  ! ... machine smallest number
  real(kind=kv), parameter :: machine_epsilon=epsilon(n0)
  real(kind=kv), parameter :: small=n100*machine_epsilon
  real(kind=kv), save :: MZ=tiny(n0)
  ! ... interim print
  character(len=32) :: file_name
  integer :: interim_print, data_print
end module common_parameters



! ... File shared_common_parent.f90
! ...
! ... Version last modified: R.L. Naff, 07/06
! ... Purpose: Allow for the transfer of information between modules
! ... and subroutines of "parent" type.
! ...
! ... Utilization: use "module name"
! ...
! ... Modules herein:
! ...   common_input_types_parent
! ...   common_partition_types_parent
! ...   common_MPI_types_parent
! ...   

module common_input_types_parent
  use common_parameters
  implicit none
  integer :: n_x, n_y, n_z
end module common_input_types_parent

module common_partition_types_parent
  use common_parameters
  implicit none
  integer, save :: max_part, npx, npy, npz
  integer, save :: ind_rot_rn, dim, no_rows
  integer, save :: tot_variables
  integer, save :: no_partitions, red_count, max_C
  integer, save :: red_part_count, red_node_count, black_node_count
  integer, save :: max_nodes_A, max_nx, max_ny, max_nz
  ! ... arrays
  integer, dimension(:), allocatable :: perm_p, inv_perm_p
  integer, dimension(:), allocatable :: part_end
  integer, dimension(:), allocatable :: perm
end module common_partition_types_parent

module common_reorder_types_parent
  use common_parameters
  implicit none
  integer, dimension(:), allocatable, target :: ii_1, ii_2, ii_3
  real(kind=kv), dimension(:), allocatable, target :: C1, C2, C3, &
 CC_1, CC_2, CC_3, coef
end module common_reorder_types_parent

module common_MPI_types_parent
  integer :: pc_intracomm, pc_intra_root
end module common_MPI_types_parent

module reorder_parent
  ! ... Version last modified: R.L. Naff, 02/07
  ! ... Purpose: reorder stiffness coefficients into partitions and 
  ! ... send coefficients to children (slaves).
  ! ...
  ! ... Subroutines herein:
  ! ...   subroutine AC_reorder
  ! ... Called from subroutine MS_PCG_solve, module MS_PCG_parent
  ! ... Sends or BCasts to Child: coef, C1, C2, C3, 
  ! ...   CC_1, CC_2, CC_3 (surrogates for hcoef, C_x, C_y, C_z 
  ! ...   and part_con arrays).
  ! ...
  ! ...
  use omp_lib
  use common_parameters
  use common_input_types_parent
  ! ... n_x, n_y, n_z
  use common_partition_types_parent
  use common_reorder_types_parent
  use common_MPI_types_parent
  !tmp use utilities_parent
  !tmp use error_handler
  ! ... pointer arrays holding incoming coefficients
  real, save, pointer, dimension(:) :: Cii, Cjj, Ckk, hcoef
  ! ... Arrays pointed in MS_PCG_solve
  ! ...
contains

  subroutine AC_reorder(i_bound, ib0_count)
! ... Based on domain partitioning, rearrange coefficients and 
! ... assign to a process.
! ...
! ... Argument list
! ...
integer, intent(out) :: ib0_count
integer, dimension(:), intent(in) :: i_bound
! ...
! ... local variables
! ...
integer :: p, i, j, k, ii, jj, kk, i_org, xyz_loc
integer :: i_1, i_2, i_3, np1, np2, np3
integer :: d_1s, d_2s, d_3s, i_range=range(n1)
integer :: n_1, n_2, n_3, d_1, d_2, d_3
integer :: node, row_ct, level_ct, A_nodes
integer :: pn_count, ls1, ls2, ls3, e_1, e_2, e_3
integer :: ierr, error, tag_out, a_size
integer :: i11, i22, i33, int_real_type
integer, dimension(1:3) :: C_count
integer, pointer, dimension(:) :: I_point
real(kind=kv) :: C11, C22, C33, t_num
real :: one=1.0, neg_one=-1.0
real(kind=kv), pointer, dimension(:) :: R_point
character(len=64) :: err_loc_me

[Bug middle-end/37861] [4.3/4.4 Regression] Bogus array bounds warning

[jamborm at gcc dot gnu dot org]

--- Comment #6 from jamborm at gcc dot gnu dot org  2008-11-05 16:08 ---
Subject: Bug 37861

Author: jamborm
Date: Wed Nov  5 16:06:38 2008
New Revision: 141613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141613
Log:
2008-11-05  Martin Jambor  <[EMAIL PROTECTED]>

PR middle-end/37861
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Don't turn
pointer arithmetics into array_ref if the array is accessed
through an indirect_ref.
* testsuite/gcc.dg/Warray-bounds-5.c: New file.
* testsuite/gcc.dg/Warray-bounds-6.c: New file.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-5.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c


-- 


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

[Bug c/38023] New: isinfl(-inf) returns 1

[grxnprzn at gmx dot net]

isinfl(-inf) should return -1. This worked with GCC 4.0.
With GCC 4.3, the return value is 1.

The follwing code can be used to reproduce the error:

#include 
#include 

int main()
{
   long double value1 = -1/0.0; //HUGE_VALL;
   int rc = isinfl(value1);
   printf("value1: %Lf isinfl(value1)=%d\n", value1, rc );
   return 0;
}


-- 
   Summary: isinfl(-inf) returns 1
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grxnprzn at gmx dot net
 GCC build triplet: i586-suse-linux
  GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux


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

[Bug fortran/35219] zdotu (copy of BLAS version) works in x86, x86_64, segfaults in arm.

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-11-05 15:49 ---
Subject: Bug 35219

Author: jason
Date: Wed Nov  5 15:48:01 2008
New Revision: 141612

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141612
Log:
PR c++/35219
* cp-tree.h: Fix DECL_NONSTATIC_MEMBER_P to handle member template
functions.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected

[dje at gcc dot gnu dot org]

--- Comment #38 from dje at gcc dot gnu dot org  2008-11-05 15:45 ---
I think the AIX testsuite problem is a problem with the testsuite harness.  If
I compile a trivial Java program with gcj, it works.  If I manually compile
programs from libjava.lang testsuite, they work.  If I manually run the
testsuite executables built by the testsuite, they work.  But the testsuite
reports that execution fails.  Where is libjava_load defined?


-- 


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

[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected

[ro at techfak dot uni-bielefeld dot de]

--- Comment #37 from ro at techfak dot uni-bielefeld dot de  2008-11-05 
15:07 ---
Subject: Re:  [4.4 Regression] libgcj linkage failure: Incorrect library ABI
version detected

aph at redhat dot com writes:

> Feel free to CC me with any of these.

Thanks.  A considerable number of them was already reported as PR
target/4.

Rainer


-- 


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

[Bug target/35574] [4.4 Regression] unrecognizable insn generated for vector move

[kazu at gcc dot gnu dot org]

--- Comment #6 from kazu at gcc dot gnu dot org  2008-11-05 14:48 ---
Posted another revised patch.  See the patch URL above.


-- 

kazu at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2008-   |patches/2008-
   |10/msg00787.html|11/msg00163.html


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

[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-11-05 14:32 ---
The updated patch is at

http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00130.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2008-   |patches/2008-
   |10/msg00724.html|11/msg00130.html


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

[Bug c++/38022] New: [4.4 regression] Incorrect warning with -Wshadow

[martin at mpa-garching dot mpg dot de]

Consider the following one-liner:

int func(int foo, int (*fn)(int foo));

Current g++ complains about shadowing, which seems incorrect to me:
~/tmp>g++ -c -W -Wall -Wshadow bug.cc
bug.cc:1: warning: declaration of 'int foo' shadows a parameter
bug.cc:1: warning: shadowed declaration is here

Curiously, no warning is generated by g++ 4.3.
gcc 4.4 and 4.3 don't produce the warning either.


-- 
   Summary: [4.4 regression] Incorrect warning with -Wshadow
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected

[aph at redhat dot com]

--- Comment #36 from aph at redhat dot com  2008-11-05 14:02 ---
Subject: Re:  [4.4 Regression] libgcj linkage failure: Incorrect
 library ABI version detected

ro at techfak dot uni-bielefeld dot de wrote:

> After rebuilding jc1 and rerunning the libjava testsuite on
> alpha-dec-osf5.1b, I'm back at the same set of testsuite failures that I
> had on 20080313.

Feel free to CC me with any of these.

Andrew.


-- 


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

[Bug fortran/37992] [4.4 Regression] ICE segfault for "character(len=len(x)) :: foo,x"

[mikael at gcc dot gnu dot org]

-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mikael at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-11-01 22:42:53 |2008-11-05 14:02:04
   date||


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

[Bug c/38019] Cannot use nested designated initializer with unnamed inner aggregate

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2008-11-05 13:47 ---
Subject: Re:  Cannot use nested designated initializer with
 unnamed inner aggregate

On Wed, 5 Nov 2008, rguenth at gcc dot gnu dot org wrote:

> I get
> 
> t.c: In function 'vec_add':
> t.c:10: error: unknown field 'x' specified in initializer
> t.c:11: error: unknown field 'y' specified in initializer
> t.c:11: warning: excess elements in union initializer
> t.c:11: warning: (near initialization for '(anonymous)')
> t.c:12: error: unknown field 'z' specified in initializer
> t.c:12: warning: excess elements in union initializer
> t.c:12: warning: (near initialization for '(anonymous)')
> 
> instead.

That matches bug 10676.


-- 


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

[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected

[ro at techfak dot uni-bielefeld dot de]

--- Comment #35 from ro at techfak dot uni-bielefeld dot de  2008-11-05 
13:40 ---
Subject: Re:  [4.4 Regression] libgcj linkage failure: Incorrect library ABI
version detected

jakub at gcc dot gnu dot org writes:

> This bug seems to be fixed then, if there are unrelated AIX or HPUX libjava
> testsuite failures, please file separate bugs for them.

After rebuilding jc1 and rerunning the libjava testsuite on
alpha-dec-osf5.1b, I'm back at the same set of testsuite failures that I
had on 20080313.

Rainer


-- 


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

[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c

[dominiq at lps dot ens dot fr]

--- Comment #11 from dominiq at lps dot ens dot fr  2008-11-05 13:29 ---
Could somebody check if the following changes are OK?

diff -u ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-14.c
gcc/testsuite/gcc.dg/visibility-14.c
--- ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-14.c  2008-08-19
18:11:26.0 +0200
+++ gcc/testsuite/gcc.dg/visibility-14.c2008-11-05 14:17:04.0
+0100
@@ -1,7 +1,7 @@
 /* Test that called external functions are marked. */
 /* { dg-do compile } */
 /* { dg-require-visibility "" } */
-/* { dg-final { scan-hidden "foo" } } */
+/* { dg-final { scan-hidden "foo" { target !*-apple-darwin* } } } */

 extern void foo(void) __attribute__ ((visibility ("hidden")));
 int f () {
diff -u ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-15.c
gcc/testsuite/gcc.dg/visibility-15.c
--- ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-15.c  2008-08-19
18:11:25.0 +0200
+++ gcc/testsuite/gcc.dg/visibility-15.c2008-11-05 14:20:25.0
+0100
@@ -1,7 +1,7 @@
 /* Test that accessed external functions are marked. */
 /* { dg-do compile } */
 /* { dg-require-visibility "" } */
-/* { dg-final { scan-hidden "foo" } } */
+/* { dg-final { scan-hidden "foo" { target !*-apple-darwin* } } } */

 extern void foo(void) __attribute__ ((visibility ("hidden")));
 typedef void (*foo_t)(void);
diff -u ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-16.c
gcc/testsuite/gcc.dg/visibility-16.c
--- ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-16.c  2008-08-19
18:11:26.0 +0200
+++ gcc/testsuite/gcc.dg/visibility-16.c2008-11-05 14:20:42.0
+0100
@@ -1,7 +1,7 @@
 /* Test that accessed external variables are marked. */
 /* { dg-do compile } */
 /* { dg-require-visibility "" } */
-/* { dg-final { scan-hidden "foo" } } */
+/* { dg-final { scan-hidden "foo" { target !*-apple-darwin* } } } */

 extern int foo __attribute__ ((visibility ("hidden")));
 int f () {
diff -u ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-17.c
gcc/testsuite/gcc.dg/visibility-17.c
--- ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-17.c  2008-08-19
18:11:25.0 +0200
+++ gcc/testsuite/gcc.dg/visibility-17.c2008-11-05 14:20:59.0
+0100
@@ -1,7 +1,7 @@
 /* Test that external variable whose address is taken are marked. */
 /* { dg-do compile } */
 /* { dg-require-visibility "" } */
-/* { dg-final { scan-hidden "foo" } } */
+/* { dg-final { scan-hidden "foo" { target !*-apple-darwin* } } } */

 extern int foo __attribute__ ((visibility ("hidden")));
 int *f () {
diff -u ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-18.c
gcc/testsuite/gcc.dg/visibility-18.c
--- ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-18.c  2008-08-19
18:11:27.0 +0200
+++ gcc/testsuite/gcc.dg/visibility-18.c2008-11-05 14:21:11.0
+0100
@@ -1,7 +1,7 @@
 /* Test that external variable whose address is taken are marked. */
 /* { dg-do compile } */
 /* { dg-require-visibility "" } */
-/* { dg-final { scan-hidden "foo" } } */
+/* { dg-final { scan-hidden "foo" { target !*-apple-darwin* } } } */

 extern int foo __attribute__ ((visibility ("hidden")));
 int *test = &foo;
diff -u ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-19.c
gcc/testsuite/gcc.dg/visibility-19.c
--- ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-19.c  2008-08-19
18:11:25.0 +0200
+++ gcc/testsuite/gcc.dg/visibility-19.c2008-11-05 14:21:27.0
+0100
@@ -1,7 +1,7 @@
 /* Test that accessed external functions are marked. */
 /* { dg-do compile } */
 /* { dg-require-visibility "" } */
-/* { dg-final { scan-hidden "foo" } } */
+/* { dg-final { scan-hidden "foo" { target !*-apple-darwin* } } } */

 extern void foo(void) __attribute__ ((visibility ("hidden")));
 typedef void (*foo_t)(void);


-- 


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

[Bug middle-end/37908] atomic NAND op generate wrong code; __sync_nand_and_fetch, __sync_fetch_and_nand

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2008-11-05 13:22 ---
Next revision of the patch (v3) at [1] generates a message when nand builtin is
encountered.

[1] http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00157.html 


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2008-   |patches/2008-
   |10/msg01224.html|11/msg00157.html


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

[Bug libstdc++/38017] [4.4 Regression] 30_threads/thread/cons/X.cc

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2008-11-05 13:20 
---
Jon just forgot to svan delete.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/38017] [4.4 Regression] 30_threads/thread/cons/X.cc

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-11-05 13:11 ---
On Linux/x86, revision 141603 gave

+FAIL: 20_util/function_objects/return_types/result_of.cc (test for excess
errors)
+FAIL: 20_util/function_objects/return_types/result_of_neg.cc (test for excess
errors)
+FAIL: 20_util/function_objects/return_types/result_of_ref.cc (test for excess
errors)


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2008-11-05 12:18 
---
Subject: Bug 37742

Author: rguenth
Date: Wed Nov  5 12:17:10 2008
New Revision: 141606

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141606
Log:
2008-11-05  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/37742
* tree-ssa.c (useless_type_conversion_p_1): Check different restrict
qualified pointer conversion before stripping qualifiers.
* gimplify.c (create_tmp_from_val): Use correctly qualified type.
* tree-flow.h (may_propagate_address_into_dereference): Declare.
* tree-ssa-ccp.c (may_propagate_address_into_dereference): New
function.
(ccp_fold): Use it.
* tree-ssa-forwprop.c (rhs_to_tree): Remove useless conversions,
properly canonicalize binary ops.
(forward_propagate_addr_expr_1): Use
may_propagate_address_into_dereference.

cp/
* decl.c (start_preparsed_function): Use the correct type for
building the RESULT_DECL.

* gcc.c-torture/compile/pr37742.c: New testcase.
* g++.dg/pr37742.C: Likewise.
* gcc.dg/tree-ssa/forwprop-7.c: Check for two volatile loads.

Added:
trunk/gcc/testsuite/g++.dg/pr37742.C
trunk/gcc/testsuite/gcc.c-torture/compile/pr37742.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-7.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-ssa-ccp.c
trunk/gcc/tree-ssa-forwprop.c
trunk/gcc/tree-ssa.c


-- 


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

[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2008-11-05 12:17 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug testsuite/36711] FAIL: gcc.dg/compat/struct-by-value-17a c_compat_* compile

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-11-05 12:01 ---
This PR seems to have been fixed with a revision before r137480. So I close it
as fixed.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/35983] C_LOC in derived type constructor gives weird result

[mikael dot morin at tele2 dot fr]

--- Comment #2 from mikael dot morin at tele2 dot fr  2008-11-05 11:43 
---
There is a reset of the expression to NULL_EXPR in case we encounter c_null_ptr
or c_null_funptr. 
However, the if conditions for this relies on the is_iso_c attribute, which is
the case of c_loc. 
This patch changes this behavior by relying on the symtree names instead. 

Index: trans-expr.c
===
--- trans-expr.c(révision 141583)
+++ trans-expr.c(copie de travail)
@@ -3689,15 +3682,16 @@ gfc_trans_structure_assign (tree dest, gfc_expr *
 {
   /* Skip absent members in default initializers.  */
   if (!c->expr)
-continue;
+   continue;

   /* Update the type/kind of the expression if it represents either
 C_NULL_PTR or C_NULL_FUNPTR.  This is done here because this may
 be the first place reached for initializing output variables that
 have components of type C_PTR/C_FUNPTR that are initialized.  */
-  if (c->expr->ts.type == BT_DERIVED && c->expr->ts.derived
- && c->expr->ts.derived->attr.is_iso_c)
-{
+  if (c->expr->symtree && c->expr->symtree->name
+ && (!strcmp ("c_null_ptr", c->expr->symtree->name)
+ || !strcmp ("c_null_funptr", c->expr->symtree->name)))
+   {
  c->expr->expr_type = EXPR_NULL;
  c->expr->ts.type = c->expr->ts.derived->ts.type;
  c->expr->ts.f90_type = c->expr->ts.derived->ts.f90_type;

With this patch alone, I still get wrong-code though (pointer uninitialized
instead of nullified). 
I've had to revert this patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35150#c7
to have it working. 

There is only one regression, c_loc_tests_12.f03. 
That one is expected, and we are back at PR35150. 
I looked at that one too, but I must admit I'm at least as confused as FX when
he fixed it. 
If some middle-end gurus could take a look/give some tips there...


-- 


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

[Bug c++/38021] New: C++ hang for new keywords

[dcb314 at hotmail dot com]

I just tried to compile the following one liner C++ program
with gcc version 4.4.0 snapshot 20081031.

auto enum : { do

I've no idea what this lump of C++ is supposed to mean, but it
hangs the snapshot at compile time for over ten minutes on
an otherwise idle machine.

The snapshot does print the warning message

bug27.cc:2: warning: scoped enums only available with -std=c++0x or
-std=gnu++0x

before it hangs, which may mean some new code for scoped enums is broken.
No optimisation flags required.


-- 
   Summary: C++ hang for new keywords
   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: suse-linux-x86_64


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

[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected

[jakub at gcc dot gnu dot org]

--- Comment #34 from jakub at gcc dot gnu dot org  2008-11-05 10:14 ---
This bug seems to be fixed then, if there are unrelated AIX or HPUX libjava
testsuite failures, please file separate bugs for them.


-- 

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

[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected

[aph at gcc dot gnu dot org]

--- Comment #33 from aph at gcc dot gnu dot org  2008-11-05 10:06 ---
Subject: Bug 37068

Author: aph
Date: Wed Nov  5 10:05:03 2008
New Revision: 141604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141604
Log:
2008-11-04  Andrew Haley  <[EMAIL PROTECTED]>

PR java/37068
* jcf-parse.c (java_emit_static_constructor): Don't call
cgraph_build_static_cdtor.  Rewrite.

Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/jcf-parse.c


-- 


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

[Bug middle-end/37286] [4.4 regression] gfortran, trunk: ICE subst_stack_regs_pat, at reg-stack.c:1537

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2008-11-05 10:04 ---
Fixed, thanks.


-- 

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

[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-11-05 10:04 ---
I guess this issue can be fixed by following (untested) trivial patch:

--cut here--
Index: mips.md
===
--- mips.md (revision 141602)
+++ mips.md (working copy)
@@ -4508,7 +4508,7 @@
   rtx low = mips_subword (operands[1], 0);
   rtx high = mips_subword (operands[1], 1);
   emit_insn (gen_load_low (operands[0], low));
-  if (ISA_HAS_MXHC1)
+  if (TARGET_HARD_FLOAT && ISA_HAS_MXHC1)
emit_insn (gen_mthc1 (operands[0], high, operands[0]));
   else
emit_insn (gen_load_high (operands[0], high, operands[0]));
@@ -4518,7 +4518,7 @@
   rtx low = mips_subword (operands[0], 0);
   rtx high = mips_subword (operands[0], 1);
   emit_insn (gen_store_word (low, operands[1], const0_rtx));
-  if (ISA_HAS_MXHC1)
+  if (TARGET_HARD_FLOAT && ISA_HAS_MXHC1)
emit_insn (gen_mfhc1 (high, operands[1]));
   else
emit_insn (gen_store_word (high, operands[1], const1_rtx));
--cut here--

Nebu, can you bootstrap and regression test this patch on your target?


-- 


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

[Bug middle-end/37286] [4.4 regression] gfortran, trunk: ICE subst_stack_regs_pat, at reg-stack.c:1537

[uros at gcc dot gnu dot org]

--- Comment #12 from uros at gcc dot gnu dot org  2008-11-05 09:59 ---
Subject: Bug 37286

Author: uros
Date: Wed Nov  5 09:57:49 2008
New Revision: 141603

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141603
Log:
PR middle-end/37286
* reg-stack.c (subst_stack_regs_pat) [MINUS, DIV, MULT, PLUS]:
Initialize uninitialized input registers with a NaN.

testsuite/ChangeLog:

PR middle-end/37286
* gfortran.dg/pr37286.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr37286.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reg-stack.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37861] [4.3/4.4 Regression] Bogus array bounds warning

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.3.2
  Known to work||4.2.4
Summary|Bogus array bounds warning  |[4.3/4.4 Regression] Bogus
   ||array bounds warning
   Target Milestone|--- |4.3.3


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

[Bug target/38016] [4.2/4.3/4.4 Regression] -fno-ivopts exposes CRIS port bug, more with -fno-gcse

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.2.5


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

[Bug target/38015] Converting between int and vector using intrinsics goes through memory

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-11-05 09:38 ---
I think this was done on purpose.


-- 

rguenth 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=38015

[Bug libstdc++/38017] [4.4 Regression] 30_threads/thread/cons/X.cc

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2008-11-05 09:38 ---
Fixed, sorry for the breakage


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/38014] [4.4 Regression] in-tree gmp and mpfr libraries no longer work

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[4.4 regression] in-tree gmp|[4.4 Regression] in-tree gmp
   |and mpfr libraries no longer|and mpfr libraries no longer
   |work|work


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

[Bug libstdc++/38017] [4.4 Regression] 30_threads/thread/cons/X.cc

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2008-11-05 09:37 ---
Subject: Bug 38017

Author: redi
Date: Wed Nov  5 09:36:35 2008
New Revision: 141602

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141602
Log:
PR libstdc++/38017
Revert:
* include/tr1_impl/functional (result_of,reference_wrapper): Update
to use C++0x features.
* testsuite/20_util/function_objects/return_types/result_of.cc: New.
* testsuite/20_util/function_objects/return_types/result_of_neg.cc:
New.
* testsuite/20_util/function_objects/return_types/result_of_ref.cc:
New.
* testsuite/20_util/reference_wrapper/24803.cc: Uncomment FIXMEs.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1_impl/functional
   
trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/result_of.cc
   
trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/result_of_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/function_objects/return_types/result_of_ref.cc
trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/24803.cc


-- 


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

[Bug c/38019] Cannot use nested designated initializer with unnamed inner aggregate

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-11-05 09:36 ---
I get

t.c: In function 'vec_add':
t.c:10: error: unknown field 'x' specified in initializer
t.c:11: error: unknown field 'y' specified in initializer
t.c:11: warning: excess elements in union initializer
t.c:11: warning: (near initialization for '(anonymous)')
t.c:12: error: unknown field 'z' specified in initializer
t.c:12: warning: excess elements in union initializer
t.c:12: warning: (near initialization for '(anonymous)')

instead.


-- 


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

[Bug c++/38020] New: Undiagnosed const violation in pointer conversion in CRTP context.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  template 
  struct Base { Derived * f() { return static_cast(this); } };

  struct D: Base {};

  int main() { D d; d.f(); }

This code is ill-formed, because f is declared to return a Derived*, but the
return statement specifies an expression of type Derived const*.

However, g++ accepts the code without any diagnostic.

Comeau 4.3.10.1 /does/ diagnose the problem, saying "error: return value type
does not match the function type".


-- 
   Summary: Undiagnosed const violation in pointer conversion in
CRTP context.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c/38019] New: Cannot use nested designated initializer with unnamed inner aggregate

[josh at freedesktop dot org]

I have an aggregate with this definition:

typedef union vec3 {
struct {
double x, y, z;
};
double component[3];
} vec3;

Given this definition, I tried to write the following:

static inline vec3 vec_add(vec3 a, vec3 b)
{
return (vec3) {
   .x = a.x + b.x,
   .y = a.y + b.y,
   .z = a.z + b.z,
};
}

GCC complained about this:
vec.h: In function ‘vec_add’:
vec.h:15: error: missing braces around initializer
vec.h:15: error: (near initialization for ‘(anonymous).’)

If I had given the nameless inner struct a name, such as "foo", I could have
written:

static inline vec3 vec_add(vec3 a, vec3 b)
{
return (vec3) {
   .foo.x = a.foo.x + b.foo.x,
   .foo.y = a.foo.y + b.foo.y,
   .foo.z = a.foo.z + b.foo.z,
};
}

So since the inner struct does not have a name, it seems reasonable to allow a
designated initializer to omit the name.  GCC has no problem unambiguously
resolving the field reference a.x, so it seems like GCC should unambiguously
resolve the designated initializer .x = expression.


In case it helps:
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --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.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)


-- 
   Summary: Cannot use nested designated initializer with unnamed
inner aggregate
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: josh at freedesktop dot org


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