[Bug middle-end/36238] [4.4 Regression] ICE in reg_or_subregno, at jump.c:1730

2008-08-09 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2008-08-10 04:56 ---
Subject: Bug 36238

Author: pinskia
Date: Sun Aug 10 04:54:37 2008
New Revision: 138924

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138924
Log:
2008-08-09  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/36238
* reload1.c (gen_reload): Guard calls to get_secondary_mem
for memory subregs.

2008-08-09  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/36238
* gcc.c-torture/compile/pr36238.c: New testcase.



Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr36238.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload1.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug middle-end/36238] [4.4 Regression] ICE in reg_or_subregno, at jump.c:1730

2008-08-09 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2008-08-10 04:55 ---
Fixed, sorry this too so long to fix, there were other failures that were
blocking me to commit this patch.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||08/msg00640.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug target/37050] gcc-4.3.1 bootstrap failure on sparc Solaris 10

2008-08-09 Thread Jay dot St dot Pierre at Colorado dot EDU


--- Comment #2 from Jay dot St dot Pierre at Colorado dot EDU  2008-08-10 
03:14 ---
I was able to build gcc-4.2.4 using the Sun Studio 12 compiler.  However, I was
unable to compile gcc-4.3.1 with gcc-4.2.4, albeit with different errors than
when I tried to use Sun's gcc.  This time I got a bunch of errors like:

ld: fatal: relocation error: R_SPARC_64: file
/appl/local_sde_dev/src/gcc/gcc-4.3.1/sparc-SunOS-5.10/gcc-4.3.1-obj/./gcc/sparcv9/crti.o:
symbol : offset 0x78a186d9 is non-aligned


-- 


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



[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

2008-08-09 Thread eric dot weddington at atmel dot com


--- Comment #11 from eric dot weddington at atmel dot com  2008-08-10 03:13 
---
(In reply to comment #10)

> Since we include limits.h, we are at the mercy of the contents of the limits.h
> that is found. This isn't very reliable. We just need to a pedantic warning in
> the header. This works in x86_64, could you test on your side?

Yes, this patch causes all of the tests to pass for the AVR.

Thanks for working to find a solution for the AVR target.


-- 


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



[Bug c++/37070] bogus unreachable warning on throw statement

2008-08-09 Thread sebor at roguewave dot com


--- Comment #4 from sebor at roguewave dot com  2008-08-10 02:23 ---
My gcc is yesterday's build:
gcc version 4.4.0 20080808 (experimental) (GCC) 


-- 


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



[Bug c++/20118] missing template<> causes weird errors

2008-08-09 Thread manu at gcc dot gnu dot org


--- Comment #7 from manu at gcc dot gnu dot org  2008-08-09 23:24 ---
Testing the following patch. Not as good as ICC's diagnostic but close.

Index: gcc/testsuite/g++.dg/parse/pr20118.C
===
--- gcc/testsuite/g++.dg/parse/pr20118.C(revision 0)
+++ gcc/testsuite/g++.dg/parse/pr20118.C(revision 0)
@@ -0,0 +1,9 @@
+// { dg-do compile }
+// { dg-options "-fshow-column" }
+templatestruct foo {
+  static const int i; };
+
+const int foo::i = 5; // { dg-error ":11: error: specializing member
‘foo::‘i’’ requires ‘template<>’ syntax" }
+
+int main() { return 0; }
+
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 138906)
+++ gcc/cp/parser.c (working copy)
@@ -1905,11 +1905,11 @@ static tree cp_parser_lookup_name_simple
 static tree cp_parser_maybe_treat_template_as_class
   (tree, bool);
 static bool cp_parser_check_declarator_template_parameters
   (cp_parser *, cp_declarator *, location_t);
 static bool cp_parser_check_template_parameters
-  (cp_parser *, unsigned, location_t);
+  (cp_parser *, unsigned, location_t, cp_declarator *);
 static tree cp_parser_simple_cast_expression
   (cp_parser *);
 static tree cp_parser_global_scope_opt
   (cp_parser *, bool);
 static bool cp_parser_constructor_declarator_p
@@ -11591,11 +11591,12 @@ cp_parser_elaborated_type_specifier (cp_
 || cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON)));
  /* An unqualified name was used to reference this type, so
 there were no qualifying templates.  */
  if (!cp_parser_check_template_parameters (parser,
/*num_templates=*/0,
-   token->location))
+   token->location,
+   /*declarator=*/NULL))
return error_mark_node;
  type = xref_tag (tag_type, identifier, ts, template_p);
}
 }

