[Bug lto/47900] New: Missed optimization with LTO

[d.g.gorbachev at gmail dot com]

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

   Summary: Missed optimization with LTO
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com


Created attachment 23474
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23474
Testcase

[Bug c/47899] New: ICE in get_loop_body, at cfgloop.c:831

[regehr at cs dot utah.edu]

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

   Summary: ICE in get_loop_body, at cfgloop.c:831
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
  Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
 Build: i686-pc-linux-gnu


regehr@home:~/volatile/bugs/tmp351$ current-gcc -v
Using built-in specs.

COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/mnt/z/z/compiler-install/gcc-r170512-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/mnt/z/z/compiler-install/gcc-r170512-install
--program-prefix=r170512- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20110226 (experimental) (GCC) 

regehr@home:~/volatile/bugs/tmp351$ current-gcc -O -funroll-loops small.c -o
small

small.c: In function ‘main’:
small.c:53:1: internal compiler error: in get_loop_body, at cfgloop.c:831
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

regehr@home:~/volatile/bugs/tmp351$ cat small.c


static unsigned
foo (unsigned ui1, unsigned ui2)
{
  return ui1 - ui2;
}

static unsigned g_5[3][1][9] = {
};

static short g_17;

static short *g_80[4] = {
  &g_17, &g_17, &g_17, &g_17
};

static short **g_79[5] = {
  &g_80[1], &g_80[1], &g_80[1], &g_80[1], &g_80[1]
};

static int g_132;
static short ***volatile g = &g_79[1];
static unsigned g_566;

static void func_1 (void)
{
lbl_777:*g;
  for (; g; g += 0)
for (; g; g += 1)
  {
for (;;)
  {
  }
  }
lbl_802:if (g_566)
goto lbl_777;
  for (g_132 = 0; g_132 >= 0; g_132 = foo (g_132, 1))
{
  if (g_5[+3][+1][+9] || **g)
{
  for (; g; g += 1)
{
}
}
  else
goto lbl_802;
}
}

int main (int argc, char *argv[])
{
  func_1 ();
}

[Bug target/19205] [m68k] avoid converting INDEX to SI mode if a narrower mode suffices

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #7 from Steven Bosscher  2011-02-26 
00:17:56 UTC ---
Also fine, not closed. Great to see that you pay enough attention to stop the
reporter from closing his own PRs. I wish you would be just as fast with
actually doing something about them. It is not even clear whether these
problems still exist!

If this still not OK with you, I suggest you do something about these 15+ years
old problems, or close these and re-file under your own account. They may not
bother you but I don't want them anymore in my list.

