[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.

[kkojima at gcc dot gnu dot org]

--- Comment #33 from kkojima at gcc dot gnu dot org  2010-02-05 07:42 
---
Your fix of the middle end looks plausible but I think the target
shouldn't generate a CP at the eh landing pad anyway.  I'll commit
the hunk below anyway after your patch for pic problem is installed.

@@ -4654,6 +4654,13 @@ find_barrier (int num_mova, rtx mova, rt
   if (last_got)
from = PREV_INSN (last_got);

+  /* Don't insert the constant pool table at the position which
+may be the landing pad.  */
+  if (flag_exceptions
+ && CALL_P (from)
+ && find_reg_note (from, REG_EH_REGION, NULL_RTX))
+   from = PREV_INSN (from);
+
   /* Walk back to be just before any jump or label.
 Putting it before a label reduces the number of times the branch
 around the constant pool table will be hit.  Putting it before


-- 


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

[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.

[chrbr at gcc dot gnu dot org]

--- Comment #32 from chrbr at gcc dot gnu dot org  2010-02-05 07:05 ---
> Looks smart and clean!  One minor nit, I guess that the occurence of
> gbr and GBR in ChangeLog and comments should be replaced with GOT to
> avoid confusion with GBR register of SH CPU.

Thanks for catching up this error in the comment. I meant GP of course, which
is even more preferable that GOT (which is what we load, not what we compute).

(In reply to comment #31)
> When you propose it to the list, could you please separate the third
> hunk which is for the original PR42841 as an independant patch.  Also
> don't forget to update the copyright years in the first one.
> 

OK, that was also my intention to submit the 3rd hunk (the one that fixes the
jump to the landing pad around the constant table right ?) as a separate patch
as it will require the approval of a middle end maintainer. 
If it cannot go in the trunk before the 4.5 freeze I can propose you to commit
your workaround (comment #23) so not to block the regression. Then we can
revert when the proper patch is discussed/accepted. (I'm a little bit late for
that sorry).


-- 


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

[Bug fortran/42958] Weird temporary array allocation

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2010-02-05 05:36 ---
(In reply to comment #1)

> Why there is a negative check? Well, I do not know. I also can speculate about
> a poor man's overflow check, which sometimes indeed works, but often fails.

I suspect that you are being generous and that this is rather a sin of omission
rather than commission.


> Paul, what do you think?

I think that your arguments are correct.

> 
> (PS: POSIX Allows "ptr = malloc(0); free(ptr)", where "malloc(0)" returns
> either NULL or a unique pointer.)

Indeed.

Paul


-- 


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

[Bug fortran/42309] Problem with a pointer array passed to a subroutine

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2010-02-05 05:28 ---
Subject: Bug 42309

Author: pault
Date: Fri Feb  5 05:28:37 2010
New Revision: 156512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156512
Log:
2010-02-05  Paul Thomas  

PR fortran/42309
* trans-expr.c (gfc_conv_subref_array_arg): Add new argument
'formal_ptr'. If this is true, give returned descriptor unity
lbounds, in all dimensions, and the appropriate offset.
(gfc_conv_procedure_call); If formal is a pointer, set the last
argument of gfc_conv_subref_array_arg to true.
* trans.h : Add last argument for gfc_conv_subref_array_arg.
* trans-io.c (set_internal_unit, gfc_trans_transfer): Set the
new arg of gfc_conv_subref_array_arg to false.
* trans-stmt.c (forall_make_variable_temp): The same.

2010-02-05  Paul Thomas  

PR fortran/42309
* gfortran.dg/subref_array_pointer_4.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/subref_array_pointer_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-02-05 05:00 
---
Subject: Bug 42901

Author: jvdelisle
Date: Fri Feb  5 05:00:15 2010
New Revision: 156510

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156510
Log:
2010-02-04  Jerry DeLisle  

PR libfortran/42901
* gfortran.dg/namelist_60.f90: New test.
* gfortran.dg/namelist_59.f90: New test.
* gcc/testsuite/gfortran.dg/namelist_47.f90: Update test.
* gcc/testsuite/gfortran.dg/namelist_40.f90: Update test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_59.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_60.f90
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_40.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_47.f90


-- 


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

[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2010-02-05 04:58 
---
Subject: Bug 42901

Author: jvdelisle
Date: Fri Feb  5 04:58:30 2010
New Revision: 156509

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156509
Log:
2010-02-04  Jerry DeLisle  

PR libfortran/42901
* io/list_read.c (nml_get_obj_data): Add new qualifier flag, clean up
code, and adjust logic to set namelist info pointer correctly for array
qualifiers of derived type components.

Modified:
branches/gcc-4_3-branch/libgfortran/ChangeLog
branches/gcc-4_3-branch/libgfortran/io/list_read.c


-- 


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

[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2010-02-05 04:51 
---
Subject: Bug 42901

Author: jvdelisle
Date: Fri Feb  5 04:50:53 2010
New Revision: 156508

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156508
Log:
2010-02-04  Jerry DeLisle  

PR libfortran/42901
*gfortran.dg/namelist_60.f90: New test.
*gfortran.dg/namelist_59.f90: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_59.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/namelist_60.f90
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/42901] [4.3/4.4/4.5 Regression] reading array of structures from namelist fails

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-02-05 04:47 
---
Subject: Bug 42901

Author: jvdelisle
Date: Fri Feb  5 04:47:12 2010
New Revision: 156507

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156507
Log:
2010-02-04  Jerry DeLisle  

PR libfortran/42901
* io/list_read.c (nml_get_obj_data): Add new qualifier flag, clean up
code, and adjust logic to set namelist info pointer correctly for array
qualifiers of derived type components.

Modified:
branches/gcc-4_4-branch/libgfortran/ChangeLog
branches/gcc-4_4-branch/libgfortran/io/list_read.c


-- 


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

[Bug fortran/22210] gfc_conv_array_initializer weirdness

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2010-02-05 03:25 
---
1 year has gone by again.


-- 


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

[Bug libfortran/21185] Improve testsuite results on newlib targets

[jvdelisle at gcc dot gnu dot org]

--- Comment #26 from jvdelisle at gcc dot gnu dot org  2010-02-05 03:13 
---
I think this is fixed and looks like it has dried up.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build

[jvdelisle at gcc dot gnu dot org]

--- Comment #17 from jvdelisle at gcc dot gnu dot org  2010-02-05 03:04 
---
Closing. Not a gcc/gfortran bug.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug java/42967] New: gcj: error trying to exec 'ecj1': execvp: No such file or directory

[dan_1997 at mail dot ru]

+++ This bug was initially created as a clone of Bug #35923 +++

I get the following error on a clean 4.3.0 build when trying (eg) "gcj
foo.java":

gcj: error trying to exec 'ecj1': execvp: No such file or directory

I also have the same bug.


-- 
   Summary: gcj: error trying to exec 'ecj1': execvp: No such file
or directory
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dan_1997 at mail dot ru
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug c++/41090] [4.3/4.4/4.5 Regression] Using static label reference in c++ class constructor produces wrong code

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2010-02-05 01:41 ---
Ah, I guess we don't support the same body alias optimization on darwin, so the
testcase should be restricted to targets that do support it.


-- 


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

[Bug other/42965] no "warnings being treated as errors" for individual -Werror=x options

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2010-02-05 01:23 ---
Adding Simon Baldwin to CC list (although it seems he doesn't read bugzilla
mail).


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||simonb at gcc dot gnu dot
   ||org


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

[Bug other/42966] add some indication that a warning has been converted to an error

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2010-02-05 01:20 ---
@Simon,

I think this solution would be accepted more readily by everybody, since anyway
we already have the [-W*] markers for most warnings except default ones. What
do you think?

I specially like showing the flag for disabling but that would be perhaps more
transgressive.


-- 


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

[Bug other/42966] New: add some indication that a warning has been converted to an error

[manu at gcc dot gnu dot org]

See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01197.html

Currently, warnings enabled by flags are indicated by the flag when using
-fdiagnostics-show-option. However, warnings enabled by default do not show
anything. Two possible fixes:

1) Give the flag that enables the warning (like now). For default warnings, say
"[default warning]". 

2) Give the flag that disables the warning. For default warnings, say "[-w]".

Also, it would be good to move this info after "warning:" (or "error:" if
-Werror=) to make it easier to see/parse.

Of course, anything that does not have a [something] is a hard error that
cannot be disabled.


-- 
   Summary: add some indication that a warning has been converted to
an error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org


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

[Bug other/42965] New: no "warnings being treated as errors" for individual -Werror=x options

[manu at gcc dot gnu dot org]

We do not currently give the message: "warnings being treated as errors" for
individual -Werror=x options.

See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01197.html

Also, it would be good to print the message near the end of the compilation
rather than at the start.


-- 
   Summary: no "warnings being treated as errors" for individual -
Werror=x options
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org


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

[Bug target/42964] New: gcc.c-torture/compile/20001226-1.c takes too long to compile

[raj dot khem at gmail dot com]

This testcase takes too long to compile at -O3. It freezes my box. I really did
not get it to completion but I will try. Same compiles fine when gcc is
configured for native build. So it seems like mips specific issue.

here is how gcc is configured

Configured with: /sources/gcc-trunk/configure --target=mips64-none-elf
--prefix=/scratch/baremetal/mips64-none-elf/tools --enable-multilib
--disable-werror --enable-languages=c,c++ --with-newlib
Thread model: single
gcc version 4.5.0 20100204 (experimental) (GCC) 


I tried same test with gcc 4.1(mips64-elf) and it took about 48 seconds and
about 11s for native compile.


-- 
   Summary: gcc.c-torture/compile/20001226-1.c takes too long to
compile
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: mips64-none-elf


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

[Bug c++/41090] [4.3/4.4/4.5 Regression] Using static label reference in c++ class constructor produces wrong code

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2010-02-04 
23:35 ---
The new g++.dg/ext/label13.C testcase fails on *-apple-darwin*. On
x86_64-apple-darwin10, the error message is...

/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/gcc/testsuite/g++.dg/ext/label13.C
 -nostdinc++
-I/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/libstdc++-v3/include/x86_64-apple-darwin10.3.0
-I/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/libstdc++-v3/testsuite/util
-fmessage-length=0 
-L/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/./libstdc++-v3/src/.libs

-B/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/./libstdc++-v3/src/.libs

-L/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/./libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/x86_64-apple-darwin10.3.0/./libiberty
 -multiply_defined suppress -lm   -o ./label13.exe 
/sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/gcc/testsuite/g++.dg/ext/label13.C:
In constructor ‘C::C()’:
/sw/src/fink.build/gcc45-4.4.999-20100203/gcc-4.5-20100203/gcc/testsuite/g++.dg/ext/label13.C:8:3:
sorry, unimplemented: function ‘C::C()’ can never be copied because it saves
address of local label in a static variable


-- 


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

[Bug tree-optimization/42963] New: [4,5 Regression] Redundant switch labels not cleaned up anymore

[steven at gcc dot gnu dot org]

Test case is taken from bug 18046:
-
extern void foo (void);
extern int i;
void
bar (void)
{
  switch (i)
{
case 0:
  foo ();
  break;
case 1:
  break;
}


  switch (i)
{
case 0:
  foo ();
  break;
case 1:
  break;
}
}
-


the .012t.cfg dump with trunk (r156492) today looks like this:

bar ()
{
  int i.0;

:
  i.0 = i;
  switch (i.0) , case 0: , case 1: >

:
  foo ();

:
  i.0 = i;
  switch (i.0) , case 0: , case 1: >

:
  foo ();

:
  return;

}



The dump with "gcc (Debian 4.3.4-5) 4.3.4" looks better:

bar ()
{
  int i.0;

  # BLOCK 2
  # PRED: ENTRY (fallthru)
  i.0 = i;
  switch (i.0)
{
  case 0: goto ;
  default : goto ;
}
  # SUCC: 3 4

  # BLOCK 3
  # PRED: 2
:;
  foo ();
  # SUCC: 4 (fallthru)

  # BLOCK 4
  # PRED: 2 3 (fallthru)
:;
  i.0 = i;
  switch (i.0)
{
  case 0: goto ;
  default : goto ;
}
  # SUCC: 5 6

  # BLOCK 5
  # PRED: 4
:;
  foo ();
  # SUCC: 6 (fallthru)

  # BLOCK 6
  # PRED: 4 5 (fallthru)
:;
  return;
  # SUCC: EXIT

}


Note how GCC 4.5 fails to clean up  the "case 1" label.  The label is retained
all the way through the .137t.nrv dump (at -O2) and only disappears in the
.139t.optimized dump.

This confuses things in a couple of places and costs memory for no reason.


-- 
   Summary: [4,5 Regression] Redundant switch labels not cleaned up
anymore
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org


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

[Bug tree-optimization/18046] Missed jump threading optimization

[steven at gcc dot gnu dot org]

--- Comment #14 from steven at gcc dot gnu dot org  2010-02-04 22:52 ---
Still not fixed. Still the major source of RTL jump threads.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-09-21 13:59:00 |2010-02-04 22:52:40
   date||


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

[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.

[kkojima at gcc dot gnu dot org]

--- Comment #31 from kkojima at gcc dot gnu dot org  2010-02-04 22:42 
---
Looks smart and clean!  One minor nit, I guess that the occurence of
gbr and GBR in ChangeLog and comments should be replaced with GOT to
avoid confusion with GBR register of SH CPU.
When you propose it to the list, could you please separate the third
hunk which is for the original PR42841 as an independant patch.  Also
don't forget to update the copyright years in the first one.


-- 


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

[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none

[wilson at tuliptree dot org]

--- Comment #10 from wilson at tuliptree dot org  2010-02-04 22:16 ---
Subject: Re:  Optimization flag -O1 -fschedule-insns2
 cause red zone to be used when there is none

On Thu, 2010-02-04 at 16:36 +, pinskia at gmail dot com wrote:
> Well powerpc64 it is valid to move across the stack pointer if the  
> stack is less than a specific size so this can cause regressions  
> there. And will also cause a performance regressions on x86_64 also  
> for the same reason.

We could perhaps make it a target hook.  For powerpc, the hook returns
true if this is the sysv ABI, and returns false if this is the AIX ABI.
That might also be useful for ARM, if you need it to be true for thumb
and false for the arm port.

I'm not sure at the moment if this is necessary though.  The testcase in
this bug report is a little different than the one I have.  First thing
I notice is that the powerpc port is not emitting the stack_tie insn
here because there is no frame pointer.  But I think it is always
necessary for the sysv ABI.  If I modify rs6000_emit_stack_reset to
check DEFAULT_ABI == ABI_V4 in the rs6000_emit_stack_tie check, then I
get correct code for this testcase.  I still need to modify the
stack_tie pattern to use (MEM:BLK (scratch)) to get correct code for my
testcase.  These are two fairly simple powerpc backend changes though.

I'll have to look at the arm/thumb port next to see what is going on
there.

Jim


-- 


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

[Bug c++/42915] [4.5 Regression] ICE: same canonical type node for different types in recent builds

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2010-02-04 22:06 ---
A candidate patch was posted to
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00204.html


-- 


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

[Bug rtl-optimization/42962] New: Place constant strings in local constant pool

[jingyu at google dot com]

GCC is inefficient when loading constant strings.

The sample code is:
  printf( "\nMCF SPEC CPU2006 version 1.10\n" );

GCC places the constant string a a read-only data section. If compiled with
-fpic, gcc places the string's offset(relative to GOT entry) in GOT table.
To address the string, gcc needs to

load the GOT relative base address
Compute GOT absolute base address
load the string's GOT offset
compute the string's absolute address

gcc emits 4 instructions to get the address of the first string, and 2
instructions for following strings (because the GOT absolute address is the
same for them).

ARM RVCT is more efficient. RVCT places constant string right after the
function in the code section. It only uses one instruction ADR to get the
string address.

98  a03c  ADR  r0,|L1.396|
9a  f7fe  BL   printf
...
 |L1.396|



Placing constant strings in global data section enables sharing the strings.
But usually, there is little sharing for long strings. For short strings, the
overhead of loading the short strings through GOT table almost overcome the
savings of sharing the short strings.

Shall we change the placement of constant strings? We can use an option to
choose where to put constant strings. For ARM with -fpic, I think the benefit
of placing constant strings in local constant pool is bigger than the cost.

Any suggestion?


-- 
   Summary: Place constant strings in local constant pool
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
 GCC build triplet: i686-linux-gnu, x86_64-pc-linux-gnu
  GCC host triplet: i686-linux-gnu, x86_64-pc-linux-gnu
GCC target triplet: arm-unknown-eabi


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

[Bug middle-end/42961] New: [4.5 regression] IRA register preferencing bug

[hubicka at gcc dot gnu dot org]

For following testcase:
int e,f;
float
main(float d,float c)
{
   float a;
   float e;
   if (e)
 a=d, e=c;
   else
 a=c, c=e;
   if (f)
 e=a;
   return e;
}
(it looks artifical, but all the moves are there just to make "a" to be only
source or destination of reg-reg move that is not that uncommon in real world
code)
we generate completely bogus:
main:
.LFB0:
.cfi_startproc
xorps   %xmm2, %xmm2
movss   %xmm1, -4(%rsp)
movl-4(%rsp), %eax
ucomiss %xmm2, %xmm2
jp  .L7
je  .L3
.L7:
movss   %xmm0, -4(%rsp)
movl-4(%rsp), %eax
movaps  %xmm1, %xmm2
.L3:
movlf(%rip), %edx
testl   %edx, %edx
je  .L4
movl%eax, -4(%rsp)
movss   -4(%rsp), %xmm2
.L4:
movaps  %xmm2, %xmm0
ret

instead of
main:
.LFB2:
movaps  %xmm0, %xmm3
xorps   %xmm0, %xmm0
movaps  %xmm1, %xmm2
ucomiss %xmm0, %xmm0
jp  .L2
je  .L3
.L2:
movaps  %xmm3, %xmm2
movaps  %xmm1, %xmm0
.L3:
movlf(%rip), %eax
testl   %eax, %eax
je  .L4
movaps  %xmm2, %xmm0
.L4:
rep
ret
.LFE2:

generated by GCC 4.3.2.

The problem is that IRA concludes wrong register preferencing:
a3 (r62,l0) best SSE_REGS, cover SSE_REGS
a2 (r61,l0) best SSE_FIRST_REG, cover SSE_REGS
a1 (r59,l0) best GENERAL_REGS, cover GENERAL_REGS
a0 (r58,l0) best SSE_FIRST_REG, cover SSE_REGS

this is because of movdf pattern having alternative for general regs.
This alternative is however useful primarily when the value is temporary for
mem-mem moves, and IRA should be able to work this out.


-- 
   Summary: [4.5 regression] IRA register preferencing bug
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug c/42960] segfault internal compiler error when trying to compile latest linux kernel

[rvoicilas at gmail dot com]

--- Comment #2 from rvoicilas at gmail dot com  2010-02-04 21:24 ---
(In reply to comment #1)
> > See  for instructions.
> > The bug is not reproducible, so it is likely a hardware or OS problem.
> 
> First it says to see redhat's bugzilla file this bug report.  Second since 
> this
> version of gcc has been modified to try compile it again and it cannot
> reproduce it on the second run through, it says it might be a hardware or OS
> issue so you might want to try testing your hardware first.  Try memtest to 
> see
> if your memory is bad.
> 

I already did the memory test and my memories are just fine.
And I have filled a fedora bug as well, but I hoped that I get more ideas here.


-- 


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

[Bug c/42960] segfault internal compiler error when trying to compile latest linux kernel

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-04 21:16 ---
> See  for instructions.
> The bug is not reproducible, so it is likely a hardware or OS problem.

First it says to see redhat's bugzilla file this bug report.  Second since this
version of gcc has been modified to try compile it again and it cannot
reproduce it on the second run through, it says it might be a hardware or OS
issue so you might want to try testing your hardware first.  Try memtest to see
if your memory is bad.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/42960] New: segfault internal compiler error when trying to compile latest linux kernel

[rvoicilas at gmail dot com]

I am having a hard time compiling the latest stable linux kernel on Fedora 12,
gcc 4.4.2

I get random `internal compiler error` like the one bellow (in different
sections of the kernel code):

/home/raduv/work/linux-2.6.32.7/drivers/hid/hid-apple.c:274: internal compiler
error: in set_lattice_value, at tree-ssa-ccp.c:471
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
make[3]: *** [drivers/hid/hid-apple.o] Error 1
make[2]: *** [drivers/hid] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2


GCC Version:
$ gcc -v
Using built-in specs.
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch=i686
--build=i686-redhat-linux
Thread model: posix
gcc version 4.4.2 20091222 (Red Hat 4.4.2-20) (GCC)


-- 
   Summary: segfault internal compiler error when trying to compile
latest linux kernel
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rvoicilas at gmail dot com


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

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

[debian-gcc at lists dot debian dot org]

--- Comment #20 from debian-gcc at lists dot debian dot org  2010-02-04 
21:02 ---
Created an attachment (id=19806)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19806&action=view)
fix \n quoting

fixes the manual page, didn't check the html output


-- 


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

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

[debian-gcc at lists dot debian dot org]

--- Comment #19 from debian-gcc at lists dot debian dot org  2010-02-04 
21:00 ---
std::basic_fstream.3cxx.gz 1213: warning: macro `)).' not defined
std::basic_ifstream.3cxx.gz 1037: warning: macro `)).' not defined
std::basic_iostream.3cxx.gz 1172: warning: macro `)).' not defined
std::basic_istream.3cxx.gz 1002: warning: macro `)).' not defined
std::basic_istringstream.3cxx.gz 1025: warning: macro `)).' not defined
std::basic_stringstream.3cxx.gz 1202: warning: macro `)).' not defined
std::exponential_distribution.3cxx.gz 66: warning: numeric expression expected
(got `m')
std::gamma_distribution.3cxx.gz 79: normal or special character expected (got a
space)
std::linear_congruential_engine.3cxx.gz 82: warning: numeric expression
expected (got `f')
std::lognormal_distribution.3cxx.gz 79: warning: numeric expression expected
(got `r')
std::normal_distribution.3cxx.gz 79: warning: numeric expression expected (got
`g')
std::regex_constants.3cxx.gz 200: warning: macro `,' not defined
std::student_t_distribution.3cxx.gz 76: warning: numeric expression expected
(got `r')
std::weibull_distribution.3cxx.gz 69: normal or special character expected (got
a space)

The one class of quoting problems seems to be fixed. 

remaining:

include/std/istream:403: Returns @c getline(s,n,widen('\n'))
include/std/istream:363: Returns @c getline(s,n,widen('\n'))
include/std/istream:330: Returns @c get(s,n,widen('\n'))

which translates to:

.PP
Returns \fCget\fP(sb,widen('
.br
')). 
.PP

quoting the backslash, I get this output (man not complaining anymore)
   template __istream_type&
std::basic_istream< _CharT, _Traits >::get
   (char_type * __s, streamsize __n) [inline, inherited]
   Simple multiple-character extraction. Parameters:
   s Pointer to an array.
   n Maximum number of characters to store in s.

   Returns:
   *this

   Returns get(s,n,widen('\n')).

   Definition at line 333 of file istream.

the other errors in the *distribution man pages are from using latex macros.

  Matthias


-- 


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

[Bug debug/42959] New: g++ does not emit DW_AT_default_value

[tromey at gcc dot gnu dot org]

Currently, g++ does not emit the DW_AT_default_value attribute for
formal parameters that have default values.
I think it should; this is a prerequisite to letting gdb work with
default arguments.


-- 
   Summary: g++ does not emit DW_AT_default_value
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org


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

[Bug tree-optimization/41464] vector loads are unnecessarily split into high and low loads

[bredelin at ucla dot edu]

--- Comment #9 from bredelin at ucla dot edu  2010-02-04 20:29 ---
In reply to comment #8
> So in the end all this boils down to the Frontend / middle-end issue of
> weak handling of aligned types.

Would you mind giving a general idea of what the outlook for improvement on
this front is?

Also, this is interesting:
http://eigen.tuxfamily.org/index.php?title=Benchmark


-- 


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

[Bug fortran/42958] Weird temporary array allocation

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-02-04 19:32 ---
> so, we check if the array-size is empty, ubound - lbound < 0.  In that
> case we set size to zero.  Otherwise we compute it
> as (ubound - lbound + 1) *8.
> Then we check whether size is negative and error out.
> Then we actually allocate max(1,size).

The reason for the setting it to zero is that Fortran allows one to allocate a
zero-sized array:  ALLOCATE ( Array(0:-2) )

The reason for  MAX(1, size)  is to make  ALLOCATE(A(1:0)); if(ALLOCATED(A))
work. (This was added later than "size < 0 ? 0 : size".)

Why there is a negative check? Well, I do not know. I also can speculate about
a poor man's overflow check, which sometimes indeed works, but often fails.

 * * *

> Why not simply do
>   size = (ubound - lbound + 1) * 8;
>   malloc (size);

I think that would be the future: With the array descriptor (dope vector)
reform, we will have an "allocated" field and thus one can do:

   descriptor.allocated = true
   descriptor.data = malloc (max (0,size))

Where "if(allocated(A))" translates into "if(A.allocated)".

Actually, maybe one should better use:
   size = (ubound - lbound + 1)
   if (size > 0)
 {
   descriptor.data = malloc(size)
   if (descriptor.data == NULL)
 error ("allocate failed");
 }
   descriptor.allocated = true

The "allocated" member of the descriptor is also needed in order to make the
following work properly:
   integer, target :: int
   integer, pointer :: ptr
   ptr => int
   deallocate(ptr, stat=i) ! shall return "i != 0" but not crash

Thus, from my side: The negative check should be removed and the simplified
version should be applied after the descriptor update. Before the descriptor
update (planned for 4.6, breaks ABI) one can use:
   size = (ubound - lbound + 1) * 8;
   malloc (max(1,size));


Paul, what do you think?


(PS: POSIX Allows "ptr = malloc(0); free(ptr)", where "malloc(0)" returns
either NULL or a unique pointer.)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


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

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

[debian-gcc at lists dot debian dot org]

--- Comment #18 from debian-gcc at lists dot debian dot org  2010-02-04 
18:39 ---
this is a check run by the lintian tool to check .deb packages after they are
built. for this check, lintian calls 'man --warnings -E UTF-8 -l ' for
every generated manpage. Afaik Debian/Ubuntu do use another man implementation
than Fedora, so I don't know if this option is available there as well.


-- 


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

[Bug libstdc++/22634] [DR 539] partial_sum is too constrained

[paolo dot carlini at oracle dot com]

--- Comment #22 from paolo dot carlini at oracle dot com  2010-02-04 18:36 
---
*** Bug 42943 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||potswa at mac dot com


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

[Bug libstdc++/42943] std::partial_sum performs improper casts

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-02-04 18:36 
---
... to close as duplicate.

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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/42943] std::partial_sum performs improper casts

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-02-04 18:36 
---
Reopen...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

[bkoz at gcc dot gnu dot org]

-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2010-01-07 18:40:02 |2010-02-04 18:28:04
   date||


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

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

[bkoz at gcc dot gnu dot org]

--- Comment #17 from bkoz at gcc dot gnu dot org  2010-02-04 18:27 ---

Hey. Can you re-check trunk now? I should have most of the quoting issues
fixed.

I've uploaded man pages with the new markup here:
ftp://gcc.gnu.org/pub/libstdc++/doxygen/libstdc++-man.20100204.tar.bz2

Can you check these (or equivalent from trunk) please?


-- 


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

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

[bkoz at gcc dot gnu dot org]

--- Comment #16 from bkoz at gcc dot gnu dot org  2010-02-04 18:20 ---
Subject: Bug 42460

Author: bkoz
Date: Thu Feb  4 18:20:34 2010
New Revision: 156502

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156502
Log:
2010-02-04  Benjamin Kosnik  

PR libstdc++/42460
* doc/doxygen/user.cfg.in: Update file list.
* include/debug/safe_sequence.h: Doxygen markup fixes for '' and "".
* include/debug/safe_base.h: Same.
* include/debug/macros.h: Same.
* include/tr1_impl/regex: Same.
* include/std/iostream: Same.
* include/std/streambuf: Same.
* include/std/bitset: Same.
* include/std/iosfwd: Same.
* include/std/limits: Same.
* include/std/fstream: Same.
* include/std/istream: Same.
* include/std/ostream: Same.
* include/std/sstream: Same.
* include/parallel/multiway_merge.h: Same.
* include/parallel/for_each.h: Same.
* include/parallel/workstealing.h: Same.
* include/parallel/omp_loop_static.h: Same.
* include/parallel/omp_loop.h: Same.
* include/c_std/csignal: Same.
* include/c_std/cstdlib: Same.
* include/c_std/cstdio: Same.
* include/c_std/cstdarg: Same.
* include/c_std/cctype: Same.
* include/c_std/cerrno: Same.
* include/c_std/cmath: Same.
* include/c_std/ciso646: Same.
* include/c_std/ctime: Same.
* include/c_std/clocale: Same.
* include/c_std/climits: Same.
* include/c_std/cassert: Same.
* include/c_std/csetjmp: Same.
* include/c_std/cwchar: Same.
* include/c_std/cfloat: Same.
* include/c_std/cstring: Same.
* include/c_std/cstddef: Same.
* include/c_std/cwctype: Same.
* include/profile/iterator_tracker.h: Same.
* include/profile/impl/profiler_trace.h: Same.
* include/ext/vstring.h: Same.
* include/ext/algorithm: Same.
* include/ext/pb_ds/detail/pat_trie_/pat_trie_.h.pp: Same.
* include/ext/pb_ds/detail/bin_search_tree_/bin_search_tree_.h.pp:
Same.
* include/ext/pb_ds/detail/type_utils.hpp: Same.
* include/ext/pb_ds/detail/splay_tree_/splay_tree_.hpp: Same
* include/ext/pb_ds/detail/rb_tree_map_/rb_tree_.hpp: Same.
* include/ext/rc_string_base.h: Same.
* include/ext/stdio_sync_filebuf.h: Same.
* include/ext/functional: Same.
* include/ext/mt_allocator.h: Same.
* include/bits/basic_ios.h: Same.
* include/bits/stl_map.h: Same.
* include/bits/stl_algobase.h: Same.
* include/bits/stl_queue.h: Same.
* include/bits/locale_classes.h: Same.
* include/bits/stl_set.h: Same.
* include/bits/locale_facets.h: Same.
* include/bits/stl_stack.h: Same.
* include/bits/stl_iterator_base_types.h: Same.
* include/bits/basic_string.h: Same.
* include/bits/stl_multimap.h: Same.
* include/bits/ios_base.h: Same.
* include/bits/stl_deque.h: Same.
* include/bits/stl_multiset.h: Same.
* include/bits/stl_iterator_base_funcs.h: Same.
* include/bits/char_traits.h: Same.
* include/bits/stl_algo.h: Same.
* include/bits/stl_iterator.h: Same.
* include/bits/stl_tempbuf.h: Same.
* include/bits/random.tcc: Same.
* include/bits/stl_function.h: Same.
* include/bits/cpp_type_traits.h: Same.
* include/bits/random.h: Same.
* include/bits/allocator.h: Same.
* include/bits/locale_facets_nonio.h: Same.
* include/c_global/csignal: Same.
* include/c_global/cstdlib: Same.
* include/c_global/cstdio: Same.
* include/c_global/cstdarg: Same.
* include/c_global/cctype: Same.
* include/c_global/cerrno: Same.
* include/c_global/cmath: Same.
* include/c_global/ciso646: Same.
* include/c_global/ctime: Same.
* include/c_global/clocale: Same.
* include/c_global/climits: Same.
* include/c_global/cassert: Same.
* include/c_global/csetjmp: Same.
* include/c_global/cwchar: Same.
* include/c_global/cfloat: Same.
* include/c_global/cstring: Same.
* include/c_global/cstddef: Same.
* include/c_global/cwctype: Same.
* include/tr1/hypergeometric.tcc: Same.
* include/tr1/random.tcc: Same.
* include/tr1/functional: Same.
* include/tr1/random.h: Same.
* include/backward/auto_ptr.h: Same.
* include/backward/binders.h: Same.
* testsuite/23_containers/deque/requirements/dr438/assign_neg.cc:
Adjust line numbers.
* testsuite/23_containers/deque/requirements/dr438/insert_neg.cc: Same.
*
testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc:
Same.
*
testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc:

[Bug libstdc++/41861] [C++0x] does not use monotonic_clock

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-02-04 18:02 
---
It seems to me that if DR887 is indeed resolved per the discussion in Santa
Cruz, thus the wait_for functions removed, the wait_until functions use
system_clock, then this issue could be immediately resolved. In other terms, I
would add [DR 887] to the Subject and suspend. Agreed?


-- 


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

[Bug driver/42955] undecorated cross-compiler gcc fails to find cc1

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-04 17:17 ---
How did you configure the cross compiler?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|regression  |driver


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

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

[davek at gcc dot gnu dot org]

--- Comment #19 from davek at gcc dot gnu dot org  2010-02-04 17:12 ---
Created an attachment (id=19805)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19805&action=view)
Further bugfix

fixed silly cut'n'pasto in the endianness layer which was truncating 4-byte
fields to 2 bytes.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #19797|0   |1
is obsolete||


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

[Bug fortran/42958] New: Weird temporary array allocation

[rguenth at gcc dot gnu dot org]

I see

D.1631 = izz.dim[0].lbound;
D.1632 = izz.dim[0].ubound;
D.1643 = D.1632 - D.1631;
D.1647 = D.1643 < 0;
D.1648 = D.1643 + 1;
D.1649 = D.1647 ? 0 : D.1648 * 8;
if (D.1649 < 0)
  {
_gfortran_runtime_error (&"Attempt to allocate
a negative amount of memory."[1]{lb: 1 sz: 1});
  }
D.1650 = (void * restrict) __builtin_malloc
(MAX_EXPR );
if (D.1650 == 0B)
  {
_gfortran_os_error (&"Memory allocation
failed"[1]{lb: 1 sz: 1});
  }
D.1651 = D.1650;
atmp.5.data = D.1651;

so, we check if the array-size is empty, ubound - lbound < 0.  In that
case we set size to zero.  Otherwise we compute it as (ubound - lbound + 1) *
8.
Then we check whether size is negative and error out.
Then we actually allocate max(1,size).

Why do we at all check for this "negative" amount allocation?  Are you
trying to detect overflow here?  (which won't work, you do the
computation with signed arithmetic so VRP will screw you anyway)

Why not simply do

  size = (ubound - lbound + 1) * 8;
  malloc (size);

which surely fails very quickly on you for negative size and the allocation
fails.

?

Surely for compiler-generated temporary allocations nothing more fancy
should be required (even the check of the allocation could be removed
when optimizing).


-- 
   Summary: Weird temporary array allocation
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none

[pinskia at gmail dot com]

--- Comment #9 from pinskia at gmail dot com  2010-02-04 16:36 ---
Subject: Re:  Optimization flag -O1 -fschedule-insns2 cause red zone to be used
when there is none



Sent from my iPhone

On Feb 4, 2010, at 2:48 AM, "rearnsha at gcc dot gnu dot org"
 wrote:

>
>
> --- Comment #8 from rearnsha at gcc dot gnu dot org  2010-02-04  
> 10:48 ---
> Created an attachment (id=19803)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19803&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19803&action=view)
> Possible patch
>
> I've been testing the attached patch on ARM (well, thumb) where  
> there's a
> similar issue.  It's perhaps a bit more aggressive than it needs to  
> be, but it
> should solve the problem generically rather than requiring each back- 
> end to
> implement hacks for what is really a MI issue.
>
> Could someone test this on PPC?

Well powerpc64 it is valid to move across the stack pointer if the  
stack is less than a specific size so this can cause regressions  
there. And will also cause a performance regressions on x86_64 also  
for the same reason.

>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
>


-- 


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

Re: [Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none

[Andrew Pinski]

Sent from my iPhone

On Feb 4, 2010, at 2:48 AM, "rearnsha at gcc dot gnu dot org" > wrote:





--- Comment #8 from rearnsha at gcc dot gnu dot org  2010-02-04  
10:48 ---

Created an attachment (id=19803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19803&action=view)
Possible patch

I've been testing the attached patch on ARM (well, thumb) where  
there's a
similar issue.  It's perhaps a bit more aggressive than it needs to  
be, but it
should solve the problem generically rather than requiring each back- 
end to

implement hacks for what is really a MI issue.

Could someone test this on PPC?


Well powerpc64 it is valid to move across the stack pointer if the  
stack is less than a specific size so this can cause regressions  
there. And will also cause a performance regressions on x86_64 also  
for the same reason.





--


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

[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-02-04 16:22 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.3.4 4.4.3
  Known to work||4.3.5 4.4.4 4.5.0
 Resolution||FIXED


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

[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-02-04 16:22 
---
Subject: Bug 42952

Author: rguenth
Date: Thu Feb  4 16:21:47 2010
New Revision: 156496

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156496
Log:
2010-02-04  Richard Guenther  

PR rtl-optimization/42952
* dse.c (const_or_frame_p): Remove MEM handling.

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

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr42952.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/dse.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-02-04 16:18 ---
Subject: Bug 42952

Author: rguenth
Date: Thu Feb  4 16:18:01 2010
New Revision: 156495

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156495
Log:
2010-02-04  Richard Guenther  

PR rtl-optimization/42952
* dse.c (const_or_frame_p): Remove MEM handling.

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

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr42952.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/dse.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-02-04 16:14 ---
Subject: Bug 42952

Author: rguenth
Date: Thu Feb  4 16:14:17 2010
New Revision: 156494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156494
Log:
2010-02-04  Richard Guenther  

PR rtl-optimization/42952
* dse.c (const_or_frame_p): Remove MEM handling.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr42952.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dse.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/42957] New: ARM: Segfault when invalid -mfpu argument is specified.

[rmansfield at qnx dot com]

r...@zoidberg:~/gnu/gcc/trunk/build/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi
--with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root
--enable-languages=c,c++ --disable-multilib --with-float=soft
--disable-sjlj-exceptions --enable-__cxa_atexit
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
Thread model: posix
gcc version 4.5.0 20100204 (experimental) [trunk revision 156492] (GCC) 

r...@zoidberg:~/gnu/gcc/trunk/build/gcc$ touch t.c
r...@zoidberg:~/gnu/gcc/trunk/build/gcc$ ./cc1plus -quiet t.c -mfpu=foo
t.c:1:0: error: invalid floating point option: -mfpu=foo
t.c:1:0: 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.
(gdb) bt
#0  0x08a06fd6 in arm_override_options () at ../../gcc/config/arm/arm.c:1645
#1  0x087b7a6c in process_options () at ../../gcc/toplev.c:1810
#2  0x087b8528 in do_compile () at ../../gcc/toplev.c:2389
#3  0x087b8624 in toplev_main (argc=4, argv=0xb364)
at ../../gcc/toplev.c:2447
#4  0x083cd2ab in main (argc=4, argv=0xb364) at ../../gcc/main.c:35

Patch:

2010-02-04  Ryan Mansfield  
PR target/x
* config/arm/arm.c (arm_override_options): Handle invalid arguments to
-mfpu.

Index: arm.c
===
--- arm.c   (revision 156492)
+++ arm.c   (working copy)
@@ -1292,6 +1292,7 @@
   unsigned i;
   enum processor_type target_arch_cpu = arm_none;
   enum processor_type selected_cpu = arm_none;
+  const char *default_fpu_name;

   /* Set up the flags based on the cpu/architecture selected by the user.  */
   for (i = ARRAY_SIZE (arm_select); i--;)
@@ -1618,29 +1619,31 @@
   target_fpe_name);
 }

