[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

2010-04-08 Thread bart dot vanassche at gmail dot com


--- Comment #14 from bart dot vanassche at gmail dot com  2010-04-08 06:03 
---
(In reply to comment #13)
 I agree it's probably not worth backporting to a release branch, it wasn't a
 regression.
 
 Haven't affected users written valgrind suppression files by now? :)

Since the races on _S_empty_rep_storage are triggered by an inline function
many different suppression patterns would have to be added in order to suppress
these races. And adding such suppression patterns would suppress several real
races.


-- 


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



[Bug bootstrap/43681] bootstrap fails with unused var message for an apparently used var.

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #1 from jakub at gcc dot gnu dot org  2010-04-08 07:00 ---
Created an attachment (id=20331)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20331action=view)
gcc46-pr43681.patch

Untested patch.


-- 


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



[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604

2010-04-08 Thread dominiq at lps dot ens dot fr


--- Comment #15 from dominiq at lps dot ens dot fr  2010-04-08 07:48 ---
With the patch in comment #14, the test in comment #1 compiles and gives:

 evt=  234, flv=  1, col=  2, hel=  3, -0.122E-13 + i* 0.675E-14 ~ 0.267E-02
 evt=  234, flv=  1, col=  2, hel=  6, -0.122E-13 + i*-0.675E-14 ~ 0.267E-02
 evt=  289, flv=  1, col=  2, hel=  3, -0.161E-12 + i* 0.292E-12 ~ 0.446E-01
 evt=  289, flv=  1, col=  2, hel=  6, -0.161E-12 + i*-0.292E-12 ~ 0.446E-01
 evt=  380, flv=  1, col=  2, hel=  3,  0.102E-11 + i*-0.568E-13 ~ 0.817E-01
 evt=  380, flv=  1, col=  2, hel=  4, -0.383E-12 + i* 0.213E-13 ~ 0.817E-01
 evt=  380, flv=  1, col=  2, hel=  5, -0.383E-12 + i*-0.213E-13 ~ 0.817E-01
 evt=  380, flv=  1, col=  2, hel=  6,  0.102E-11 + i* 0.568E-13 ~ 0.817E-01
 evt=  380, flv=  1, col=  5, hel=  3, -0.108E-11 + i* 0.710E-12 ~ 0.217E+00
 evt=  380, flv=  1, col=  5, hel=  6, -0.108E-11 + i*-0.710E-12 ~ 0.217E+00
  10  failures in4  attempts
STOP 1

Regtested without failure.


-- 


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



[Bug target/43635] [4.5/4.6 Regression] ICE in s390_emit_call, at config/s390/s390.c:9484

2010-04-08 Thread rguenther at suse dot de


--- Comment #4 from rguenther at suse dot de  2010-04-08 08:11 ---
Subject: Re:  [4.5/4.6 Regression] ICE in s390_emit_call,
 at config/s390/s390.c:9484

On Wed, 7 Apr 2010, krebbel at gcc dot gnu dot org wrote:

 --- Comment #3 from krebbel at gcc dot gnu dot org  2010-04-07 15:56 
 ---
 Created an attachment (id=20328)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20328action=view)
  -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20328action=view)
 Reduced testcase
 
 The check for valid sibcalls in the S/390 back-end relies on the decl to be
 available in the DECL parameter:
 
   /* The 31 bit PLT code uses register 12 (GOT pointer - caller saved)
  which would have to be restored before the sibcall.  */
   if (!TARGET_64BIT  flag_pic  decl  !targetm.binds_local_p (decl))
 return false;
 
 The type cast of the function pointer in the testcase introduces a temporary
 variable on 4.5 which is not linked with the function decl anymore:
 
   x_1 = (void (*T244) (float) (*T248) (void *)) d;
   D.1966_3 = x_1 (p_2(D)); [tail call]
   return D.1966_3;
 
 With 4.4:
 
   D.1224 = (void (*T242) (float) (*T246) (void *)) d (p); [tail call]
   return D.1224;
 
 So we probably have to always reject sibcalls if the fndecl is not reachable.

The extra cast happens if the function signatures are not compatible
(by means of useless_type_conversion_p).  I can't deciper the
function type from (void (*T244) (float) (*T248) (void *))
right now, but it's early in the morning ;)

Richard.


-- 


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



[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2010-04-08 08:14 ---
Mine then.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
  Component|c   |tree-optimization
   Keywords||ice-on-valid-code
   Last reconfirmed|2010-04-07 22:04:29 |2010-04-08 08:14:03
   date||
Summary|ice in gen_lsm_tmp_name, at |[4.5/4.6 Regression] ice in
   |tree-ssa-loop-im.c:1812 |gen_lsm_tmp_name, at tree-
   ||ssa-loop-im.c:1812
   Target Milestone|--- |4.5.1


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



[Bug libstdc++/43683] New: libstdc++ profile mode is not working on OpenSolaris (build 134) due to compilation failure

2010-04-08 Thread kgardas at objectsecurity dot com
Hello,
I'm using:
ka...@thinkpad:/tmp/gcc-4.5.0-RC-20100406$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-rc0-20100412/libexec/gcc/i386-pc-solaris2.11/4.5.0/lto-wrapper
Target: i386-pc-solaris2.11
Configured with: /tmp/gcc-4.5.0-RC-20100406/configure
--prefix=/usr/local/gcc-4.5-rc0-20100412 --with-as=/usr/bin/gas --with-gnu-as
--with-ld=/usr/bin/ld --without-gnu-ld --enable-shared --enable-threads
--enable-languages=c++ --with-gmp-include=/usr/include/gmp
--with-mpfr-include=/usr/include/mpfr --with-mpc=/usr/local/gcc-4.5-reqs/
Thread model: posix
gcc version 4.5.0 20100406 (prerelease) (GCC) 

and attempt to use libstdc++ profile mode on test:

#include vector
using namespace std;
int main() {
  vectorint v;
  for (int k = 0; k  1024; ++k) v.insert(v.begin(), k);
}

The problem is that it's compilation fails with:

In file included from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_hash_func.h:51:0,
 from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler.h:400,
 from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/base.h:44,
 from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/vector:39,
 from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/vector:77,
 from test.cc:1:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In function ‘__gnu_profile::__mutex_t
__gnu_profile::__get___global_lock()’:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:81:1:
error: no matching function for call to
‘_pthread_mutex::_pthread_mutex(brace-enclosed initializer list)’
/usr/include/sys/types.h:404:31: note: candidates are:
_pthread_mutex::_pthread_mutex()
/usr/include/sys/types.h:404:31: note:
_pthread_mutex::_pthread_mutex(const _pthread_mutex)
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In constructor ‘__gnu_profile::__trace_base__object_info,
__stack_info::__trace_base() [with __object_info =
__gnu_profile::__hashfunc_info, __stack_info =
__gnu_profile::__hashfunc_stack_info]’:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_hash_func.h:125:60:
  instantiated from here
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:307:3:
error: no match for ‘operator=’ in
‘((__gnu_profile::__trace_base__gnu_profile::__hashfunc_info,
__gnu_profile::__hashfunc_stack_info*)this)-__gnu_profile::__trace_base__gnu_profile::__hashfunc_info,
__gnu_profile::__hashfunc_stack_info::__stack_table_lock = {{0, 0, 0, 0,
19800}, {{{0}}}, 0}’
/usr/include/sys/types.h:404:31: note: candidate is: _pthread_mutex
_pthread_mutex::operator=(const _pthread_mutex)
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In constructor ‘__gnu_profile::__trace_base__object_info,
__stack_info::__trace_base() [with __object_info =
__gnu_profile::__container_size_info, __stack_info =
__gnu_profile::__container_size_stack_info]’:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_container_size.h:190:74:
  instantiated from here
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:307:3:
error: no match for ‘operator=’ in
‘((__gnu_profile::__trace_base__gnu_profile::__container_size_info,
__gnu_profile::__container_size_stack_info*)this)-__gnu_profile::__trace_base__gnu_profile::__container_size_info,
__gnu_profile::__container_size_stack_info::__stack_table_lock = {{0, 0, 0, 0,
19800}, {{{0}}}, 0}’
/usr/include/sys/types.h:404:31: note: candidate is: _pthread_mutex
_pthread_mutex::operator=(const _pthread_mutex)
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In constructor ‘__gnu_profile::__trace_base__object_info,
__stack_info::__trace_base() [with __object_info =
__gnu_profile::__map2umap_info, __stack_info =
__gnu_profile::__map2umap_stack_info]’:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_map_to_unordered_map.h:204:60:
  instantiated from here

[Bug libstdc++/43683] libstdc++ profile mode is not working on OpenSolaris (build 134) due to compilation failure

2010-04-08 Thread kgardas at objectsecurity dot com


--- Comment #1 from kgardas at objectsecurity dot com  2010-04-08 08:16 
---
Created an attachment (id=20332)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20332action=view)
preprocessed test.cc


