[Bug tree-optimization/47004] missed optimization in length comparison

2010-12-19 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47004

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.19 08:55:31
 CC||ebotcazou at gcc dot
   ||gnu.org
Version|4.5.4   |4.6.0
Summary|missed optimization in  |missed optimization in
   |comparison  |length comparison
 Ever Confirmed|0   |1
   Severity|minor   |enhancement

--- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-19 
08:55:31 UTC ---
Still visible on the mainline.  Maybe this could help other languages as well.


[Bug c++/47011] New: ICE when using attribute optimize

2010-12-19 Thread lcastelli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47011

   Summary: ICE when using attribute optimize
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lcaste...@gmail.com
Target: x86_64-linux-gnu


When compiling the attached file with:
 g++ -O3 -c gcc-crash.cpp

the following error is emitted:
 gcc-crash.cpp: In member function ‘virtual A B::m()’:
 gcc-crash.cpp:7: internal compiler error: in tree_nrv, at tree-nrv.c:143

This happens with gcc 4.4.5 and the current branch on SVN. It doesn't seem to
happen on gcc 4.5.


[Bug c++/47011] ICE when using attribute optimize

2010-12-19 Thread lcastelli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47011

--- Comment #1 from Lorenzo Castelli lcastelli at gmail dot com 2010-12-19 
10:18:34 UTC ---
Created attachment 22819
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22819
Code to reproduce the error


[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)

2010-12-19 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199

--- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr 
2010-12-19 10:53:47 UTC ---
This PR seems to have been fixed at revision 168044 (likely r 168031).  May be
pr46974 was a duplicate of this PR. Could someone check this and close this PR
if it is the case? TIA


