Re: old aliasing bug: fixed?

[Albert Cahalan]

On Thu, Sep 30, 2010 at 5:39 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Thu, Sep 30, 2010 at 9:54 AM, Albert Cahalan acaha...@gmail.com wrote:
 int weird(float *fp){
        // access an int as an int (see caller),
        // so not an aliasing violation
        return *(int*)fp;
 }
 int main(int argc, char *argv[]){
        return weird((float*)argc);
 }

 I just tried this code with gcc 4.4.5 on 32-bit powerpc using -O2 -W -Wall.
 Assembly code for the weird function looks OK, both inlined and not, but
 that certainly isn't proof that gcc will always tolerate such code.
 I recall that there were problems handling this type of code. (never mind
 any non-conformant callers that actually pass a pointer to a float -- not
 that gcc would be able to see them in separately compiled files)

 So, is it fixed now? (what gcc version?) If not, is it at least fixed
 if I change float to void and/or unsigned char?

 BTW, oddly it looks like gcc tolerates a genuine aliasing violation
 as well now. (passing the value as a float) Of course, that may just
 be my luck with the optimizer.

 I indeed fixed the above problem at some point (4.1 may be still
 broken, 4.3 should be fixed I think).

 We're trying to tolerate genuine alias violations if we can see
 what the user intended (in compiler-speak, when we detect
 a must-alias relationship we do not try to disabiguate using
 type-based alias analysis).  That's just being nice to users and
 not breaking their code just because we can.

I've been trying to come up with an example where either:

a. gcc gains optimization from type-based alias analysis
b. traditional assumptions result in breakage

I am no longer able to find either. Is it safe to consider the
type-based aliasing to be essentially disabled now?

Re: Hooks, macros and target configuration

[Richard Guenther]

On Tue, Oct 19, 2010 at 11:55 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
 My ongoing work to implement the multilib selection changes described
 at http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html will in due
 course require option-related hooks to be shared between the driver
 and the compilers proper (cc1 etc.).  As we do not currently have a
 hooks system in the driver, it seems appropriate to consider what
 design we want for hooks extended into this part of the compiler -
 and, more generally, what we would like the system for target
 configuration to look like.

 (In this message I only consider designs for C.  It is certainly
 possible that in future a native C++ approach with less heavy use of
 macros may be used, but I think the same general issues arise.)

 The basic design for target hooks was implemented by Neil Booth in
 June 2001 following a discussion
 http://gcc.gnu.org/ml/gcc/2001-06/subjects.html#00932 I started
 (this was not the first time the principle of moving away from macros
 had come up), with langhooks following later that year, the
 targhooks.c system for incremental transition of individual macros to
 hooks being added in 2003, and automatic generation of much of the
 boilerplate code from a single .def file being added much more
 recently by Joern Rennecke; we now have about 300 target hooks.  The
 point that such functions should be linkable into the driver came up
 in the second message of that thread.

 The motivations for moving from macros to hooks remain as discussed
 then: cleaner design, better-specified interfaces with prototypes (so
 eliminating one cause of warnings building target-independent files
 only when configured for some targets, or errors from code conditioned
 with #if) and potentially the ability to swap out target structures
 for multi-target compiler binaries.

 In general, the existing target hooks are defined through #define
 within the target .c file, before the targetm variable is defined with
 its initializer.  This works well for hooks that largely depend on the
 target architecture alone, not on the target OS.  There are some
 exceptions where OS-dependent hooks are defined in the .h files listed
 in $tm_file, and some cases where targets modify hooks at runtime
 (this should generally be for hooks that are integer or string
 constants rather than functions, though I have not checked whether any
 function hooks are also being modified at runtime).  Such cases would
 make a multi-target compiler (with each source file compiled only
 once, but multiple target OSes for a single architecture) a bit
 harder; targetm would need to move to its own .c file, with only that
 .c file being compiled separately for each target.

 Some target macros - which should become hooks in some form - are much
 more dependent on the target OS.  This applies, in particular, to all
 the various specs used by the driver.  Given this, my inclination is
 that the driver's targetm structure should be defined in its own .c
 file, with the macros providing its initializer generally coming from
 .h files.  This isn't very far distant from the present system for
 specs (where the macros initialize variables and otherwise the
 variables are generally what's used, potentially being modified at
 runtime when a specs file is read).

 The advantage as I see it would come if the target .h files could be
 split up, with the driver-only defines coming from a separate set of
 headers from those used in the core compiler.  The ones used in the
 core compiler would likely be simpler and have fewer OS dependencies.
 It might make it easier to move towards using these headers
 consistently in the order given in config.gcc as the preferred order -
 with the aim being to avoid architecture-specific cases in config.gcc
 mentioning architecture-independent headers at all.  (A case statement
 over target architectures should deal with architecture-specific
 configuration; one over OSes should deal with OS-specific
 configuration; one over pairs should deal with the combination; and
 target-independent code should put together the lists from each of
 those case statements in the standard order.)

 This separation of configuration for different purposes is closely
 related to the issues with hooks for option handling.  Target .h files
 configuration used in various ways, with some macros used in more than
 one way:

 * Definitions for use in the target's own .c files.

 * Definitions for use in code in the target's .md files.

 * Definitions for use in code in the core compiler (middle-end and
  front ends).  tm_p.h has prototypes for use in such code, and an
  intermediate goal in converting macros to hooks might be to convert
  every macro that uses a function on any target, so that tm_p.h is
  only included in the target's .c files and in the generated files
  containing code from the .md files.

 * Definitions for use in the driver.

 * Definitions for use in collect2.  These overlap 

Re: old aliasing bug: fixed?

[Richard Guenther]

On Wed, Oct 20, 2010 at 10:29 AM, Albert Cahalan acaha...@gmail.com wrote:
 On Thu, Sep 30, 2010 at 5:39 AM, Richard Guenther
 richard.guent...@gmail.com wrote:
 On Thu, Sep 30, 2010 at 9:54 AM, Albert Cahalan acaha...@gmail.com wrote:
 int weird(float *fp){
        // access an int as an int (see caller),
        // so not an aliasing violation
        return *(int*)fp;
 }
 int main(int argc, char *argv[]){
        return weird((float*)argc);
 }

 I just tried this code with gcc 4.4.5 on 32-bit powerpc using -O2 -W -Wall.
 Assembly code for the weird function looks OK, both inlined and not, but
 that certainly isn't proof that gcc will always tolerate such code.
 I recall that there were problems handling this type of code. (never mind
 any non-conformant callers that actually pass a pointer to a float -- not
 that gcc would be able to see them in separately compiled files)

 So, is it fixed now? (what gcc version?) If not, is it at least fixed
 if I change float to void and/or unsigned char?

 BTW, oddly it looks like gcc tolerates a genuine aliasing violation
 as well now. (passing the value as a float) Of course, that may just
 be my luck with the optimizer.

 I indeed fixed the above problem at some point (4.1 may be still
 broken, 4.3 should be fixed I think).

 We're trying to tolerate genuine alias violations if we can see
 what the user intended (in compiler-speak, when we detect
 a must-alias relationship we do not try to disabiguate using
 type-based alias analysis).  That's just being nice to users and
 not breaking their code just because we can.

 I've been trying to come up with an example where either:

 a. gcc gains optimization from type-based alias analysis
 b. traditional assumptions result in breakage

 I am no longer able to find either. Is it safe to consider the
 type-based aliasing to be essentially disabled now?

int foo (int *i, float *f)
{
  *i = 1;
  *f = 0;
  return *i;
}

is a case for a.  We optimize this to return 1.  I don't quite understand
what you seek for with b, but for example for

int foo (void)
{
  int i = 1;
  *(float *)i = 0.0;
  return i;
}

GCC is allowed to optimize it to return 1, but for example GCC 4.6
will optimize it to return 0 as the user probably expected because
when optimizing the load of i we now see a must-alias store to it.

Richard.

Re: GCC RTX generation question

[Radu Hobincu]

 Radu Hobincu radu.hobi...@arh.pub.ro writes:

 1. I have the following code:

 ---
 extern void doSmth();

 void bugTest(){
  doSmth();
 }
 ---

 It compiles fine with -O0, but when I try to use -O3, I get the
 following
 compiler error:

 -
 test0.c:13: error: unrecognizable insn:
 (call_insn 7 6 8 3 test0.c:12 (call (mem:SI (mem:SI (reg/f:SI 41) [0 S4
 A32]) [0 S4 A32])
 (const_int 0 [0x0])) -1 (nil)
 (nil))
 test0.c:13: internal compiler error: in extract_insn, at recog.c:2048
 -

 I don't understand why the compiler generates (call (mem (mem (reg)
 )))...
 and also, I was under the impression that any address should checked by
 the GO_IF_LEGITIMATE_ADDRESS macro, but I checked and the macro doesn't
 receive a (mem (reg)) rtx to verify. This is most likely a failure of my
 part to describe something correctly, but the error message isn't very
 explicit.

 This looks like gcc is loading the function address from memory.  Is
 that required for your target?  Assuming it is, then the problem seems
 to be that the operand predicate for your call instruction accepts
 (mem:SI (mem:SI (reg:SI 41))).  That seems odd.