@@ -15049,11 +15050,12 @@ cp_parser_class_head (cp_parser* parser,
  end of this function; set "type "to the correct return value and
  use "goto done;" to return.  */
   /* Make sure that the right number of template parameters were
  present.  */
   if (!cp_parser_check_template_parameters (parser, num_templates,
-   type_start_token->location))
+   type_start_token->location,
+   /*declarator=*/NULL))
 {
   /* If something went wrong, there is no point in even trying to
 process the class-definition.  */
   type = NULL_TREE;
   goto done;
@@ -16946,13 +16948,13 @@ cp_parser_check_declarator_template_para
   == TEMPLATE_ID_EXPR)
/* If the DECLARATOR has the form `X' then it uses one
   additional level of template parameters.  */
++num_templates;

-  return cp_parser_check_template_parameters (parser,
- num_templates,
- declarator_location);
+  return cp_parser_check_template_parameters
+   (parser, num_templates, declarator_location, declarator);
+

 case cdk_function:
 case cdk_array:
 case cdk_pointer:
 case cdk_reference:
@@ -16969,34 +16971,42 @@ cp_parser_check_declarator_template_para
   return false;
 }

 /* NUM_TEMPLATES were used in the current declaration.  If that is
invalid, return FALSE and issue an error messages.  Otherwise,
-   return TRUE.  */
+   return TRUE.  If DECLARATOR is non-NULL, then we are checking a
+   declarator and we can print more accurate diagnostics.  */

 static bool
 cp_parser_check_template_parameters (cp_parser* parser,
 unsigned num_templates,
-location_t location)
+location_t location,
+cp_declarator *declarator)
 {
+  /* If there are the same number of template classes and parameter
+ lists, that's OK.  */
+  if (parser->num_template_parameter_lists == num_templates)
+return true;
+  /* If there are more, but only one more, then we are referring to a
+ member template.  That's OK too.  */
+  if (parser->num_template_parameter_lists == num_templates + 1)
+return true;
   /* If there are more template classes than parameter lists, we have
  something like:

template  void S::R::f ();  */
   if (parser->num_template_parameter_lists < num_templates)
 {
-  error ("%Htoo few template-parameter-lists", &location);
+  if (declarator)
+   error_at (location, "specializing member %<%T::%qE%> "
+ "requires %%> syntax",
+ declarator->u.id.qualifying_scope,
+   

[Bug c++/37070] bogus unreachable warning on throw statement

2008-08-09 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2008-08-09 22:59 ---
> t.C: In function ‘void bar()’:
> t.C:2: warning: will never be executed

I don't get that warning in either the trunk or in 4.0.1.


-- 


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



[Bug c++/37070] bogus unreachable warning on throw statement

2008-08-09 Thread sebor at roguewave dot com


--- Comment #2 from sebor at roguewave dot com  2008-08-09 22:51 ---
I'm not sure what you're trying to say but it sure looks like a bug to me.
How else is one supposed to throw an exception without triggering this
warning?

Btw., the argument of a throw expression can throw, and when it does, it
becomes the thrown object:

$ cat t.C && g++ -O2 -Wunreachable-code t.C && ./a.out; echo $?
struct S { S () { throw 0; } };
void bar () { throw S (); }

int main ()
{
try { bar (); }
catch (int) { return 0; }
return 1;
}
t.C: In constructor ‘S::S()’:
t.C:1: warning: will never be executed
t.C: In function ‘void bar()’:
t.C:2: warning: will never be executed
0


-- 


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



[Bug c++/37070] bogus unreachable warning on throw statement

2008-08-09 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-09 22:31 ---
I don't think this is really bogus as the expression inside a throw cannot
throw so GCC is able to optimize away the catch inside that throw.
  [t.cc : 3] try
{
  [t.cc : 3] D.2413 = (int *) D.2410;
  [t.cc : 3] *D.2413 = 0;
}
  catch
{
  [t.cc : 3] <<>>
{

[t.cc : 3] terminate ();

}
}

That catch is not reachable.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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



[Bug c++/37070] New: bogus unreachable warning on throw statement

2008-08-09 Thread sebor at roguewave dot com
gcc 4.3.0 generates the bogus warning below (4.4.0 behaves the same):

$ cat -n t.C && g++ -v && g++ -c -Wunreachable-code t.C
 1  void f ()
 2  {
 3  throw 0;
 4  }
 5
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/sebor/gcc/trunk/configure
--prefix=/build/sebor/bin/gcc-4.4.0/ --enable-languages=c,c++
--with-mpfr=/usr/local/mpfr-2.3.1
Thread model: posix
gcc version 4.4.0 20080808 (experimental) (GCC) 
t.C: In function ‘void f()’:
t.C:3: warning: will never be executed


-- 
   Summary: bogus unreachable warning on throw statement
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-09 Thread gerald at pfeifer dot com


--- Comment #12 from gerald at pfeifer dot com  2008-08-09 22:20 ---
This also breaks the bootstrap of the 4.3 branch on i386-unknown-freebsd6.3
without Ada being involved.


-- 

gerald at pfeifer dot com changed:

   What|Removed |Added

  GCC build triplet||[EMAIL PROTECTED]


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



[Bug target/37055] [4.4 Regression] Revision 138835 breaks -msse2 -mfpmath=sse -Os

2008-08-09 Thread hjl at gcc dot gnu dot org


--- Comment #5 from hjl at gcc dot gnu dot org  2008-08-09 21:48 ---
Subject: Bug 37055

Author: hjl
Date: Sat Aug  9 21:47:28 2008
New Revision: 138916

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138916
Log:
2008-08-09  Jan Hubicka  <[EMAIL PROTECTED]>

PR target/37055
* optabs.c (maybe_emit_unop_insn): Remove produced code if
expansion failed.
(expand_fix): Be prepared for expansion to fail.
(expand_sfix_optab): Remove instructions if expansion failed.

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


-- 


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



[Bug c/37067] gcc creating wrong code with -O2

2008-08-09 Thread rguenth at gcc dot gnu dot org


--- Comment #8 from rguenth at gcc dot gnu dot org  2008-08-09 21:07 ---
You can use -fwrapv.


-- 


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



[Bug c/37067] gcc creating wrong code with -O2

2008-08-09 Thread brian at dessent dot net


--- Comment #7 from brian at dessent dot net  2008-08-09 21:00 ---
Subject: Re:  gcc creating wrong code with -O2

Just make it unsigned since unsigned overflow is always defined.


-- 


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



[Bug c/37067] gcc creating wrong code with -O2

2008-08-09 Thread stefan dot bruens at rwth-aachen dot de


--- Comment #6 from stefan dot bruens at rwth-aachen dot de  2008-08-09 
20:56 ---
So is there any possibility to flag a variable to be expected to overflow and
"wrap around"? I think there is a lot of code in the wild assuming the loop to
run 10 times and d_phase to overflow all the time, becoming negative.


-- 


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



[Bug c/37067] gcc creating wrong code with -O2

2008-08-09 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2008-08-09 20:46 ---
>The loop should run 10 times, as i does not overflow.

i does not overflow but d_phase does ...

2046 7ff0
2047 8000
That is an overflow.

So is:
4094 fff0
4095 0


-- 


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



[Bug c/37067] gcc creating wrong code with -O2

2008-08-09 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2008-08-09 20:43 ---
As I said - it works for me (i686, gcc (Debian 4.3.1-8) 4.3.1).  Still the
overflow invokes undefined behavior and thus _can_ affect the loop.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug c/37067] gcc creating wrong code with -O2

2008-08-09 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2008-08-09 20:42 ---
>The loop should run 10 times, as i does not overflow.

i does not overflow but d_phase_inc does ...


-- 


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



[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

2008-08-09 Thread manu at gcc dot gnu dot org


--- Comment #10 from manu at gcc dot gnu dot org  2008-08-09 20:38 ---
Yeah, silly me, it obviously fails because there is no "next" pr36901.h to
include.

Since we include limits.h, we are at the mercy of the contents of the limits.h
that is found. This isn't very reliable. We just need to a pedantic warning in
the header. This works in x86_64, could you test on your side?


Index: gcc/testsuite/gcc.dg/pr36901-3.c
===
--- gcc/testsuite/gcc.dg/pr36901-3.c(revision 138906)
+++ gcc/testsuite/gcc.dg/pr36901-3.c(working copy)
@@ -4,7 +4,6 @@
 void foo(void)
 {
   int s = sc;
 }
 /* { dg-message "file included" "In file included" { target *-*-* } 0 } */
-/* { dg-warning "overflow" "overflow" { target *-*-* } 0 } */
-/* { dg-error "overflow" "overflow" { target *-*-* } 0 } */
+/* { dg-error "ordered comparison of pointer with integer zero" "pedantic
error" { target *-*-* } 0 } */
Index: gcc/testsuite/gcc.dg/pr36901-4.c
===
--- gcc/testsuite/gcc.dg/pr36901-4.c(revision 138906)
+++ gcc/testsuite/gcc.dg/pr36901-4.c(working copy)
@@ -4,8 +4,6 @@
 void foo(void)
 {
   int s = sc;
 }
 /* { dg-message "from " "In file included" { target *-*-* } 0 } */
-/* { dg-warning "overflow" "overflow" { target *-*-* } 0 } */
-/* { dg-error "overflow" "overflow" { target *-*-* } 0 } */
-/* { dg-error "#include_next is a GCC extension" "#include_next" { target
*-*-* } 0 } */
+/* { dg-error "ordered comparison of pointer with integer zero" "pedantic
error" { target *-*-* } 0 } */
Index: gcc/testsuite/gcc.dg/pr36901.h
===
--- gcc/testsuite/gcc.dg/pr36901.h  (revision 138906)
+++ gcc/testsuite/gcc.dg/pr36901.h  (working copy)
@@ -1,2 +1,2 @@
-#include 
-static int sc = INT_MAX + 1;
+int sc = (&sc > 0);
+


-- 


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



[Bug c/37067] gcc creating wrong code with -O2

2008-08-09 Thread stefan dot bruens at rwth-aachen dot de


--- Comment #2 from stefan dot bruens at rwth-aachen dot de  2008-08-09 
20:37 ---
The expected output is quite clear - 69f0 6a00 - but output is 69f0
0.
The loop should run 10 times, as i does not overflow.
d_phase does overflow after 2048 steps, but this should not influence the loop.

with -O2, gcc seems to do the following:
- d_phase is the same as i*0x10
- the block should run 0x186a0 times
- (0x186a0 * 0x10) & 0x = 0x6a00
- break when d_phase reaches 0x6a00 (1696 increment steps)

with -O3 and -O1, d_phase and i get their own variables
there should be at least a warning


-- 

stefan dot bruens at rwth-aachen dot de changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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



[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

2008-08-09 Thread eric dot weddington at atmel dot com


--- Comment #9 from eric dot weddington at atmel dot com  2008-08-09 19:34 
---
You're right in that limits.h for the AVR does not use #include_next. The
limits.h that the AVR toolchain uses is installed by gcc.

Unfortunately your suggestion makes the situation worse. There are now 4
failures instead of one:
FAIL: gcc.dg/pr36901-1.c (test for excess errors)
FAIL: gcc.dg/pr36901-4.c overflow (test for warnings, line )
FAIL: gcc.dg/pr36901-4.c overflow (test for errors, line )
FAIL: gcc.dg/pr36901-4.c (test for excess errors)


Here are the details from the log:
Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c   -pedantic-errors
-DSTACK_SIZE=2048 -DNO_TRAMPOLINES -fno-show-column -S  -DSIGNAL_SUPPRESS
-mmcu=atmega128   -o pr36901-1.s(timeout = 300)
In file included from
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:3:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-system.h:2: error:
pr36901.h: No such file or directory
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c: In function 'foo':
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:6: error: 'sc'
undeclared (first use in this function)
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:6: error: (Each
undeclared identifier is reported only once
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:6: error: for each
function it appears in.)
compiler exited with status 1
output is:
In file included from
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:3:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-system.h:2: error:
pr36901.h: No such file or directory
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c: In function 'foo':
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:6: error: 'sc'
undeclared (first use in this function)
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:6: error: (Each
undeclared identifier is reported only once
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:6: error: for each
function it appears in.)

FAIL: gcc.dg/pr36901-1.c (test for excess errors)
Excess errors:
In file included from
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:3:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-system.h:2: error:
pr36901.h: No such file or directory
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:6: error: 'sc'
undeclared (first use in this function)
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:6: error: (Each
undeclared identifier is reported only once
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-1.c:6: error: for each
function it appears in.)

Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-2.c   -pedantic-errors
-w -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -fno-show-column -S  -DSIGNAL_SUPPRESS
-mmcu=atmega128   -o pr36901-2.s(timeout = 300)
PASS: gcc.dg/pr36901-2.c (test for excess errors)
Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-3.c   -pedantic-errors
-DSTACK_SIZE=2048 -DNO_TRAMPOLINES -fno-show-column -S  -DSIGNAL_SUPPRESS
-mmcu=atmega128   -o pr36901-3.s(timeout = 300)
In file included from
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-3.c:3:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901.h:2: warning: integer
overflow in expression
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901.h:2: error: overflow in
constant expression
compiler exited with status 1
output is:
In file included from
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-3.c:3:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901.h:2: warning: integer
overflow in expression
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901.h:2: error: overflow in
constant expression

PASS: gcc.dg/pr36901-3.c In file included (test for warnings, line )
PASS: gcc.dg/pr36901-3.c overflow (test for warnings, line )
PASS: gcc.dg/pr36901-3.c overflow (test for errors, line )
PASS: gcc.dg/pr36901-3.c (test for excess errors)
Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-4.c   -pedantic-errors
-Wsystem-headers -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -fno-show-column -S 
-DSIGNAL_SUPPRESS -mmcu=atmega128   -o pr36901-4.s(timeout = 300)
In file included from
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-4.c:3:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-system.h:2: error:
#include_next is a GCC extension
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-system.h:2: error:
pr36901.h: No such file or directory
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-4.c: In function 'foo':
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr36901-4.c:6: error: 'sc'
undeclared

[Bug fortran/36582] Namelist I/O error: Bogus "Cannot match namelist object"

2008-08-09 Thread jvdelisle at gcc dot gnu dot org


--- Comment #19 from jvdelisle at gcc dot gnu dot org  2008-08-09 19:19 
---
Closing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug fortran/36582] Namelist I/O error: Bogus "Cannot match namelist object"

2008-08-09 Thread jvdelisle at gcc dot gnu dot org


--- Comment #18 from jvdelisle at gcc dot gnu dot org  2008-08-09 19:18 
---
Subject: Bug 36582

Author: jvdelisle
Date: Sat Aug  9 19:17:24 2008
New Revision: 138914

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138914
Log:
2008-07-22  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/36582
* io/list_read.c: If variable rank is zero, do not adjust the found
namelist object pointer. Fix ChangeLog.

Modified:
trunk/libgfortran/ChangeLog


-- 


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



[Bug fortran/36582] Namelist I/O error: Bogus "Cannot match namelist object"

2008-08-09 Thread jvdelisle at gcc dot gnu dot org


--- Comment #17 from jvdelisle at gcc dot gnu dot org  2008-08-09 19:13 
---
Subject: Bug 36582

Author: jvdelisle
Date: Sat Aug  9 19:12:04 2008
New Revision: 138913

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138913
Log:
2008-07-26  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/36582
Backport from trunk.  Fix ChangeLog.
* io/list_read.c: If variable rank is zero, do not adjust the found
namelist object pointer.

Modified:
branches/gcc-4_3-branch/libgfortran/ChangeLog


-- 


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



[Bug fortran/36582] Namelist I/O error: Bogus "Cannot match namelist object"

2008-08-09 Thread jvdelisle at gcc dot gnu dot org


--- Comment #16 from jvdelisle at gcc dot gnu dot org  2008-08-09 19:05 
---
I did commit these fixes but reversed two digits in the PR number in the change
log so they did not record here.  Fix follows.


-- 


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



[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it

2008-08-09 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-09 18:06 ---
Well, the switch conversion pass should create a locally binding (and hidden)
object to store the values.  If it does not then this certainly is a bug.
Though in this case it looks like it needs to build a table of addresses
of non-locally binding objects?  This it shouldn't do by default either I
guess.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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



[Bug c/37067] gcc creating wrong code with -O2

2008-08-09 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-09 18:01 ---
This works for me as far as I can see (you didn't specify the expected
output, and certainly if the loop doesn't run as often as you want you
may print uninitialized memory).  Anyway, if it doesn't work then it is
because d_phase overflows and so invokes undefined behavior.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

2008-08-09 Thread manu at gcc dot gnu dot org


--- Comment #8 from manu at gcc dot gnu dot org  2008-08-09 17:30 ---
I don't have AVR so I cannot know what exactly is going on or test a fix.
However, I guess that the limits.h used by AVR do not use #include_next. So you
could try by adding #include_next in pr36901-system.h, that is:

- #include "pr36901.h"
+ #include_next "pr36901.h"

Could you test that?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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



[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

2008-08-09 Thread eric dot weddington at atmel dot com


--- Comment #7 from eric dot weddington at atmel dot com  2008-08-09 17:16 
---
*** Bug 37069 has been marked as a duplicate of this bug. ***


-- 


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



[Bug other/37069] [4.4 Regression] FAIL: gcc.dg/pr36901-4.c #include_next (test for errors, line )

2008-08-09 Thread eric dot weddington at atmel dot com


--- Comment #1 from eric dot weddington at atmel dot com  2008-08-09 17:16 
---


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


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

2008-08-09 Thread eric dot weddington at atmel dot com


--- Comment #6 from eric dot weddington at atmel dot com  2008-08-09 17:15 
---
Your fix causes a regression on the AVR:

FAIL: gcc.dg/pr36901-4.c #include_next (test for errors, line )

Success with trunk revision 138883
Failed with trunk revision 138904


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 CC||eric dot weddington at atmel
   ||dot com
 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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



[Bug other/37069] New: [4.4 Regression] FAIL: gcc.dg/pr36901-4.c #include_next (test for errors, line )

2008-08-09 Thread eric dot weddington at atmel dot com
FAIL: gcc.dg/pr36901-4.c #include_next (test for errors, line )

Success with trunk revision 138883
Failed with trunk revision 138904


-- 
   Summary: [4.4 Regression] FAIL: gcc.dg/pr36901-4.c #include_next
(test for errors, line )
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot weddington at atmel dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr-unknown-none


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



[Bug target/37050] gcc-4.3.1 bootstrap failure on sparc Solaris 10

2008-08-09 Thread Jay dot St dot Pierre at Colorado dot EDU


--- Comment #1 from Jay dot St dot Pierre at Colorado dot EDU  2008-08-09 
16:34 ---
Created an attachment (id=16049)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16049&action=view)
config.log from the sparc-sun-solaris2.10/libgcc directory


-- 


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



[Bug libstdc++/37059] ctype_members.cc:137: error: redefinition of 'bool std::ctype::do_is(lo ng unsigned int, wchar_t) const'

2008-08-09 Thread paolo dot carlini at oracle dot com


--- Comment #6 from paolo dot carlini at oracle dot com  2008-08-09 16:18 
---
(In reply to comment #2)
> This did work .
> So, the regression is recent.

And here, you didn't have the --enable-clocale=gnu. Really no mystery ;)


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug libstdc++/37059] ctype_members.cc:137: error: redefinition of 'bool std::ctype::do_is(lo ng unsigned int, wchar_t) const'

2008-08-09 Thread paolo dot carlini at oracle dot com


--- Comment #5 from paolo dot carlini at oracle dot com  2008-08-09 16:16 
---
(In reply to comment #0)
> --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu

Note: configuring with the gnu clocale certainly is a bad idea on darwin,
*cannot* work. The only remaining mystery is why we were protected from this
misconfiguration until some time ago... Anyway, please remove that from your
config and report back, I'm sure the build will be ok (before, do an SVN
update, to be sure, in the meanwhile I fixed an unrelated small issue in the
darwin config, a missing include).


-- 


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



[Bug libstdc++/37059] ctype_members.cc:137: error: redefinition of 'bool std::ctype::do_is(lo ng unsigned int, wchar_t) const'

2008-08-09 Thread paolo dot carlini at oracle dot com


--- Comment #4 from paolo dot carlini at oracle dot com  2008-08-09 15:51 
---
Please investigate why you are compiling the generic ctype_members.cc instead
of the darwin-specific one. In the library nothing changed in this area
recently, for sure.


-- 


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



[Bug libstdc++/37059] ctype_members.cc:137: error: redefinition of 'bool std::ctype::do_is(lo ng unsigned int, wchar_t) const'

2008-08-09 Thread paolo dot carlini at oracle dot com


--- Comment #3 from paolo dot carlini at oracle dot com  2008-08-09 15:49 
---
To confirm that something is going wrong when forcing this different config, at
line 137 of the darwin-specific ctype_members.cc there is *no* do_is function!
For some reason, the generic locale model (thus the generic, instead of the
darwin-specific, ctype_members.cc) is wrongly selected.


-- 


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



[Bug libstdc++/37059] ctype_members.cc:137: error: redefinition of 'bool std::ctype::do_is(lo ng unsigned int, wchar_t) const'

2008-08-09 Thread dave at hiauly1 dot hia dot nrc dot ca


--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-09 
15:49 ---
Subject: Re:  ctype_members.cc:137: error: redefinition of 'bool
std::ctype::do_is(lo ng unsigned int, wchar_t)

> I think something has to be updated / extended on the target-specific bits for
> darwin when i686-apple-darwin9 is involved, because the "normal" (meaning,
> default) one is absolutely fine for me (to wit, i386-apple-darwin-9.4.0, just
> booted and tested). Did this i686-apple-darwin9 config ever worked for you? In
> any case, please add in CC a darwin maintainer, because it's unlikely that we
> can fix this issue without, sorry, ...

This did work .
So, the regression is recent.

Dave


-- 


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



[Bug libstdc++/37059] ctype_members.cc:137: error: redefinition of 'bool std::ctype::do_is(lo ng unsigned int, wchar_t) const'

2008-08-09 Thread paolo dot carlini at oracle dot com


--- Comment #1 from paolo dot carlini at oracle dot com  2008-08-09 15:40 
---
I think something has to be updated / extended on the target-specific bits for
darwin when i686-apple-darwin9 is involved, because the "normal" (meaning,
default) one is absolutely fine for me (to wit, i386-apple-darwin-9.4.0, just
booted and tested). Did this i686-apple-darwin9 config ever worked for you? In
any case, please add in CC a darwin maintainer, because it's unlikely that we
can fix this issue without, sorry, ...


-- 


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



[Bug debug/37033] [4.4 Regression] Revision 138733 breaks PCH

2008-08-09 Thread hjl dot tools at gmail dot com


--- Comment #5 from hjl dot tools at gmail dot com  2008-08-09 15:15 ---
It doesn't work on gcc.dg/pch/valid-1b.c since it explicitly tests -g vs -g0:

[EMAIL PROTECTED] testsuite]$ cat gcc.dg/pch/valid-1b.c
/* { dg-options "-I. -Winvalid-pch -g0" } */

#include "valid-1b.h"

int x;
[EMAIL PROTECTED] testsuite]$


-- 

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



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

2008-08-09 Thread danglin at gcc dot gnu dot org
Executing on host:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/
../libtool --silent --tag=GCJ --mode=link /test/gnu/gcc/objdir/gcc/gcj
-B/test/g
nu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/test/gnu/gcc/objdir/gcc/
--encod
ing=UTF-8 -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../
/te
st/gnu/gcc/gcc/libjava/testsuite/libjava.cni/PR9577.jar natPR9577.o  -w 
-no-ins
tall --main=PR9577 -g 
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.l
ibs -lm   -o PR9577(timeout = 300)
PASS: linking PR9577
set_ld_library_path_env_vars:
ld_library_path=.:/test/gnu/gcc/objdir/hppa2.0w-hp
-hpux11.11/./libjava/.libs
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjav
a/.libs:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs
libgcj failure: gcj linkage error.
Incorrect library ABI version detected.  Aborting.

FAIL: PR9577 run

This error breaks most gcj tests.  See
.  See
 for results
from the previous revision.

-bash-3.2$ ./xgcc -B. -v
Reading specs from ./specs
Target: hppa2.0w-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as
--enable-shared --disable-nls --with-local-prefix=/opt/gnu
--prefix=/opt/gnu/gcc/gcc-4.4.0 --enable-debug=no --enable-threads=posix
--with-mpfr=/opt/gnu/gcc/gcc-4.4.0 --with-gmp=/opt/gnu/gcc/gcc-4.3.0
--disable-libmudflap --enable-languages=c++,java
Thread model: posix
gcc version 4.4.0 20080715 (experimental) [trunk revision 137834] (GCC) 

The bug was introduced by the following change:

2008-07-15  Jan Hubicka  <[EMAIL PROTECTED]>

* lang.c (java_init_options): Enable unit-at-a-time by default.

So, presumably this change has broken reading the library ABI information.


-- 
   Summary: [4.4 Regression] libgcj linkage failure: Incorrect
library ABI version detected
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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



[Bug c/37067] New: gcc creating wrong code with -O2

2008-08-09 Thread stefan dot bruens at rwth-aachen dot de
The following code is producing false results with -O2 optimization (-O1 and O3
are correct):
---
#include 
#define BLOCK_SIZE 10

int main()
{
  int i;
  float block_f[BLOCK_SIZE];
  int d_phase = 0;
  int d_phase_inc = 0x10;

  for (i = 0; i < BLOCK_SIZE; i++){
  block_f[i] = (float)(d_phase);
  d_phase += d_phase_inc;
}

  printf ("%x %x\n", (int)block_f[1695], (int)block_f[1696]);
  return 0;
}
-
With -O2, the loop is run only 0x6a0 times, instead of 0x186a0 times.

gcc is from openSUSE 11.0 (4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)), but fc9 is most probably affected as well.

Failing code is a very simplified test case from gnuradio
(http://www.ruby-forum.com/topic/156807)


-- 
   Summary: gcc creating wrong code with -O2
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefan dot bruens at rwth-aachen dot de


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



[Bug target/37055] [4.4 Regression] Revision 138835 breaks -msse2 -mfpmath=sse -Os

2008-08-09 Thread hjl dot tools at gmail dot com


--- Comment #4 from hjl dot tools at gmail dot com  2008-08-09 14:12 ---
(In reply to comment #3)
> The proposed patch eliminated the previous failures but I am now see some
> additional ones in current gcc trunk...
> 
> FAIL: gcc.target/i386/incoming-1.c scan-assembler andl[\\t ]*\\$-16,[\\t 
> ]*%esp
> FAIL: gcc.target/i386/incoming-4.c scan-assembler andl[\\t ]*\\$-16,[\\t 
> ]*%esp
> FAIL: gcc.target/i386/incoming-5.c scan-assembler andl[\\t ]*\\$-8,[\\t ]*%esp
> 

Those tests are invalid on Darwin. I posted a patch at

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00610.html


-- 


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



[Bug c++/17880] -Wsequence-point doesn't warn inside if, while, do conditions, for beg/cond/end expressions etc.

2008-08-09 Thread manu at gcc dot gnu dot org


--- Comment #5 from manu at gcc dot gnu dot org  2008-08-09 13:09 ---
Fixed in the C front-end, broken in the C++ front-end. I also have a patch for
this.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |manu at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Component|c   |c++
   Last reconfirmed|2005-12-18 00:42:06 |2008-08-09 13:09:57
   date||


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



[Bug c++/37066] New: partial specialization of function depends on the order

2008-08-09 Thread marc dot glisse at normalesup dot org
In the following code, adapted from gmpxx, the output is HELLO2. If however I
change the order of the two partial specializations, the output becomes HELLO1.
At least one other compiler I tried outputs HELLO1 in both cases. I know that I
can remove the "template<>" and overload the function instead of partially
specializing it, but I would like to understand why the current code is
failing.


#include 

struct mpz_t{};

template 
class __gmp_expr{};

template 
void __gmp_set_expr(const __gmp_expr &);

typedef __gmp_expr mpz_class;

template <>
void __gmp_set_expr(const __gmp_expr &expr)
{
std::cerr << "HELLO1\n";
}

template 
void __gmp_set_expr(const __gmp_expr &expr)
{
std::cerr << "HELLO2\n";
}

int main(){
mpz_class a;
mpz_t t;
__gmp_set_expr(a);
}


-- 
   Summary: partial specialization of function depends on the order
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
  GCC host triplet: i486-linux-gnu


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



[Bug c/17880] -Wsequence-point doesn't warn inside if, while, do conditions, for beg/cond/end expressions etc.

2008-08-09 Thread manu at gcc dot gnu dot org


--- Comment #4 from manu at gcc dot gnu dot org  2008-08-09 12:38 ---
Subject: Bug 17880

Author: manu
Date: Sat Aug  9 12:37:32 2008
New Revision: 138904

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138904
Log:
2008-08-09  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR c/17880
* c-typeck.c (digest_init): Call verify_sequence_points from here.
(c_finish_return): Likewise.
(c_start_case): Likewise.
* c-common.c (warn_for_collisions_1): Use explicit location in
warning.
* c-parser.c (c_parser_condition): New. Call
verify_sequence_points.
(c_parser_paren_condition): Call c_parser_condition.
(c_parser_for_statement): Call c_parser_condition.
testsuite/
* gcc.dg/sequence-pt-pr17880.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/sequence-pt-pr17880.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-parser.c
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug libfortran/18985] opening unit 6 messes up print

2008-08-09 Thread schilds at sun dot ac dot za


--- Comment #11 from schilds at sun dot ac dot za  2008-08-09 07:27 ---
Jeez! After reading what all of you have said ... I see this code does actually
do something as crazy (and simple) as set the logical unit number for a file to
6, in a subroutine (when I had thought they had only done writes). 

Yes, this is a known Fortran issue from way back. I apologise profusely for
wasting your time in the manner I have. Again, I apologise.

P.S. If it makes you feel better, just think of the task I have ahead of me.


-- 


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