[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away

2010-12-19 Thread davek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674

--- Comment #12 from Dave Korn davek at gcc dot gnu.org 2010-12-19 11:14:23 
UTC ---
Author: davek
Date: Sun Dec 19 11:14:19 2010
New Revision: 168047

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168047
Log:
PR middle-end/46674
PR middle-end/46221
* varasm.c (symbol_alias_set_t): New typedef for derived pointer_set
wrapper class.
(symbol_alias_set_create): New wrapper function.
(symbol_alias_set_destroy): Likewise.
(symbol_alias_set_contains): Likewise.
(symbol_alias_set_insert): Likewise.
(compute_visible_aliases): Use the above and return symbol_alias_set_t,
not a pointer_set.
(remove_unreachable_alias_pairs): Adjust likewise to match.
(finish_aliases_1): Likewise.


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


[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing

2010-12-19 Thread davek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221

--- Comment #27 from Dave Korn davek at gcc dot gnu.org 2010-12-19 11:14:23 
UTC ---
Author: davek
Date: Sun Dec 19 11:14:19 2010
New Revision: 168047

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168047
Log:
PR middle-end/46674
PR middle-end/46221
* varasm.c (symbol_alias_set_t): New typedef for derived pointer_set
wrapper class.
(symbol_alias_set_create): New wrapper function.
(symbol_alias_set_destroy): Likewise.
(symbol_alias_set_contains): Likewise.
(symbol_alias_set_insert): Likewise.
(compute_visible_aliases): Use the above and return symbol_alias_set_t,
not a pointer_set.
(remove_unreachable_alias_pairs): Adjust likewise to match.
(finish_aliases_1): Likewise.


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


[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away

2010-12-19 Thread davek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674

Dave Korn davek at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Dave Korn davek at gcc dot gnu.org 2010-12-19 11:17:27 
UTC ---
Fully fixed now, I trust.


[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing

2010-12-19 Thread davek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221

Dave Korn davek at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #28 from Dave Korn davek at gcc dot gnu.org 2010-12-19 11:18:37 
UTC ---
Problems (PR46674) with this fix now resolved.


[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)

2010-12-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 
11:24:34 UTC ---
Yes, looks as duplicate of PR 46974.

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


[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

2010-12-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974

--- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 
11:24:34 UTC ---
*** Bug 34199 has been marked as a duplicate of this bug. ***


[Bug rtl-optimization/47008] [4.6 Regression] gfortran.dg/extends_{23}.f03 FAIL with -Os -fschedule-insns

2010-12-19 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47008

--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-19 
11:34:22 UTC ---
Yep, this indeed looks like aliasing bug...


[Bug fortran/47007] Values from namelist file should not depend on locale settings

2010-12-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007

--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 
11:35:14 UTC ---
(In reply to comment #4)
 The standard says namelist IO will
 use whatever current decimal separator is.  If locale sets
 the default to ',', then that is what should be used unless
 explicitly set by the user.

I disagree: The standard says for the OPEN statement (9.5.6.7 DECIMAL=
specifier in the OPEN statement, quote of F2008): If this specifier is
omitted in an OPEN statement that initiates a connection, the default value is
POINT.

Thus, for unit-based I/O the answer is clear: A decimal POINT shall be used by
default - independent of the LOCALE setting.

For internal I/O: The initial value of a connection mode (9.5.2) is the value
that would be implied by an initial OPEN statement without the corresponding
keyword. -- Thus, DECIMAL=POINT is the default (which can be overridden by
the DECIMAL= specifier in the data transfer statement - or [if a format
specification is used] by the dp/dc edit descriptors).


[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2010-12-19 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.12.19 11:43:48
 Ever Confirmed|0   |1

--- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-19 
11:43:48 UTC ---
I finally got into some time to test the various solutions. easiest is probably
the following:
Index: predict.c
===
--- predict.c   (revision 168047)
+++ predict.c   (working copy)
@@ -126,7 +126,7 @@ maybe_hot_frequency_p (int freq)
   if (node-frequency == NODE_FREQUENCY_EXECUTED_ONCE
freq = (ENTRY_BLOCK_PTR-frequency * 2 / 3))
 return false;
-  if (freq  BB_FREQ_MAX / PARAM_VALUE (HOT_BB_FREQUENCY_FRACTION))
+  if (freq  ENTRY_BLOCK_PTR-frequency / PARAM_VALUE
(HOT_BB_FREQUENCY_FRACTION))
 return false;
   return true;
 }
It makes GCC to decide on cold basic blocks not based on the innermost loop
nest but on the entry block frequency - so many conditoinals or EH renders BB
cold but not the fact it is outside of very many BBs.

Could you try if this solves the problem?


[Bug target/47000] [4.5 Regression] Failure to inline SSE intrinsics

2010-12-19 Thread hubicka at ucw dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47000

--- Comment #21 from Jan Hubicka hubicka at ucw dot cz 2010-12-19 11:49:53 
UTC ---
 I'd like to wait for Honza's opinion before we just start trying random
 patches. 
Well, if H.J.'s proposed backport of the builtin cost sizes helps, I guess it
is sane
way to fix this.  I will take a look why main inliner don't do the job when
early inliner
ignores the call.

I am not sure how much of heuristics changes makes sense to backport to 4.5.
Depends on importance
of the regression I guess.

Honza


[Bug target/47000] [4.5 Regression] Failure to inline SSE intrinsics

2010-12-19 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47000

--- Comment #22 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-19 
11:53:32 UTC ---
  freq:  8000 size:  2 time:  2 D.13088_5480 = VIEW_CONVERT_EXPRvector
int(D.8004_729);
  freq:  8000 size:  2 time:  2 D.13087_5481 = VIEW_CONVERT_EXPRvector
int(a_5271);
  freq:  8000 size:  7 time: 16 D.13086_5482 = __builtin_ia32_paddd128
(D.13087_5481, D.13088_5480);

obviously we also should count V_C_E as free like other conversions.  Will test
patch for that.


[Bug target/47000] [4.5 Regression] Failure to inline SSE intrinsics

2010-12-19 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47000

--- Comment #23 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-19 
11:58:35 UTC ---
sha256_4way.c:287:78: warning: called from here
sha256_4way.c:50:23: warning: inlining failed in call to ‘ROTR’: --param
inline-unit-growth limit reached

so you could also workaround with --param inline-unit-growth=some sufficiently
large number.
Otherwise H.J.'s proposed backport seems like most sane way to solve the
problem.  I guess it can be backported.


I am testing
Index: tree-inline.c
===
--- tree-inline.c   (revision 168047)
+++ tree-inline.c   (working copy)
@@ -3281,6 +3281,7 @@ estimate_operator_cost (enum tree_code c
 CASE_CONVERT:
 case COMPLEX_EXPR:
 case PAREN_EXPR:
+case VIEW_CONVERT_EXPR:
   return 0;

 /* Assign cost of 1 to usual operations.

to solve the V_C_E problems.


[Bug libobjc/47012] New: nonatimic Properties behave wrong

2010-12-19 Thread js-gcc at webkeks dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

   Summary: nonatimic Properties behave wrong
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js-...@webkeks.org


It seems nonatomic properties retain and autorelease the result, which is
breaking existing code targeting the Apple runtime.

This bug has been also in the GNUstep runtime and the Cocotron runtime, it
seems this bug has been copied to the new GNU runtime now.

The Apple doc says:
If you specify nonatomic, then a synthesized accessor for an object property
simply returns the value directly.
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocProperties.html

I have written a property implementation which is known to be compatible to the
Apple runtime which is quite short and I'd like to contribute. It is currently
licensed under the QPL, but I plan to relicense it as GPL if you are
interested.

If you need a testcase, there is a test for properties included in ObjFW
https://webkeks.org/hg/objfw, in src/PropertiesTests.m, which also fails. It
works well with the Apple runtime and the included properties implementation in
src/objc-properties.m - this is also the implementation I'd like to contribute.
Let me know if you are interested.

Direct links:
Runtime I'd like to contribute:
https://webkeks.org/hg/objfw/file/tip/src/objc_properties.m (Will relicense
if there's interest!)
Tests that fail:
https://webkeks.org/hg/objfw/file/tip/tests/PropertiesTests.m


[Bug target/46729] Many 32-bit 30_threads execution tests fail on Solaris 10+/SPARC with as

2010-12-19 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46729

--- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-19 
12:19:16 UTC ---
Author: ebotcazou
Date: Sun Dec 19 12:19:12 2010
New Revision: 168049

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168049
Log:
PR target/46729
* config/sparc/sparc.h (GLOBAL_OFFSET_TABLE_REGNUM): New macro.
(PIC_OFFSET_TABLE_REGNUM): Rewrite in terms of above macro.
* config/sparc/sparc.c (pic_helper_needed): Delete.
(global_offset_table): Likewise.
(pic_helper_symbol): Rename to...
(got_helper_rtx): ...this.
(global_offset_table_rtx): New global variable.
(sparc_got_symbol): Likewise.
(sparc_got): New static function.
(check_pic): Use local variable and call sparc_got.
(sparc_tls_symbol): Initialize to NULL_RTX.
(sparc_tls_got): In non-PIC mode, reload the GOT register for Sun TLS
and 32-bit ABI and copy the GOT symbol to a new register otherwise.
(get_pc_thunk_name): Rename local variable.
(gen_load_pcrel_sym): New wrapper around load_pcrel_sym{si,di}.
(load_pic_register): Rename to...
(load_got_register): ...this.  Adjust and call gen_load_pcrel_sym.
(sparc_expand_prologue): Do not test flag_pic.
(sparc_output_mi_thunk): Use pic_offset_table_rtx directly.
(sparc_file_end): Test got_helper_rtx instead of pic_helper_needed.
Rename local variable and do not call get_pc_thunk_name again.
* config/sparc/sparc.md (load_pcrel_sym): Add operand #3.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c
trunk/gcc/config/sparc/sparc.h
trunk/gcc/config/sparc/sparc.md


[Bug target/46729] Many 32-bit 30_threads execution tests fail on Solaris 10+/SPARC with as

2010-12-19 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46729

--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-19 
12:20:12 UTC ---
Author: ebotcazou
Date: Sun Dec 19 12:20:08 2010
New Revision: 168050

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168050
Log:
PR target/46729
* config/sparc/sparc.h (GLOBAL_OFFSET_TABLE_REGNUM): New macro.
(PIC_OFFSET_TABLE_REGNUM): Rewrite in terms of above macro.
* config/sparc/sparc.c (pic_helper_needed): Delete.
(global_offset_table): Likewise.
(pic_helper_symbol): Rename to...
(got_helper_rtx): ...this.
(global_offset_table_rtx): New global variable.
(sparc_got_symbol): Likewise.
(sparc_got): New static function.
(check_pic): Use local variable and call sparc_got.
(sparc_tls_symbol): Initialize to NULL_RTX.
(sparc_tls_got): In non-PIC mode, reload the GOT register for Sun TLS
and 32-bit ABI and copy the GOT symbol to a new register otherwise.
(get_pc_thunk_name): Rename local variable.
(gen_load_pcrel_sym): New wrapper around load_pcrel_sym{si,di}.
(load_pic_register): Rename to...
(load_got_register): ...this.  Adjust and call gen_load_pcrel_sym.
(sparc_expand_prologue): Do not test flag_pic.
(sparc_output_mi_thunk): Use pic_offset_table_rtx directly.
(sparc_file_end): Test got_helper_rtx instead of pic_helper_needed.
Rename local variable and do not call get_pc_thunk_name again.
* config/sparc/sparc.md (load_pcrel_sym): Add operand #3.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/sparc/sparc.c
branches/gcc-4_5-branch/gcc/config/sparc/sparc.h
branches/gcc-4_5-branch/gcc/config/sparc/sparc.md


[Bug target/46729] 32-bit 30_threads execution tests fail on Solaris 10/SPARC with Sun as

2010-12-19 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46729

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-12-19 
12:24:53 UTC ---
They should pass now.


[Bug fortran/46797] libquadmath: make install relinks libgfortran

2010-12-19 Thread rwild at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46797

Ralf Wildenhues rwild at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-12-19 
12:27:49 UTC ---
Closing as invalid.  Issues resulting from the relinking behavior are tracked
in PR 46607.

Thanks.


[Bug target/46729] 32-bit 30_threads execution tests fail on Solaris 10/SPARC with Sun as

2010-12-19 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46729

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

Version|4.6.0   |4.5.2
   Target Milestone|--- |4.5.3


[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852

2010-12-19 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334

--- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr 
2010-12-19 13:37:17 UTC ---
 Could you try if this solves the problem?

The patch in comment #14 fixed the problem on x86_64-apple-darwin10 (I cannot
say anything for AMD). I have run the polyhedron tests without noticing any
slow down. I'll do a clean regstrap tonight. Thanks for the patch.


[Bug testsuite/29057] gcc.target/powerpc/ppc64-abi-1.c fails to compile on powerpc-apple-darwin8 at -m64

2010-12-19 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29057

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-19 
13:50:41 UTC ---
On powerpc-apple-darwin9 this seems to have been fixed between revisions 166105
and 166379. Could someone check on darwin8 if this PR is still there? TIA.


[Bug fortran/47007] Values from namelist file should not depend on locale settings

2010-12-19 Thread fenixk19 at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007

--- Comment #6 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 
13:54:58 UTC ---
Created attachment 22820
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22820
Test case


[Bug fortran/47007] Values from namelist file should not depend on locale settings

2010-12-19 Thread fenixk19 at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007

--- Comment #7 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 
13:58:35 UTC ---
$ gfortran -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) 

libc6 version - 2.12.1. This is from Ubuntu 10.10 repo, it is called Embedded
GNU C library there.


[Bug fortran/47007] Values from namelist file should not depend on locale settings

2010-12-19 Thread fenixk19 at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007

--- Comment #8 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 
14:13:24 UTC ---
Created attachment 22821
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22821
Write namelist test case

Here is also test case for writing namelist. It shows, that '.' is used
whatever locale is selected. It is fun - i can generate namelist file on ru_RU
with '.' as decimal, and then program will fail to  read it on the same locale,
because it expects ','. Moreover, ',' can't be used as decimal, because it is
used to separate values in namelist.


[Bug testsuite/47013] New: FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS succeeded *

2010-12-19 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013

   Summary: FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms SMS
succeeded *
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: e...@il.ibm.com
Target: powerpc*-*-*


I believed that a PR has been opened for this failures, but I cannot find any.
Since over a year (see
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02672.html to
http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01632.html ) The following
tests

FAIL: gcc.dg/sms-2.c scan-rtl-dump-times sms SMS succeeded 1
FAIL: gcc.dg/sms-4.c scan-rtl-dump-times sms SMS succeeded 1
FAIL: gcc.dg/sms-5.c scan-rtl-dump-times sms SMS succeeded 1
FAIL: gcc.dg/sms-6.c scan-rtl-dump-times sms SMS succeeded 3
FAIL: gcc.dg/sms-7.c scan-rtl-dump-times sms SMS succeeded 3
FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 1

fail on powerpc*-*-* for both -m32 and -m64. In addition on
powerpc-apple-darwin9

FAIL: gcc.dg/sms-3.c scan-rtl-dump-times sms SMS succeeded 1

also fails with -m32. The dumps for sms-2.c are

[karma] f90/bug% less sms-2.c.180r.sms 

;; Function fun (fun)

(note 1 0 4 NOTE_INSN_DELETED)

(note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 3 4 0 2 NOTE_INSN_FUNCTION_BEG)


try_optimize_cfg iteration 1

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
Reordered sequence:
 2 compensation  [1]
(note 1 0 4 NOTE_INSN_DELETED)

(note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 3 4 0 2 NOTE_INSN_FUNCTION_BEG)
starting the processing of deferred insns
ending the processing of deferred insns

[karma] f90/bug% less sms-2.c.189r.sms

;; Function fun (fun)

(note 1 0 4 NOTE_INSN_DELETED)

(note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 3 4 0 2 NOTE_INSN_FUNCTION_BEG)


try_optimize_cfg iteration 1

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
Reordered sequence:
 2 compensation  [1]
(note 1 0 4 NOTE_INSN_DELETED)

(note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 3 4 0 2 NOTE_INSN_FUNCTION_BEG)
starting the processing of deferred insns
ending the processing of deferred insns


[Bug c++/47014] New: internal compiler error: tree check: expected tree that contains ‘decl minimal’ structure, have ‘nop_expr’ in decl_linkage, at cp/tree.c:2975

2010-12-19 Thread 1zeeky at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47014

   Summary: internal compiler error: tree check: expected tree
that contains ‘decl minimal’ structure, have
‘nop_expr’ in decl_linkage, at cp/tree.c:2975
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 1ze...@gmail.com


Created attachment 22822
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22822
testcase

I (unsuccessfully) tried passing a lambda as a template-parameter and resorted
to reinterpret_casting it to a normal function-pointer, which caused an
internal compiler error and gcc telling me to report it.

$ gcc -v --save-temps -std=c++0x test.cpp
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-gold --enable-ld --with-gold
--enable-lto --disable-multilib --enable-languages=c,c++,lto --enable-threads
Thread model: posix
gcc version 4.6.0 20101212 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -E -quiet -v
-D_GNU_SOURCE test.cpp -mtune=generic -march=x86-64 -std=c++0x -fpch-preprocess
-o test.ii
ignoring nonexistent directory
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -fpreprocessed
test.ii -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test
-std=c++0x -version -o test.s
GNU C++ (GCC) version 4.6.0 20101212 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20101212 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.6.0 20101212 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20101212 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 1c7bc545debdfc2a0b314e4103e7e06d
test.cpp:8:18: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘nop_expr’ in decl_linkage, at cp/tree.c:2975
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

I've attached test.cpp, which is very short and has almost the same contents as
test.ii anyways.


[Bug fortran/47007] Values from namelist file should not depend on locale settings

2010-12-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.19 14:41:16
 Ever Confirmed|0   |1

--- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 
14:41:16 UTC ---
I can reproduce this. It only occurs if one explicitly calls setlocale - as
by default the locale for C programs is LC_ALL=C, which works.

As the locale can be change all the time, one would need to do:

  char *cur_locale;
  cur_local = setlocale(LC_NUMERIC, NULL);
  setlocale(LC_NUMERIC, );
  ...
  setlocale(LC_NUMERIC, cur_locale);

around each and every READ transfer statement ...


[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

2010-12-19 Thread mikael at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46978

--- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2010-12-19 
15:47:14 UTC ---
This seems to be the problem :
the front-end generates a transposed descriptor for a non-intrinsic function. 
If the function is an intrinsic, the descriptor is filled in the library, and
it is not transposed.


[Bug testsuite/45342] FAIL: gcc.dg/tls/thr-cse-1.c scan-assembler-not emutls_get_address.*emutls_get_address.*

2010-12-19 Thread danglin at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45342

--- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2010-12-19 
15:51:25 UTC ---
Author: danglin
Date: Sun Dec 19 15:51:22 2010
New Revision: 168060

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168060
Log:
PR testsuite/45342
* gcc.dg/tls/thr-cse-1.c: Fix match on hppa*-*-hpux*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tls/thr-cse-1.c


[Bug testsuite/45342] FAIL: gcc.dg/tls/thr-cse-1.c scan-assembler-not emutls_get_address.*emutls_get_address.*

2010-12-19 Thread danglin at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45342

John David Anglin danglin at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2010-12-19 
15:56:25 UTC ---
Fixed by patch.


[Bug target/46972] __thread storage class variable gets optimized out on ARM

2010-12-19 Thread paulius.zaleckas at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46972

--- Comment #4 from Paulius Zaleckas paulius.zaleckas at gmail dot com 
2010-12-19 16:07:15 UTC ---
Created attachment 22823
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22823
diff with and without -fsection-anchors

I have found out that it is -fsection-anchors optimization causing this bug.
Attached -S assembler output diff with and without this option.


[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

2010-12-19 Thread paolo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46869

--- Comment #14 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 
2010-12-19 16:20:29 UTC ---
Author: paolo
Date: Sun Dec 19 16:20:25 2010
New Revision: 168063

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168063
Log:
2010-12-19  John David Anglin  dave.ang...@nrc-cnrc.gc.ca

PR libstdc++/46869
* testsuite/20_util/enable_shared_from_this/cons/constexpr.cc:
Compile with -g0.
* testsuite/20_util/shared_ptr/cons/constexpr.cc: Likewise.
* testsuite/20_util/unique_ptr/cons/constexpr.cc: Likewise.
* testsuite/20_util/weak_ptr/cons/constexpr.cc: Likewise.


Modified:
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/testsuite/20_util/enable_shared_from_this/cons/constexpr.cc
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/constexpr.cc
trunk/libstdc++-v3/testsuite/20_util/unique_ptr/cons/constexpr.cc
trunk/libstdc++-v3/testsuite/20_util/weak_ptr/cons/constexpr.cc


[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

2010-12-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46869

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|bkoz at gcc dot gnu.org,|
   |paolo.carlini at oracle dot |
   |com |
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-19 
16:22:39 UTC ---
Committed.


[Bug fortran/47007] Values from namelist file should not depend on locale settings

2010-12-19 Thread jvdelisle at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007

Jerry DeLisle jvdelisle at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jvdelisle at gcc dot
   |gnu.org |gnu.org

--- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-12-19 
17:47:54 UTC ---
Putting the Fortran standard aside for a moment, it seems reasonable to me that
we do something about this bug, even if it is as an extension. I have assigned
to myself and will give it some thought before I suggest a solution.

Thanks for the report.


[Bug fortran/47007] Values from namelist file should not depend on locale settings

2010-12-19 Thread fenixk19 at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007

--- Comment #11 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 
18:04:04 UTC ---
I was glad to help.


[Bug c++/47014] [C++0x] ICE: tree check: expected tree that contains ‘decl minimal’ structure, have ‘nop_expr’ in decl_linkage, at cp/tree.c:2975

2010-12-19 Thread 1zeeky at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47014

--- Comment #1 from 1zeeky at gmail dot com 2010-12-19 18:04:41 UTC ---
The problem arises (or at least seems to) whenever you 'force' (i.e. via
reinterpret_cast) a non-function as template-parameter (e.g. an int fails to
compile with almost the same ICE).
That would imply that a lambda is not regarded as a proper function, as the
following fails as well with the same ICE as already posted:

templatevoid (fn)()
class LambdaFunctor
{
};

LambdaFunctor*[](){} functor;


[Bug libobjc/47012] nonatomic Properties behave wrong

2010-12-19 Thread nicola at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

Nicola Pero nicola at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.19 18:31:43
 CC||nicola at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 18:31:43 
UTC ---
Hi Jonathan

nice to hear from you again (we met at Fosdem a few years ago, not sure you
remember me; I do remember you). ;-)

You are right that the GNU runtime does [[x retain] autorelease] before 
returning the value for an object, nonatomic synthesized property .  The reason 
everyone but Apple does it, I suppose, it is because everyone felt it is a bug 
in the Apple implementation. ;-)

The additional retain/autorelease should make it safer (but slower) than the
Apple implementation; I don't think it should cause it to behave differently
(other than prevent the object from being released until the next autorelease
pool is emptied).  Do you have a testcase where an actual difference in 
behaviour (other than the object being safe to use for longer, and the 
implementation with autorelease/retain being obviously slower) can be seen ?

I guess you're concerned about performance ?

Do you have any evidence that Apple did that on purpose and it's not a bug ?  
If you have any such evidence [ie, they won't fix it at the next release and 
we'll suddenly be the broken ones ;-)], we should certainly change it to 
behave in the same way.

Maybe we should change it to behave in the same way anyway ;-)

Thanks

PS: Your contribution to GCC's libobjc would be much appreciated.  The existing 
implementation of properties accessors is fairly finished though --

http://gcc.gnu.org/viewcvs/trunk/libobjc/accessors.m?revision=165903view=markup

It would be a one-liner to make the change if we want to.


[Bug libobjc/45953] Registering untyped selector mutates existing selector

2010-12-19 Thread nicola at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45953

Nicola Pero nicola at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.19 18:35:08
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 18:35:08 
UTC ---
Yes, it's confirmed.

Thanks


[Bug libobjc/47012] nonatomic Properties behave wrong

2010-12-19 Thread js-gcc at webkeks dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

--- Comment #2 from js-gcc at webkeks dot org js-gcc at webkeks dot org 
2010-12-19 18:49:39 UTC ---
Hi Nicola,

yes, I do remember our talk at FOSDEM and I plan to attend it next year again,
since I unfortunately could not attend it this year.

Well, I guess it's not really like this because everyone felt this is better, I
guess it is because Cocotron was the first to implement it (IIRC), then GNUstep
looked how they solved it and now GCC looked how GNUstep solved it ;).

I think it's not a bug, but intended, as not only the Apple runtime handles it
like that, but the doc also says it's just a return. So the documented
behaviour and the real behaviour are in sync, I guess the name nonatomic was
just a bad choice and the real idea was to have a way to create a lightweight
accessor which is mostly used internally. There are several hints that
nonatomic is thought for internal use in the formulations used by Apple. Plus,
if you care that much about performance that the spinlock is too much for you,
then autoreleasing would definitely also be a problem for you ;).

I mostly use nonatomic in some special cases like exceptions where the object
which caused the exception should not be retained and autoreleased to prevent
exception-loops (for example, if autorelease caused the exception to be thrown,
that'd be a problem here).

In the code you linked, is that objc_mutex_t a spinlock? If not, this might be
performance problem.

Speaking of performance and contributing: I wrote my own runtime some time ago.
The lookup is twice as fast as in libobjc in my tests (with ASM enabled even
more). Maybe we could work on merging that into libobjc on next FOSDEM? I
mostly wrote my runtime because there weren't any changes in the GNU runtime
for a long time and I was happy to see that things finally changed with gcc 4.6
:).

If you want to have a look: https://webkeks.org/hg/objfw-rt
(Hint: Thread-safety is still missing, though the data structure for the lookup
only needs a write-lock and no read-lock and can still be read while it is
written and it's also missing exceptions (copying the exception.c from GNU
libobjc works))

I think it would be great to also work with the guys from Clang. I think it
would only make sense to have the same runtime on all non-Apple systems,
regardless of the compiler.


[Bug c++/39511] Bad warning, with return type, switch and enum

2010-12-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39511

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-19 
18:55:30 UTC ---
The URL for preprocessed source gives a 404 now.

The enum has a range 0-7 and if you call parityToString(ParityType(5)) then
control falls off the end of the function, so the warning is correct.


[Bug fortran/46520] [4.6 Regression] libquadmath: fails at link test on bare irons

2010-12-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520

--- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 
19:01:41 UTC ---
Author: burnus
Date: Sun Dec 19 19:01:38 2010
New Revision: 168069

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168069
Log:
2010-12-19  Tobias Burnus  bur...@net-b.de

PR fortran/46520
* configure.ac: Do not call AC_CHECK_LIB for gcc_no_link.
* configure: Regenerate


Modified:
trunk/libquadmath/ChangeLog
trunk/libquadmath/configure
trunk/libquadmath/configure.ac


[Bug libobjc/47012] nonatomic Properties behave wrong

2010-12-19 Thread nicola at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

--- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 19:10:29 
UTC ---
Author: nicola
Date: Sun Dec 19 19:10:26 2010
New Revision: 168070

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168070
Log:
In libobjc/:
2010-12-19  Nicola Pero  nicola.p...@meta-innovation.com

PR libobjc/47012
* accessors.m (objc_getProperty): If not atomic, do not
retain/autorelease the returned value. (Problem reported by

Modified:
trunk/libobjc/ChangeLog
trunk/libobjc/accessors.m


[Bug libobjc/47012] nonatomic Properties behave wrong

2010-12-19 Thread nicola at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

--- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 19:12:33 
UTC ---
Yes, I was actually thinking about this, and you're right - it makes sense not
to use retain/autorelease! ;-)

'nonatomic' means that other threads are not involved.  Which also means that
the programmer calling the accessor has full control of what happens (there
aren't alternative flows of execution that may jump in); he should do the
retain/autorelease himself if there is a risk that something he does while
using the object returned may call the accessor setter and trigger a release of
the object; else, he can get away without a retain/autorelease and get a good
speedup.

And doing the same that Apple does is obviously helpful for portability.

So I made the change in subversion.

Thanks

PS: GCC is currently in bug-fixing mode only for 4.6 so we can't accept
non-bug-fix changes, but as soon as it reopens, you're very welcome to
contribute.  Faster method lookup sounds very exciting (and non-trivial).


[Bug libobjc/47012] nonatomic Properties behave wrong

2010-12-19 Thread nicola at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

Nicola Pero nicola at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2010-12-19 19:14:49 
UTC ---
Fixed in trunk (will be GCC 4.6).

Thanks


[Bug libobjc/47012] nonatomic Properties behave wrong

2010-12-19 Thread js-gcc at webkeks dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47012

--- Comment #6 from js-gcc at webkeks dot org js-gcc at webkeks dot org 
2010-12-19 19:19:33 UTC ---
Well, I did not plan to get that included in 4.6.

If you are interested in optimizing the lookup: The lookup could be greatly
improved if we also change the ABI, which is currently the limitation as the
current ABI does not allow for coherent inline caching etc. This needs changes
in the compiler, therefore I did not do that - maintaining a runtime AND
patchset for two compilers really is too much work for a single person ;).

I'd love to work on that, will you visit FOSDEM next year? If so, we could meet
up there and hack on that :). I'd really love to reduce the extremely huge
speed difference between the GNU runtime and the Apple runtime. At the moment,
dispatch is more than 5 times faster with GNU (at least that's what I measured
some time ago on Leopard, I guess with Snow Leopard it might be even more).


[Bug lto/46905] -flto -fno-lto does not disable lto

2010-12-19 Thread ak at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905

--- Comment #3 from ak at gcc dot gnu.org 2010-12-19 19:36:29 UTC ---
Author: ak
Date: Sun Dec 19 19:36:25 2010
New Revision: 168071

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168071
Log:
Fix -fno-lto (PR lto/46905)

gcc/

2010-12-19  Andi Kleena...@linux.intel.com

PR lto/46905
* collect2.c (main): Handle -fno-lto.
* opts.c (common_handle_option): Handle -fno-lto.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/collect2.c
trunk/gcc/opts.c


[Bug target/46972] __thread storage class variable gets optimized out on ARM

2010-12-19 Thread paulius.zaleckas at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46972

--- Comment #5 from Paulius Zaleckas paulius.zaleckas at gmail dot com 
2010-12-19 19:39:07 UTC ---
Did some testing through various GCC versions:

4.5.2 - buggy
4.4.5 - buggy
4.3.5 - OK, but does not have -fsection-anchors optimization for ARM


[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm

2010-12-19 Thread danglin at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915

--- Comment #14 from John David Anglin danglin at gcc dot gnu.org 2010-12-19 
19:50:20 UTC ---
Author: danglin
Date: Sun Dec 19 19:50:17 2010
New Revision: 168072

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168072
Log:
Backport from mainline:
2010-12-18  John David Anglin  dave.ang...@nrc-cnrc.gc.ca

PR target/46915
* config/pa/pa.c (branch_to_delay_slot_p): Use next_active_insn instead
of next_real_insn.  Search forward checking for both ASM_INPUT and
ASM_OPERANDS asms until exit condition is found.
(branch_needs_nop_p): Likewise.
(use_skip_p): New function.
(output_cbranch): Use use_skip_p.
(output_bb, output_bvb): Likewise.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/pa/pa.c


[Bug ada/46950] Stage 3 ada bootstrap error on i686-apple-darwin9

2010-12-19 Thread danglin at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46950

--- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2010-12-19 
20:11:52 UTC ---
Introduced by following change:

2010-12-12  Jan Hubicka  j...@suse.cz
Rainer Orth  r...@cebitec.uni-bielefeld.de

* varasm.c (default_function_section): Check flag_reorder_functions
and targetm.have_named_sections.
* config/darwin.c (darwin_function_section): Check
flag_reorder_functions.


[Bug target/46950] Stage 3 ada bootstrap error on i686-apple-darwin9

2010-12-19 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46950

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-19 
20:20:16 UTC ---
The same revision caused pr46916. Could you try the patch in
http://gcc.gnu.org/bugzilla/attachment.cgi?id=22787 ?


[Bug target/47015] New: gcc/gengtype.c: undefined references

2010-12-19 Thread brooks.brian at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47015

   Summary: gcc/gengtype.c: undefined references
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: brooks.br...@gmail.com


make fails, see attachment.

Ubuntu 10.10 64-bit, checked out latest svn source as of Dec 19, noon.


[Bug target/47015] gcc/gengtype.c: undefined references

2010-12-19 Thread brooks.brian at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47015

--- Comment #1 from Brian Brooks brooks.brian at gmail dot com 2010-12-19 
20:30:33 UTC ---
Created attachment 22824
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22824
make log

command: sudo make -j8


[Bug bootstrap/47016] New: bootstrap on darwin needs much more disk space than expected to complete

2010-12-19 Thread Denis.Excoffier at airbus dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47016

   Summary: bootstrap on darwin needs much more disk space than
expected to complete
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: denis.excoff...@airbus.com


Created attachment 22825
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22825
created during stage2-gcc, produces a huge temporary during compare-debug

I have bootstraped GCC 4.5.2 on darwin (ppc 9.8.0) successfully, with all
default options, in
particular bootstrap-debug.

Nevertheless i noticed that the disk space used is 2Gb more than expected. This
is due to the
- contrib/compare-debug script
- that uses, in case of Darwin: ld -S -r -no_uuid xxx.o -o xxx.o.stripped
(instead of a simple strip)
- which produces:
  - for the host-darwin.o created during stage2 (with -gtoggle)
  - and also for the host-darwin.o created during stage3 (without -gtoggle)
  a huge host-darwin.o.stripped containing 1Gb with many many zeroes
  (all the other xxx.o in stage2-gcc or stage3-gcc are ok)

As a coincidence, both host-darwin.o.stripped are exactly equal, therefore no
failure in comparison of stage2 and stage3, and consequently no failure in
bootstrap. Of
course if you don't have such extra disk space, something will surely fail. I
could suggest, in case this is not a local problem occurring only to my
configuration, to add gcc/host-darwin.o in compare_exclusions (in the main
./configure).

Attached stage2-gcc/host-darwin.o. I can also add stage2/host-darwin.o.stripped
(ie `od -c`on it) if
needed.

I cannot say whether the host-darwin.o created for GCC 4.5.1 had the same
problem.

I suppose this could be also reported to Apple, but in case someone meets that
very same
problem, a bypass is given: increase free disk space.


[Bug c++/20478] poor parse error diagnostic with missing right paren in vecflow())))

2010-12-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20478

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever Confirmed|1   |0

--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-19 
20:55:54 UTC ---
99% of the original code is irrelevant to the parse error. This seems to be a
reasonable approximation of the testcase:

templatetypename T
struct opApi
{
  opApi(const char*, int);
};

templatetypename T struct vec { };

typedef int flow;

int deDup(int);
int pop(int, vecflow);

int main()
{
  opApiflow flowApis[2] = {
 opApiflow(, deDup(
  pop(0,
  vecflow())),
 opApiflow(, deDup(
  pop(0,
  vecflow(
  };
}

then that can be further reduced to

struct opApi
{
  opApi(int);
};

struct vec { };

int deDup(vec);

int main()
{
  opApi flowApis[2] = {
 opApi(deDup(
  vec()),
 opApi(deDup(
  vec()))
  };

}

Current releases don't complain about a missing default constructor (presumably
they stop after the earlier parse error).


[Bug c++/46901] Error message repeats itself

2010-12-19 Thread goeran at uddeborg dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46901

Göran Uddeborg goeran at uddeborg dot se changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #4 from Göran Uddeborg goeran at uddeborg dot se 2010-12-19 
20:59:17 UTC ---
Looks good in 4.6-b20101218.


[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

2010-12-19 Thread amylaar at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677

--- Comment #15 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 
2010-12-19 21:21:30 UTC ---
Author: amylaar
Date: Sun Dec 19 21:21:26 2010
New Revision: 168075

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168075
Log:
PR other/46677
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02772.html
gcc:
* targhooks.c (pointer_size): New function.
* cppbuiltin.c (define_builtin_macros_for_lp64): Use pointer_size.
(define_builtin_macros_for_type_sizes): Likewise.
* target.h (pointer_size): Declare.

* cppbuiltin.c (define_builtin_macros_for_type_sizes):
Use TYPE_PRECISION (char_type_node).
gcc/c-family:
c-common.c (c_common_nodes_and_builtins): Use pointer_size.
gcc/java:
* decl.c (java_init_decl_processing): Use pointer_size.
* java-tree.h (JAVA_POINTER_SIZE): Define.
* class.c (make_class_data): Use JAVA_POINTER_SIZE.
(emit_register_classes): Likewise.
* jcf-parse.c (handle_long_constant): Likewise.
* constants.c (build_constants_constructor): Likewise.
* builtins.c (UNMARSHAL3, UNMARSHAL4, UNMARSHAL5): Likewise.
(compareAndSwapObject_builtin): Likewise.
* boehm.c (get_boehm_type_descriptor): Likewise.
(mark_reference_fields): Add log2_size parameter.  Changed all callers.
gcc/cp:
* cvt.c (cp_convert_to_pointer): Use TYPE_PRECISION (ptr_type_node).
gcc/fortran:
* trans-types.c (gfc_init_kinds): Use pointer_size.
gcc/lto:
* lto-object.c (lto_obj_begin_section): Use pointer_size.
ada:
* gcc-interface/decl.c (gnat_to_gnu_entity): Replace pointer_size
with pointer_size_t.  Replace POINTER_SIZE with pointer_size ().
(rest_of_type_decl_compilation_no_defer): Use pointer_size.
(gnat_to_gnu_param, annotate_rep, make_type_from_size): Likewise.
* gcc-interface/utils2.c: Include target.h .
(maybe_wrap_malloc, maybe_wrap_free): Use pointer_size.
* gcc-interface/targtyps.c: Include target.h .
(get_target_pointer_size): Use pointer_size.

Modified:
branches/pr46489-20101217-branch/gcc/ChangeLog.46489
branches/pr46489-20101217-branch/gcc/ada/gcc-interface/decl.c
branches/pr46489-20101217-branch/gcc/ada/gcc-interface/targtyps.c
branches/pr46489-20101217-branch/gcc/ada/gcc-interface/utils2.c
branches/pr46489-20101217-branch/gcc/c-family/c-common.c
branches/pr46489-20101217-branch/gcc/cp/cvt.c
branches/pr46489-20101217-branch/gcc/cppbuiltin.c
branches/pr46489-20101217-branch/gcc/fortran/f95-lang.c
branches/pr46489-20101217-branch/gcc/fortran/trans-types.c
branches/pr46489-20101217-branch/gcc/java/boehm.c
branches/pr46489-20101217-branch/gcc/java/builtins.c
branches/pr46489-20101217-branch/gcc/java/class.c
branches/pr46489-20101217-branch/gcc/java/constants.c
branches/pr46489-20101217-branch/gcc/java/decl.c
branches/pr46489-20101217-branch/gcc/java/java-tree.h
branches/pr46489-20101217-branch/gcc/java/jcf-parse.c
branches/pr46489-20101217-branch/gcc/lto/lto-object.c
branches/pr46489-20101217-branch/gcc/target.h
branches/pr46489-20101217-branch/gcc/targhooks.c


[Bug ada/47017] New: [4.6 Regression] gnatlib ICE on sparc64-linux

2010-12-19 Thread laurent at guerby dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47017

   Summary: [4.6 Regression] gnatlib ICE on sparc64-linux
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: laur...@guerby.net
CC: ebotca...@gcc.gnu.org
  Host: sparc64-linux
Target: sparc64-linux
 Build: sparc64-linux


/home/guerby/build/./gcc/xgcc -B/home/guerby/build/./gcc/
-B/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/bin/
-B/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/lib/ -isystem
/n/62/guerby/\
install-trunk-64/sparc64-unknown-linux-gnu/include -isystem
/n/62/guerby/install-trunk-64/sparc64-unknown-linux-gnu/sys-include-c -g
-O2  -fPIC  -W -Wall -gnatpg   a-cdlili.adb -o a-cdlili.o
+===GNAT BUG DETECTED==+
| 4.6.0 20101218 (experimental) [trunk revision 168022]
(sparc64-unknown-linux-gnu) |
| Storage_Error stack overflow (or erroneous memory access)|
| Error detected at s-finroo.ads:53:4  |

compilation abandoned
make[7]: *** [a-cdlili.o] Error 1
make[7]: Leaving directory `/home/guerby/build/gcc/ada/rts'
make[6]: *** [gnatlib] Error 2
make[6]: Leaving directory `/home/guerby/build/gcc/ada'
make[5]: *** [gnatlib-shared-default] Error 2
make[5]: Leaving directory `/home/guerby/build/gcc/ada'
make[4]: *** [gnatlib-shared-dual] Error 2
make[4]: Leaving directory `/home/guerby/build/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory `/home/guerby/build/gcc/ada'
make[2]: *** [gnatlib-shared] Error 2
make[2]: Leaving directory
`/home/guerby/build/sparc64-unknown-linux-gnu/libada'
make[1]: *** [all-target-libada] Error 2
make[1]: Leaving directory `/home/guerby/build'
make: *** [bootstrap] Error 2

../trunk/configure --prefix=/n/62/guerby/install-trunk-64 --disable-werror
--enable-languages=c,fortran,ada --enable-__cxa_atexit --disable-nls
--enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1-64 --\
with-gmp=/opt/cfarm/gmp-4.2.4-64 --with-mpc=/opt/cfarm/mpc-0.8-64
export CC=gcc -m64


[Bug fortran/47007] Values from namelist file should not depend on locale settings

2010-12-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007

--- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-19 
21:32:49 UTC ---
Vaguely related: PR 35862 (rounding on input). Both PR 35862 and this PR seem
to require writing a libgfortran-specific version of
strtof/strtod/strtold/quadmath_strtopQ - currently, the system's version is
called in convert_real.

The only alternatives I see are:
a) To reset the locale for every READ statement ('setlocale(LC_NUMERIC, C)')
- and restore it afterwards.
b) To use localeconv and convert the decimal sign appropriately in the string
(as currently done for DECIMAL=comma) - again, this needs to happen for every
READ statement
c) Simply document (gfortran.texi) that messing around with setlocale might
produce surprising results. [LC_ALL/LANG environment variables do not have any
effect unless setlocale is explicitly called. Cf.
http://www.opengroup.org/onlinepubs/007904875/functions/setlocale.html]

I think (a) and (b) are (too) slow and cumbersome and regarding (c): No one
reads the documentation.


[Bug target/46972] __thread storage class variable gets optimized out on ARM

2010-12-19 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46972

--- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-19 
21:53:14 UTC ---
I think enumtls has been fixed on the trunk with respect of fsection-anchors. 
Can you try the trunk?


[Bug target/47015] gcc/gengtype.c: undefined references

2010-12-19 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47015

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.12.19 21:56:59
 Ever Confirmed|0   |1

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-19 
21:56:59 UTC ---
gengtype-lex.c:1: warning: ISO C forbids an empty translation unit


Do you have GNU flex installed?


[Bug target/47015] gcc/gengtype.c: undefined references

2010-12-19 Thread brooks.brian at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47015

--- Comment #3 from Brian Brooks brooks.brian at gmail dot com 2010-12-19 
22:05:42 UTC ---
(In reply to comment #2)
 gengtype-lex.c:1: warning: ISO C forbids an empty translation unit
 
 
 Do you have GNU flex installed?

Yes, under /usr/bin/flex


[Bug target/46950] Stage 3 ada bootstrap error on i686-apple-darwin9

2010-12-19 Thread dave at hiauly1 dot hia.nrc.ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46950

--- Comment #3 from dave at hiauly1 dot hia.nrc.ca 2010-12-20 00:36:28 UTC ---
On Sun, 19 Dec 2010, dominiq at lps dot ens.fr wrote:

 The same revision caused pr46916. Could you try the patch in
 http://gcc.gnu.org/bugzilla/attachment.cgi?id=22787 ?

It resolves the ada build error.

Dave


[Bug debug/47018] New: ICE: in pre_and_rev_post_order_compute, at cfganal.c:1047 with -fnon-call-exceptions -fvar-tracking -g

2010-12-19 Thread zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47018

   Summary: ICE: in pre_and_rev_post_order_compute, at
cfganal.c:1047 with -fnon-call-exceptions
-fvar-tracking -g
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22826
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22826
reduced testcase

Compiler output:
$ gcc -fnon-call-exceptions -fvar-tracking -g pr47018.C 
pr47018.C: In function 'void foo(float)':
pr47018.C:12:1: internal compiler error: in pre_and_rev_post_order_compute, at
cfganal.c:1047
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

(gdb) bt
#0  fancy_abort (file=0x125c3a8 /mnt/svn/gcc-trunk/gcc/cfganal.c, line=1047, 
function=0x125c5c0 pre_and_rev_post_order_compute) at
/mnt/svn/gcc-trunk/gcc/diagnostic.c:892
#1  0x00724d27 in pre_and_rev_post_order_compute (pre_order=0x0,
rev_post_order=0x19495c0, 
include_entry_exit=0 '\000') at /mnt/svn/gcc-trunk/gcc/cfganal.c:1047
#2  0x00bc7b41 in vt_find_locations () at
/mnt/svn/gcc-trunk/gcc/var-tracking.c:6025
#3  0x00bc9475 in variable_tracking_main_1 () at
/mnt/svn/gcc-trunk/gcc/var-tracking.c:8522
#4  variable_tracking_main () at /mnt/svn/gcc-trunk/gcc/var-tracking.c:8567
#5  0x00939d96 in execute_one_pass (pass=0x17bb680) at
/mnt/svn/gcc-trunk/gcc/passes.c:1553
#6  0x0093a085 in execute_pass_list (pass=0x17bb680) at
/mnt/svn/gcc-trunk/gcc/passes.c:1608
#7  0x0093a097 in execute_pass_list (pass=0x17b8180) at
/mnt/svn/gcc-trunk/gcc/passes.c:1609
#8  0x0093a097 in execute_pass_list (pass=0x17b81e0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1609
#9  0x00a7a2a6 in tree_rest_of_compilation (fndecl=0x75d1c600) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:422
#10 0x00c3f552 in cgraph_expand_function (node=0x75d1f2c0) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1508
#11 0x00c41f1d in cgraph_output_in_order () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1661
#12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1822
#13 0x00c421aa in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1031
#14 0x005b75bd in cp_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:3974
#15 0x00a23b76 in compile_file (argc=16, argv=0x7fffdad8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591
#16 do_compile (argc=16, argv=0x7fffdad8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1874
#17 toplev_main (argc=16, argv=0x7fffdad8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1937
#18 0x76586bbd in __libc_start_main () from /lib/libc.so.6
#19 0x004fe711 in _start ()


Tested revisions:
r168061 - crash
4.5 r168062 - crash
4.4 r168062 - crash


[Bug middle-end/47019] New: [4.6 Regression] ICE: in rename_uses, at sese.c:535 with -O -ftree-pre -fgraphite-identity -fno-tree-copy-prop

2010-12-19 Thread zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47019

   Summary: [4.6 Regression] ICE: in rename_uses, at sese.c:535
with -O -ftree-pre -fgraphite-identity
-fno-tree-copy-prop
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: s...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22827
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22827
reduced testcase (from pr43097.f)

Compiler output:
$ gcc -O -ftree-pre -fgraphite-identity -fno-tree-copy-prop pr47019.f   
pr47019.f: In function 'foo':
pr47019.f:1:0: internal compiler error: in rename_uses, at sese.c:535
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

(gdb) bt
#0  fancy_abort (file=0x13aabe2 /mnt/svn/gcc-trunk/gcc/sese.c, line=535,
function=0x13aae34 rename_uses)
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892
#1  0x010aa42a in rename_uses (bb=value optimized out,
region=0x1842bf0, next_e=value optimized out, 
iv_map=0x1893720) at /mnt/svn/gcc-trunk/gcc/sese.c:535
#2  graphite_copy_stmts_from_block (bb=value optimized out, region=0x1842bf0,
next_e=value optimized out, 
iv_map=0x1893720) at /mnt/svn/gcc-trunk/gcc/sese.c:618
#3  copy_bb_and_scalar_dependences (bb=value optimized out, region=0x1842bf0,
next_e=value optimized out, 
iv_map=0x1893720) at /mnt/svn/gcc-trunk/gcc/sese.c:638
#4  0x0102b4ba in translate_clast_user (region=value optimized out,
context_loop=0x77ecfaa0, 
stmt=value optimized out, next_e=0x75ccea80, newivs=0x7fffd648,
newivs_index=0x1882570, 
bb_pbb_mapping=0x1855710, level=3, params_index=0x1882c60) at
/mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:947
#5  translate_clast (region=value optimized out, context_loop=0x77ecfaa0,
stmt=value optimized out, 
next_e=0x75ccea80, newivs=0x7fffd648, newivs_index=0x1882570,
bb_pbb_mapping=0x1855710, level=3, 
params_index=0x1882c60) at
/mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1115
#6  0x0102b145 in translate_clast_for_loop (region=value optimized
out, context_loop=0x77ecfa18, 
stmt=value optimized out, next_e=0x75cca6e0, newivs=0x7fffd648,
newivs_index=0x1882570, 
bb_pbb_mapping=0x1855710, level=2, params_index=0x1882c60) at
/mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1032
#7  translate_clast_for (region=value optimized out,
context_loop=0x77ecfa18, stmt=value optimized out, 
next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570,
bb_pbb_mapping=0x1855710, level=2, 
params_index=0x1882c60) at
/mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1065
#8  translate_clast (region=value optimized out, context_loop=0x77ecfa18,
stmt=value optimized out, 
next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570,
bb_pbb_mapping=0x1855710, level=2, 
params_index=0x1882c60) at
/mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1120
#9  0x0102b145 in translate_clast_for_loop (region=value optimized
out, context_loop=0x77ecfe58, 
stmt=value optimized out, next_e=0x75cca6e0, newivs=0x7fffd648,
newivs_index=0x1882570, 
bb_pbb_mapping=0x1855710, level=1, params_index=0x1882c60) at
/mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1032
#10 translate_clast_for (region=value optimized out,
context_loop=0x77ecfe58, stmt=value optimized out, 
next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570,
bb_pbb_mapping=0x1855710, level=1, 
params_index=0x1882c60) at
/mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1065
#11 translate_clast (region=value optimized out, context_loop=0x77ecfe58,
stmt=value optimized out, 
next_e=0x75cca6e0, newivs=0x7fffd648, newivs_index=0x1882570,
bb_pbb_mapping=0x1855710, level=1, 
params_index=0x1882c60) at
/mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1120
#12 0x0102c3d5 in gloog (scop=value optimized out,
bb_pbb_mapping=0x1855710)
at /mnt/svn/gcc-trunk/gcc/graphite-clast-to-gimple.c:1557
#13 0x010294d2 in graphite_transform_loops () at
/mnt/svn/gcc-trunk/gcc/graphite.c:286
#14 0x00a15327 in graphite_transforms () at
/mnt/svn/gcc-trunk/gcc/tree-ssa-loop.c:296
#15 0x0084f736 in execute_one_pass (pass=0x16b2a60) at
/mnt/svn/gcc-trunk/gcc/passes.c:1553
#16 0x0084fa25 in execute_pass_list (pass=0x16b2a60) at
/mnt/svn/gcc-trunk/gcc/passes.c:1608
#17 0x0084fa37 in execute_pass_list (pass=0x16b2ac0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1609
#18 0x0084fa37 in execute_pass_list (pass=0x16b2d60) at
/mnt/svn/gcc-trunk/gcc/passes.c:1609
#19 0x0084fa37 in execute_pass_list (pass=0x16b1f20) at

[Bug c++/47020] New: [4.6 Regression] [C++0x] ICE: unexpected expression 'foo' of kind overload when storing address of overloaded function

2010-12-19 Thread zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47020

   Summary: [4.6 Regression] [C++0x] ICE: unexpected expression
'foo' of kind overload when storing address of
overloaded function
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: ja...@gcc.gnu.org


-- testcase.C --
bool foo ();
bool foo (int);

struct S {
  bool (*foo) (int);
} s = {
  foo
};
---

Compiler output:
$ gcc -std=c++0x testcase.C 
testcase.C:8:1: internal compiler error: unexpected expression 'foo' of kind
overload
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r168061 - crash
4.5 r168062 - OK


[Bug tree-optimization/47002] [4.6 Regression] segmentation fault in find_uses_to_rename_use

2010-12-19 Thread spop at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47002

--- Comment #2 from Sebastian Pop spop at gcc dot gnu.org 2010-12-20 05:23:29 
UTC ---
I cannot reproduce the error on amd64-linux with ./cc1 -O3 bug.i
Please report the exact flags and the architecture.

However I can see several unrelated memory leaks (i.e., not the one reported)
with 
valgrind --leak-check=full ./cc1 -O3 bug.i


[Bug tree-optimization/47002] [4.6 Regression] segmentation fault in find_uses_to_rename_use

2010-12-19 Thread spop at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47002

--- Comment #3 from Sebastian Pop spop at gcc dot gnu.org 2010-12-20 05:25:00 
UTC ---
I tested tr...@168000.


[Bug tree-optimization/47021] New: graphite branch fails to bootstrap

2010-12-19 Thread spop at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47021

   Summary: graphite branch fails to bootstrap
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@gcc.gnu.org


Last message error on the auto-tester is while building the libstdc++:

libtool: compile: 
/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/./gcc/xgcc
-shared-libgcc -B/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/./gcc
-nostdinc++
-L/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
-L/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/n/16/grosser/daily_git_builds/install/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/bin/
-B/n/16/grosser/daily_git_builds/install/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/lib/
-isystem
/n/16/grosser/daily_git_builds/install/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/include
-isystem
/n/16/grosser/daily_git_builds/install/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/sys-include
-m32
-I/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/n/16/grosser/daily_git_builds/obj/2010_12_18_00_03_09/x86_64-unknown-linux-gnu/32/libstdc++-v3/include
-I/n/16/grosser/daily_git_builds/tmp_src/2010_12_18_00_03_09/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -m32 -std=gnu++0x -c
/n/16/grosser/daily_git_builds/tmp_src/2010_12_18_00_03_09/libstdc++-v3/src/debug.cc
 -fPIC -DPIC -o .libs/debug.o
/n/16/grosser/daily_git_builds/tmp_src/2010_12_18_00_03_09/libstdc++-v3/src/debug.cc:
In function ‘__gnu_cxx::__mutex {anonymous}::get_safe_base_mutex(void*)’:
/n/16/grosser/daily_git_builds/tmp_src/2010_12_18_00_03_09/libstdc++-v3/src/debug.cc:45:3:
internal compiler error: in scan_tree_for_params, at
graphite-sese-to-poly.c:851
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


[Bug c++/47022] New: ICE: in tsubst_copy, at cp/pt.c:11682

2010-12-19 Thread silver24k at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47022

   Summary: ICE: in tsubst_copy, at cp/pt.c:11682
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: silver...@gmail.com


Created attachment 22828
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22828
reduced code from wxWidget trunk

the trunk version of gcc ICEs when I try to build wxWidgets trunk

$ mingw32-gcc -v -c ice.cpp
Using built-in specs.
COLLECT_GCC=mingw32-gcc
COLLECT_LTO_WRAPPER=/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../libexec/gcc/mingw32/4.6.0/lto-wrapper
Target: mingw32
Configured with: ../../../gcc_trunk/configure --target=mingw32
--prefix=/platform/cross-on-linux/mingw
--with-build-time-tools=/platform/cross-on-linux/mingw --with-pkgversion='Cross
MingW32 GCC 4.6' --enable-shared --enable-static --enable-threads=win32
--enable-version-specific-runtime-libs --disable-win32-registry
--enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local
--with-mpc=/usr/local --with-ppl=/usr/local --with-cloog=/usr/local
--enable-languages=c,c++ --disable-nls --disable-libgcj --enable-lto
--disable-lto-plugin --enable-sjlj-exceptions
Thread model: win32
gcc version 4.6.0 20101219 (experimental) mingw-20090616 (Cross MingW32 GCC
4.6)
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=pentiumpro'

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../libexec/gcc/mingw32/4.6.0/cc1plus
-quiet -v -iprefix
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/
-D__MSVCRT_DLL__ ice.cpp -quiet -dumpbase ice.cpp -mtune=generic
-march=pentiumpro -auxbase ice -version -o /tmp/ccVwSqFd.s
GNU C++ (Cross MingW32 GCC 4.6) version 4.6.0 20101219 (experimental)
mingw-20090616 (mingw32)
compiled by GNU C version 4.4.3, GMP version 5.0.1, MPFR version
3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/../../../../mingw32/sys-include
ignoring duplicate directory
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++
ignoring duplicate directory
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++/mingw32
ignoring duplicate directory
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include/c++/backward
ignoring duplicate directory
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include
ignoring duplicate directory
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/include-fixed
ignoring nonexistent directory
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/../../../../mingw32/sys-include
ignoring duplicate directory
/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/../../lib/gcc/mingw32/4.6.0/../../../../mingw32/include
#include ... search starts here:
#include ... search starts here:

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include/c++

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include/c++/mingw32

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include/c++/backward

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/include-fixed

/home/starlight/src/gnu-toolchain/platform/cross-on-linux/mingw/bin/../lib/gcc/mingw32/4.6.0/../../../../mingw32/include
End of search list.
GNU C++ (Cross MingW32 GCC 4.6) version 4.6.0 20101219 (experimental)
compiled by GNU C version 4.4.3, GMP version 5.0.1, MPFR version
3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 77abd6679d94bf4b2788fa18297de959
ice.cpp: In function 'void foo(long double*, char*) [with _T = char, va_list =
char*]':
ice.cpp:12:25:   instantiated from here
ice.cpp:6:3: internal compiler error: in tsubst_copy, at cp/pt.c:11682
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

while gcc 4.4.3 (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)) gives:
ice.cpp: In function ‘void bar(__va_list_tag*)’:
ice.cpp:12: error: no matching function for call to ‘foo(long double*,
__va_list_tag*)’