-- 


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



[Bug middle-end/40815] redundant neg instruction caused by loop-invariant

2010-04-08 Thread mkuvyrkov at gcc dot gnu dot org


--- Comment #10 from mkuvyrkov at gcc dot gnu dot org  2010-04-08 08:20 
---
Subject: Bug 40815

Author: mkuvyrkov
Date: Thu Apr  8 08:20:36 2010
New Revision: 158105

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158105
Log:
PR middle-end/40815
* tree-ssa-reassoc.c (broken_up_substracts): Rename to plus_negates.
(negate_value): Move code to push elements to broken_up_substracts ...
(eliminate_plus_minus_pair): ... here.  Push operands that have no
negative pair to plus_negates.
(repropagate_negates, init_reassoc, fini_reassoc): Update.

PR middle-end/40815
* gcc.dg/tree-ssa/reassoc-19.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-19.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c


-- 


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



[Bug middle-end/40815] redundant neg instruction caused by loop-invariant

2010-04-08 Thread mkuvyrkov at gcc dot gnu dot org


--- Comment #11 from mkuvyrkov at gcc dot gnu dot org  2010-04-08 08:31 
---
Fixed in the above revision.


-- 

mkuvyrkov at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug bootstrap/43681] [4.6 Regression] bootstrap fails with unused var message for an apparently used var.

2010-04-08 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
Summary|bootstrap fails with|[4.6 Regression] bootstrap
   |unused var message for an |fails with unused var
   |apparently used var.|message for an apparently
   ||used var.
   Target Milestone|--- |4.6.0


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



[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2010-04-08 08:39 ---
The middle-end trusts the C++ frontends TYPE_MIN/MAX_VALUE which is according
to the C++ standard the range for an (unsigned) integer type with a precision
just as wide as to represent all values in the enum.

I did want to remove that optimization at some point but people complained
that it was highly useful (the C++ FE can still set TYPE_PRECISION
accordingly if it wants to, but TYPE_MIN/MAX_VALUE cannot really be trusted
in the middle-end as conversions between integer types of same precision
but different TYPE_MIN/MAX_VALUE are 1) useless and 2) do not produce code
to truncate the values).

It's VRP btw, that does this optimization.  If I have your support I'll rip
out this optimization from VRP ... (I didn't yet manage to create a wrong-code
bug due to the useless conversion thing, but I believe that is possible).

I also believe that the TYPE_MIN/MAX_VALUE on enums might be needed for
proper debug information.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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