Thank you, you are right, the description of call was way off. Fixed it
and it works now with any optimization level.


 2. I have another piece of code that fails to compile with -O3.

 -
 struct desc{
  int int1;
  int int2;
  int int3;
 };

 int bugTest(struct desc *tDesc){
  return *((int*)(tDesc-int1 + 16));
 }
 --

 That code looks awfully strange.  Is that an integer or a pointer?

 This time the compiler crashes with a segmentation fault. From what I
 could dig up with gdb, the compilers tries to make a LIBCALL for a
 memcopy, but I'm not really sure why. At the end is the back-trace of
 the
 crash.

 gcc is invoking memmove.  This is happening in the return statement.
 For some reason gcc thinks that the function returns a struct.  Your
 example does not return a struct..  I can not explain this.

Ok, after changing both PARM_BOUNDARY and STACK_BOUNDARY from 8 to 32, now
the compiler no longer crashes with segmentation fault, but it still
generates a memmove syscall.

To explain the code, I have a structure holding some info about a serial
interface. One of the fields of the structure is the base address at which
the serial is mapped in the main memory. Offseted by 16 bytes is the
address from which I can read the available byte count received by the
serial. It would probably be a better practice to define the base as
(*int) rather than (int) but this should work as well. I tried both

return *((int*)tDesc-int1 + 4);
return *((int*)(tDesc-int1 + 16));

The result is the same: a system call. Is this in any way related to the
back-end definition which I might have done wrong, or is it middle-end
related?

Regards,
Radu

Re: GCC RTX generation question

[Ian Lance Taylor]

Radu Hobincu radu.hobi...@arh.pub.ro writes:

 2. I have another piece of code that fails to compile with -O3.

 -
 struct desc{
 int int1;
 int int2;
 int int3;
 };

 int bugTest(struct desc *tDesc){
 return *((int*)(tDesc-int1 + 16));
 }
 --

 That code looks awfully strange.  Is that an integer or a pointer?

 This time the compiler crashes with a segmentation fault. From what I
 could dig up with gdb, the compilers tries to make a LIBCALL for a
 memcopy, but I'm not really sure why. At the end is the back-trace of
 the
 crash.

 gcc is invoking memmove.  This is happening in the return statement.
 For some reason gcc thinks that the function returns a struct.  Your
 example does not return a struct..  I can not explain this.

 Ok, after changing both PARM_BOUNDARY and STACK_BOUNDARY from 8 to 32, now
 the compiler no longer crashes with segmentation fault, but it still
 generates a memmove syscall.

 To explain the code, I have a structure holding some info about a serial
 interface. One of the fields of the structure is the base address at which
 the serial is mapped in the main memory. Offseted by 16 bytes is the
 address from which I can read the available byte count received by the
 serial. It would probably be a better practice to define the base as
 (*int) rather than (int) but this should work as well. I tried both

 return *((int*)tDesc-int1 + 4);
 return *((int*)(tDesc-int1 + 16));

 The result is the same: a system call. Is this in any way related to the
 back-end definition which I might have done wrong, or is it middle-end
 related?

I don't know.  There is something very odd about the fact that gcc
thinks that you are returning a struct when you are actually returning
an int.  In particular, as far as I can see, cfun-returns_struct is
true.  I think you need to try to figure out why that is happening.

Ian

Re: Questions about selective scheduler and PowerPC

[Pat Haugen]

 On 10/18/2010 10:33 AM, Jeff Law wrote:

 On 10/18/10 09:22, David Edelsohn wrote:
On Mon, Oct 18, 2010 at 8:27 AM, Nathan 
Froydfroy...@codesourcery.com  wrote:

On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote:

3. The aforementioned rs6000 hack rs6000_issue_rate was added by

2003-03-03  David Edelsohnedels...@gnu.org

 * config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): 