-  if (target_fpu_name == NULL)
-{
 #ifdef FPUTYPE_DEFAULT
-  target_fpu_name = FPUTYPE_DEFAULT;
+  default_fpu_name = FPUTYPE_DEFAULT;
 #else
-  if (arm_arch_cirrus)
-   target_fpu_name = "maverick";
-  else
-   target_fpu_name = "fpe2";
+  if (arm_arch_cirrus)
+default_fpu_name = "maverick";
+  else
+default_fpu_name = "fpe2";
 #endif
-}

   arm_fpu_desc = NULL;
   for (i = 0; i < ARRAY_SIZE (all_fpus); i++)
 {
-  if (streq (all_fpus[i].name, target_fpu_name))
-   {
- arm_fpu_desc = &all_fpus[i];
- break;
-   }
-}
-  if (!arm_fpu_desc)
-error ("invalid floating point option: -mfpu=%s", target_fpu_name);
+  if (streq (all_fpus[i].name, default_fpu_name))
+   arm_fpu_desc = &all_fpus[i];
+  if (target_fpu_name) 
+{
+  if (streq (all_fpus[i].name, target_fpu_name))
+   {
+ arm_fpu_desc = &all_fpus[i];
+ break;
+   }
+  if (i == ARRAY_SIZE (all_fpus) - 1)
+   error ("invalid floating point option: -mfpu=%s", target_fpu_name);
+}
+} 

   switch (arm_fpu_desc->model)
 {


-- 
   Summary: ARM: Segfault when invalid -mfpu argument is specified.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnu


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

[Bug rtl-optimization/36712] Inefficient loop unrolling

[steven at gcc dot gnu dot org]

--- Comment #15 from steven at gcc dot gnu dot org  2010-02-04 16:06 ---
The patches for bug 31849 have been commited, it seems, and it doesn't help for
this case.


-- 


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

[Bug tree-optimization/31849] [4.3/4.4/4.5 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[steven at gcc dot gnu dot org]

--- Comment #50 from steven at gcc dot gnu dot org  2010-02-04 16:04 ---
Bernd Schmidt has worked on this, see here:

http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01788.html
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00268.html

It is hard to tell whether this has actually addresses the issues raised in
this bug report, because it is unclear what code the OP is expecting from the
compiler.


-- 


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-02-04 15:54 ---
typedef const int cint;
typedef struct {
} Bounds;
int ndim_, ncomp_, selectedcomp_, nregions_;
void *voidregion_;
typedef struct {
double diff, err, spread;
} Errors;
typedef const Errors cErrors;
void Split(int iregion, int depth, int xregion)
{
  typedef struct {
  double avg, err, spread, chisq;
  double xmin[ndim_], xmax[ndim_];
  } Result;
  typedef struct region {
  Result result[ncomp_];
  } Region;
  Errors errors[ncomp_];
  int comp, ireg, xreg;
  double tmp;
  for( ireg = iregion, xreg = xregion; ireg < nregions_; ireg = xreg++ )
{
  Result *result = ((Region *)voidregion_)[ireg].result;
  for( comp = 0; comp < ncomp_; ++comp )
{
  Result *r = &result[comp];
  cErrors *e = &errors[comp];
  double c = tmp*e->diff;
  if( r->err > 0 ) r->err = r->err*e->err + c;
}
}
}


-- 


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-02-04 15:44 ---
Confirmed at -O2.  Reducing.

../Cuba-1.6/src/divonne/Split.c: In function 'Split':
../Cuba-1.6/src/divonne/Split.c:275:13: error: expected an SSA_NAME object
../Cuba-1.6/src/divonne/Split.c:275:13: error: in statement
D.15203_353 = D.8489 /[ex] 8;
../Cuba-1.6/src/divonne/Split.c:275:13: internal compiler error: verify_ssa
failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Keywords||ice-on-valid-code
  Known to fail||4.4.3 4.5.0
  Known to work||4.3.5 4.4.2
Summary|internal compiler error:|[4.4/4.5 Regression]
   |Segmentation fault with -O1 |internal compiler error:
   ||Segmentation fault with -O1
   Target Milestone|--- |4.4.4


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

[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-02-04 15:38 ---
The easiest way would be to expose the middle-end ref-all pointer annotation
so you could do typedef struct T *my_ptr __attribute__((ref_all)).


-- 


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

[Bug rtl-optimization/42952] [4.3/4.4/4.5 Regression] possible integer wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-02-04 15:22 ---
Also fails with 4.3.4 and 4.4.2 if you do -fno-tree-ccp -fno-tree-fre
(I have a fix for the CCP optimization regression as well).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P2
Summary|[4.5 Regression] possible   |[4.3/4.4/4.5 Regression]
   |integer wrong code bug  |possible integer wrong code
   ||bug
   Target Milestone|4.5.0   |4.3.5


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

[Bug rtl-optimization/36712] Inefficient loop unrolling

[steven at gcc dot gnu dot org]

--- Comment #14 from steven at gcc dot gnu dot org  2010-02-04 15:19 ---
Part of the problem comes from the way IVOPTS optimizes the memory access:

;; Generating RTL for gimple basic block 3

;; D.1814_10 = MEM[base: D.1846_29];

(insn 52 51 0 tst.c:6 (set (reg:SI 172 [ D.1814 ])
(mem:SI (reg:SI 179 [ ivtmp.20 ]) [2 *D.1846_29 S4 A32])) -1 (nil))

;; ivtmp.20_24 = ivtmp.20_25 + 4;

(insn 53 52 0 tst.c:6 (set (reg:SI 179 [ ivtmp.20 ])
(plus:SI (reg:SI 179 [ ivtmp.20 ])
(const_int 4 [0x4]))) -1 (nil))

;; MEM[base: D.1847_30, offset: 4294967292] = D.1816_13;

(insn 54 53 55 tst.c:6 (set (reg:SI 189)
(mult:SI (reg:SI 172 [ D.1814 ])
(reg:SI 180 [ pretmp.11 ]))) -1 (nil))

(insn 55 54 0 tst.c:6 (set (mem:SI (plus:SI (reg:SI 179 [ ivtmp.20 ])
(const_int -4 [0xfffc])) [2 *D.1847_30 S4 A32])
(reg:SI 189)) -1 (nil))

;; if (ivtmp.20_24 != D.1849_32)

(insn 57 55 58 tst.c:4 (set (reg:CC 24 cc)
(compare:CC (reg:SI 179 [ ivtmp.20 ])
(reg:SI 183 [ D.1849 ]))) -1 (nil))

(jump_insn 58 57 0 tst.c:4 (set (pc)
(if_then_else (ne (reg:CC 24 cc)
(const_int 0 [0x0]))
(label_ref 56)
(pc))) -1 (expr_list:REG_BR_PROB (const_int 9844 [0x2674])
(nil)))


This yields the sequence:
   52 r172:SI=[r179:SI]
   53 r179:SI=r179:SI+0x4
   54 r189:SI=r172:SI*r180:SI
   55 [r179:SI-0x4]=r189:SI

and we never get rid of this again.  There is another bug related to this one:
bug 31849. The patch there probably needs dusting off, and then I'll see if it
improves things for this bug as well.


-- 


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

[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug

[matz at gcc dot gnu dot org]

--- Comment #6 from matz at gcc dot gnu dot org  2010-02-04 15:03 ---
Re comment #4, there are two possibilities to fix this:
1) as you say, don't regard MEM addresses (i.e. used in double indirection)
   as const_or_frame_p, because that would put different (but runtime-same)
   bases into different groups, or
2) fix this marvel in check_mem_read_rtx:
 if (group_id == store_info->group_id)
   ...
 /* else
The else case that is missing here is that the
bases are constant but different.  There is nothing
to do here because there is no overlap.  */

Clearly the comment is wrong, base addresses can be constant, different for
rtx_equal purposes, but still be the same at runtime.

When going the (2) way we would need to ask the oracle, which most of the time
would probably say "don't know" anyway, and be slow.  Hence not regarding
such base addresses as interesting for the global problem seems to be the
better fix.


-- 


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

[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug

[zadeck at naturalbridge dot com]

--- Comment #5 from zadeck at naturalbridge dot com  2010-02-04 14:57 
---
Richi, you are, of course, correct.   

kenny


-- 


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

[Bug rtl-optimization/36712] Inefficient loop unrolling

[steven at gcc dot gnu dot org]

--- Comment #13 from steven at gcc dot gnu dot org  2010-02-04 14:56 ---
With -fno-web, the patches from bug 42617 do not help and the output is the
same as that of comment #8 (second asm dump).


-- 


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

[Bug rtl-optimization/36712] Inefficient loop unrolling

[steven at gcc dot gnu dot org]

--- Comment #12 from steven at gcc dot gnu dot org  2010-02-04 14:54 ---
With the patches from bug 42617 applied, I get the following:

.file   "tst.c"
.text
.align  2
.global Unroll
.type   Unroll, %function
Unroll:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r0, r0, asl #16
stmfd   sp!, {r4, r5, r6, r7, r8}
mov r0, r0, asr #16
add r8, r1, #256
.L2:
ldr ip, [r1, #0]
mov r7, r1
mul r2, ip, r0
str r2, [r7], #4
ldr r3, [r1, #4]
ldr r5, [r7, #4]
mul r6, r3, r0
str r6, [r7, #0]
ldr r4, [r1, #12]
ldr ip, [r1, #16]
add r2, r1, #20
ldmia   r2, {r2, r3, r7}@ phole ldm
mul r6, r5, r0
mul r5, r4, r0
mul r4, ip, r0
mul ip, r2, r0
mul r2, r3, r0
mul r3, r7, r0
str r6, [r1, #8]
str r5, [r1, #12]
str r4, [r1, #16]
str ip, [r1, #20]
str r2, [r1, #24]
add r1, r1, #32
cmp r1, r8
str r3, [r1, #-4]
bne .L2
ldmfd   sp!, {r4, r5, r6, r7, r8}
bx  lr
.size   Unroll, .-Unroll
.ident  "GCC: (GNU) 4.5.0 20100204 (experimental) [trunk revision
156492]"

(flags: -std=c99 -mcpu=arm9 -O2 -funroll-loops)


This is good but not perfect.


-- 


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

[Bug c/34156] gcc ignores the __may_alias__ attribute on a struct typedef

[vda dot linux at googlemail dot com]

--- Comment #3 from vda dot linux at googlemail dot com  2010-02-04 14:33 
---
I was bitten by this whet I was trying to get rid of
"warning: dereferencing type-punned pointer will break strict-aliasing rules"
on this fairly normal networking-related code:

if (cmsgptr->cmsg_level == IPPROTO_IP && cmsgptr->cmsg_type == IP_PKTINFO) {
# define pktinfo(cmsgptr) ((struct in_pktinfo*)(CMSG_DATA(cmsgptr)))
to->sa_family = AF_INET;
memcpy(&to4->sin_addr, &pktinfo(cmsgptr)->ipi_addr, sizeof(to4->sin_addr));

I can't modify struct in_pktinfo declaration, it's in system header, so I
wanted to create a "aliasing" version of it, but this doesn't work for structs.


Distilled, the problem is that this works:

typedef int aliased_int __attribute__((__may_alias__));

but the same thing on structs does not, even if struct is hidden behind an
intermediate typedef:

struct s { int i; };
typedef struct s t;
typedef struct s aliased_s __attribute__((__may_alias__));
typedef t aliased_t __attribute__((__may_alias__));

last two typedefs both throw:

warning: ignoring attributes applied to 'struct s' after definition


-- 


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

[Bug c/42956] internal compiler error: Segmentation fault with -O1

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-04 14:30:49
   date||


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

[Bug c/42956] internal compiler error: Segmentation fault with -O1

[peb at mppmu dot mpg dot de]

--- Comment #2 from peb at mppmu dot mpg dot de  2010-02-04 14:27 ---
Created an attachment (id=19804)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19804&action=view)
preprocessed source


-- 


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

[Bug c/42956] internal compiler error: Segmentation fault with -O1

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-02-04 14:26 
---
Please follow the instructions here

  http://gcc.gnu.org/bugs/#report

provide a preprocessed file. Thanks.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/42956] New: internal compiler error: Segmentation fault with -O1

[peb at mppmu dot mpg dot de]

When building Cuba-1.6 (http://www.feynarts.de/cuba/Cuba-1.6.tar.gz)
via configure && make, there is an internal compiler error (segmentation fault)
in the compilation of Divonne.c.  This may or may not be related to #41155.

gcc says:
gcc-4.4.3 -O3 -fomit-frame-pointer -ffast-math -DHAVE_CONFIG_H
-I../Cuba-1.6/src/common -I. -I../Cuba-1.6 -I../Cuba-1.6/src/divonne -c -o
Divonne.o ../Cuba-1.6/src/divonne/Divonne.c
In file included from ../Cuba-1.6/src/divonne/common.c:19,
 from ../Cuba-1.6/src/divonne/Divonne.c:41:
../Cuba-1.6/src/divonne/Split.c: In function 'Split':
../Cuba-1.6/src/divonne/Split.c:275: internal compiler error: Segmentation
fault

This error occurs for gcc-4.4.3 with -O3, -O2, and -O1 but neither with -O0 nor
for gcc-4.4.2


-- 
   Summary: internal compiler error: Segmentation fault with -O1
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peb at mppmu dot mpg dot de
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu


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

[Bug fortran/42954] gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry)

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-02-04 14:06 ---
Daniel: Wouldn't it be enough to duplicate c-cppbuiltin.c's
builtin_define_with_value and builtin_define_with_int_value for fortran/cpp.c?
Regarding builtin_define_std: Couldn't one simply define __ and 
(after stripping leading _) ignoring the unmodified version?


-- 


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

[Bug regression/42955] New: undecorated cross-compiler gcc fails to find cc1

[ossman at cendio dot se]

I upgrade from gcc 4.1.2 to 4.4.3 and discovered that the gcc in
/usr/$(target_noncanonical)/bin no longer is functional. Using it results in:

gcc: error trying to exec 'cc1': execvp: No such file or directory

Digging around, it turns out that the internal paths are screwed up:

$ /usr/sparc-sun-solaris2.10/bin/gcc -print-prog-name=cc1
cc1

$ /usr/sparc-sun-solaris2.10/bin/gcc -print-search-dirs
install: /usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/
programs:
=/usr/sparc-sun-solaris2.10/bin/../libexec/gcc/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../libexec/gcc/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/bin/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/bin/
libraries:
=/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/lib/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/lib/:/usr/sparc-sun-solaris2.10/sys-root/lib/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/sys-root/lib/:/usr/sparc-sun-solaris2.10/sys-root/usr/lib/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/sys-root/usr/lib/

(quick summary: the required path /usr/libexec/gcc/sparc-sun-solaris2.10/4.4.3/
is not in there)

The decorated compiler works just fine though:

$ /usr/bin/sparc-sun-solaris2.10-gcc -print-prog-name=cc1
/usr/libexec/gcc/sparc-sun-solaris2.10/4.4.3/cc1

Further digging seems to indicate that this was caused by r118765, where the
configured in paths only are added if the binary is in $(bindir).

I'm hoping this is only an oversight and someone forgot about this extra bindir
for cross-compilers as this regression is causing quite a bit of pain here.


-- 
   Summary: undecorated cross-compiler gcc fails to find cc1
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ossman at cendio dot se


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

[Bug fortran/42954] gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry)

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2010-02-04 13:03 ---
*** Bug 36380 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/36380] preprocessing: define built-in target-related macros

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2010-02-04 13:03 ---


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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/42950] gfortran testsuite failures on mingw64

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-02-04 12:31 ---
Regarding (2): gcc/fortran/cpp.c contains the following, see PR 42954

  /* FIXME: Pandora's Box
Using the macros below results in multiple breakages:
 - mingw will fail to compile this file as dependent macros
   assume to be used in c-cppbuiltin.c only. Further, they use
   flags only valid/defined in C (same as noted above).
   [config/i386/mingw32.h, config/i386/cygming.h]
 - other platforms (not as popular) break similarly
   [grep for 'builtin_define_with_int_value' in gcc/config/]

  TARGET_CPU_CPP_BUILTINS ();
  TARGET_OS_CPP_BUILTINS ();
  TARGET_OBJFMT_CPP_BUILTINS (); */


Regarding (4)/(5): The NaN problems might be because we do not use
  __USE_MINGW_ANSI_STDIO=1  or  _POSIX
which is needed for POSIX compatible printf routines. Cf.
  http://sourceforge.net/project/shownotes.php?release_id=24832
Even if it is not the issue, it presumably makes sense to define it.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||42954


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

[Bug fortran/42954] New: gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry)

[burnus at gcc dot gnu dot org]

gcc/fortran/cpp.c contains:

  /* FIXME: Pandora's Box
Using the macros below results in multiple breakages:
 - mingw will fail to compile this file as dependent macros
   assume to be used in c-cppbuiltin.c only. Further, they use
   flags only valid/defined in C (same as noted above).
   [config/i386/mingw32.h, config/i386/cygming.h]
 - other platforms (not as popular) break similarly
   [grep for 'builtin_define_with_int_value' in gcc/config/]

  TARGET_CPU_CPP_BUILTINS ();
  TARGET_OS_CPP_BUILTINS ();
  TARGET_OBJFMT_CPP_BUILTINS (); */


Grepping for builtin_define_with_int_value shows:

gcc/config/frv/frv.h
gcc/config/i386/mingw32.h
gcc/config/mips/mips.h
gcc/config/freebsd-spec.h


Expected: The macros which make only sense for C are only used for C, e.g. many
of the __attribute__(()) ones.


-- 
   Summary: gfortran with libcpp: TARGET_*_CPP_BUILDINS issues
(MinGW, FreeBSD, MIPS, Fry)
   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=42954

[Bug rtl-optimization/36712] Inefficient loop unrolling

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-02-04 11:47 
---
Also try the patches from PR42617 to see if they improve the pre-regalloc
scheduling.


-- 


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

[Bug middle-end/42290] strange 'warning: "ISRA.2" may be used uninitialized in this function'

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2010-02-04 11:26 ---
(In reply to comment #7)
> I can't reproduce this issue in current trunk (r156468)

Closing then as FIXED, the warning was caused by bug 42508.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/36712] Inefficient loop unrolling

[steven at gcc dot gnu dot org]

--- Comment #10 from steven at gcc dot gnu dot org  2010-02-04 11:21 ---
I'm going to crack this bug.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-20 13:19:56 |2010-02-04 11:21:25
   date||


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

[Bug rtl-optimization/36712] Inefficient loop unrolling

[rearnsha at gcc dot gnu dot org]

--- Comment #9 from rearnsha at gcc dot gnu dot org  2010-02-04 11:11 
---
(In reply to comment #8)

> ldr r2, [r1, #0]
> mul r3, r2, r0
> str r3, [r1], #4
> ldr r2, [r1, #0]
> mul r3, r2, r0
> str r3, [r1], #4
> ldr r2, [r1, #0]
[...]

Ug, on a dual-issue core with load delay slots that code will REALLY suck. 
there's almost nothing that can be dual issued and the loaded values are used
in the instruction immediately after the load.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu dot
   ||org


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

[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none

[rearnsha at gcc dot gnu dot org]

--- Comment #8 from rearnsha at gcc dot gnu dot org  2010-02-04 10:48 
---
Created an attachment (id=19803)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19803&action=view)
Possible patch

I've been testing the attached patch on ARM (well, thumb) where there's a
similar issue.  It's perhaps a bit more aggressive than it needs to be, but it
should solve the problem generically rather than requiring each back-end to
implement hacks for what is really a MI issue.

Could someone test this on PPC?


-- 


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

[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-02-04 10:36 ---
The only addresses treated as the dse "constant" kind should be symbol-refs.
Or we need to lookup the constant initializer the constant mem refers to
and use that (but I have no idea if that's easily possible on RTL).


-- 


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

[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-02-04 10:33 ---
Well, dse puts

(mem/u/f/c/i:DI (symbol_ref:DI ("q") [flags 0x2]  )
[0 q+0 S8 A64])

(mem/u/f/c/i:DI (symbol_ref:DI ("p") [flags 0x2]  )
[0 p+0 S8 A64])

into different groups:

**scanning insn=9
cselib value 2 0x10f8e58 (reg/f:DI 63 [ q ])

cselib lookup (reg/f:DI 63 [ q ]) => 2
  mem: (reg/f:DI 63 [ q ])

   after canon_rtx address: (mem/u/f/c/i:DI (symbol_ref:DI ("q") [flags 0x2] 
) [0 q+0 S8 A64])
  gid=2 offset=0
 processing const load gid=2[0..4)
mems_found = 0, cannot_delete = true
cselib lookup (mem:SI (reg/f:DI 63 [ q ]) [0 S4 A32]) => 0

**scanning insn=10
cselib lookup (reg/f:DI 58 [ p.0 ]) => 1
  mem: (reg/f:DI 58 [ p.0 ])

   after canon_rtx address: (mem/u/f/c/i:DI (symbol_ref:DI ("p") [flags 0x2] 
) [0 p+0 S8 A64])
  gid=1 offset=0
 processing const base store gid=1[0..4)
trying store in insn=7 gid=1[0..4)


just because the addresses are MEM_READONLY_P.  But that obviously does not
mean they do not point to the same thing - no idea what implementor had
in mind here.  Kenny?

The following fixes this for me:

Index: dse.c
===
--- dse.c   (revision 156468)
+++ dse.c   (working copy)
@@ -1015,9 +1015,6 @@ const_or_frame_p (rtx x)
 {
   switch (GET_CODE (x))
 {
-case MEM:
-  return MEM_READONLY_P (x);
-
 case CONST:
 case CONST_INT:
 case CONST_DOUBLE:


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||zadeck at gcc dot gnu dot
   ||org


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

[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-04 10:11 ---
dse1 deletes insn 7 in

(insn 7 6 8 2 t.c:11 (set (mem:SI (reg/f:DI 58 [ p.0 ]) [0 S4 A32])
(const_int 0 [0x0])) 47 {*movsi_1} (nil))

(insn 8 7 9 2 t.c:12 (set (reg/f:DI 63 [ q ])
(mem/u/f/c/i:DI (symbol_ref:DI ("q") [flags 0x2]  ) [0 q+0 S8 A64])) 89 {*movdi_1_rex64} (nil))

(insn 9 8 10 2 t.c:12 (set (reg:SI 64)
(mem:SI (reg/f:DI 63 [ q ]) [0 S4 A32])) 47 {*movsi_1}
(expr_list:REG_DEAD (reg/f:DI 63 [ q ])
(nil)))

(insn 10 9 11 2 t.c:12 (set (mem:SI (reg/f:DI 58 [ p.0 ]) [0 S4 A32])
(reg:SI 64)) 47 {*movsi_1} (expr_list:REG_DEAD (reg:SI 64)
(expr_list:REG_DEAD (reg/f:DI 58 [ p.0 ])
(nil

The two canonical RTXen that are not detected as conflicting are

(mem/u/f/c/i:DI (symbol_ref:DI ("q") [flags 0x2]  )
[0 q+0 S8 A64])

(mem/u/f/c/i:DI (symbol_ref:DI ("p") [flags 0x2]  )
[0 p+0 S8 A64])

I will have a look.


-- 

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
   Last reconfirmed|2010-02-04 10:03:02 |2010-02-04 10:11:02
   date||


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

[Bug rtl-optimization/42952] [4.5 Regression] possible integer wrong code bug

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-02-04 10:03 ---
Confirmed.  Fails with -O -fno-tree-pta as well.

extern void abort (void);

static int g[1];

static int *p = &g[0];
static int *q = &g[0];

int main(void)
{
  g[0] = 1;
  *p = 0;
  *p = *q;
  if (g[0] != 0)
abort ();
  return 0;
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |rtl-optimization
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |i?86-*-* x86_64-*-*
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2010-02-04 10:03:02
   date||


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

[Bug target/42951] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-02-04 09:55 ---
Confirmed.


-- 

rguenth 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-02-04 09:55:10
   date||


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

[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build

[ktietz at gcc dot gnu dot org]

--- Comment #16 from ktietz at gcc dot gnu dot org  2010-02-04 08:47 ---
(In reply to comment #15)
> Any further word on this?

As I said in comment #14, we fixed a strict-aliasing bug in our C runtime
related to POSIX printf. As I tested it with current runtime, result looks ok
to me. It isn't an alignment issue, and neiter it was a gcc-bug.

Kai


-- 


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