[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2010-04-08 08:40 ---
Oh, and actually I don't think this bug is a wrong-code bug but at most
a quality of implementation issue.


-- 


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



[Bug bootstrap/43684] New: multiple 'set but not used' errors.

2010-04-08 Thread iains at gcc dot gnu dot org
The following patches are proposed for both i686 and powerpc:

this is reasonably self-evident..
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00338.html

This one is in an area I've worked on - and I've checked that
-static-libgfortran is still doing its job (on i686-apple-darwin9).
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00329.html

This one is needed for both i686/powerpc - I have done the mechanical job of
removing the unused vars but cannot, of course, guarantee that the original
author intended them to be unused.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00331.html

This one applies to powerpc only - I have done the mechanical job of removing
the unused vars but cannot, of course, guarantee that the original author
intended them to be unused.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00345.html

PowerPC also needs the resolution to :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681

bootstrapped on {i686,powerpc}-apple-darwin9, ia32-pc-linux
(tests are in progress).


-- 
   Summary: multiple 'set but not used' errors.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: *-apple-darwin9


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



[Bug bootstrap/43681] [4.6 Regression] bootstrap fails with unused var message for an apparently used var.

2010-04-08 Thread iains at gcc dot gnu dot org


--- Comment #2 from iains at gcc dot gnu dot org  2010-04-08 08:59 ---
(In reply to comment #1)
 Created an attachment (id=20331)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20331action=view) [edit]
 gcc46-pr43681.patch
 
 Untested patch.

yes, thanks that works.
- I couldn't see what to do there; 
see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43684
 for the ones I think I can resolve. 


-- 


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



[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums

2010-04-08 Thread manu at gcc dot gnu dot org


--- Comment #7 from manu at gcc dot gnu dot org  2010-04-08 09:02 ---
(In reply to comment #1)
 
 Don't we already have a warning that warns about assigning values outside the
 range of an enum?
 

pr43680.C:14:26: warning: the result of the conversion is unspecified because
‘5’ is outside the range of type ‘E’ [-Wconversion]

Implemented by yours truly in GCC 4.5. (or perhaps already in 4.4.)


-- 


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



[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2010-04-08 09:11 ---
Unfolded *g_7 from PRE.  I have a patch.


-- 


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



[Bug debug/43670] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O -ftree-vrp

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #5 from jakub at gcc dot gnu dot org  2010-04-08 09:16 ---
Subject: Bug 43670

Author: jakub
Date: Thu Apr  8 09:16:28 2010
New Revision: 158108

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158108
Log:
PR debug/43670
* cfgexpand.c (expand_debug_expr): If for non-NULL offset
op0 is not a MEM, just return NULL instead of assertion
failure.
(discover_nonconstant_array_refs): Don't walk debug stmts.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr43670.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug debug/43670] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O -ftree-vrp

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #6 from jakub at gcc dot gnu dot org  2010-04-08 09:18 ---
Subject: Bug 43670

Author: jakub
Date: Thu Apr  8 09:17:52 2010
New Revision: 158109

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158109
Log:
PR debug/43670
* cfgexpand.c (expand_debug_expr): If for non-NULL offset
op0 is not a MEM, just return NULL instead of assertion
failure.
(discover_nonconstant_array_refs): Don't walk debug stmts.

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

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr43670.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/cfgexpand.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug target/43635] [4.5/4.6 Regression] ICE in s390_emit_call, at config/s390/s390.c:9484

2010-04-08 Thread krebbel at gcc dot gnu dot org


--- Comment #5 from krebbel at gcc dot gnu dot org  2010-04-08 09:23 ---
(In reply to comment #4)
 The extra cast happens if the function signatures are not compatible
 (by means of useless_type_conversion_p).

Ok. Do you know why that behavior changed between gcc 4.4 and 4.5?

Is there a way to obtain the function decl from D.1966_3 in the 4.5 example or
do we really need to reject sibcall optimizations in that case?


-- 


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



[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #13 from rguenth at gcc dot gnu dot org  2010-04-08 09:23 
---
43627 is fallout and would need to be backported as well.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||43627


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



[Bug target/41653] not optimal result for multiplication with constant when -Os is specified

2010-04-08 Thread carrot at gcc dot gnu dot org


--- Comment #9 from carrot at gcc dot gnu dot org  2010-04-08 09:27 ---
Subject: Bug 41653

Author: carrot
Date: Thu Apr  8 09:27:44 2010
New Revision: 158110

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158110
Log:
PR target/41653
* config/arm/arm.c (thumb1_size_rtx_costs): New function.
(arm_size_rtx_costs): Call the new function when optimized for size.


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


-- 


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



[Bug target/41653] not optimal result for multiplication with constant when -Os is specified

2010-04-08 Thread carrot at google dot com


--- Comment #10 from carrot at google dot com  2010-04-08 09:29 ---
Fixed by the above patch.


-- 

carrot at google dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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



[Bug libstdc++/43683] libstdc++ profile mode is not working on OpenSolaris (build 134) due to compilation failure

2010-04-08 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2010-04-08 09:32 
---
I don't think anybody is making promises that profile mode works everywhere...
Anyway, CC-ing Silvius.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||rus at google dot com


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



[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

2010-04-08 Thread paolo dot carlini at oracle dot com


--- Comment #15 from paolo dot carlini at oracle dot com  2010-04-08 09:33 
---
Re-open to..


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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



[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

2010-04-08 Thread paolo dot carlini at oracle dot com


--- Comment #16 from paolo dot carlini at oracle dot com  2010-04-08 09:33 
---
unassign myself


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|REOPENED|NEW


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



[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

2010-04-08 Thread paolo dot carlini at oracle dot com


--- Comment #17 from paolo dot carlini at oracle dot com  2010-04-08 09:34 
---
.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug target/43677] #8216;__powitf2#8217;: unrecognizable insn

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2010-04-08 09:40 ---
I can't seem to be able to reproduce this with r158106.  How did you configure?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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



[Bug libstdc++/35353] C++ wide character locale doesn't work

2010-04-08 Thread paolo dot carlini at oracle dot com


--- Comment #16 from paolo dot carlini at oracle dot com  2010-04-08 09:44 
---
We may make progress on this for 4.6.0, but I don't make promises. If, after
having studied the relevant bits of the Standard and the current implementation
of these features (I remind you that this is Free Software, thus no mysteries,
no need for black-box thinking) I would recommend going ahead and proposing a
patch (after having filed the required Copyright Assignment). Thanks.


-- 


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



[Bug target/43677] #8216;__powitf2#8217;: unrecognizable insn

2010-04-08 Thread schwab at linux-m68k dot org


--- Comment #2 from schwab at linux-m68k dot org  2010-04-08 09:45 ---
configured by ../gcc/configure, generated by GNU Autoconf 2.64,
  with options  '--prefix=/usr' '--build=x86_64-linux' '--enable-shared'
'--enable-threads=posix' '--with-system-zlib' '--enable-__cxa_atexit'
'build_alias=x86_64-linux' 'CFLAGS=-O2 -g' 'CXXFLAGS=-O2 -g'
'--enable-languages=c,c++,lto'


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-08 09:45:26
   date||


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



[Bug target/43635] [4.5/4.6 Regression] ICE in s390_emit_call, at config/s390/s390.c:9484

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2010-04-08 10:00 ---
(In reply to comment #5)
 (In reply to comment #4)
  The extra cast happens if the function signatures are not compatible
  (by means of useless_type_conversion_p).
 
 Ok. Do you know why that behavior changed between gcc 4.4 and 4.5?

It changed because of the gimple type system got a verifier.

 Is there a way to obtain the function decl from D.1966_3 in the 4.5 example or
 do we really need to reject sibcall optimizations in that case?

You can do a lookup in the SSA web (well, but it'll be expanded as an
indirect call probably - you have to check).


-- 


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



[Bug bootstrap/43681] [4.6 Regression] bootstrap fails with unused var message for an apparently used var.

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #3 from jakub at gcc dot gnu dot org  2010-04-08 10:12 ---
Subject: Bug 43681

Author: jakub
Date: Thu Apr  8 10:12:35 2010
New Revision: 158111

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158111
Log:
PR bootstrap/43681
* expr.c (block_move_libcall_safe_for_call_parm): Avoid
set but not used variable warning.

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


-- 


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



[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2010-04-08 10:21 ---
Subject: Bug 43679

Author: rguenth
Date: Thu Apr  8 10:21:23 2010
New Revision: 158112

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158112
Log:
2010-04-08  Richard Guenther  rguent...@suse.de

PR tree-optimization/43679
* tree-ssa-pre.c (eliminate): Only propagate copies.

* gcc.c-torture/compile/pr43679.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr43679.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c


-- 


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



[Bug target/43677] #8216;__powitf2#8217;: unrecognizable insn

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2010-04-08 10:24 ---
Works for me.


-- 


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



[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2010-04-08 10:26 ---
Subject: Bug 43679

Author: rguenth
Date: Thu Apr  8 10:25:57 2010
New Revision: 158113

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158113
Log:
2010-04-08  Richard Guenther  rguent...@suse.de

PR tree-optimization/43679
* tree-ssa-pre.c (eliminate): Only propagate copies.

* gcc.c-torture/compile/pr43679.c: New testcase.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr43679.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-ssa-pre.c


-- 


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



[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2010-04-08 10:26 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.5.1   |4.5.0


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



[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

2010-04-08 Thread bart dot vanassche at gmail dot com


--- Comment #18 from bart dot vanassche at gmail dot com  2010-04-08 10:28 
---
(In reply to comment #12)
 In my opinion it's too late now, I'm not even sure a 4.4.4 will be released 
 any
 time soon, and 4.5.0 is around the corner. But if Jon would also like to see 
 it
 in 4.4.4 and wants to backport the patch I do not object.

Please keep in mind that this behavior can have a severe negative impact on
multithreaded C++ software that uses class std::string intensively because the
unnecessary writes to _S_empty_rep_storage will cause unnecessary cache line
bouncing.


-- 


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



[Bug fortran/43685] New: libgfortran: Consider using __int128

2010-04-08 Thread burnus at gcc dot gnu dot org
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00354.html (review/committal
pending)

Currently, there is no C type for INTEGER(16); I think some code could be made
more readable if one uses __int128 directly.


-- 
   Summary: libgfortran: Consider using __int128
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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



[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

2010-04-08 Thread paolo dot carlini at oracle dot com


--- Comment #19 from paolo dot carlini at oracle dot com  2010-04-08 10:33 
---
Please keep in mind that nobody complained so far, over the last ~10 years, and
4.4 is close to its end of life.


-- 


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



[Bug lto/41588] [4.5 Regression] LTO bugs to be addressed before release

2010-04-08 Thread steven at gcc dot gnu dot org


--- Comment #1 from steven at gcc dot gnu dot org  2010-04-08 10:37 ---
Supposed to be addressed before release except that they haven't. So let's
make it a 4.5 Regression, which it is to some degree.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org
Summary|LTO bugs to be addressed|[4.5 Regression] LTO bugs to
   |before release  |be addressed before release


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



[Bug lto/41528] LTO needs better internal and user documentation

2010-04-08 Thread steven at gcc dot gnu dot org


--- Comment #1 from steven at gcc dot gnu dot org  2010-04-08 10:39 ---
No progress since this PR was opened. Ping.


-- 


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



[Bug lto/41576] LTO complains about mismatches in common sections

2010-04-08 Thread steven at gcc dot gnu dot org


--- Comment #2 from steven at gcc dot gnu dot org  2010-04-08 10:39 ---
What happened to the patch mentioned in comment #1?


-- 


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



[Bug lto/43212] [LTO] error: control flow in the middle of basic block

2010-04-08 Thread steven at gcc dot gnu dot org


--- Comment #2 from steven at gcc dot gnu dot org  2010-04-08 10:43 ---
Should LTO reject function declarations with incompatible attributes? Or should
the discovery of the attribute in one translation unit be used to update the
control flow graph in the other units (e.g. by writing out summaries for the
attributes and have a stage in LTO that merges them)?


-- 


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



[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #12 from rguenth at gcc dot gnu dot org  2010-04-08 10:47 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #13 from rguenth at gcc dot gnu dot org  2010-04-08 10:47 
---
Subject: Bug 43186

Author: rguenth
Date: Thu Apr  8 10:46:46 2010
New Revision: 158114

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158114
Log:
2010-04-08  Richard Guenther  rguent...@suse.de

PR tree-optimization/43186
* params.def (PARAM_MAX_UNROLL_ITERATIONS): New param.
* doc/invoke.texi (max-completely-peel-loop-nest-depth): Document.
* tree-ssa-loop-ivcanon.c (tree_unroll_loops_completely): Limit
unroller iterations.

* gcc.c-torture/compile/pr43186.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr43186.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/doc/invoke.texi
branches/gcc-4_4-branch/gcc/params.def
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-loop-ivcanon.c


-- 


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



[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums

2010-04-08 Thread ebotcazou at gcc dot gnu dot org


--- Comment #8 from ebotcazou at gcc dot gnu dot org  2010-04-08 10:48 
---
 I did want to remove that optimization at some point but people complained
 that it was highly useful (the C++ FE can still set TYPE_PRECISION
 accordingly if it wants to, but TYPE_MIN/MAX_VALUE cannot really be trusted
 in the middle-end as conversions between integer types of same precision
 but different TYPE_MIN/MAX_VALUE are 1) useless and 2) do not produce code
 to truncate the values).

We had the exact same problem in Ada until 4.4, it has been solved by setting
TYPE_MIN/MAX_VALUE to their canonical values...

 I also believe that the TYPE_MIN/MAX_VALUE on enums might be needed for
 proper debug information.

...and this one by providing a get_subrange_bounds lang hook.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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



[Bug lto/41576] LTO complains about mismatches in common sections

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2010-04-08 11:01 ---
They are still there and don't work completely.  There is a more complete
and proper solution in my mind but it's not implemented yet.


-- 


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



[Bug target/43677] #8216;__powitf2#8217;: unrecognizable insn

2010-04-08 Thread schwab at linux-m68k dot org


--- Comment #4 from schwab at linux-m68k dot org  2010-04-08 11:04 ---
Sorry, I had a broken experimental change that I forgot to remove.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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



[Bug lto/41584] WHOPR doesn't grok empty units

2010-04-08 Thread steven at gcc dot gnu dot org


--- Comment #3 from steven at gcc dot gnu dot org  2010-04-08 11:09 ---
Interestingly, LTO actually tries to use the original file name:

  /* Since SET does not need to be processed by LTRANS, use
 the original file name and mark it with a '*' prefix so that
 lto_execute_ltrans knows not to process it.  */
  cgraph_node_set_iterator si = csi_start (set);
  struct cgraph_node *first = csi_node (si);
  fname = prefix_name_with_star (first-local.lto_file_data-file_name);

But it tries to take the file name from the first node in the call graph. And
the reason why we try re-use the original file name, is because the call graph
is empty. Strange logic...

Maybe WHOPR should give a fatal error if the only set is empty.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-08 11:09:52
   date||


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



[Bug lto/43212] [LTO] error: control flow in the middle of basic block

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2010-04-08 11:23 ---
We do have a fixup pass for this, but somehow it doesnt' work.


-- 


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



[Bug tree-optimization/43614] [4.4 Regression] ice in gimple_rhs_has_side_effects, at gimple.c:2248

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #7 from jakub at gcc dot gnu dot org  2010-04-08 11:28 ---
Subject: Bug 43614

Author: jakub
Date: Thu Apr  8 11:28:06 2010
New Revision: 158117

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158117
Log:
Backport from mainline:
2010-04-01  Richard Guenther  rguent...@suse.de

PR middle-end/43614
* tree-ssa-address.c (copy_mem_ref_info): Copy TREE_SIDE_EFFECTS
and TREE_THIS_VOLATILE.
(copy_ref_info): Likewise.
* tree-ssa-operands.c (get_tmr_operands): Check TREE_THIS_VOLATILE.
* tree.c (build7_stat): Ignore side-effects of all but arg5
for TARGET_MEM_REF.  Set TREE_THIS_VOLATILE from arg5 of
TARGET_MEM_REF.

* gcc.c-torture/compile/pr43614.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr43614.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-address.c
branches/gcc-4_4-branch/gcc/tree-ssa-loop-ivopts.c
branches/gcc-4_4-branch/gcc/tree-ssa-operands.c
branches/gcc-4_4-branch/gcc/tree.c


-- 


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



[Bug tree-optimization/43607] [4.3/4.4 Regression] ICE in gimple_op, at gimple.h:1633 with -fipa-type-escape

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #5 from jakub at gcc dot gnu dot org  2010-04-08 11:29 ---
Subject: Bug 43607

Author: jakub
Date: Thu Apr  8 11:29:28 2010
New Revision: 158118

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158118
Log:
Backport from mainline:
2010-04-01  Richard Guenther  rguent...@suse.de

PR tree-optimization/43607
* ipa-type-escape.c (check_call): Do not access non-existing
arguments.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/ipa-type-escape.c


-- 


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



[Bug tree-optimization/43560] [4.3/4.4 Regression] possible wrong code bug

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #12 from jakub at gcc dot gnu dot org  2010-04-08 11:31 ---
Subject: Bug 43560

Author: jakub
Date: Thu Apr  8 11:31:00 2010
New Revision: 158119

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158119
Log:
Backport from mainline:
2010-03-29  Richard Guenther  rguent...@suse.de

PR tree-optimization/43560
* tree-ssa-loop-im.c (ref_always_accessed_p): Add store_p
parameter.
(can_sm_ref_p): Treat stores to readonly locations as
trapping.

* gcc.dg/torture/pr43560.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr43560.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-loop-im.c


-- 


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



[Bug tree-optimization/43614] [4.4 Regression] ice in gimple_rhs_has_side_effects, at gimple.c:2248

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #8 from jakub at gcc dot gnu dot org  2010-04-08 11:34 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug tree-optimization/43607] [4.3 Regression] ICE in gimple_op, at gimple.h:1633 with -fipa-type-escape

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #6 from jakub at gcc dot gnu dot org  2010-04-08 11:34 ---
Fixed also for 4.4.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.2.4 4.5.0 |4.2.4 4.5.0 4.4.4
Summary|[4.3/4.4 Regression] ICE in |[4.3 Regression] ICE in
   |gimple_op, at gimple.h:1633 |gimple_op, at gimple.h:1633
   |with -fipa-type-escape  |with -fipa-type-escape


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



[Bug tree-optimization/43560] [4.3 Regression] possible wrong code bug

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #13 from jakub at gcc dot gnu dot org  2010-04-08 11:35 ---
Fixed also for 4.4.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|3.4.6 4.5.0 |3.4.6 4.5.0 4.4.4
Summary|[4.3/4.4 Regression]|[4.3 Regression] possible
   |possible wrong code bug |wrong code bug


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



[Bug debug/43670] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O -ftree-vrp

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #7 from jakub at gcc dot gnu dot org  2010-04-08 11:41 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug tree-optimization/42956] [4.4 Regression] internal compiler error: Segmentation fault with -O1

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #11 from rguenth at gcc dot gnu dot org  2010-04-08 11:47 
---
Subject: Bug 42956

Author: rguenth
Date: Thu Apr  8 11:47:13 2010
New Revision: 158123

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158123
Log:
2010-04-08  Richard Guenther  rguent...@suse.de

PR middle-end/42956
* gimplify.c (gimple_fold_indirect_ref): Avoid generating
new ARRAY_REFs on variable size element or minimal index arrays.
* tree-ssa-loop-ivopts.c (find_interesting_uses_address): Use
gimple_fold_indirect_ref.

* gcc.c-torture/compile/pr42956.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42956.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/gimplify.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-loop-ivopts.c


-- 


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



[Bug tree-optimization/42956] [4.4 Regression] internal compiler error: Segmentation fault with -O1

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #12 from rguenth at gcc dot gnu dot org  2010-04-08 11:47 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug middle-end/43656] -fcompare-debug failure with -O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity

2010-04-08 Thread jakub at gcc dot gnu dot org


--- Comment #2 from jakub at gcc dot gnu dot org  2010-04-08 11:53 ---
Can't reproduce this with r158104.


-- 


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



[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux

2010-04-08 Thread mikpe at it dot uu dot se


--- Comment #33 from mikpe at it dot uu dot se  2010-04-08 12:14 ---
Created an attachment (id=20333)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20333action=view)
eliminate use of _Unwind_GetRegionStart on ARM, part 1

Here's a preliminary patch to eliminate the functional dependency on
_Unwind_GetRegionStart on ARM.  There are two key changes:
output_function_exception_table outputs a proper @LPStart pointer in each LSDA
blob, and every PR's parse_lsda_header sets @Start to @LPstart if @Start is
NULL.

Without these updates making _Unwind_GetRegionStart return NULL on ARM causes
massive regressions in the c++/objc/obj-c++ test suites, and some in the c and
libffi test suites.  With these updates those regressions are eliminated.

There are however two new regressions:

1. There are several orders of magnitude more alignment exceptions during the
test suite run, probably in the read_encoded_value calls that now trigger.

2. For initial testing I ran this on i686 with its _Unwind_GetRegionStart made
to return NULL too, and while it worked the g++.old-deja/g++.law/weak.C test
case failed with a linkage error.  It looks like gcc emitted exception table
data for a discarded piece of code.  On my ARM box the test suite considered
that test case UNSUPPORTED so never ran it.

The first regression can probably be fixed by avoiding to define unneeded
@LPStart pointers and making read_encoded_value mis-alignment safe.

The second regression might be fixable by making the @LPStart symbol references
weak.

More fixes will be needed for libjava's stacktrace mess though.


-- 


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



[Bug middle-end/43656] -fcompare-debug failure with -O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity

2010-04-08 Thread zsojka at seznam dot cz


--- Comment #3 from zsojka at seznam dot cz  2010-04-08 12:21 ---
Created an attachment (id=20334)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20334action=view)
testcase that crashes in r158095

When size of arrays is changed from 64 to 1000, it fails again in r158095


-- 

zsojka at seznam dot cz changed:

   What|Removed |Added

  Attachment #20318|0   |1
is obsolete||


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



[Bug c/43686] New: GCC doesn't duplicate computed gotos for functions marked as hot

2010-04-08 Thread dmitry at zend dot com
I've found the bug working on direct threaded interpreter for PHP. Moving from
GCC 4.3 to GCC 4.4 caused a significant performance degradation. Looking into
produced assembler code I realized that GCC 4.4 doesn't replace all jmps to
indirect jmp with indirect jmp itself. The reason is the following new
condition in function duplicate_computed_gotos() bb-reorder.c 

if (!optimize_bb_for_size_p (bb))
  continue;

I thought I would able to fix the problem using hot attribute, but
according to this condition, in case I mark function with __attribute__((hot))
duplication doesn't work, and in case I mark it with __attribute__((cold)) it
starts work. As result hot function works slower than cold.

You can use the simplified code to verify it. I ran it with 'gcc -O2 -S
direct.c'

direct.c

#define NEXT goto **ip++
#define guard(n) asm(# #n)

__attribute__((cold)) void *emu (void **prog)
{
  static void  *labels[] =
{next1,next2,next3,next4,next5,next6,next7,next8,next9,loop};
  void **ip;
  intcount;

  if (!prog) {
  return labels;
  }  

  ip=prog;
  count = 1000;


  NEXT;
 next1:
  guard(1);
  NEXT;
 next2:
  guard(2);
  NEXT;
 next3:
  guard(3);
  NEXT;
 next4:
  guard(4);
  NEXT;
 next5:
  guard(5);
  NEXT;
 next6:
  guard(6);
  NEXT;
 next7:
  guard(7);
  NEXT;
 next8:
  guard(8);
  NEXT;
 next9:
  guard(9);
  NEXT;
 loop:
  if (count0) {
count--;
ip=prog;
NEXT;
  }
  return 0;
}


int main() {
void *prog[]   = {(void*)0,(void*)1,
  (void*)0,(void*)2,
  (void*)0,(void*)3,
  (void*)0,(void*)4,
  (void*)0,(void*)9};
void **labels = emu(0);
int i;
for (i=0; i  sizeof(prog)/sizeof(prog[0]); i++) {
prog[i] = labels[(int)prog[i]];
}
emu(prog);
return 0;
}

I saw that the check causing the slowdown was removed in trunk, however I can't
check that it was done in a proper way.


-- 
   Summary: GCC doesn't duplicate computed gotos for functions
marked as hot
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dmitry at zend dot com
 GCC build triplet: i686-redhat-linux
  GCC host triplet: i686-redhat-linux
GCC target triplet: i686-redhat-linux


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



[Bug lto/41528] LTO needs better internal and user documentation

2010-04-08 Thread dnovillo at gcc dot gnu dot org


--- Comment #2 from dnovillo at gcc dot gnu dot org  2010-04-08 12:51 
---
(In reply to comment #1)
 No progress since this PR was opened. Ping.

Yes, progress has been impossible until now.  I expect to slowly getting some
content written in the next little while.


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-08 12:51:11
   date||


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



[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums

2010-04-08 Thread bangerth at gmail dot com


--- Comment #9 from bangerth at gmail dot com  2010-04-08 12:53 ---
I'm not saying we *should* apply a mask (in fact, I think that would be
silly). But we *could*, and if we did then VRP's actions might lead to
faster but not different code.

All I want to say is that VRP is a powerful tool. Let's not just throw
the baby out with the bath water.

W.


-- 


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



[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends

2010-04-08 Thread hubicka at gcc dot gnu dot org


--- Comment #14 from hubicka at gcc dot gnu dot org  2010-04-08 13:14 
---
Adding a simple limit on number of loop nests in recursive inlining is easy
thing to do, but I am not quite sure how useful it is (well, overall recursive
inlining tends to help only few very special benchmrks).
So the problem is that function body after inlinng is resonable but with
unrolling it explodes?


-- 


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



[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #15 from rguenth at gcc dot gnu dot org  2010-04-08 13:19 
---
(In reply to comment #14)
 Adding a simple limit on number of loop nests in recursive inlining is easy
 thing to do, but I am not quite sure how useful it is (well, overall recursive
 inlining tends to help only few very special benchmrks).
 So the problem is that function body after inlinng is resonable but with
 unrolling it explodes?

The main issue is that we are doing a very poor job in limiting the work
we do during complete unrolling (as well as leaving as little work for
subsequent passes as possible).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||matz at gcc dot gnu dot org


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



[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends

2010-04-08 Thread hubicka at ucw dot cz


--- Comment #16 from hubicka at ucw dot cz  2010-04-08 13:26 ---
Subject: Re:  [4.4 Regression] A loop in
tree_unroll_loops_completely never ends

 The main issue is that we are doing a very poor job in limiting the work
 we do during complete unrolling (as well as leaving as little work for
 subsequent passes as possible).

Well, I guess in addition to number of instructions after optimizing we can
also estimate number of instruction we actually produce by unrolling and have
some cutoff (a lot bigger than for code size estimate growth) on those as
well...

Honza


-- 


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



[Bug driver/43687] New: Unexpected error message for bad command line argument

2010-04-08 Thread joel at gcc dot gnu dot org
I meant to use -Wl,--wrap but accidentally just used --wrap. Notice that the
error message has turned it into -fwrap.  This is confusing.

[j...@iceland tmp]$ gcc --wrap -c m.c
cc1: error: unrecognized command line option -fwrap
[j...@iceland tmp]$ gcc --version
gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)


-- 
   Summary: Unexpected error message for bad command line argument
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org


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



[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends

2010-04-08 Thread rguenther at suse dot de


--- Comment #17 from rguenther at suse dot de  2010-04-08 13:29 ---
Subject: Re:  [4.4 Regression] A loop in
 tree_unroll_loops_completely never ends

On Thu, 8 Apr 2010, hubicka at ucw dot cz wrote:

 --- Comment #16 from hubicka at ucw dot cz  2010-04-08 13:26 ---
 Subject: Re:  [4.4 Regression] A loop in
 tree_unroll_loops_completely never ends
 
  The main issue is that we are doing a very poor job in limiting the work
  we do during complete unrolling (as well as leaving as little work for
  subsequent passes as possible).
 
 Well, I guess in addition to number of instructions after optimizing we can
 also estimate number of instruction we actually produce by unrolling and have
 some cutoff (a lot bigger than for code size estimate growth) on those as
 well...

We do.  But it all get's just smaller - but only after optimizing.

Richard.


-- 


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



[Bug target/43129] Simplify global variable's address loading with option -fpic

2010-04-08 Thread carrot at google dot com


--- Comment #5 from carrot at google dot com  2010-04-08 13:31 ---
(In reply to comment #4)
 I guess you'll have to experiment with your implementation to
 see what gives the best results on a large body of code.
 

I will experiment on CSiBE.


-- 


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



[Bug c/43686] GCC doesn't duplicate computed gotos for functions marked as hot

2010-04-08 Thread mikpe at it dot uu dot se


--- Comment #1 from mikpe at it dot uu dot se  2010-04-08 13:32 ---
Duplicate of PR42621?


-- 


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



[Bug tree-optimization/43688] New: ICE: in analyze_function, at ipa-reference.c:733 with -fipa-reference

2010-04-08 Thread zsojka at seznam dot cz
Command line:
gfortran -fipa-reference testcase.f90

Tested revisions:
r158095 - crash

Output:
$ /mnt/svn/gcc-trunk/binary-158095-lto-fortran/bin/gfortran -fipa-reference
testcase.f90
testcase.f90: In function #8216;sub#8217;:
testcase.f90:8:0: internal compiler error: in analyze_function, at
ipa-reference.c:733
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


-- 
   Summary: ICE: in analyze_function, at ipa-reference.c:733 with -
fipa-reference
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz


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



[Bug tree-optimization/43688] ICE: in analyze_function, at ipa-reference.c:733 with -fipa-reference

2010-04-08 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2010-04-08 13:38 ---
Created an attachment (id=20335)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20335action=view)
auto-reduced testcase

reduced from gfortran.dg/subref_array_pointer_1.f90


-- 


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



[Bug target/43671] [4.4/4.5/4.6 Regression] -fsched2-use-superblocks -m32 produces wrong code with vectorization

2010-04-08 Thread matz at gcc dot gnu dot org


--- Comment #5 from matz at gcc dot gnu dot org  2010-04-08 13:40 ---
Um, how can r138953 be the reason when (as the original report says) it's
still okay with r153685?  In any case, my patch just shuffled around the
activation/non-activation of the scheduler, so if at all it exposed a latent
bug in it, which given that -fsched2-use-superblocks isn't used by default
is very likely.


-- 


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



[Bug target/43671] [4.4/4.5/4.6 Regression] -fsched2-use-superblocks -m32 produces wrong code with vectorization

2010-04-08 Thread zsojka at seznam dot cz


--- Comment #6 from zsojka at seznam dot cz  2010-04-08 13:48 ---
I am sorry for the confusion. The original testcase from comment #1 doesn't
fail in r153685 and 4.4.3. Later I found different testcase (comment #2) that
fails there.


-- 


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



[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

2010-04-08 Thread redi at gcc dot gnu dot org


--- Comment #20 from redi at gcc dot gnu dot org  2010-04-08 13:51 ---
You can still reduce the helgrind output with just one suppression

{
  libstdcxx_std_string_race_pr40518
  Helgrind:Race
  fun:_ZNSs9_M_mutateEmmm
}

I'm not convinced the impact is severe, COW strings already have problems in
multiprocessor systems, I don't think erase() on empty strings is the
bottleneck!   It's not been a problem in my own experience, and I'm not aware
of any distros having felt the need to backport the patch to their 4.4
packages.

I'll look into backporting it tonight on condition you cease the hyperbole


-- 


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



[Bug c/43686] GCC doesn't duplicate computed gotos for functions marked as hot

2010-04-08 Thread dmitry at zend dot com


--- Comment #2 from dmitry at zend dot com  2010-04-08 13:54 ---
yes. It's definitely the same issue.

The only additional note that __attribute__((hot)) doesn't fix the problem (as
I would expect tracing down optimize_bb_for_size_p()), but makes an additional
slowdown. In opposite, the __attribute__((cold)) solves the issue. It looks
very strange.

I suppose some condition has to be inverted :)


-- 


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



[Bug libstdc++/40518] data races when calling std::string::erase() on empty string

2010-04-08 Thread paolo dot carlini at oracle dot com


--- Comment #21 from paolo dot carlini at oracle dot com  2010-04-08 14:04 
---
 I'll look into backporting it tonight on condition you cease the hyperbole
^   

That's why (among other reasons) I voted in favor of appointing Jon maintainer
;) Agreed.


-- 


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



[Bug objc++/43689] New: const-str-5/6 fails

2010-04-08 Thread iains at gcc dot gnu dot org
these two tests are failing at both m32 and m64.

FAIL: obj-c++.dg/const-str-5.mm -fgnu-runtime (test for excess errors)
Excess errors:
built-in:0:0: warning: 'MyConstantString' has a field
'MyConstantString::_contents' whose type uses the anonymous namespace


-- 
   Summary: const-str-5/6 fails
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: *-apple-darwin9, ia32-pc-linux


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



[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends

2010-04-08 Thread hubicka at ucw dot cz


--- Comment #18 from hubicka at ucw dot cz  2010-04-08 14:41 ---
Subject: Re:  [4.4 Regression] A loop in
tree_unroll_loops_completely never ends

  Well, I guess in addition to number of instructions after optimizing we can
  also estimate number of instruction we actually produce by unrolling and 
  have
  some cutoff (a lot bigger than for code size estimate growth) on those as
  well...
 
 We do.  But it all get's just smaller - but only after optimizing.

Yep, we compute what will get optimized out as constant expression after full
unrolling.  I guess we need to compute both values - one with taking these into
account (i.e. estimating effect on the generated code) and one without (i.e.
estimating effect on memory and time we will blow on this) and limit both...

At least this is my backup plan for inliner if we ever run into case that the
heuristic will blow up out of time and space by giving something that optimizes
very well subsequently.

I can play with this if this seems sane. (as I guess my unrolling estimate
improvements are source of this issue)

Honza


-- 


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



[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register

2010-04-08 Thread ro at gcc dot gnu dot org


--- Comment #3 from ro at gcc dot gnu dot org  2010-04-08 14:46 ---
Mine.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ro at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Known to fail||4.4.4 4.5.0 4.6.0
   Last reconfirmed|2010-04-05 10:06:06 |2010-04-08 14:46:42
   date||


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



[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register

2010-04-08 Thread ro at gcc dot gnu dot org


--- Comment #4 from ro at gcc dot gnu dot org  2010-04-08 14:48 ---
Subject: Bug 43643

Author: ro
Date: Thu Apr  8 14:48:46 2010
New Revision: 158130

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158130
Log:
gcc:
PR target/43643
* config/i386/gmon-sol2.c [__x86_64__]: Properly restore %rcx.

gcc/testsuite:
PR target/43643
* gcc.dg/pr43643.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr43643.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/gmon-sol2.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends

2010-04-08 Thread matz at gcc dot gnu dot org


--- Comment #19 from matz at gcc dot gnu dot org  2010-04-08 14:50 ---
This seems rather like a hack for our not-so-capable loop unroller.  The
estimator already correctly knows that much of it will be optimized away,
hence it would make more sense for the code emitter to also not emit
useless things that the estimator already knows will be optimized away.

It seems backward to have an additional limit on compile time/memory need
for a transformation that we know will succeed.


-- 


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



[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register

2010-04-08 Thread ro at gcc dot gnu dot org


--- Comment #5 from ro at gcc dot gnu dot org  2010-04-08 14:51 ---
Subject: Bug 43643

Author: ro
Date: Thu Apr  8 14:50:56 2010
New Revision: 158131

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158131
Log:
gcc:
PR target/43643
* config/i386/gmon-sol2.c [__x86_64__]: Properly restore %rcx.

gcc/testsuite:
PR target/43643
* gcc.dg/pr43643.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr43643.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/gmon-sol2.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug c/43690] New: Internal compiler error detected by avr-gcc.

2010-04-08 Thread philippe dot hoogvorst at neuf dot fr

 avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib
--infodi--mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib
--libdir=/usr/lib --enabystem-zlib --enable-long-long --enable-nls
--without-included-gettext --disable-checking--build=i486-linux-gnu
--host=i486-linux-gnu --target=avr
Thread model: single
gcc version 4.3.4 (GCC) 

Minimal source code causing the bug, removing any token makes the compiler work
OK. No header is to be included into this code to see the bug.
---
void doit( )
{
char *pk=0 ;
for(;;)
{
asm ( nop : :m(pk++) );
asm ( nop : :m(pk++) );
}
}

 avr-gcc -Wall -mmcu=atmega128 -O3  -c -o /dev/null  
 /tmp/present-wddl-both-encrypt.c
/tmp/present-wddl-both-encrypt.c: In function ‘doit’:
/tmp/present-wddl-both-encrypt.c:2: internal compiler error: in
copy_reference_ops_from_ref, at tree-ssa-sccvn.c:577
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Note that removing -Wall does not remove the bug but that removing -O3
makes the compiler work OK.

Best regards.


-- 
   Summary: Internal compiler error detected by avr-gcc.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe dot hoogvorst at neuf dot fr
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: avr


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



[Bug bootstrap/43681] [4.6 Regression] bootstrap fails with unused var message for an apparently used var.

2010-04-08 Thread iains at gcc dot gnu dot org


--- Comment #4 from iains at gcc dot gnu dot org  2010-04-08 15:07 ---
bootstrapped {powerpc,i686}-apple-darwin9.
this is fixed. 
(other 'set but not used'  issues at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43684 remain)


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86

2010-04-08 Thread ro at gcc dot gnu dot org


--- Comment #12 from ro at gcc dot gnu dot org  2010-04-08 15:09 ---
Subject: Bug 38085

Author: ro
Date: Thu Apr  8 15:09:17 2010
New Revision: 158133

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158133
Log:
gcc:
PR target/43643
* config/i386/gmon-sol2.c [__x86_64__]: Properly restore %rcx.

gcc/testsuite:
PR target/43643
* gcc.dg/pr43643.c: New test.

gcc:
Backport from mainline:
2010-03-22  Rainer Orth  r...@cebitec.uni-bielefeld.de

PR target/38085
* config/i386/i386.c (x86_function_profiler)
[!NO_PROFILE_COUNTERS]: Fix typo.
* config/i386/gmon-sol2.c (_mcleanup) [__x86_64__]: Use call
instead of callq.

libgcc:
Backport from mainline:
2010-03-22  Rainer Orth  r...@cebitec.uni-bielefeld.de

PR target/38085
* config/i386/t-sol2 ($(T)gmon.o): Use CFLAGS instead of
MULTILIB_CFLAGS.
($(T)gcrt1.o): Likewise.
($(T)crt1.o): Likewise.
($(T)crti.o): Likewise.
($(T)crtn.o): Likewise.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr43643.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/i386/gmon-sol2.c
branches/gcc-4_4-branch/gcc/config/i386/i386.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/libgcc/ChangeLog
branches/gcc-4_4-branch/libgcc/config/i386/t-sol2


-- 


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



[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register

2010-04-08 Thread ro at gcc dot gnu dot org


--- Comment #6 from ro at gcc dot gnu dot org  2010-04-08 15:09 ---
Subject: Bug 43643

Author: ro
Date: Thu Apr  8 15:09:17 2010
New Revision: 158133

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158133
Log:
gcc:
PR target/43643
* config/i386/gmon-sol2.c [__x86_64__]: Properly restore %rcx.

gcc/testsuite:
PR target/43643
* gcc.dg/pr43643.c: New test.

gcc:
Backport from mainline:
2010-03-22  Rainer Orth  r...@cebitec.uni-bielefeld.de

PR target/38085
* config/i386/i386.c (x86_function_profiler)
[!NO_PROFILE_COUNTERS]: Fix typo.
* config/i386/gmon-sol2.c (_mcleanup) [__x86_64__]: Use call
instead of callq.

libgcc:
Backport from mainline:
2010-03-22  Rainer Orth  r...@cebitec.uni-bielefeld.de

PR target/38085
* config/i386/t-sol2 ($(T)gmon.o): Use CFLAGS instead of
MULTILIB_CFLAGS.
($(T)gcrt1.o): Likewise.
($(T)crt1.o): Likewise.
($(T)crti.o): Likewise.
($(T)crtn.o): Likewise.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr43643.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/i386/gmon-sol2.c
branches/gcc-4_4-branch/gcc/config/i386/i386.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/libgcc/ChangeLog
branches/gcc-4_4-branch/libgcc/config/i386/t-sol2


-- 


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



[Bug middle-end/43690] [4.3/4.4/4.5 Regression] Internal compiler error detected by avr-gcc.

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2010-04-08 15:11 ---
Well, we have not properly gimplified the invalid function:

doit ()
{
  char * pk;
  char * pk.1;
  char * pk.0;

bb 2:
  pk = 0B;

bb 3:
  __asm__ __volatile__(nop::m pk);
  pk = pk + 1;
  pk.0 = pk;
  __asm__ __volatile__(nop::m pk.0);
  pk.1 = pk.0 + 1;
  pk = pk.1;
  goto bb 3;


pk is addressable, so pk + 1 needs to load from pk first.

3.4.x prints

t.i: In function `doit':
t.i:6: warning: use of memory input without lvalue in asm operand 0 is
deprecated
t.i:7: warning: use of memory input without lvalue in asm operand 0 is
deprecated
t.i:6: error: impossible constraint in `asm'
t.i:7: error: impossible constraint in `asm'

so we ICE on the invalid asm.

We also fail to diagnose this with newer compilers (but the gimple verifier
triggers with checking enabled).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |middle-end
 Ever Confirmed|0   |1
  GCC build triplet|i486-linux-gnu  |
   GCC host triplet|i486-linux-gnu  |
 GCC target triplet|avr |
   Keywords||diagnostic, ice-on-invalid-
   ||code
  Known to fail||4.1.2 4.3.4 4.4.4 4.5.0
   ||4.6.0
  Known to work||3.4.6
   Last reconfirmed|-00-00 00:00:00 |2010-04-08 15:11:43
   date||
Summary|Internal compiler error |[4.3/4.4/4.5 Regression]
   |detected by avr-gcc.|Internal compiler error
   ||detected by avr-gcc.
   Target Milestone|--- |4.3.5


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



[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register

2010-04-08 Thread ro at gcc dot gnu dot org


--- Comment #7 from ro at gcc dot gnu dot org  2010-04-08 15:12 ---
Fixed for 4.4.4, 4.5.0, 4.6.0.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.4.4 4.5.0 4.6.0   |
  Known to work||4.4.4 4.5.0 4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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



[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86

2010-04-08 Thread ro at gcc dot gnu dot org


--- Comment #13 from ro at gcc dot gnu dot org  2010-04-08 15:13 ---
Reopen to document backport.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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



[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86

2010-04-08 Thread ro at gcc dot gnu dot org


--- Comment #14 from ro at gcc dot gnu dot org  2010-04-08 15:14 ---
Fixed for 4.4.4, 4.5.0.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||03/msg00609.html
 Status|REOPENED|RESOLVED
   Keywords||patch
  Known to work||4.4.4 4.5.0
 Resolution||FIXED


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



[Bug tree-optimization/43688] ICE: in analyze_function, at ipa-reference.c:733 with -fipa-reference

2010-04-08 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2010-04-08 15:18 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2010-04-08 15:18:44
   date||


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



[Bug testsuite/43495] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC

2010-04-08 Thread zsojka at seznam dot cz


--- Comment #5 from zsojka at seznam dot cz  2010-04-08 15:35 ---
Created an attachment (id=20336)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20336action=view)
testcase with inlined f()

Even when the f() is declared as

static inline __attribute__((always_inline))
double f(struct s1 *a, struct s2 *b)

the testcase still fails with:
$ gcc -fschedule-insns -fstrict-aliasing pr43495-2.c  ./a.out
Aborted


-- 


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



[Bug testsuite/43495] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC

2010-04-08 Thread zsojka at seznam dot cz


--- Comment #6 from zsojka at seznam dot cz  2010-04-08 15:38 ---
Testcase from comment #5 fails at x86_64-linux, trunk r153685, r158095.
It doesn't fail in the 4.4 branch.


-- 

zsojka at seznam dot cz changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz


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



[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums

2010-04-08 Thread jason at gcc dot gnu dot org


--- Comment #10 from jason at gcc dot gnu dot org  2010-04-08 15:57 ---
@7: But -Wconversion only warns if it knows the constant value, it doesn't warn
about converting from an arbitrary int variable such as (importantly) a loop
counter.

@5: It seems appropriate to me for VRP to optimize based on TYPE_MIN/MAX_VALUE,
the problem is that the front end is lying; either we need to apply a mask on
conversion to the enum, or we should set TYPE_MIN/MAX_VALUE to the appropriate
values for the mode.  My preference is for the latter, and it sounds like Ada
made the same choice.

The debugging backends don't seem to care about TYPE_MIN/MAX_VALUE for enums.


-- 


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



[Bug target/43669] libgcc build fails with Error: cannot represent subtraction with an offset

2010-04-08 Thread sterling_augustine at tensilica dot com


--- Comment #2 from sterling_augustine at tensilica dot com  2010-04-08 
16:05 ---
(Removed Bob Wilson who is no longer maintaining the Xtensa port.)

This problem was actually a limitation in the gnu assembler, and is fixed
there. Unfortunately, this change didn't make it into the binutils 2.20.1
release, so your only option is to apply the patch described in the message
here:

http://sourceware.org/ml/binutils/2009-09/msg00546.html


-- 

sterling_augustine at tensilica dot com changed:

   What|Removed |Added

 CC|bob dot wilson at acm dot   |
   |org |


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



[Bug c/43691] New: Code segfault when compiled with -Os, -O2, or -O3

2010-04-08 Thread mattst88 at gmail dot com
When this testcase, using inline assembly, is compiled with -Os, -O2, or -O3 it
segfaults. -O0 and -O1 allow it to run correctly.

Moving the inline assembly into a separate file and including it in the
compilation allow the program to run correctly at all -O levels.

My results are
gcc -O0 -mcpu=ev67 -D__FAIL rewritten.S test.c -o test  ./test # works
gcc -O1 -mcpu=ev67 -D__FAIL rewritten.S test.c -o test  ./test # works
gcc -Os -mcpu=ev67 -D__FAIL rewritten.S test.c -o test  ./test # segfault
gcc -O2 -mcpu=ev67 -D__FAIL rewritten.S test.c -o test  ./test # segfault
gcc -O3 -mcpu=ev67 -D__FAIL rewritten.S test.c -o test  ./test # segfault

Compiling without -D__FAIL causes the external assembly in rewritten.S to be
used. Without -D__FAIL, the program runs correctly at all -O levels.


-- 
   Summary: Code segfault when compiled with -Os, -O2, or -O3
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mattst88 at gmail dot com
 GCC build triplet: alpha-unknown-linux-gnu
  GCC host triplet: alpha-unknown-linux-gnu
GCC target triplet: alpha-unknown-linux-gnu


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



[Bug c/43691] Code segfault when compiled with -Os, -O2, or -O3

2010-04-08 Thread mattst88 at gmail dot com


--- Comment #1 from mattst88 at gmail dot com  2010-04-08 16:50 ---
Created an attachment (id=20337)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20337action=view)
rewritten.S - external assembly


-- 


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



[Bug c/43691] Code segfault when compiled with -Os, -O2, or -O3

2010-04-08 Thread mattst88 at gmail dot com


--- Comment #2 from mattst88 at gmail dot com  2010-04-08 16:50 ---
Created an attachment (id=20338)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20338action=view)
test.c


-- 


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



  1   2   >