Delete.

 (TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete.
 (rs6000_variable_issue): Do not return negative value.
 (rs6000_issue_rate): Uniformly set issue rate to 1 for first
 scheduling pass.

, which was more than 7 years ago. Is this still needed now?

I asked David about this on IRC several days ago.  He indicated that it
was necessary to prevent the first scheduling pass from unnecessarily
increasing register pressure.  I don't know whether anybody has 
actually

tested it with recent GCC, though presumably it did help when it was
installed.

I am not sure when it last was re-checked, but it was checked after
sched_pressure was added.  When that option is not enabled, the
issue_rate change still helped.
Did anyone check this after Bernd's work to better handle allocation 
of double-word pseudos in IRA?  That code should be handling the false 
conflicts created by movement of clobbers.


Running CPU2006, with the hack removed I see about a 1% improvement in 
specint (10% in 456.hmmer, a couple others in the 3% range, -3% 
401.bzip2) and a 1% degradation in specfp (mainly due to a 13% 
degradation in 435.gromacs). But 454.calculix also fails for me (output 
miscompare), so assume we're generating incorrect code for some reason 
with the hack removed.


-Pat

Re: Questions about selective scheduler and PowerPC

[Jie Zhang]

On 10/21/2010 04:08 AM, Pat Haugen wrote:

On 10/18/2010 10:33 AM, Jeff Law wrote:

On 10/18/10 09:22, David Edelsohn wrote:

On Mon, Oct 18, 2010 at 8:27 AM, Nathan
Froydfroy...@codesourcery.com wrote:

On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote:

3. The aforementioned rs6000 hack rs6000_issue_rate was added by

2003-03-03 David Edelsohnedels...@gnu.org

* config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete.
(TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete.
(rs6000_variable_issue): Do not return negative value.
(rs6000_issue_rate): Uniformly set issue rate to 1 for first
scheduling pass.

, which was more than 7 years ago. Is this still needed now?

I asked David about this on IRC several days ago. He indicated that it
was necessary to prevent the first scheduling pass from unnecessarily
increasing register pressure. I don't know whether anybody has actually
tested it with recent GCC, though presumably it did help when it was
installed.

I am not sure when it last was re-checked, but it was checked after
sched_pressure was added. When that option is not enabled, the
issue_rate change still helped.

Did anyone check this after Bernd's work to better handle allocation
of double-word pseudos in IRA? That code should be handling the false
conflicts created by movement of clobbers.


Running CPU2006, with the hack removed I see about a 1% improvement in
specint (10% in 456.hmmer, a couple others in the 3% range, -3%
401.bzip2) and a 1% degradation in specfp (mainly due to a 13%
degradation in 435.gromacs). But 454.calculix also fails for me (output
miscompare), so assume we're generating incorrect code for some reason
with the hack removed.

Thanks for benchmarking! Since there is a bug in max_issue, issue_rate 
is not really honored. Could you try this patch


http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01719.html

with and without the hack?


Regards,
--
Jie Zhang
CodeSourcery

[Bug fortran/46087] Double precision values, when read in from data file, include random trailing numbers

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20 
07:20:18 UTC ---
(In reply to comment #0)
 Results using gfortran 4.5.1:
 2.18015987

There are also different philosophies how many digits shall be printed with
list-directed I/O (fmt=*). Some compilers do not print the last / the last
few digits to avoid such puzzling results. gfortran prints all to allow
lossless reading of the written data.

However, you can use an explicit format and print fewer significant digits,
which avoids showing the last digits; for instance
 print '(g0.7)', 2.18
shows
2.18

Regarding the output:

 Results using f77:
 
 2.1800

That looks like a bug in Absoft's compiler: If the compiler shows that many
digits, it ought to show also the non-zero digits. For comparison, Intel,
PathScale and NAG show the following:
2.18015987
2.18016000
2.18015987

[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-10-20 
07:26:30 UTC ---
 The versions of the libraries mentioned on my box are
 above the minimum recommended:
 
 mpfr-3.0.0
 gmp-5.0.1
 binutils-2.20.1_3
 
 or did I miss something else?

Yes, to read carefully, especially the second paragraph.

[Bug rtl-optimization/46088] [4.6 Regression] ICE: SIGSEGV in ix86_binary_operator_ok (i386.c:15025) with -Os -fnon-call-exceptions -fpeel-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug fortran/46079] [4.6 Regression] ABI for empty stop statement broken

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c++/46078] [4.6 regression] new valgrind warnings when compiling an optimization test case

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 
08:20:06 UTC ---
The errors in libcpp is just something that we need to suppress in valgrind
suppressions.

[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/46068] [4.6 Regression] ICE: in consider_split, at ipa-split.c:313 with asm goto and __builtin_unreachable ()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[ubizjak at gmail dot com]

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

--- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2010-10-20 08:28:57 
UTC ---
(In reply to comment #2)
 Created attachment 22089 [details]
 sh script to test sqrtf
 
 Similar problems can also be found with:
 
   printf (%.60f\n%.60f\n%.60f\n, sqrtf(x), sqrtf(x), sqrtf(x));
 
 I've found that every GCC version I could test was showing some incorrect
 behavior (but GCC 4.2.4 was the most consistent one). With the attached 
 script,
 I get:
 
-DSEP  -O0   -O1   -O2
 GCC 3.4.6   SSS   SSS   SDD   SDD
 GCC 4.1.3   SSS   SSS   DSS   DDS
 GCC 4.2.4   SSS   SSS   DDD   DDD   (x86)
 GCC 4.3.5   SSS   SSS   DSS   DDD   (ditto with GCC 4.3.2 on x86)
 GCC 4.4.5   DSS   SSD   DSS   DDD
 
 where S means that one gets the result in single precision (as expected) and D
 means that one gets the result in double precision.

You should use -ffloat-store to remove excess precision.

[Bug c++/46065] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at cp/decl.c:477

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/45860] [4.6 Regression] ICE: verify_ssa failed: virtual SSA name for non-VOP decl at -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators

[rodrigorivascosta at gmail dot com]

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

--- Comment #6 from Rodrigo Rivas rodrigorivascosta at gmail dot com 
2010-10-20 08:56:30 UTC ---
Ok, thank you for the report...
It looks like the range-for temporary completely ignore destructors.

Also, if the range is a temporary it gets destructed quite early, instead of
being kept alive because of the implicit reference.

for (auto x : temp() )
//the temporary is destroyed here
{
   //...
} //instead of here

It shouldn't be too difficult to patch, though, so I'll try and have a patch in
a while...

[Bug objc/23709] [4.3/4.4/4.5/4.6 Regression] error recovery is not smart enough

[nicola at gcc dot gnu.org]

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

--- Comment #11 from Nicola Pero nicola at gcc dot gnu.org 2010-10-20 
09:03:10 UTC ---
Author: nicola
Date: Wed Oct 20 09:03:06 2010
New Revision: 165713

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165713
Log:
In gcc/testsuite/:
2010-10-20  Nicola Pero  nicola.p...@meta-innovation.com

PR objc/23709
* objc.dg/pr23709.m: New.
* obj-c++.dg/pr23709.m: New.

Added:
trunk/gcc/testsuite/obj-c++.dg/pr23709.mm
trunk/gcc/testsuite/objc.dg/pr23709.m
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/46092] New: Improve constant handling of thumb2 instructions

[carrot at google dot com]

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

   Summary: Improve constant handling of thumb2 instructions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
CC: car...@google.com
  Host: i686-linux
Target: arm-eabi
 Build: i686-linux


Compile the following code with options -march=armv7-a -mthumb -Os

unsigned long tv(unsigned long x)
{
  if (x = 65521)
x = x - 65521;
  return x;
}

gcc generates:

tv:
movwr3, #65520
cmp r0, r3
ittthi
subhi   r0, r0, #65024   // A
subhi   r0, r0, #496 // B
subhi   r0, r0, #1   // C
bx  lr

Notice that (x = x - 65521) is translated into 3 instructions. Actually 65521
can be loaded into register with one instruction. So the shorter result is:

tv:
movwr3, #65520
cmp r0, r3
ittthi
movwhi   r1, #65521
subhi   r0, r1
bx  lr

This should be improved by function arm_gen_constant. The function is already
commented with
/* ??? This needs more work for thumb2.  */

[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 
09:39:29 UTC ---
Or in 4.6 better yet -std=c99 or -fexcess-precision=standard

[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.20 09:52:32
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 
09:52:31 UTC ---
Created attachment 22090
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22090
gcc46-pr46066.patch

Untested fix.

[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[zimmerma+gcc at loria dot fr]

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

--- Comment #5 from Paul Zimmermann zimmerma+gcc at loria dot fr 2010-10-20 
09:54:01 UTC ---
(In reply to comment #3)
 You should use -ffloat-store to remove excess precision.

the main issue is not the excess of precision, but the fact that identical
calls
to printf with identical arguments give different values in the same program!

The fact that different versions of GCC behave differently vs precision is a
different issue.

Paul

[Bug tree-optimization/45860] [4.6 Regression] ICE: verify_ssa failed: virtual SSA name for non-VOP decl at -O1

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 
09:57:41 UTC ---
I have a patch.

[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators

[rodrigorivascosta at gmail dot com]

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

--- Comment #7 from Rodrigo Rivas rodrigorivascosta at gmail dot com 
2010-10-20 10:06:39 UTC ---
I've just sent a patch to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01699.html

In the testcase I added a lot of other destructor checks, just to be sure.

[Bug lto/46083] gcc.dg/initpri1.c FAILs with -flto/-fwhopr (attribute constructor/destructor doesn't work)

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 
10:06:54 UTC ---
Honza, maybe your constructor re-ordering doesn't honor priority?

[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 
10:46:14 UTC ---
That depends on the register allocation, whether the result of fsqrt needs to
be flushed into memory or can stay in the i387 register stack.  In the former
case it gets rounded from long double to float, in the latter case it doesn't.

OT, I wonder about:
  /* Test the result; if it is NaN, set errno=EDOM because
 the argument was not in the domain.  */
  do_compare_rtx_and_jump (target, target, EQ, 0, GET_MODE (target),
   NULL_RTX, NULL_RTX, lab,
   /* The jump is very likely.  */
   REG_BR_PROB_BASE - (REG_BR_PROB_BASE / 2000 - 1));
Why do we use (EQ target target) here instead of (ORDERED target target)?
At least on i?87 the latter is cheaper than the former, we eventually simplify
it, but it would be IMHO better to avoid generating useless rtx when the
comparison often needs to be split into ORDERED  UNEQ.

[Bug target/46093] New: code compiled with -fsplit-stack crashes when passing large struct

[zsojka at seznam dot cz]

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

   Summary: code compiled with -fsplit-stack crashes when passing
large struct
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


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

Output (-g is not needed to reproduce):
$ gcc -fsplit-stack testcase.c -g
$ gdb ./a.out
...
Program received signal SIGSEGV, Segmentation fault.
0x00400ca9 in foo (s=...) at testcase.c:14
14bar (s);
(gdb) bt
#0  0x00400ca9 in foo (s=...) at testcase.c:14
#1  0x00400d84 in __morestack () at
/mnt/svn/gcc-trunk/libgcc/config/i386/morestack.S:374
#2  0x00400d00 in main () at testcase.c:21

I am not sure if that can be a problem here, but this is my binutils info:
$ ld -v
GNU ld (GNU Binutils) 2.20.1.20100303

[Bug tree-optimization/45860] [4.6 Regression] ICE: verify_ssa failed: virtual SSA name for non-VOP decl at -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 
11:09:57 UTC ---
Author: rguenth
Date: Wed Oct 20 11:09:54 2010
New Revision: 165718

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165718
Log:
2010-10-20  Richard Guenther  rguent...@suse.de

PR tree-optimization/45860
* tree-ssa-phiopt.c (cond_store_replacement): Do not do
conditional store replacement for non-register type stores.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr45860.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/46085] [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-20 
11:21:22 UTC ---
Author: hjl
Date: Wed Oct 20 11:21:19 2010
New Revision: 165719

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165719
Log:
Correct reduc_splus_v8sf and reduc_splus_v4df.

gcc/

2010-10-20  H.J. Lu  hongjiu...@intel.com

PR target/46085
* config/i386/sse.md (reduc_splus_v8sf): Updated.
(reduc_splus_v4df): Likewise.

gcc/testsuite/

2010-10-20  H.J. Lu  hongjiu...@intel.com

PR target/46085
* gcc.target/i386/pr46085-1.c: New.
* gcc.target/i386/pr46085-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr46085-1.c
trunk/gcc/testsuite/gcc.target/i386/pr46085-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/46094] New: -fsplit-stack doesn't honour x86_64 ABI wrt. stack alignment

[zsojka at seznam dot cz]

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

   Summary: -fsplit-stack doesn't honour x86_64 ABI wrt. stack
alignment
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


If I understand http://www.x86-64.org/documentation/abi.pdf correctly, and the
ABI described here is valid enough, -fsplit-stack doesn't align stack correctly
when calling functions.
At the moment of function entry, this should hold: (rsp15)==8

As example, I will use the testcase from PR46093 (
http://gcc.gnu.org/bugzilla/attachment.cgi?id=22091 ). There are values of rsp
at the moment of function entry:

GDB breakpoints:
b main
b foo
b __morestack
b __morestack_block_signals
b __generic_morestack
b __morestack_unblock_signals
b __generic_releasestack
b pthread_sigmask
b sigprocmask

(for some reason, breakpoint at __morestack wasn't set correctly by this
procedure, so I had to set it manually)

functionrsp
main0x7fffde58
__morestack 0x7fffde50
__morestack_block_signals   0x7fffddf0
sigprocmask 0x7fffddf0
__generic_morestack 0x7fffde00
__morestack_unblock_signals 0x77ff9ff8
sigprocmask 0x77ff9ff8
foo 0x77ff5fe8
...

this could cause problem if (for example) sigprocmask() used SSE instructions
to access stack

[Bug tree-optimization/46085] [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3

[hjl.tools at gmail dot com]

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

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 11:26:39 
UTC ---
Fixed.

[Bug c++/46065] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at cp/decl.c:477

[hjl.tools at gmail dot com]

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

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.20 11:34:47
 CC||hjl.tools at gmail dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 11:34:47 
UTC ---
It is caused by revision 162223:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00577.html

[Bug tree-optimization/45860] [4.6 Regression] ICE: verify_ssa failed: virtual SSA name for non-VOP decl at -O1

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 
12:11:17 UTC ---
Fixed.

[Bug bootstrap/45954] LTO isn't enabled in stage1 cc1 with --with-build-config=bootstrap-lto

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-20 
12:38:33 UTC ---
Author: hjl
Date: Wed Oct 20 12:38:22 2010
New Revision: 165721

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165721
Log:
Add LTO to boot language if it is enabled.

2010-10-20  H.J. Lu  hongjiu...@intel.com

PR bootstrap/45954
* config-lang.in (boot_language): Set to $enable_lto.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/config-lang.in

[Bug bootstrap/45954] LTO isn't enabled in stage1 cc1 with --with-build-config=bootstrap-lto

[hjl.tools at gmail dot com]

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

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 12:40:11 
UTC ---
Fixed.

[Bug fortran/46067] [F03] invalid procedure pointer assignment not detected

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.20 13:11:39
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #5 from janus at gcc dot gnu.org 2010-10-20 13:11:39 UTC ---
Mine. The accepts-invalid problem in comment #2 is fixed by the following
patch:

Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 165712)
+++ gcc/fortran/interface.c(working copy)
@@ -1056,7 +1056,7 @@ gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol
   }

 /* Check type and rank.  */
-if (!compare_type_rank (f1-sym, f2-sym))
+if (!compare_type_rank (f2-sym, f1-sym))
   {
 if (errmsg != NULL)
   snprintf (errmsg, err_len, Type/rank mismatch in argument '%s',

[Bug debug/46095] New: [4.6 Regression] ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:2341 with -fstack-protector

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in dwarf2out_frame_debug_expr,
at dwarf2out.c:2341 with -fstack-protector
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


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

Compiler output:
$ gcc -O -fschedule-insns2 -fno-omit-frame-pointer -fstack-protector pr46095.c
pr46095.c: In function 'foo':
pr46095.c:8:1: internal compiler error: in dwarf2out_frame_debug_expr, at
dwarf2out.c:2341
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r165719 - crash
r163636 - OK

[Bug c/46090] 16 bit uint16_t puts non-zero in highest bits when shifting

[kshakhna at gmail dot com]

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

--- Comment #2 from Kamo Shakhnazaryan kshakhna at gmail dot com 2010-10-20 
13:30:40 UTC ---
(In reply to comment #1)
 input * 0x0101 is really ((int)input) * 0x0101.  So this behavior is correct.

input is declared as uint16_t.

Why input * 0x0101 is really ((int)input) * 0x0101 ?

[Bug c/46090] 16 bit uint16_t puts non-zero in highest bits when shifting

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 
13:34:31 UTC ---
Because that's what the C standard says, under the rules for integer promotions

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[danglin at gcc dot gnu.org]

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

--- Comment #88 from John David Anglin danglin at gcc dot gnu.org 2010-10-20 
13:41:38 UTC ---
(In reply to comment #85)
 Created attachment 22079 [details]
 patch
 I haven't yet tested this on a cross-compiler, but it bootstrapped and
 regtested fine on x86_64-pc-linux-gnu.

I also tested the patch on armv5tejl-unknown-linux-gnueabi.  The ICE in
function '__popcountsi2' is still there, so this must be a separate issue.

[Bug c++/46065] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in poplevel_named_label_1, at cp/decl.c:477

[froydnj at gcc dot gnu.org]

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

Nathan Froyd froydnj at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Froyd froydnj at gcc dot gnu.org 2010-10-20 
13:46:08 UTC ---
I will fix this shortly after stage 3 starts.

[Bug c/45062] [4.6 Regression] Revision 162223 caused ICE at c-decl.c:4064

[froydnj at gcc dot gnu.org]

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

Nathan Froyd froydnj at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Froyd froydnj at gcc dot gnu.org 2010-10-20 
13:47:51 UTC ---
I will fix this shortly after stage 3 starts.

[Bug c++/46096] New: Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

   Summary: Code produces two different outputs when optimized
respectively with -O2 and without it.
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zwei...@gmail.com


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

The code attached is a very simple application of threads using SDL_threads
library. 

In the code just one thread is created and it should enter in a loop waiting
for a class variable to become 4 and exit printing END on the screen. Since
the variable is modified to 4 in the main program, the thread should exit and
print END on the screen always. However, this does not happen all the time in
the -O2 compiled version.

The compiled version WITHOUT -O2 gives the expected output END (Reproducible:
always).
On the other hand, the -O2 version of the code produces an executable which
sometimes print and sometimes do not print END on the screen (Occasionally
one may need to run the program 20 times to spot 1 error). 

I attached the very simple test.cpp file.

And here is the output from g++ without optimization:

g++ -v -save-temps -o sdl_thread -Wall test.cpp -lSDL 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.3.4 p1.1, pie-10.1.5'
Thread model: posix
gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=i686 -Wall -fpch-preprocess
-o test.ii
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/i686-pc-linux-gnu
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/backward
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=i686 -auxbase test -Wall -version -o
test.s
GNU C++ (Gentoo 4.3.4 p1.1, pie-10.1.5) version 4.3.4 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.4, GMP version 4.3.2, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a9af7e955b36498814b0c0d47ad1b377
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o test.o test.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.18
COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker 

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[vmakarov at gcc dot gnu.org]

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

--- Comment #23 from Vladimir Makarov vmakarov at gcc dot gnu.org 2010-10-20 
13:51:37 UTC ---
Author: vmakarov
Date: Wed Oct 20 13:51:31 2010
New Revision: 165722

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165722
Log:
2010-10-20  Vladimir Makarov  vmaka...@redhat.com

PR fortran/42169
* ira-emit.c (store_can_be_removed_p): Return false instead of
gcc_unreachable.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-emit.c

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
   Severity|major   |normal

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 
14:00:49 UTC ---
There is no memory synchronisation, so there is no guarantee that the write to
alpha1-number ever becomes visible to other threads.

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[vmakarov at gcc dot gnu.org]

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

--- Comment #24 from Vladimir Makarov vmakarov at gcc dot gnu.org 2010-10-20 
14:05:25 UTC ---
Author: vmakarov
Date: Wed Oct 20 14:05:21 2010
New Revision: 165723

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165723
Log:
2010-10-20  Vladimir Makarov  vmaka...@redhat.com

PR fortran/42169
* ira-emit.c (store_can_be_removed_p): Return false instead of
gcc_unreachable.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/ira-emit.c

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[vmakarov at gcc dot gnu.org]

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

--- Comment #25 from Vladimir Makarov vmakarov at gcc dot gnu.org 2010-10-20 
14:06:11 UTC ---
Author: vmakarov
Date: Wed Oct 20 14:06:08 2010
New Revision: 165724

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165724
Log:
2010-10-20  Vladimir Makarov  vmaka...@redhat.com

PR fortran/42169
* ira-emit.c (store_can_be_removed_p): Return false instead of
gcc_unreachable.


Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/ira-emit.c

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

--- Comment #2 from Danilo zweifel at gmail dot com 2010-10-20 14:07:45 UTC 
---
(In reply to comment #1)
 There is no memory synchronisation, so there is no guarantee that the write to
 alpha1-number ever becomes visible to other threads.

According to http://wiki.libsdl.org/moin.cgi/SDL_CreateThread, the threads
created share the same memory. So I guess sync is not needed.

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[bonzini at gnu dot org]

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

--- Comment #89 from Paolo Bonzini bonzini at gnu dot org 2010-10-20 14:09:33 
UTC ---
The armv5 failure is a stage2 miscompilation.  Is it caused by Bernd's patch
too?  Or by fwprop?

According to comment 22, previously it was not bootstrapping but the failure
was elsewhere.  But we don't know if it is one or two bugs, and we don't know
how it relates with the fwprop problem (which was latent all the time even
before Bernd's patch).  The only good news is that a stage2 libgcc crash is
slightly simpler to debug than a stage3 comparison failure.  In any case, the
next thing to do is to bisect to find where the crash appeared, then go to the
previous revision, try applying my patch and see if it fixes the failure of
comment 22.

[Bug lto/45667] [4.6 Regression] ICE: verify_stmts failed: type mismatch in address expression with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 
14:11:09 UTC ---
Author: rguenth
Date: Wed Oct 20 14:11:06 2010
New Revision: 165725

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165725
Log:
2010-10-20  Richard Guenther  rguent...@suse.de

PR lto/45667
* lto-streamer-out.c (output_gimple_stmt): Fix typo.
* tree-cfg.c (verify_gimple_call): Properly get the call fndecl.
(verify_gimple_assign_single): Disable ADDR_EXPR type check
when in LTO.

* g++.dg/lto/20101020-1_0.h: New testcase.
* g++.dg/lto/20101020-1_0.C: Likewise.
* g++.dg/lto/20101020-1_1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/lto/20101020-1_0.C
trunk/gcc/testsuite/g++.dg/lto/20101020-1_0.h
trunk/gcc/testsuite/g++.dg/lto/20101020-1_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2010-10-20 
14:13:44 UTC ---
Author: jason
Date: Wed Oct 20 14:13:38 2010
New Revision: 165726

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165726
Log:
PR c++/46056
* parser.c (cp_convert_range_for): Call cp_finish_decl
instead of finish_expr_stmt.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/45667] [4.6 Regression] ICE: verify_stmts failed: type mismatch in address expression with -flto

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-20 
14:14:07 UTC ---
Fixed.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

Danilo zweifel at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #3 from Danilo zweifel at gmail dot com 2010-10-20 14:17:30 UTC 
---
Changed the status back to unconfirmed.

[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators

[alserkli at inbox dot ru]

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

Alexander Klimov alserkli at inbox dot ru changed:

   What|Removed |Added

  Attachment #22086|0   |1
is obsolete||

--- Comment #9 from Alexander Klimov alserkli at inbox dot ru 2010-10-20 
14:19:23 UTC ---
Created attachment 22094
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22094
simple testcase

Your patch seems to work, thanks!

Btw, the original simple testcase did not contain

  It(const It){ ++it_counter; }

and thus would fail (It() is called twice, while ~It() -- thrice).

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 
14:24:30 UTC ---
yes, they share the same address space, but modern processors have multilevel
caches and unless you provide suitable synchronisation the write to
alpha1-number might not get made visible to other threads

I suggest you use a mutex around shared data

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 
14:27:18 UTC ---
The field is not volatile, so in the loop nothing forces -number field to be
loaded from memory again.
So it is perfectly fine to optize the whole loop into:
if (alpha1-number!=4)
  for (;;); /* Endless loop.  */

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 
14:29:09 UTC ---
Using a mutex around the reads and writes of shared data will make it work as
expected, the compiler won't optimise away the read and will re-read the value
every time.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-10-20 
14:34:40 UTC ---
 Using a mutex around the reads and writes of shared data will make it work as
 expected, the compiler won't optimise away the read and will re-read the value
 every time.

This is overkill here though, you just need:

  volatile alpha *alpha1 = ( alpha * )data;

[Bug c++/46097] New: Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

   Summary: Switch to warn of global variables in a C++ shared
object
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: noloa...@gmail.com


Feature reqeust only. Not a bug.

C++ shared objects are an interesting beast under certain circumstances (many
times, the shared object acts like a generic C module). Interesting includes:
* C++ module
* Shared object
* Shared object throws an exception which will cross module boundaries
* Shared object opened with RTLD_GLOBAL
* Shared object has global objects with destructors

Lots have been said about C++ exceptions, RTTI, type equality for the
'catch(const Exception)', and RTLD_GLOBAL (versus RTLD_LOCAL) [1,2,3,4,5].

When a module meets the above compile and runtime requirements, a crash can
occur in global objects with destructors when more than one process loads and
subsequently unloads a shared object.

A switch to warn of global variables in a compilation unit would be very
helpful for those who are aware of the issue (and the circumstances to
encounter the issue). It appears that GCC does not supply such a switch [6].

The switch would be useful for module writers since its not always feasible to
'hand audit' all project files. And a warning would be exetremely useful for
package maintainers who don't write the module - they simply fixup the code and
package it for a distribution.

Perhaps -Wglobal-variable?

Jeffrey Walton
Baltimore, MD, US

[1] Minimal GCC/Linux shared lib + EH bug example,
http://gcc.gnu.org/ml/gcc/2002-05/msg00866.html
[2] dlopen and placing exception body in .cpp file,
http://gcc.gnu.org/ml/gcc-help/2010-08/msg00290.html
[3] Comparing types across SOs (sic),
http://groups.google.com/group/cryptopp-users/browse_thread/thread/eb815f228db50380
[4] Errors with multiple loading cryptopp as shared lib on Linux,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc22e8c6e2f48
[5] RTLD_GLOBAL and libcryptopp.so crash,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726
[6] Audit Use of Global Variables in C++ Shared Object (GCC Warning?), GCC-Help
mailing list, October, 2010 [not yet indexed].

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #90 from dave at hiauly1 dot hia.nrc.ca 2010-10-20 14:39:26 UTC ---
 The armv5 failure is a stage2 miscompilation.  Is it caused by Bernd's patch
 too?  Or by fwprop?

Actually, the ICE I saw this morning was in stage3.  This box is only
accessible at my contractor's site, so my access to it is limited.

Dave

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 
14:40:21 UTC ---
I don't recommend people use volatile to avoid multithreading races, it only
prevents compiler optimisations, not hardware reordering. Using proper atomics,
memory barriers or other explicit synchronisation is better.
But for this testcase, yes, volatile will fix it.

Danilo, you might like to read these
http://www.drdobbs.com/cpp/201804238
http://www.drdobbs.com/high-performance-computing/212701484

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

--- Comment #9 from Danilo zweifel at gmail dot com 2010-10-20 14:43:18 UTC 
---
(In reply to comment #7)
  Using a mutex around the reads and writes of shared data will make it work 
  as
  expected, the compiler won't optimise away the read and will re-read the 
  value
  every time.
 
 This is overkill here though, you just need:
 
   volatile alpha *alpha1 = ( alpha * )data;

This solved it! Did not know about volatile variables. I was trying to avoid
exactly the use of mutexes and the like.

Thank you very much!

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

Danilo zweifel at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #10 from Danilo zweifel at gmail dot com 2010-10-20 14:45:18 UTC 
---
(In reply to comment #8)
 I don't recommend people use volatile to avoid multithreading races, it only
 prevents compiler optimisations, not hardware reordering. Using proper 
 atomics,
 memory barriers or other explicit synchronisation is better.
 But for this testcase, yes, volatile will fix it.
 
 Danilo, you might like to read these
 http://www.drdobbs.com/cpp/201804238
 http://www.drdobbs.com/high-performance-computing/212701484

Thanks you very much, Jonathan! I will surely read the references.

I am considering this as closed.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 
14:46:24 UTC ---
Busy waiting is rarely a good idea, so it depends on what are you exactly
waiting for and whether say pthread_barrier_wait, or mutex, or condvar etc.
wouldn't be more appropriate.

[Bug tree-optimization/38153] ICE in testcase when compiled with -ftree-parallelize-loops

[zsojka at seznam dot cz]

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

Zdenek Sojka zsojka at seznam dot cz changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #4 from Zdenek Sojka zsojka at seznam dot cz 2010-10-20 14:52:32 
UTC ---
A bit different testcase, crashes on x86_64-pc-linux-gnu, r165719

- testcase.c -
void
foo (void **a, int i)
{
  while (i--)
a[i] = label;
label:;
}
--

$ gcc -O -ftree-parallelize-loops=2 testcase.c
testcase.c: In function 'foo':
testcase.c:2:1: error: label 
label has incorrect context in bb 6testcase.c:2:1: internal compiler error:
verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

-ftree-parallelize-loops=N, crashes for N=2

[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer

[zsojka at seznam dot cz]

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

Zdenek Sojka zsojka at seznam dot cz changed:

   What|Removed |Added

  Known to fail||4.3.5, 4.4.5, 4.5.2

--- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-10-20 15:02:12 
UTC ---
4.1.2 doesn't know _Decimal128, 4.2.4 refuses to compile

$ gcc-4.1.2 -Os -fno-omit-frame-pointer pr45946.c
pr45946.c:3: warning: parameter names (without types) in function declaration

$ gcc-4.2.4 pr45946.c
pr45946.c:2: error: decimal floating point not supported for this target

4.3.5 and newer compile without any optimisation, but fail with given flags

[Bug c++/45983] [4.5 Regression] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2010-10-20 
15:05:28 UTC ---
Author: jason
Date: Wed Oct 20 15:05:22 2010
New Revision: 165728

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165728
Log:
PR c++/45983
* tree.c (cp_build_qualified_type_real): Don't reuse a variant
with a different typedef variant of the element type.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/lto/pr45983_0.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/tree.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug target/46098] New: [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[zsojka at seznam dot cz]

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

   Summary: [4.5/4.6 Regression] ICE: in extract_insn, at
recog.c:2100 with -msse3 -ffloat-store and
__builtin_ia32_loadupd()
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.c -
typedef double v2df __attribute__((vector_size (16)));

v2df foo (double *d)
{
  return __builtin_ia32_loadupd (d);
}
--

Compiler output:
$ gcc -msse3 -ffloat-store testcase.c
testcase.c: In function 'foo':
testcase.c:6:1: error: unrecognizable insn:
(insn 7 6 8 3 (set (mem/c/i:V2DF (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -16 [0xfff0])) [0 D.2706+0 S16 A128])
(unspec:V2DF [
(mem:V2DF (reg:DI 60) [0 S16 A8])
] UNSPEC_MOVU)) testcase.c:5 -1
 (nil))
testcase.c:6:1: internal compiler error: in extract_insn, at recog.c:2110
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r165719 - crash
r153685 - crash
4.5 r163761 - crash
4.4 r160770 - OK

[Bug tree-optimization/45919] [4.6 Regression] ICE: SIGSEGV in fold_ctor_reference (tree-ssa-ccp.c:1527) at -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 
15:19:12 UTC ---
Created attachment 22095
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22095
gcc46-pr45919.patch

Untested fix.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 
15:52:53 UTC ---
(In reply to comment #0)
 When a module meets the above compile and runtime requirements, a crash can
 occur in global objects with destructors when more than one process loads and
 subsequently unloads a shared object.

Are you saying independent processes interfere with each other?

[Bug tree-optimization/46099] New: [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g

[zsojka at seznam dot cz]

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

   Summary: [4.5/4.6 Regression] ICE: in replace_ssa_name, at
tree-cfg.c:5643 with -ftree-parallelize-loops -g
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


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

Compiler output:
$ gcc -ftree-parallelize-loops=2 -g -O pr46099.c 
pr46099.c: In function 'foo':
pr46099.c:7:1: internal compiler error: in replace_ssa_name, at tree-cfg.c:5643
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r165719 - crash
r158095 - crash
r153685 - OK
4.5 r163761 - crash
4.4 r160770 - OK

[Bug fortran/46100] New: Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

   Summary: Non-variable pointer expression as actual argument to
INTENT(OUT) non-pointer dummy
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Reported at c.l.f by Thomas Jahns:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread
/a64e2f255466a87a

GNU Fortran (and most other compilers) reject passing a non-variable pointer
expression as actual argument to an INTENT(OUT)/INTENT(INOUT) non-pointer dummy
argument.

The reason for rejecting is that the pointer expression (i.e. a function
returning a pointer) itself is not definable. However, I believe now that it
the code is valid. Thus, only if the argument were a pointer dummy or the
expression were not a pointer expression, it would be invalid.

Example:

call one (two ())
contains
  subroutine one (x)
integer, intent(inout) :: x
  end subroutine one
  function two ()
integer, pointer :: two
allocate(two)
  end function two
end

Error message:

call one (two ())
  1
Error: Non-variable expression in variable definition context (actual argument
to INTENT = OUT/INOUT) at (1)

[Bug rtl-optimization/43721] Failure to optimise (a/b) and (a%b) into single __aeabi_idivmod call

[ams at gcc dot gnu.org]

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

Andrew Stubbs ams at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ams at gcc dot gnu.org

--- Comment #6 from Andrew Stubbs ams at gcc dot gnu.org 2010-10-20 16:53:13 
UTC ---
Here's the problem: expand_divmod always prefers the straight div library
call over the divmod library call, no exceptions.

Yes, divmodsi4 in a .md is indeed preferred over divsi4, so the
optimization works fine on targets that have those, but ARM doesn't, so those
rules are irrelevant.

ARM does not provide a separate library function for mod, so expand_divmod
does use divmod for mod operations, but never for div operations.

The reason for the apparent opposite rules appears to be that the divmodsi4
rule can be coded to auto-detect the most optimal kind of underlying operation
to use, whereas the library call is fixed, once chosen.

I see two possible ways to fix this:
 1. Teach CSE (or somewhere) that div and divmod library calls have some
overlap.
 2. Always prefer divmod, and find some other way to convert it to div, where
appropriate.

I don't see any way to generate the RTL with the right call, so I'm pretty sure
it does have to be fixed up after the fact.

Or, I could be way off. :)

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

--- Comment #12 from Danilo zweifel at gmail dot com 2010-10-20 16:53:53 UTC 
---
(In reply to comment #11)
 Busy waiting is rarely a good idea, so it depends on what are you exactly
 waiting for and whether say pthread_barrier_wait, or mutex, or condvar etc.
 wouldn't be more appropriate.

My objective of using threads is to detach a system in a simulation
environment. For this reason, it would be impracticable to use any type of lock
for everytime the I/O changes (which will happen all the time), so I guess
volatiles are the only way??

I am still reading the sites posted by Jonathan and understanding the
difficulties of doing this in modern CPUs, while it is so easy in hardware.
Maybe just always compiling without optimizations will do?

[Bug debug/46101] New: [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in build_abbrev_table, at
dwarf2out.c:10333 with -feliminate-dwarf2-dups -g
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


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

Compiler output:
$ gcc -feliminate-dwarf2-dups -g pr46101.C 
pr46101.C:6:4: internal compiler error: in build_abbrev_table, at
dwarf2out.c:10333
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r165719 - crash
r161659 - crash
r159696 - OK
4.5 r163761 - OK

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 
16:57:45 UTC ---
If the value changes because of IO (rather than being set by another thread, as
in your testcase) then volatile might be the right option.  Condvars could also
work and allow you to block, rather than doing a busy wait while holding a
lock.

[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[hjl.tools at gmail dot com]

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

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.20 16:58:52
 CC||hjl.tools at gmail dot com,
   ||matz at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 16:58:52 
UTC ---
It is caused by revision 146817:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-10-20 
17:18:33 UTC ---
 Maybe just always compiling without optimizations will do?

Adding volatile is exactly saying do not optimize this loop, i.e. you get
at -O2 what you do at -O0, nothing more, nothing less.  This is a language
feature that is orthogonal to the synchronization stuff.

[Bug fortran/46100] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20 
17:21:30 UTC ---
Forgot to add: In the current ISO Fortran standard (Fortran 2008), one finds:

If a nonpointer dummy argument without the VALUE attribute corresponds
to a pointer actual argument that is pointer associated with a target,
the dummy argument becomes argument associated with that target.

The INTENT (INOUT) attribute for a nonpointer dummy argument specifies
that any actual argument that corresponds to the dummy argument shall be
definable.

definable -- capable of definition and permitted to become defined

Thus, it boils down to the questions whether the target (to which the
pointer is pointer associated) is definable. I think that is usually
the case, which makes the example valid.

 * * *

Note, however, that Richard Maine disagrees - he thinks that it is invalid
Fortran 2003, while it might be valid Fortran 2008. I cannot see an essential
difference between the F2003 and F2008 wording, but there might be.

(See thread and see interpretation request F95/0074 in
http://j3-fortran.org/doc/standing/links/022.txt . Using a pointer function as
LHS of an assignment is tracked by F2008's PR 40054.)

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton noloader at gmail dot com 2010-10-20 
17:33:43 UTC ---
(In reply to comment #1)
 (In reply to comment #0)
  When a module meets the above compile and runtime requirements, a crash can
  occur in global objects with destructors when more than one process loads 
  and
  subsequently unloads a shared object.
 Are you saying independent processes interfere with each other?
Yes and No :/

If each process loads the SO with RTLD_LOCAL, then No. If the processes each
load with RTLD_GLOBAL (so an exception can be caught) *AND* the SO has an
non-trivial global (such as an object with a destructor) then YES.

Crpyto++ has a test case demonstrating the RTLD_GLOBAL crash at [1]. [1] is
accompanied by an analysis under GDB at [2]. Unfortunately, the test case is
not minimal. It is based on the Crypto++ library and needs intermediate SOs to
load the SO of interest. So the final executable never directly loads the
Crypto++ shared object.

Based on the demonstartion, Wei Dai modified global objects so that only PODs
were global. Non-trivial objects were hidden in a GetGlobalXxx() (some hand
waiving). A write up distribution packagers (from our understanding of the
moving parts) is available at [3,4].

[1] http://www.cryptopp.com/w/images/8/89/Cryptopp-SO-Test-1.zip
[2]
http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726
[3] http://www.cryptopp.com/wiki/Linux#Note_for_Shared_Object_Callers
[4] http://www.cryptopp.com/wiki/Linux#Note_for_Distribution_Packagers

[Bug c++/46024] g++.dg/warn/miss-format-1.C FAILs on Solaris 8 and 9

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2010-10-20 17:36:24 UTC 
---
Author: ro
Date: Wed Oct 20 17:36:15 2010
New Revision: 165731

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165731
Log:
fixincludes:
PR c++/46024
* inclhack.def (solaris_sys_va_list): New fix.
* fixincl.x: Regenerate.
* tests/base/sys/va_list.h: New test.

gcc/testsuite:
PR c++/46024
* g++.dg/warn/miss-format-1.C: Enclose dg-error target list in braces.

Added:
trunk/fixincludes/tests/base/sys/va_list.h
Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/miss-format-1.C

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #3 from Jeffrey Walton noloader at gmail dot com 2010-10-20 
17:38:59 UTC ---
(In reply to comment #2)
 (In reply to comment #1)
  (In reply to comment #0)
   When a module meets the above compile and runtime requirements, a crash 
   can
   occur in global objects with destructors when more than one process loads 
   and
   subsequently unloads a shared object.
  Are you saying independent processes interfere with each other?
 ...
 Crpyto++ has a test case demonstrating the RTLD_GLOBAL crash at [1]. [1] is
 accompanied by an analysis under GDB at [2]. Unfortunately, the test case is
 not minimal. It is based on the Crypto++ library and needs intermediate SOs to
 load the SO of interest. So the final executable never directly loads the
 Crypto++ shared object.
If a picture is worth a 1000 words, here's the scenario we are trying to
accomplist (to verify Crypto++ does not crash when unloaded). But keep in mind
that two distinct process will perform what's in the image.
http://www.cryptopp.com/wiki/File:Cryptopp-so-test.png

[Bug fortran/46100] [Fortran 2008] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|Non-variable pointer|[Fortran 2008] Non-variable
   |expression as actual|pointer expression as
   |argument to INTENT(OUT) |actual argument to
   |non-pointer dummy   |INTENT(OUT) non-pointer
   ||dummy

--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20 
17:45:27 UTC ---
After carefully reading the interpretation request,
http://www.j3-fortran.org/doc/year/08/08-172.txt, I think the reason that it is
invalid in Fortran 95/2003 is that only variables are definable and as f() is
not a variable, it is invalid.

Fortran 2008 has (cf. PR 40054):
   R602 variable  is  designator
  or  expr
   C602 (R602) expr shall be a reference to a function that has a pointer
   result.

Which makes the program valid.

[Bug debug/46102] New: ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490) with -feliminate-dwarf2-dups when using precompiled headers

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490)
with -feliminate-dwarf2-dups when using precompiled
headers
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.H -
/* NOTHING */
--
- testcase.C -
#include testcase.H
int i;
--

Generate files:
echo   testcase.H
echo '#include testcase.H'  testcase.C
echo 'int i;'  testcase.C

Compile:
(testcase.H can be compiled with -feliminate-dwarf2-dups, it still fails)
$ gcc -g testcase.H
$ gcc -g testcase.C -feliminate-dwarf2-dups
testcase.C:2:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Related valgrind output:
==21702== Invalid read of size 8
==21702==at 0x74AB61: dwarf2out_finish (dwarf2out.c:8490)
==21702==by 0x9C6A15: toplev_main (toplev.c:961)
==21702==by 0x658ABBC: (below main) (in /lib64/libc-2.11.2.so)
==21702==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==21702== 
testcase.C:2:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r165719 - crash
r158095 - crash
r153685 - crash
4.1.2, 4.2.4, 4.3.5, 4.4.5 - crash

[Bug debug/46101] [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug tree-optimization/46099] [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.2

[Bug fortran/46100] [Fortran 2008] Non-variable pointer expression as actual argument to INTENT(OUT) non-pointer dummy

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20 
18:01:54 UTC ---
Untested patch:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 5711634..ef516a4 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4316,7 +4316,18 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer,
const char* context)
   symbol_attribute attr;
   gfc_ref* ref;

-  if (e-expr_type != EXPR_VARIABLE)
+  if (!pointer  e-expr_type == EXPR_FUNCTION
+   e-symtree-n.sym-result-attr.pointer)
+{
+  if (!(gfc_option.allow_std  GFC_STD_F2008))
+   {
+ if (context)
+   gfc_error (Fortran 2008: Pointer functions in variable definition
+   context (%s) at %L, context, e-where);
+ return FAILURE;
+   }
+}
+  else if (e-expr_type != EXPR_VARIABLE)
 {
   if (context)
gfc_error (Non-variable expression in variable definition context
(%s)

[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer

[hjl.tools at gmail dot com]

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

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-10/msg01724.htm
   ||l
   Last reconfirmed||2010.10.20 18:03:32
 CC||hjl.tools at gmail dot com
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 18:03:32 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01724.html

[Bug fortran/40054] [F08] Pointer functions as lvalue

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-20 
18:05:23 UTC ---
Another example (from PR 46100):

two() = 7
contains
  function two ()
integer, pointer  :: two
allocate(two)
  end function two
end



Fails with:

  function two ()
  1
two() = 7
   2
Error: Procedure 'two' at (1) is already defined at (2)

  function two ()
  1
Error: INTERNAL-PROC procedure at (1) is already declared as STATEMENT-PROC
procedure

[Bug c++/46103] New: [c++0x] moving from std::array copies the elements

[marc.glisse at normalesup dot org]

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

   Summary: [c++0x] moving from std::array copies the elements
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


Hello,

this is probably another not implemented yet (although the status page seems
to say that this is done), but I noticed that moving from:
struct A { Type t; };
properly moves t while moving from:
struct B { Type t[1]; };
copies t[0] (this is the case for std::array).

Re: [Bug fortran/40054] [F08] Pointer functions as lvalue

[Mikael Morin]

 two() = 7
I don't see how it is possible to distinguish between a statement function and 
an assignment here.

[Bug debug/46095] [4.6 Regression] ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:2341 with -fstack-protector

[hjl.tools at gmail dot com]

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

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.20 19:09:13
 CC||hjl.tools at gmail dot com,
   ||rth at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 19:09:13 
UTC ---
It is caused by revision 164628:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00926.html

[Bug tree-optimization/46099] [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g

[hjl.tools at gmail dot com]

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

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.20 20:37:15
 CC||hjl.tools at gmail dot com,
   ||jakub at redhat dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 20:37:15 
UTC ---
It is caused by revision 157402:

http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00239.html

[Bug c++/46103] [c++0x] moving from std::array copies the elements

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-20 
21:10:27 UTC ---
so this would demonstrate the problem?

struct MoveOnly {
  MoveOnly(const MoveOnly) = delete;
  MoveOnly(MoveOnly) { }
  MoveOnly() = default;
};

struct A {
  MoveOnly mo[1];
};

int main() {
  A a;
  A aa = static_castA(a);
}

(I haven't checked whether this is valid, or is meant to be implemented yet in
g++)

[Bug c/46104] New: Linker error cannot find -liberty

[enrico.miglino at ovi dot com]

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

   Summary: Linker error cannot find -liberty
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: enrico.migl...@ovi.com
CC: dougmenc...@gmail.com
  Host: Ubuntu 10.04 LT
Target: ARM LPC32xx


This error was received trying to compile sourced for the ARM EABI firmware
from Embedded Artists using the gnu toolchain of CodeSourcery G++ Lite for ARM
EABI.

The toolchain compile correctly the sources, generate libraries and create
object files, but at link time linker reports the following error:

/home/tech/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/bin/ld:
cannot find -liberty

The specific linker command from the toolchain commands sequence is the
following:

arm-none-eabi-gcc timer_example.o   ../common/crt0_gnu.o  -static
-Wl,--start-group
/home/tech/CodeSourcery/software/csps/lpc32xx/lib/liblpc32xxgnu.a
/home/tech/CodeSourcery/software/csps/lpc32xx/bsps/ea3250/lib/libea3250gnu.a
/home/tech/CodeSourcery/software/lpc/lib/liblpcarm926ej-sgnu.a -lgcc -lc -lg
-lm -liberty -lstdc++ -lsupc++  -Wl,--end-group  -Xlinker -Map -Xlinker \
timer.map -Xlinker -T   ../linker/ldscript_ram_gnu.ld   \
-o timer.elf

After investigations and tests, the problem concerns libiberty library, that is
installed in the toolchain of CodeSourcery only as static library and not
shared.

Trying to find the library in the host, the result is the following:

$ find / -name *libiberty* -print

/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot/lib/libiberty.a
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot/vfp/lib/libiberty.a
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/lib/libiberty.a
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/arm-none-linux-gnueabi/lib/vfp/libiberty.a
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/libiberty.a

[Bug c++/46105] New: Ordering failure among partial specializations with non-deduced context

[potswa at mac dot com]

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

   Summary: Ordering failure among partial specializations with
non-deduced context
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pot...@mac.com


See attachment.

The second arguments of the two partial specializations evaluate to void. If
void is substituted manually, the code works fine. (But the desired SFINAE side
effect is removed.)

As neither such argument contains a parameter in a deduced context, they should
not participate in deduction. Once the partial specialization has been
determined to match, the parameters should be substituted and evaluated to
simply void.

[Bug c++/46105] Ordering failure among partial specializations with non-deduced context

[potswa at mac dot com]

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

--- Comment #1 from David Krauss potswa at mac dot com 2010-10-20 21:15:27 
UTC ---
Created attachment 22098
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22098
small example

[Bug tree-optimization/46066] [4.6 Regression] ICE: in create_parallel_loop, at tree-parloops.c:1455 with -ftree-parallelize-loops -g

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-20 
21:15:52 UTC ---
Author: jakub
Date: Wed Oct 20 21:15:49 2010
New Revision: 165739

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165739
Log:
PR tree-optimization/46066
* tree-parloops.c (create_parallel_loop): Use gsi_last_nondebug_bb
instead of gsi_last_bb.

* gcc.dg/autopar/pr46066.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr46066.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c