[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #13 from Steven Bosscher  2011-02-26 
00:17:54 UTC ---
Also fine, not closed. Great to see that you pay enough attention to stop the
reporter from closing his own PRs. I wish you would be just as fast with
actually doing something about them. It is not even clear whether these
problems still exist!

If this still not OK with you, I suggest you do something about these 15+ years
old problems, or close these and re-file under your own account. They may not
bother you but I don't want them anymore in my list.

[Bug target/19204] [m68k] pea can force reloads that cause inefficient code

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #6 from Steven Bosscher  2011-02-26 
00:17:55 UTC ---
Also fine, not closed. Great to see that you pay enough attention to stop the
reporter from closing his own PRs. I wish you would be just as fast with
actually doing something about them. It is not even clear whether these
problems still exist!

If this still not OK with you, I suggest you do something about these 15+ years
old problems, or close these and re-file under your own account. They may not
bother you but I don't want them anymore in my list.

[Bug c++/47897] [4.6 Regression][C++0x] static const member variable is not constant expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.26 00:13:26
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |4.6.0
Summary|[C++0x] static const member |[4.6 Regression][C++0x]
   |variable is not constant|static const member
   |expression  |variable is not constant
   ||expression
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2011-02-26 
00:13:26 UTC ---
Urgh, I can confirm this. Jason, can you have a look?

[Bug target/19205] [m68k] avoid converting INDEX to SI mode if a narrower mode suffices

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|WONTFIX |

--- Comment #6 from Andreas Schwab  2011-02-25 23:58:10 
UTC ---
Not a reason to close them.

[Bug target/19204] [m68k] pea can force reloads that cause inefficient code

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|WONTFIX |

--- Comment #5 from Andreas Schwab  2011-02-25 23:58:10 
UTC ---
Not a reason to close them.

[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|WONTFIX |

--- Comment #12 from Andreas Schwab  2011-02-25 23:58:09 
UTC ---
Not a reason to close them.

[Bug middle-end/45310] ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Steven Bosscher  2011-02-25 
23:19:08 UTC ---
If this pops up somewhere again, let's put that in a new PR with a test case.
This particular issue is closed.

[Bug tree-optimization/42963] [4.5 Regression] Redundant switch labels not cleaned up anymore

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||
 Resolution||WONTFIX

--- Comment #8 from Steven Bosscher  2011-02-25 
23:17:00 UTC ---
Will not be fixed for GCC 4.5. No need to keep this open.

[Bug target/45808] FreeBSD: -pthread is handled incompletely

[gerald at gcc dot gnu.org]

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

--- Comment #7 from gerald at gcc dot gnu.org  
2011-02-25 23:15:51 UTC ---
Author: gerald
Date: Fri Feb 25 23:15:48 2011
New Revision: 170505

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170505
Log:
PR target/45808
* config/freebsd-spec.h (FBSD_LIB_SPEC): Handle the shared case.
Update copyright years.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/freebsd-spec.h

[Bug target/45026] Empty function compiles to many loads and stores

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.25 23:15:12
 Ever Confirmed|0   |1

[Bug target/19205] [m68k] avoid converting INDEX to SI mode if a narrower mode suffices

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX

--- Comment #5 from Steven Bosscher  2011-02-25 
23:13:35 UTC ---
No response from m68k maintainers for more than 5 years.
This just clutters my bug searches. WONTFIX seems the most logical "way out".

[Bug target/19204] [m68k] pea can force reloads that cause inefficient code

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX

--- Comment #4 from Steven Bosscher  2011-02-25 
23:13:04 UTC ---
No response from m68k maintainers for more than 5 years. That may be a record.
This just clutters my bug searches. WONTFIX seems the most logical "way out".

[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX

--- Comment #11 from Steven Bosscher  2011-02-25 
23:12:26 UTC ---
No response from m68k maintainers for almost 2.5 years.
This just clutters my bug searches. WONTFIX seems the most logical "way out".

[Bug middle-end/47691] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1138 with -fgraphite-identity -ffast-math -fno-tree-scev-cprop

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.25 23:07:52
 Ever Confirmed|0   |1

[Bug middle-end/47691] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1138 with -fgraphite-identity -ffast-math -fno-tree-scev-cprop

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #1 from Steven Bosscher  2011-02-25 
23:07:32 UTC ---
I'll see if I can turn this test case into a C test case, to maybe raise this
to P1.

[Bug target/38598] MIPS extendsidi2 does not have a LO alternative

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  2011-02-25 
23:05:55 UTC ---
(In reply to comment #1)
> I have a patch, but it isn't appropriate at this stage in the 4.4 cycle.

It has been over 2 years since this comment was added, what happened to the
patch?  Could you at least attach it to the bug if you still have it around?

[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO -fuse-linker-plugin -fwhole-program

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
 CC||steven at gcc dot gnu.org

--- Comment #10 from Steven Bosscher  2011-02-25 
23:04:07 UTC ---
No test case available. Please, someone, provide a test case so that those
unlucky souls without access to SPEC2k6 can try to help debug this problem.

[Bug target/47898] error: unable to find a register to spill in class 'FPUL_REGS'

[mcnichol at austin dot ibm.com]

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

--- Comment #1 from Dan McNichol  2011-02-25 
21:49:02 UTC ---
Created attachment 23473
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23473
Preprocessor output for testcase

Attaching preprocessor output.

[Bug target/47898] New: error: unable to find a register to spill in class 'FPUL_REGS'

[mcnichol at austin dot ibm.com]

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

   Summary: error: unable to find a register to spill in class
'FPUL_REGS'
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mcnic...@austin.ibm.com


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

I get the following error when using gcc to cross compile
to an SH4 target.

# /opt/sh4/bin/sh4-linux-gcc -c -O1 sh4-gcc.c 
sh4-gcc.c: In function 'xml_transport_parser':
sh4-gcc.c:104: error: unable to find a register to spill in class 'FPUL_REGS'
sh4-gcc.c:104: error: this is the insn:
(insn 199 198 200 18 sh4-gcc.c:76 (set (mem/s/j:QI (plus:SI (reg:SI 77 fr13
[320])
(reg:SI 76 fr12 [orig:240 D.2212 ] [240])) [0 name S1 A8])
(reg:QI 1 r1 [284])) 182 {movqi_i} (expr_list:REG_DEAD (reg:QI 1 r1
[284])
(expr_list:REG_DEAD (reg:SI 76 fr12 [orig:240 D.2212 ] [240])
(nil
sh4-gcc.c:104: confused by earlier errors, bailing out


The problem only seems to happen with -O1.

Here is the information about my compiler:
#sh4-linux-gcc -v
Using built-in specs.
Target: sh4-linux
Configured with: /usr/src/BUILD/gcc/configure --prefix=/opt/sh4
--target=sh4-linux --with-cpu=sh4a --with-multilib-list=sh4a,sh4a-nofpu
--enable-incomplete-targets --disable-nls --disable-libssp --disable-libgomp
--disable-libmudflap --enable-shared --enable-languages=c,c++ --enable-cross
--enable-__cxa_atexit --enable-threads=posix --with-sysroot=/opt/sh4/crossroot
Thread model: posix
gcc version 4.3.4 [gcc-4_3-branch revision 152973] (GCC)


Attached is a small test case.

[Bug target/47715] [x32] TLS doesn't work

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org  2011-02-25 
21:25:24 UTC ---
Author: hjl
Date: Fri Feb 25 21:25:20 2011
New Revision: 170504

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170504
Log:
Use ptr_mode instead of Pmode with UNSPEC_TP.

2011-02-25  H.J. Lu  

PR target/47715
* config/i386/i386.c (get_thread_pointer): Use ptr_mode
instead of Pmode with UNSPEC_TP.

* config/i386/i386.md (tp_seg): Removed.
(*load_tp_): Replace :P with :PTR.
(*add_tp_): Likewise.
(*load_tp_x32): New.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/config/i386/i386.c
branches/x32/gcc/config/i386/i386.md

[Bug target/47715] [x32] TLS doesn't work

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  2011-02-25 21:23:10 
UTC ---
*** Bug 47403 has been marked as a duplicate of this bug. ***

[Bug target/47403] [x32] TLS doesn't work

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from H.J. Lu  2011-02-25 21:23:10 
UTC ---
Dup.

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

[Bug c++/47897] New: [C++0x] static const member variable is not constant expression

[flast at flast dot jp]

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

   Summary: [C++0x] static const member variable is not constant
expression
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp


GCC4.6.0(with C++0x mode) reject static const member variable depending
template parameter type.

 testcase.C 
template < typename T, T N >
struct S
{
static const T value = N;
typedef S< T, value + 1 > next;
};


It seems caused by r170488 (git: cfa61f8435164f3205d70c7e1c5038b2d881aa1d).

In other case, GCC accepts codes.
For example:
 testcase.C (accepted) 
template < int N >
struct S
{
static const int value = N;
typedef S< value + 1 > next;
};
---

Another case:
 testcase.C (accepted) 
template < typename T, T N >
struct S
{
static constexpr T value = N;
typedef S< T, value + 1 > next;
};
---

[Bug target/46898] libgcc build failure on lm32-elf

[lekernel at gcc dot gnu.org]

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

--- Comment #14 from Sebastien Bourdeauducq  
2011-02-25 19:26:31 UTC ---
This gets the C compiler to build; if C++ is enabled, this triggers the cc1
segfault above.

[Bug target/46898] libgcc build failure on lm32-elf

[lekernel at gcc dot gnu.org]

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

--- Comment #13 from Sebastien Bourdeauducq  
2011-02-25 19:24:24 UTC ---
Author: lekernel
Date: Fri Feb 25 19:24:20 2011
New Revision: 170502

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170502
Log:
2011-02-25  Sebastien Bourdeauducq 

PR gcc/46898
* config/lm32/lm32.md (ashrsi3): Added needed variable.

2011-02-25  Jon Beniston 

PR gcc/46898
* config/lm32/lm32.h (INCOMING_RETURN_ADDR_RTX): New.
* config/lm32/lm32.md (ashlsi3): Remove unused variable.
* config/lm32/lm32.c (TARGET_EXCEPT_UNWIND_INFO): New.
(lm32_block_move_inline): Add type cast to remove warning.
(lm32_expand_prologue): Generate fp in a way compatible with
dwarf2out.
(gen_int_relational): Move declarations to start of function.


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

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2011-02-25 
19:09:54 UTC ---
Created attachment 23471
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23471
gcc46-pr47893.patch

Updated patch, so far just lightly tested that it fixes this bug.

[Bug tree-optimization/47896] New: wrong code with -O -fno-early-inlining -fipa-pta -fno-tree-dominator-opts -fno-tree-forwprop

[zsojka at seznam dot cz]

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

   Summary: wrong code with -O -fno-early-inlining -fipa-pta
-fno-tree-dominator-opts -fno-tree-forwprop
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Output:
$ g++ -O -fno-early-inlining -fipa-pta -fno-tree-dominator-opts
-fno-tree-forwprop testcase.C
$ ./a.out 
Aborted

Testcase was reduced from g++.dg/torture/pr37922.C, which fails with:
$ g++ -O -fno-early-inlining -fipa-pta -fschedule-insns2
-fno-tree-dominator-opts -fno-tree-forwprop -funroll-loops pr37922.ii
$ ./a.out 
Aborted

Tested revisions:
r170489 - fail

[Bug target/46898] libgcc build failure on lm32-elf

[lekernel at gcc dot gnu.org]

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

--- Comment #12 from Sebastien Bourdeauducq  
2011-02-25 19:04:07 UTC ---
ok... breaks it, but with a syntax error (seems to have been fixed in the
meantime), not for the cc1 segfault we're looking for.

[Bug target/46898] libgcc build failure on lm32-elf

[lekernel at gcc dot gnu.org]

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

--- Comment #11 from Sebastien Bourdeauducq  
2011-02-25 18:49:46 UTC ---
Actually, Jon's patch (http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02561.html)
fixes this one problem introduced by Richard's commit. But after Jon's patch is
applied, the next commit to break LM32 is:

5ae82d58486a4ee6a9a7d5ca5fef2b43c2d53eb4 is the first bad commit
commit 5ae82d58486a4ee6a9a7d5ca5fef2b43c2d53eb4
Author: jsm28 
Date:   Wed Sep 29 14:49:14 2010 +

gcc:
* optc-gen.awk: Generate global_options initializer instead of
individual variables.  Add x_ prefix to names of structure
members.
* opth-gen.awk: Generate gcc_options structure.  Add x_ prefix to
names of structure members.
* doc/tm.texi.in (HARD_FRAME_POINTER_IS_FRAME_POINTER,
HARD_FRAME_POINTER_IS_ARG_POINTER): Document.
* doc/tm.texi: Regenerate.
* alias.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER
* builtins.c: Use HARD_FRAME_POINTER_IS_ARG_POINTER.
* c-parser.c (disable_extension_diagnostics,
restore_extension_diagnostics): Update names of cpp_options
members.
* combine.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER
* common.opt (fcompare-debug-second): Don't use Var.
* config/alpha/alpha.h (target_flags): Remove.
* config/arm/arm.h (HARD_FRAME_POINTER_IS_FRAME_POINTER,
HARD_FRAME_POINTER_IS_ARG_POINTER): Define.
* config/bfin/bfin.h (target_flags): Remove.
* config/cris/cris.h (target_flags): Remove.
* config/i386/i386-c.c (ix86_pragma_target_parse): Update names of
cl_target_option members.
* config/i386/i386.c (ix86_force_align_arg_pointer): Remove.
(ix86_function_specific_print, ix86_valid_target_attribute_tree,
ix86_can_inline_p): Update names of cl_target_option members.
* config/i386/i386.h (ix86_isa_flags): Remove.
* config/lm32/lm32.h (target_flags): Remove.
* config/mcore/mcore.h (mcore_stack_increment): Remove.
* config/mcore/mcore.md (addsi3): Remove extern declaration of
flag_omit_frame_pointer.
* config/mep/mep.h (target_flags): Remove.
* config/mips/mips.h (HARD_FRAME_POINTER_IS_FRAME_POINTER,
HARD_FRAME_POINTER_IS_ARG_POINTER): Define.
* config/mmix/mmix.h (target_flags): Remove.
* config/rs6000/rs6000.h (rs6000_xilinx_fpu, flag_pic,
flag_expensive_optimizations): Remove.
* config/s390/s390.h (flag_pic): Remove.
* config/score/score-conv.h (target_flags): Remove.
* config/sh/sh.h (sh_fixed_range_str): Remove.
* config/spu/spu.h (target_flags, spu_fixed_range_string): Remove.
* dbxout.c: Use HARD_FRAME_POINTER_IS_ARG_POINTER
* df-scan.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER.
* diagnostic.c (diagnostic_initialize): Update names of
diagnostic_context members.
* diagnostic.h (diagnostic_context): Rename inhibit_warnings and
warn_system_headers.
(diagnostic_report_warnings_p): Update for new names.
* dwarf2out.c: Use HARD_FRAME_POINTER_IS_ARG_POINTER
* emit-rtl.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER and
HARD_FRAME_POINTER_IS_ARG_POINTER.
* flags.h (flag_compare_debug): Declare.
* ira.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER
* opts.c (flag_compare_debug): Define.
(common_handle_option): Update names of diagnostic_context
members.  Handle -fcompare-debug-second.
(fast_math_flags_struct_set_p): Update names of cl_optimization
members.
* reginfo.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER.
* regrename.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER.
* reload.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER.
* reload1.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER.
* resource.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER.
* rtl.h (HARD_FRAME_POINTER_IS_FRAME_POINTER,
HARD_FRAME_POINTER_IS_ARG_POINTER): Define and use.
* sel-sched.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER
* stmt.c: Use HARD_FRAME_POINTER_IS_ARG_POINTER.

gcc/c-family:
* c-common.c (c_cpp_error): Update names of diagnostic_context
members.
* c-cppbuiltin.c (c_cpp_builtins_optimize_pragma): Update names of
cl_optimization members.
* c-opts.c (warning_as_error_callback, c_common_handle_option,
sanitize_cpp_opts, finish_options): Update names of cpp_options
members.

gcc/fortran:
* cpp.c (cpp_define_builtins): Update names of gfc_option_t
members.
(gfc_cpp_post_options): Update names of cpp_options members.
(cb_cpp_error): Update names of diagnostic_context members.
* f95-lang.c (gfc_init_builtin_functions): Update names of
gfc_option_t members.
* gfortran.h (gfc_option_t): Rename warn_conversion and
flag_op

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-02-25 
18:43:20 UTC ---
Created attachment 23469
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23469
statistics gathering patch

With this patch I got fncnt array summaries from i686-linux bootstrap/regtest:
56916 0 24380 27 96234 201 125938 699 1065459 5040
and from x86_64-linux bootstrap/regtest:
65358 0 11038 11 55139 84 91377 3184 701567 25806
This shows that assign_stack_temp_for_type is really never called during
bootstrap/regtest after virtual reg instantiation and at least for i386
add_frame_space is called just in ~ .5% of cases (and similarly for the size).
On x86_64 it happens more often, in ~ 3.5% of cases (haven't unfortunately
tracked which of those successes to save something were from
assign_stack_temp_for_type frame_space areas though.

Thus, I think the proposed patch is the right way to go.

[Bug target/47852] crash with g++ -lpthread on irix

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.25 18:31:39
 CC||ro at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Rainer Orth  2011-02-25 18:31:39 UTC 
---
Mine.  As suspected, libstdc++.so needs to be linked with -lpthread since
emutls
uses pthread_* functions, while libc provides only stubs for some of them.

I'll regtest the corresponding trivial patch over the weekend.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[dje at gcc dot gnu.org]

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

--- Comment #26 from David Edelsohn  2011-02-25 
17:52:21 UTC ---
Richard,

Did you look at the list of sites providing pre-built binaries for AIX listed
on the GCC website:

http://gcc.gnu.org/install/binaries.html

There are multiple options who provide much newer versions of GCC than the ones
included in the AIX Toolbox.

- David

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2011-02-25 
17:39:36 UTC ---
I guess that would break pa, because then
  else if (!STACK_ALIGNMENT_NEEDED)
{
  ...
}
will be executed whenever record_alignment_slots is false, even for non-zero
sizes or non-BLKmode.
Other than that, I think it would be better to change the bool argument into an
enum, after all we need just 3 variants, reduce_alignment_ok &&
record_alignment_slots (for caller-save), !reduce_alignment_ok &&
record_alignment_slots (for assign_stack_local) and !reduce_alignment_ok &&
!record_alignment_slots (for assign_stack_temp_for_type).

I'm currently running x86_64-linux and i686-linux bootstraps/regtests gathering
statistics, so far from the partial numbers I have a patch like that isn't
going to pessimize stuff too much, add_frame_space from within
assign_stack_temp_for_type accounts for like .5% of all add_frame_space calls
(and similarly in the number of bytes thus recorded).

[Bug rtl-optimization/47862] Incorrect code for spilling a vector register

[pthaugen at gcc dot gnu.org]

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

--- Comment #3 from Pat Haugen  2011-02-25 
17:36:03 UTC ---
The following fixes the problem by changing the save mode for FP regs to V2DF
mode for TARGET_VSX. But I have questions/concerns on this that need more
digging:

- I believe this will affect all FP reg saves, which will be overkill for SF/DF
modes since we'll be allocating 16 bytes and doing full vector store/load. Can
we modify save/restore code on the fly to use the appropriate size?

- Any issues wrt stack slot reuse (i.e. can't reuse smaller slot for vector
save)?



Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  (revision 170438)
+++ gcc/config/rs6000/rs6000.h  (working copy)
@@ -1005,6 +1005,12 @@ extern unsigned rs6000_pointer_size;

 #define HARD_REGNO_NREGS(REGNO, MODE) rs6000_hard_regno_nregs[(MODE)][(REGNO)]

+/* Ensure vector modes are handled correctly in FP regs for VSX */
+#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE)\
+  (TARGET_VSX && FP_REGNO_P (REGNO)\
+   ? V2DFmode  \
+   : choose_hard_reg_mode ((REGNO), (NREGS), false))
+
 #define HARD_REGNO_CALL_PART_CLOBBERED(REGNO, MODE)\
   (((TARGET_32BIT && TARGET_POWERPC64  \
  && (GET_MODE_SIZE (MODE) > 4) \

[Bug target/46898] libgcc build failure on lm32-elf

[joel at gcc dot gnu.org]

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

--- Comment #10 from Joel Sherrill  2011-02-25 
17:30:46 UTC ---
Richard I added this to you since I think Sebastian's bisect turned up a patch
by you.

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[bernds at gcc dot gnu.org]

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

--- Comment #9 from Bernd Schmidt  2011-02-25 
17:25:13 UTC ---
Created attachment 23468
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23468
Test patch

Does this fix it?

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[bernds at gcc dot gnu.org]

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

--- Comment #8 from Bernd Schmidt  2011-02-25 
17:24:15 UTC ---
(In reply to comment #7)
> My temptation would be to revert until someone can get in there and design
> things so that we either have a single list or there's clear rules for
> manipulating objects in each list and reflecting the necessary information 
> back
> and forth.
> 
> Even with Jakub's suggestions my worry is other similar, subtle bugs are in
> there and will bite us later.

We're not actually calling assign_stack_temp after the assign phase, are we?
IMO we can set a flag once we expect to only call assign_stack_local, and start
using the frame_space list after that point. There'll be no worries about
inconsistent lists.

[Bug target/47715] [x32] TLS doesn't work

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  2011-02-25 16:56:12 
UTC ---
Thread pointer really should be 32bit in x32.

[Bug tree-optimization/47890] [4.5/4.6 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||irar at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Guenther  2011-02-25 
16:43:11 UTC ---
Ira,

Index: gcc/tree-vect-loop.c
===
*** gcc/tree-vect-loop.c(revision 170492)
--- gcc/tree-vect-loop.c(working copy)
*** get_initial_def_for_induction (gimple iv
*** 2886,2891 
--- 2886,2894 
gimple_assign_set_lhs (new_stmt, induc_def);
si = gsi_start_bb (bb);
gsi_insert_before (&si, new_stmt, GSI_SAME_STMT);
+   set_vinfo_for_stmt (new_stmt,
+ new_stmt_vec_info (new_stmt, loop_vinfo, NULL));
+   STMT_VINFO_RELATED_STMT (vinfo_for_stmt (new_stmt)) = induction_phi;
  }

return induc_def;

fixes this for me, but I'm not familiar with how this related stmt stuff
works, so can you please double-check?

Thanks.

[Bug target/46898] libgcc build failure on lm32-elf

[lekernel at gcc dot gnu.org]

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

--- Comment #9 from Sebastien Bourdeauducq  
2011-02-25 16:40:52 UTC ---
I ran git bisect for this. Here is the result:

74897bc755ddcb5ff67a91570c83e910ed950c7c is the first bad commit
commit 74897bc755ddcb5ff67a91570c83e910ed950c7c
Author: rth 
Date:   Thu Aug 5 15:39:54 2010 +

PR 45189
Unbreak ia64 build after last dwarf2out.c change.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@162917
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #7 from Jeffrey A. Law  2011-02-25 16:40:56 
UTC ---
My temptation would be to revert until someone can get in there and design
things so that we either have a single list or there's clear rules for
manipulating objects in each list and reflecting the necessary information back
and forth.

Even with Jakub's suggestions my worry is other similar, subtle bugs are in
there and will bite us later.

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  2011-02-25 
16:10:55 UTC ---
(In reply to comment #5)
> Similarly not queuing anything into frame_space lists
> when assign_stack_local is called from within assign_stack_temp_for_type would
> kill most of the savings Bernds' original patch had.

I think that's worth trying though. I can't think of any other good solution at
the moment short of reverting the whole thing.

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-02-25 
16:06:14 UTC ---
I guess not including the space added in add_frame_space by the
assign_stack_local_1 call in temp_slot's size/full_size, while it would be easy
to do (just walk the beginning of the frame_space list looking for slots that
overlap with what we'd like to include in size/full_size), would result in too
big stack wastage (e.g. in the given testcase suddenly the fn7 and fn2 return
slot couldn't be shared, even when it isn't clear if something would actually
like to use it or not).  Similarly not queuing anything into frame_space lists
when assign_stack_local is called from within assign_stack_temp_for_type would
kill most of the savings Bernds' original patch had.

Perhaps we could add pointers from temp_slots to frame_space list and back,
when deciding to reuse an earlier temp_slot in assign_stack_temp_for_type we'd
walk the referenced list and remove frame_space entries that overlap it and
similarly when assign_stack_local_1 decides it wants to use a frame_space we'd
decrease size/full_size of the temp_slot that overlaps it.
We could of course try to prefer frame_space slots that don't overlap any
temp_slots.

Or perhaps don't try to use frame_space slots until virtuals_instantiated,
assuming assign_stack_temp_for_type/assign_stack_temp/assign_temp aren't called
after virtuals_instantiated is set, then we could just have links from
temp_slots to frame_space and not vice versa.

OT, on the other side, perhaps add_frame_space could be called e.g. for the
padding inserted in expand_used_vars by:

  /* If the target requires that FRAME_OFFSET be aligned, do it.  */ 
  if (STACK_ALIGNMENT_NEEDED)
{
  HOST_WIDE_INT align = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
  if (!FRAME_GROWS_DOWNWARD)
frame_offset += align - 1;
  frame_offset &= -align;
}

and perhaps also without -fstack-protector for inter-variable padding
(alloc_stack_frame_space - with -fstack-protector it would be a security risk
to place spills above any arrays).  But this OT isn't stage 4 matter.

[Bug other/47869] fatal error: build/gencondmd.c: No such file or directory

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu.org

--- Comment #1 from Ralf Wildenhues  2011-02-25 
15:52:14 UTC ---
Which make version are you using?  How exactly did you invoke make (-jN)? 
Thanks.

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||law at gcc dot gnu.org
 AssignedTo|jakub at gcc dot gnu.org|unassigned at gcc dot
   ||gnu.org

--- Comment #4 from Jakub Jelinek  2011-02-25 
15:40:22 UTC ---
Ugh, this is ugly.
The problem is that Bernd's changes conflict with the way
assign_stack_temp_for_type/combine_temp_slots works.
Both are now parallel lists of stack slot information, but they aren't aware of
each other.
So, when assign_stack_temp_for_type is called to allocate slot for 12 byte long
16 byte aligned slot (for fn7 return value), this internally calls
assign_stack_local (why we CEIL_ROUND the size to 16 in that case is something
I don't understand).  assign_stack_local_1 sees the current frame offset is not
16 byte aligned, so it eats 8 bytes for alignment and 16 bytes for the actual
stack slot.  assign_stack_local_1 then calls add_frame_space for the extra 8
bytes, so
that it can be used by something else later (by assign_stack_local_1) - this is
Bernd's new code.
But in assign_stack_temp_for_type it tracks the allocation in struct temp_slot,
and there it records the whole stack block including whatever padding had to be
made again (i.e. 24 bytes in this case).

If assign_stack_local called from here will actually return something from the
queued frame space slots, then frame_offset_old == frame_offset and thus it
will do really weird things, that is something that needs to be fixed too, but
is not something that happens in this case (I'd say if frame_offset_old ==
frame_offset and it wasn't BLKmode with size 0, then it should record as
size/full_size just the requested size and nothing else).

In this testcase afterwards assign_stack_temp_for_type is called for 20 byte
BLKmode requesting 16 byte alignment, and as this is -fno-strict-aliasing, it
chooses that it could share the temp slot with the above allocated one and as
its size/full_size was 24, it just uses it.  Nothing informs the frame_space
list about this though and thus it will happily give that slot again during
reload.

[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-02-25 
14:51:22 UTC ---
At what point does the direct access to IMAGPART appear?  That looks
like the bug.  Why isn't a temporary used for this?  Does s390 return the
complex number in memory?

[Bug middle-end/47895] usage of __attribute__ ((__target__ ("xyz"))) with buitins

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-02-25 
14:44:27 UTC ---
A way easier and more portable way is to split your source into multiple
compilation units and use appropriate flags to compile them.

[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #4 from Andreas Krebbel  2011-02-25 
14:08:20 UTC ---
I also see uninit-13.c failing on s390x.

The warning here is also emitted for line 7 while being expected in
line 8.

 4  typedef _Complex float C;
 5  C foo()
 6  {
 7C f;
 8__imag__ f = 0;   /* { dg-warning "is used" "unconditional" } */
 9return f;
10  }

The question is why do we expect the warning in line 8 at all?!  To me
it makes sense to either emit the warning on the uninitialized use -
that would be the "return f;" in line 9 or emit it for the declaration
of the uninitialized variable - that would be line 7 then.

To my understanding line 8 is the only one not directly related to the
warning.

warn_uninit in tree-ssa.c seems to implement exactly this.  It uses
either the location of the using gimple expression if available or it
falls back to the var decl. On s390x I see the var decl being used as
location while for x86_64 there is a stmt having its own location which
is used instead.

x86_64: uninit-13.c.083t.dce2:

foo ()
{
  float f$real;
  C f;

:
  [gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f_3 = COMPLEX_EXPR ;
  return f_3;

}



s390x: uninit-13.i.083t.dce2

foo ()
{
  float f$real;

:
  REALPART_EXPR <> = f$real_6(D);
  [gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR <> = 0.0;
  [gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return ;

}


Before dce2 the line with the COMPLEX_EXPR exists also on s390x:

s390x: uninit-13.i.082t.reassoc1:

foo ()
{
  float f$real;
  C f;
  float D.2702;

:
  [gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f$real_2 = f$real_6(D);
  [gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f_3 = COMPLEX_EXPR ;
  REALPART_EXPR <> = f$real_6(D);
  [gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR <> = 0.0;
  [gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return ;

}

I think first we should fix the testcase - moving the warning one line
up and then find a way to fix the x86_64 problem.  To me it currently
looks like this is a testcase bug.

[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely

[singler at gcc dot gnu.org]

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

--- Comment #15 from singler at gcc dot gnu.org  
2011-02-25 14:04:48 UTC ---
Author: singler
Date: Fri Feb 25 14:04:40 2011
New Revision: 170494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170494
Log:
2011-02-25  Johannes Singler  

PR libstdc++/47433
* include/parallel/losertree.h
(_LoserTree<>::__delete_min_insert):
Do not qualify swap with std:: for value type,
but include a using directive instead.
(_LoserTreeUnguarded<>::__delete_min_insert): Likewise.
* include/parallel/balanced_quicksort.h (__qsb_divide):
Use std::iter_swap instead of std::swap.
(__qsb_local_sort_with_helping): Likewise.
* include/parallel/partition.h (__parallel_partition):
Likewise. (__parallel_nth_element): Likewise.

Modified:
branches/gcc-4_5-branch/libstdc++-v3/ChangeLog
branches/gcc-4_5-branch/libstdc++-v3/include/parallel/balanced_quicksort.h
branches/gcc-4_5-branch/libstdc++-v3/include/parallel/losertree.h
branches/gcc-4_5-branch/libstdc++-v3/include/parallel/partition.h

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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

Thomas Henlich  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #27 from Thomas Henlich  
2011-02-25 14:00:18 UTC ---
Way to go, still not quite right...

print '(f3.0)', -1E-6  ! => -0.
print '(f0.0)', -1E-6  ! => ** expected -0.

Comprehensive testcase attached.

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #26 from Thomas Henlich  
2011-02-25 13:58:51 UTC ---
Created attachment 23467
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23467
Programmatic test case for multiple formats

[Bug middle-end/47895] New: usage of __attribute__ ((__target__ ("xyz"))) with buitins

[vincenzo.innocente at cern dot ch]

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

   Summary: usage of __attribute__ ((__target__ ("xyz"))) with
buitins
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


I would like to generate code for multiple targets from the same source when
using builtins
(
I think that this issue has been discussed before for instance in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39840
) 


I have code as in the example below that compiles only with -mavx.
In such a case it will use AVX instruction for all functions including the one
"targetted" for sse3
while I would like to obtain an object file that I can run on multiple
platform.
This problem occurs only when builtins are used: standard c code is correctly
emitted accordingly to the target provided that the minimal -m is used.

Is there any preprocessor flag to "activate" all intrinsics and builtins in
x86intrin.h?

-
example

#include 

float  __attribute__ ((__target__ ("sse3"))) sum3(float const * __restrict__ x,
float const * __restrict__ y, float const * __restrict__ z) {
  __m128 sum = _mm_setzero_ps();
  for (int i=0; i!=1024; i+=4)
sum  += _mm_add_ps(_mm_loadu_ps(z+i),
   _mm_mul_ps(_mm_loadu_ps(x+i),_mm_loadu_ps(y+i)) );
sum = _mm_hadd_ps(sum,sum);
sum = _mm_hadd_ps(sum,sum);
  float ret;
  _mm_store_ss(&ret,sum);
  return ret;
}

float  __attribute__ ((__target__ ("avx"))) sumv(float const * __restrict__ x,
float const * __restrict__ y, float const * __restrict__ z) {
  __m256 sum = _mm256_setzero_ps();
  for (int i=0; i!=1024; i+=8)
sum  += _mm256_add_ps(_mm256_loadu_ps(z+i),
   _mm256_mul_ps(_mm256_loadu_ps(x+i),_mm256_loadu_ps(y+i))
);
sum = _mm256_hadd_ps(sum,sum);
sum = _mm256_hadd_ps(sum,sum);
sum = _mm256_hadd_ps(sum,sum);
  float ret[8];
  _mm256_store_ps(ret,sum);
  return ret[0];
}

[Bug c/22133] In MinGW trailling slash forward not allowed in include path

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||ktietz at gcc dot gnu.org

--- Comment #8 from Kai Tietz  2011-02-25 13:15:01 
UTC ---
(In reply to comment #0)
> For a detailed description of this bug see:
> 
> https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1053052&group_id=2435
> 
> In short the file c-incpath.c (near line 331) needs to be modified to remove 
> the
> trailing slash if HAVE_DOS_BASED_FILE_SYSTEM is true. It seems on newer 
> windows
> systems the trailing slash starts to become a problem. My current makefiles 
> all
> have trailing slashes for each include path to support compilers that require
> the trailing slash. As a result I can't upgrade to the latest MinGW gcc build.
> 
> I classified this as minor since it effects portability of code.

Does the patch from Nathan Froyd fixed the issue for you?  My tests have shown
that issue is solved by it, but I would like that you can confirm this.

[Bug c++/47873] [4.6 Regression] virtual Inheritance - Covariant Virtual Function - Segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|[4.6 Regression] Multiple   |[4.6 Regression] virtual
   |Inheritance - Covariant |Inheritance - Covariant
   |Virtual Function - Segfault |Virtual Function - Segfault

--- Comment #5 from Jonathan Wakely  2011-02-25 
13:07:26 UTC ---
minimal testcase with no namespaces or multiple inheritance

the segfault goes away if Ent is an empty class or if virtual inheritance isn't
used


struct Base
{
virtual ~Base(){}

virtual Base& This() { return *this; }
};


struct Ent : virtual Base
{
void *m_Body;

Ent& This() { return *this; }

virtual Ent& body()
{
return This();
}

};


struct Msg : virtual Ent
{
Msg()
{
body();
}

Msg& This() { return *this; }
};

int main()
{
Msg m;

return 0;
}

miscompiled by gcc-4.6-20110219 snapshot

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x004007ff in Ent::body (this=0x7fffe598) at bug.cc:17
#2  0x004009ca in Msg::Msg (this=0x7fffe590,
__in_chrg=, __vtt_parm=)
at bug.cc:27
#3  0x00400719 in main () at bug.cc:35

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||4.6.0
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
  Known to fail||4.5.2

--- Comment #3 from Jakub Jelinek  2011-02-25 
12:56:15 UTC ---
Looking into it...

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.25 12:51:14
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-02-25 
12:51:14 UTC ---
Confirmed.

[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-02-25 
12:48:38 UTC ---
Seems to be caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159480

[Bug libfortran/47894] New: Documentation text for VERIFY intrinsic function is wrong.

[thenlich at users dot sourceforge.net]

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

   Summary: Documentation text for VERIFY intrinsic function is
wrong.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


The documentation states:

"Verifies that all the characters in a SET are present in a STRING."

but this should read:

"Verifies that no other characters than those in a SET are present in a
STRING."

or:

"Verifies that all the characters in STRING are present in a SET."


Also, the sentence:

"If all characters of SET are found in STRING, the result is zero."

again is wrong and should read:

"If no characters not in SET are found in STRING, the result is zero."

or

"If only characters from SET are found in STRING, the result is zero."

or

"If all characters of STRING are found in SET, the result is zero."

or, as in Fortran 2008:

"The value of the result is zero if each character in STRING is in SET or if
STRING has zero length."

The headline is also misleading:

"VERIFY — Scan a string for the absence of a set of characters"

because the string is actually scanned for the absence (or presence) of
characters NOT in SET (mathematically, that's a complement of SET, which is
also a set, but confusing to read)

Maybe it should read:
"VERIFY — Scan a string for the absence of characters not in a set"

or, as in Fortran 2008:
"Search for a character not in a given set."

[Bug middle-end/47893] New: [4.6 Regression] 4.6 miscompiles mesa on i686

[jakub at gcc dot gnu.org]

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

   Summary: [4.6 Regression] 4.6 miscompiles mesa on i686
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: blocker
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: i686-linux


Created attachment 23466
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23466
mesa.c

The following testcase (distilled from http://bugzilla.redhat.com/679924 )
is miscompiled on i?86 (and x86_64 -m32).

The problem is that struct S is 20 bytes long (why doesn't mesa pack the
bitfield structs better is beyond me) and is returned indirectly via caller
provided memory.  The assembly shows:
callfn1 #
testl   %eax, %eax  #
movl%eax, -4664(%ebp)   #, %sfp
...
leal-4680(%ebp), %eax   #,
callfn2 #
...
cmpl%ebx, -4664(%ebp)   # i, %sfp
i.e. the return value from fn1 (variable c) is spilled into %ebp-4664, but
fn2 is given as struct S return slot %ebp-4680, so when it returns it
overwrites
some 16 bytes reserved for the return value and the variable c as well.

[Bug c++/47873] [4.6 Regression] Multiple Inheritance - Covariant Virtual Function - Segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.25 11:38:32
Summary|Multiple Inheritance -  |[4.6 Regression] Multiple
   |Covariant Virtual Function  |Inheritance - Covariant
   |- Segfault  |Virtual Function - Segfault
 Ever Confirmed|0   |1

--- Comment #4 from Jonathan Wakely  2011-02-25 
11:38:32 UTC ---
confirmed, no crash with 4.5 or earlier

[Bug c++/47873] Multiple Inheritance - Covariant Virtual Function - Segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #23448|0   |1
is obsolete||

--- Comment #3 from Jonathan Wakely  2011-02-25 
11:37:37 UTC ---
Created attachment 23465
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23465
reduced testcase

reduced testcase which removes c++0x and libstdc++ dependencies, removes the
java-style access control, re-indents and renames some of the identically-named
namespaces, classes and function to make it slightly more readable

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  2011-02-25 
11:18:17 UTC ---
Author: ebotcazou
Date: Fri Feb 25 11:18:14 2011
New Revision: 170492

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170492
Log:
PR tree-optimization/45470
* tree-vect-data-refs.c (vect_analyze_data_refs): Fail if a statement
can throw internally only.
* tree-vect-stmts.c (vectorizable_call): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-stmts.c

[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2011-02-25 
11:13:07 UTC ---
Clang accepts it too.

It was probably fixed in 4.5 by Jason implementing the extended SFINAE rules

[Bug c++/47873] Multiple Inheritance - Covariant Virtual Function - Segfault

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-02-25 
11:08:07 UTC ---
this doesn't segfault with 4.5

I have a reduced version with no stdlib or c++0x dependencies, and with less
confusing naming - will attach shortly

[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE

[marc.glisse at normalesup dot org]

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

--- Comment #9 from Marc Glisse  2011-02-25 
11:05:58 UTC ---
(In reply to comment #8)
> Ideally, we should figure in which release has been fixed. Do you think the
> small testcase in Comment #3 summarizes well the issue? Apparently works with
> 4.5.x too.

Honestly, I don't even know the rules about which namespace to consider in
overload resolution well enough to determine which behavior is correct. I
reported it years ago because of the inconsistency caused by unrelated code.
Then I tested today (the original test, not the short one from the comments)
and couldn't reproduce (and the result seemed to agree with EDG and Oracle).
Maybe I should have left it to someone more knowledgeable to close it...

[Bug c/47892] Fails to vectorize comparison code, if-conversion fails

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

[Bug c/47892] Fails to vectorize comparison code, if-conversion fails

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2011-02-25 
10:57:30 UTC ---
On trunk fixed with a patch as simple as

Index: gcc/tree-if-conv.c
===
*** gcc/tree-if-conv.c  (revision 170466)
--- gcc/tree-if-conv.c  (working copy)
*** if_convertible_stmt_p (gimple stmt, VEC
*** 702,707 
--- 702,711 
  case GIMPLE_ASSIGN:
return if_convertible_gimple_assign_stmt_p (stmt, refs);

+ case GIMPLE_CALL:
+   return (gimple_call_fndecl (stmt)
+ && (gimple_call_flags (stmt) & (ECF_PURE|ECF_CONST)));
+ 
  default:
/* Don't know what to do with 'em so don't do anything.  */
if (dump_file && (dump_flags & TDF_DETAILS))

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[burnus at gcc dot gnu.org]

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

--- Comment #25 from Tobias Burnus  2011-02-25 
10:57:32 UTC ---
I think the build bug is now FIXED; thus:

Please shout loudly if there you still encounter a build failure!


TO BE DONE: The HP-UX (et al.?) compile warning regarding the _r functions and
_REENTRANT, cf. comment 20 and comment 23.

[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2011-02-25 
10:54:37 UTC ---
Ideally, we should figure in which release has been fixed. Do you think the
small testcase in Comment #3 summarizes well the issue? Apparently works with
4.5.x too.

[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Marc Glisse  2011-02-25 
10:49:33 UTC ---
Can't reproduce with 4.6.

[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #26 from Richard Guenther  2011-02-25 
10:49:33 UTC ---
Works again.

[Bug lto/47871] lto1: internal compiler error: in list_length, at tree.c:2089

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-02-25 
10:48:55 UTC ---
It seems to work for me.  Can you double-check?

[Bug c++/47873] Multiple Inheritance - Covariant Virtual Function - Segfault

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-02-25 
10:47:00 UTC ---
do you think you could make the example more confusing? maybe if you named
every namespace, class and member function the same, instead of only doing that
for most of them? ;)

[Bug tree-optimization/47890] [4.5/4.6 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.25 10:42:33
   Target Milestone|--- |4.5.3
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-02-25 
10:42:33 UTC ---
Confirmed.

[Bug c++/46341] [C++0X] ICE: in cxx_eval_vec_init_1, at cp/semantics.c:6362

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Marc Glisse  2011-02-25 
10:42:04 UTC ---
I can't reproduce it anymore, it was likely fixed at the same time as one of
the other constexpr bugs.

[Bug c/47892] Fails to vectorize comparison code, if-conversion fails

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-02-25 
10:37:40 UTC ---
PRE makes that better and we have

:
  # i_39 = PHI 
  D.2691_6 = (long unsigned int) i_39;
  D.2692_7 = D.2691_6 * 4;
  D.2693_9 = arr_8(D) + D.2692_7;
  or_10 = MEM[(float *)D.2693_9];
  if (or_10 > 5.2359879016876220703125e-1)
goto ;
  else
goto ;

:
  orig_14 = or_10 * 3.33432674407958984375e-1;
  sqr_15 = __builtin_powf (orig_14, 2.0e+0);
  D.2699_19 = sqr_15 * 2.742018523349543102085590362548828125e-6;
  D.2700_20 = D.2699_19 + -1.98410343728028237819671630859375e-4;
  D.2701_21 = D.2700_20 * sqr_15;
  D.2702_22 = D.2701_21 + 8.32836627960205078125e-3;
  D.2703_23 = D.2702_22 * sqr_15;
  D.2704_24 = D.2703_23 + -1.667163372039794921875e-1;
  D.2705_25 = D.2704_24 * sqr_15;
  D.2706_26 = D.2705_25 + 1.0e+0;
  D.2707_27 = D.2706_26 * orig_14;
  D.2731_72 = __builtin_powf (D.2707_27, 2.0e+0);
  pretmp.11_75 = D.2731_72 * 4.0e+0;
  pretmp.11_77 = 2.0e+0 - pretmp.11_75;
  pretmp.11_81 = pretmp.11_77 + 1.0e+0;
  pretmp.11_83 = D.2707_27 * pretmp.11_81;

:
  # prephitmp.12_84 = PHI 
  MEM[(float *)D.2693_9] = prephitmp.12_84;
  i_47 = i_39 + 1;
  if (len_5(D) > i_47)
goto ;
  else
goto ;


if-conversion does not handle

  sqr_15 = __builtin_powf (orig_14, 2.0e+0);

which we produce as canonicalization of x * x with -funsafe-math-optimizations.

[Bug c/47892] Fails to vectorize comparison code, if-conversion fails

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-02-25 
10:31:49 UTC ---
Ok, we vectorize on trunk only if I only make the PIO6 float.  Otherwise
if-conversion does not handle (even with -fno-tree-pre)

  if (or_10 > 5.2359879016876220703125e-1)
goto ;
  else
goto ;

:
  orig_14 = or_10 * 3.33432674407958984375e-1;
  sqr_15 = __builtin_powf (orig_14, 2.0e+0);
  D.2699_19 = sqr_15 * 2.742018523349543102085590362548828125e-6;
  D.2700_20 = D.2699_19 + -1.98410343728028237819671630859375e-4;
  D.2701_21 = D.2700_20 * sqr_15;
  D.2702_22 = D.2701_21 + 8.32836627960205078125e-3;
  D.2703_23 = D.2702_22 * sqr_15;
  D.2704_24 = D.2703_23 + -1.667163372039794921875e-1;
  D.2705_25 = D.2704_24 * sqr_15;
  D.2706_26 = D.2705_25 + 1.0e+0;
  D.2707_27 = D.2706_26 * orig_14;

:
  # iftmp.1_3 = PHI <1.0e+0(5), 0.0(4)>
  # D.2707_59 = PHI 
  D.2713_41 = __builtin_powf (D.2707_59, 2.0e+0);
  D.2714_42 = D.2713_41 * 4.0e+0;
  D.2715_43 = 2.0e+0 - D.2714_42;
  D.2716_44 = D.2715_43 * iftmp.1_3;


I think if-conversion does not handle multiple PHIs in the merge block at all.

[Bug c/47892] Fails to vectorize comparison code, if-conversion fails

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-02-25 
10:24:21 UTC ---
Testcase:

#define PIO6 0.523598776f
#define SA5 2.74201854577e-06f
#define SA4 -1.98410347969e-04f
#define SA3 8.3320429e-03f
#define SA2 -1.666e-01f

void bestseries9(float * __restrict__ arr,int len) 
{
  int i;
  for(i=0; iPIO6);
  float sqr=orig*orig;
  arr[i]=orig*(1+sqr*(SA2+sqr*(SA3+sqr*(SA4+SA5*sqr;
  arr[i]=arr[i]*(1+(or>PIO6)*(2-4*arr[i]*arr[i]));
}
}

[Bug c/47892] Fails to vectorize comparison code, if-conversion fails

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.25 10:22:06
 CC||rguenth at gcc dot gnu.org,
   ||spop at gcc dot gnu.org
Summary|Fails to vectorize  |Fails to vectorize
   |comparison code |comparison code,
   ||if-conversion fails
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-02-25 
10:22:06 UTC ---
We vectorize on trunk with -fno-tree-pre and float constants.  Without
-fno-tree-pre if-conversion is confused and on the 4.5 branch it doesn't
if-convert

  if (or_10 > 5.2359879016876220703125e-1)
goto ;
  else
goto ;

:

:
  # iftmp.1_3 = PHI <1.0e+0(7), 0.0(6)>

[Bug c/47892] Fails to vectorize comparison code

[jeremysalwen at gmail dot com]

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

--- Comment #1 from jeremysalwen at gmail dot com 2011-02-25 10:19:58 UTC ---
Note, even when switching to floating point constants:

#define PIO6 0.523598776f

#define SA5 2.74201854577e-06f
#define SA4 -1.98410347969e-04f
#define SA3 8.3320429e-03f
#define SA2 -1.666e-01f

and adding the option -fno-tree-pre

it still won't vectorize

[Bug c/47892] New: Fails to vectorize comparison code

[jeremysalwen at gmail dot com]

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

   Summary: Fails to vectorize comparison code
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jeremysal...@gmail.com


I have the following function

#define PIO6 0.523598776

#define SA5 2.74201854577e-06
#define SA4 -1.98410347969e-04
#define SA3 8.3320429e-03
#define SA2 -1.666e-01

static void bestseries9(float * __restrict__ arr,int len) {
   for(int i=0; iPIO6);
  float sqr=orig*orig;
  arr[i]=orig*(1+sqr*(SA2+sqr*(SA3+sqr*(SA4+SA5*sqr;
  arr[i]=arr[i]*(1+(or>PIO6)*(2-4*arr[i]*arr[i]));
   }
}

which should be vectorized, but it is not.  If I turn on verbose vectorization,
it says that there is a conditional in the loop, and so it won't vectorize it.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

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

--- Comment #25 from Michael Haubenwallner  2011-02-25 09:53:57 UTC ---
Ohw, and then there is bug#47032 (caused by bug#46481) you might stumble upon
in libgfortran.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

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

--- Comment #24 from Michael Haubenwallner  2011-02-25 09:49:30 UTC ---
(In reply to comment #23)
> Using your suggestion for gmake bootstrap STAGE1_FLAGS=-0 gets me much 
> further in the build. The problem has moved to building libgomp, and the 
> failure appears to be due to the fact that AIX nm needs nm -B to be 
> compatible with the AIX ld.

This acutally looks like bug#33637.

[Bug c/47882] Incorrect "array subscript is above array bounds" warning

[anders at 0x63 dot nu]

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

--- Comment #2 from Anders Waldenborg  2011-02-25 
08:51:47 UTC ---
Is there a specific patch that fixes this problem? So I can backport the fix to
4.3.