[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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



--- Comment #12 from Jakub Jelinek  2013-03-12 
08:19:28 UTC ---

Wouldn't that mean that if you emit _ZTT* for the same class in multiple TUs in

one shared library and the _ZTT* references these static _ZTC* symbols, that

the construction vtables then couldn't be comdat and thus you'd have tons of

copies of them, wasting .data space as well as dynamic relocations?

[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"

[jamborm at gcc dot gnu.org]

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



--- Comment #6 from Martin Jambor  2013-03-12 
08:32:10 UTC ---

(In reply to comment #5)

> I can reproduce the failure with a i686-apple-darwin9 cross 

> to hppa2.0w-hp-hpux11.11.



Can you please attach -fdump-tree-ealias-slim and

-fdump-tree-esra-details dumps?  Thanks.

[Bug target/56586] ARM vfpv3: Not using FPU (vsqrt op) for sqrt() / sqrtf()

[rearnsha at gcc dot gnu.org]

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



Richard Earnshaw  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Richard Earnshaw  2013-03-12 
08:40:52 UTC ---

sqrt() and sqrtf() set errno when the input is invalid.  The compiler only

inlines these when -fno-math-errno is set (or one of the other compiler options

that enables this).

[Bug c/56600] New: loop goes indefinite when non-loop integer variable overflows

[mskyeong at naver dot com]

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



 Bug #: 56600

   Summary: loop goes indefinite when non-loop integer variable

overflows

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mskye...@naver.com





Created attachment 29648

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29648

intermediate file



Hi, the following code compiles to infinite loop specifically with -O2 on gcc

4.7.2.



#include 



int main (int nargs, char** vargs){

int i=0x7ffd;

int j=0;

for (j=0; j<4; ++j){

++i;

printf("%i ",i>0);

//printf("%i ",j);

printf("%i\n",i);

}

return 0;

}



This may seem related to bug 52833, but it is actually quite different.



With -O1, the output is as expected.



1 2147483646

1 2147483647

0 -2147483648

0 -2147483647



With -O3, I assume the expression 'i>0' replaced with 1 and the loop was

unrolled. i>0 being 1 is no problem, as overflow is an undefined behavior.



1 2147483646

1 2147483647

1 -2147483648

1 -2147483647



But with -O2, it starts as above, and then goes on indefinitely! Since the loop

variable j is not overflowing or modified anywhere else, I think that this bug

may have serious implications on loop optimization. j is falsely being ignored.

Therefore I marked this bug as major.



Moreover, the result becomes the same as -O3 when (1) the printf line is

uncommented, and/or (2) i does not overflow.





FINDINGS:



the intermediate file is exactly the same with all of -O1, -O2 and -O3.



infinite loop does not happen on an older version of gcc (4.4.6).





CONDITIONS:



CPU: Intel i7-2620M (laptop)

gcc.x86_64 version 4.7.2-2.fc17 from Fedora repository

kernel 3.7.9-104.fc17.x86_64



$ gcc -v -O2 bug.c

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper

Target: x86_64-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 --disable-build-with-cxx

--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-gnu-unique-object

--enable-linker-build-id --with-linker-hash-style=gnu

--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin

--enable-initfini-array --enable-java-awt=gtk --disable-dssi

--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_32=i686

--build=x86_64-redhat-linux

Thread model: posix

gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-O2' '-mtune=generic' '-march=x86-64'

 /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1 -quiet -v bug.c -quiet

-dumpbase bug.c -mtune=generic -march=x86-64 -auxbase bug -O2 -version -o

/tmp/ccYIOd07.s

GNU C (GCC) version 4.7.2 20120921 (Red Hat 4.7.2-2) (x86_64-redhat-linux)

compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version

5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

ignoring nonexistent directory

"/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include-fixed"

ignoring nonexistent directory

"/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../x86_64-redhat-linux/include"

#include "..." search starts here:

#include <...> search starts here:

 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include

 /usr/local/include

 /usr/include

End of search list.

GNU C (GCC) version 4.7.2 20120921 (Red Hat 4.7.2-2) (x86_64-redhat-linux)

compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version

5.0.2, MPFR version 3.1.0, MPC version 0.9

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiler executable checksum: 1ddc7c1a4fba2159f711c3e228ac3970

COLLECT_GCC_OPTIONS='-v' '-O2' '-mtune=generic' '-march=x86-64'

 as -v --64 -o /tmp/ccq8Xual.o /tmp/ccYIOd07.s

GNU assembler version 2.22.52.0.1 (x86_64-redhat-linux) using BFD version

version 2.22.52.0.1-10.fc17 20120131

COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/:/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/:/usr/lib/gcc/x86_64-redhat-linux/

LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.7.2/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../:/lib/:/usr/lib/

COLLECT_GCC_OPTIONS='-

[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure

[jamborm at gcc dot gnu.org]

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



--- Comment #22 from Martin Jambor  2013-03-12 
09:09:12 UTC ---

Indeed, bootstrap with BOOT_CFLAGS='-O2 -g -fno-ipa-sra' now finally

passes.  Thanks!

[Bug c/56600] loop goes indefinite when non-loop integer variable overflows

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

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



Andreas Schwab  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Andreas Schwab  2013-03-12 09:10:33 
UTC ---

Integer overflow is causing undefined behaviour.  If you want wraparound

semantics either use unsigned int or -fwrapv.

[Bug rtl-optimization/56598] At -Os basic blocks are not properly re-ordered to avoid fallthru jumps

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||missed-optimization

 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0

Summary|Optimizer can't invert  |At -Os basic blocks are not

   |conditional when inlining a |properly re-ordered to

   |bool function   |avoid fallthru jumps



--- Comment #1 from Richard Biener  2013-03-12 
09:34:23 UTC ---

The blocks simply happen to be ordered differently on the GIMPLE level,

for some reason with -Os that ordering persists and with -O[23] the ordering

is reverted to make the appearantly more likely path the fallthru one.



The bug is that for -Os the fallthru paths are not avoided.



This works on trunk though, so - fixed.



_Z5func1j:

.LFB1:

.cfi_startproc

pushq   %rbx

.cfi_def_cfa_offset 16

.cfi_offset 3, -16

movl%edi, %ebx

movl$.LC0, %edi

callputs

cmpl$9, %ebx

jbe .L2

movl%ebx, %eax

andl$7, %eax

decl%eax

jne .L2

movl$.LC2, %edi

callputs

.L2:

movl$.LC1, %edi

callputs

leal1(%rbx), %eax

popq%rbx

   .cfi_def_cfa_offset 8

ret



_Z5func2j:

.LFB2:

.cfi_startproc

pushq   %rbx

.cfi_def_cfa_offset 16

.cfi_offset 3, -16

movl%edi, %ebx

movl$.LC0, %edi

callputs

cmpl$9, %ebx

jbe .L8

movl%ebx, %eax

andl$7, %eax

decl%eax

jne .L8

movl$.LC2, %edi

callputs

.L8:

movl$.LC1, %edi

callputs

leal1(%rbx), %eax

popq%rbx

.cfi_def_cfa_offset 8

ret

[Bug c/56600] loop goes indefinite when non-loop integer variable overflows

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-03-12 
09:35:38 UTC ---

Related to PR53265, where gcc 4.8+ could warn about this case.

[Bug c++/56597] unaligned local variable used by implicit sse instructions

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Target||mingw*

 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-03-12

 CC||ktietz at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-03-12 
09:38:13 UTC ---

"but when I try to run a test program compiled by VC++ that use the Dlls

compiled by gcc"



so I assume this is on mingw32/64.  Which means that whatever ABI is

in effect is either violated by VC++ or by GCC.



CCing win target maintainers.  Please resolve whether this is a GCC or

a VC++ bug.

[Bug rtl-optimization/56598] At -Os basic blocks are not properly re-ordered to avoid fallthru jumps

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-03-12 
09:49:07 UTC ---

Surprisingly it is reordered by LRA, with targetm.lra_p = hook_bool_void_false;

the problem still exists.  Note that for -Os I think it is a bug, because it

generates longer code, but for other optimization levels it can be fine,

depending on the bb predictions.  The numbers for those are slightly different

between the macro version and inline version.

[Bug lto/56578] Testcase behaves differently when compiled with LTO

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||wrong-code

 Status|WAITING |NEW

 CC||hubicka at gcc dot gnu.org,

   ||rguenth at gcc dot gnu.org

  Known to fail||4.6.4, 4.7.3, 4.8.0



--- Comment #3 from Richard Biener  2013-03-12 
09:51:51 UTC ---

Thanks.  With fixing the size_t issues of the testcase I can reproduce it

on x86_64 as well (original testcase reproduces with -m32).



We could say the bug is in the testcase.  Failing is:



gcc-4.8 -B /abuild/rguenther/trunk-g/gcc -flto -c func.c -o a.o

ar --plugin=/abuild/rguenther/trunk-g/gcc/liblto_plugin.so -cr libxxx.a a.o

gcc-4.8 -B /abuild/rguenther/trunk-g/gcc -flto main.c libxxx.a -o prog3

./prog3

FAIL



that's because you are providing an implementation of malloc in libxxx.a a.o

from func.c that does not have the C standards semantics.  You have to

compile this module with -fno-builtin-malloc (or -fno-builtins).



Honza: I believe we _should_ tell the linker that we have a definition of

malloc available, even if it is a "builtin".  That is, the testcase should

work as it is clearly well-defined on the linker side (setting aside that

GCC might still optimize the result in an unexpected way because it can

rely on malloc/free semantics).



Thus, confirmed as a bug in LTO symtab handling.

[Bug bootstrap/56601] New: OpenBSD lto-plugin fails to use

[m...@waldemar-brodkorb.de]

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



 Bug #: 56601

   Summary: OpenBSD lto-plugin fails to use

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m...@waldemar-brodkorb.de





Hi,



I am using OpenBSD 5.2 amd64 and try to use OpenWrt to build a cross-compiler.

This works fine on FreeBSD/Darwin and Linux, but fails on OpenBSD with

following

error message:



arm-openwrt-linux-uclibcgnueabi-gcc: fatal error: -fuse-linker-plugin, but

liblto_plugin.so not found

compilation terminated.



Indeed a liblto_plugin.so is not build, instead there is liblto_plugin.so.0.0



gmake[5]: Entering directory

`/home/wbx/openwrt/build_dir/toolchain-arm_v6k_gcc-

4.7.2_uClibc-0.9.33.2_eabi/gcc-4.7.2-initial/lto-plugin'

gmake[6]: Entering directory

`/home/wbx/openwrt/build_dir/toolchain-arm_v6k_gcc-

4.7.2_uClibc-0.9.33.2_eabi/gcc-4.7.2-initial/lto-plugin'

test -z

"/home/wbx/openwrt/staging_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc-0.9.33

.2_eabi/initial/libexec/gcc/arm-openwrt-linux-uclibcgnueabi/4.7.2" ||

/usr/local

/bin/gmkdir -p

"/home/wbx/openwrt/staging_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc

-0.9.33.2_eabi/initial/libexec/gcc/arm-openwrt-linux-uclibcgnueabi/4.7.2"

 /bin/sh ./libtool --tag=disable-static  --mode=install /usr/bin/install -c  

li

blto_plugin.la

'/home/wbx/openwrt/staging_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc

-0.9.33.2_eabi/initial/libexec/gcc/arm-openwrt-linux-uclibcgnueabi/4.7.2'

libtool: install: /usr/bin/install -c .libs/liblto_plugin.so.0.0

/home/wbx/openw

rt/staging_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc-0.9.33.2_eabi/initial/libexec/

gcc/arm-openwrt-linux-uclibcgnueabi/4.7.2/liblto_plugin.so.0.0

libtool: install: /usr/bin/install -c .libs/liblto_plugin.lai

/home/wbx/openwrt/

staging_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc-0.9.33.2_eabi/initial/libexec/gcc

/arm-openwrt-linux-uclibcgnueabi/4.7.2/liblto_plugin.la

libtool: install: warning: remember to run `libtool --finish

/home/wbx/openwrt/s

taging_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc-0.9.33.2_eabi/libexec/gcc/arm-open

wrt-linux-uclibcgnueabi/4.7.2'



gcc is configured:

(cd

/home/wbx/openwrt/build_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc-0.9.33.2_eabi/gcc-4.7.2-minimal

&& rm -f config.cache; SHELL="/usr/local/bin/bash"

/home/wbx/openwrt/build_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc-0.9.33.2_eabi/gcc-4.7.2/configure

--prefix=/home/wbx/openwrt/staging_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc-0.9.33.2_eabi

--build=amd64-unknown-openbsd5.2 --host=amd64-unknown-openbsd5.2

--target=arm-openwrt-linux-uclibcgnueabi --with-gnu-ld --enable-target-optspace

--disable-libgomp --disable-libmudflap --disable-multilib --disable-nls 

--with-host-libstdcxx=-lstdc++  

--with-gmp=/home/wbx/openwrt/staging_dir/host

--with-mpfr=/home/wbx/openwrt/staging_dir/host --disable-decimal-float

--disable-libssp --disable-__cxa_atexit --with-arch=armv6k --with-newlib

--without-headers --enable-languages=c --disable-libssp --disable-shared

--disable-threads );



Complete build log is attached.



Any idea what goes wrong here?



Creating a symlink doesn't help.



thanks in advance for any hint.

 Waldemar

[Bug rtl-optimization/56598] At -Os basic blocks are not properly re-ordered to avoid fallthru jumps

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|RESOLVED|NEW

   Last reconfirmed||2013-03-12

 Resolution|FIXED   |

   Target Milestone|4.8.0   |---

 Ever Confirmed|0   |1



--- Comment #3 from Richard Biener  2013-03-12 
09:53:51 UTC ---

Let's re-open this then.  Not sure what pass is responsible for basic-block

reordering at -Os (bbreorder doesn't run, but -freorder-blocks doesn't fix it

either).

[Bug bootstrap/56601] OpenBSD lto-plugin fails to use

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-03-12

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-03-12 
10:01:43 UTC ---

GCC doesn't find LTOPLUGINSONAME in the set of exec prefix paths.  That's

created from the config.host entry for host_lto_plugin_soname which is

liblto_plugin.so by default.



Add -v to the command to see which paths are searched for executables

(and the plugin).  Trace the driver with strace to see which files

it tries to open (yes, you do need the symlink).  Also make sure the

plugin is readable/executable by you.



Note that you need the plugin for the _host_, not sure if we messed up

things for cross-compilers (I never tried LTO with a cross ...)

[Bug bootstrap/56601] OpenBSD lto-plugin fails to use

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-03-12 
10:19:43 UTC ---

Seems to work for me with a quick test targeting arm-linux-gnueabi

[Bug bootstrap/56601] OpenBSD lto-plugin fails to use

[m...@waldemar-brodkorb.de]

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



--- Comment #4 from m...@waldemar-brodkorb.de 2013-03-12 10:25:23 UTC ---

Hi,



thanks for the fast response.

I ktrace't the driver and the log is here:

http://www.waldemar-brodkorb.de/kdump



30611 arm-openwrt-linu NAMI 

"/home/wbx/openwrt/staging_dir/toolchain-arm_v6k_gcc-4.7.2_uClibc-0.9.33.2_eabi/libexec/gcc/arm-openwrt-linux-uclibcgnueabi/4.7.2/liblto_plugin.so"



It searches not in the source directory. That was my mistake. 



Creating the symlinks in staging_dir does help.



So where does it creates the wrong filename? 



thanks

 Waldemar

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[rguenth at gcc dot gnu.org]

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



--- Comment #46 from Richard Biener  2013-03-12 
10:46:45 UTC ---

Created attachment 29649

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29649

symmetry in reference testing



Exploit symmetry in reference testing.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



  Attachment #29639|0   |1

is obsolete||



--- Comment #14 from Jakub Jelinek  2013-03-12 
11:25:01 UTC ---

Created attachment 29650

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29650

gcc48-pr53265.patch



The last patch was missing == INTEGER_CST.  Still, this patch doesn't even

bootstrap, I'll attach here various snippets that need investigations.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



--- Comment #15 from Jakub Jelinek  2013-03-12 
11:26:15 UTC ---

Created attachment 29651

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29651

X2



Incremental debugging hack.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  2013-03-12 
11:30:02 UTC ---
First issue is (with -Werror -O2) error on attribs.c.  Reduced testcase:
const void *a, *b, *c, *d, *e;
const void *f[4];
void
foo (void)
{
  unsigned long i;
  f[0] = a; f[1] = b; f[2] = c; f[3] = d;
  for (i = 0; i < (sizeof (f) / sizeof (f[0])); i++)
if (f[i] == __null)
  f[i] = e;
}

In function ‘void foo()’:
cc1plus: warning: iteration 3ul invokes undefined behavior
[-Waggressive-loop-optimizations]
/tmp/attribs.ii:8:3: note: containing loop
   for (i = 0; i < (sizeof (f) / sizeof (f[0])); i++)
   ^

We'd better not have false positives on testcases as simple as this.

[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX

[ebotcazou at gcc dot gnu.org]

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



--- Comment #7 from Eric Botcazou  2013-03-12 
11:37:27 UTC ---

> This patch adds expand_args to track library calls to

> expend arguments.  We add vzeroupper when expand_args == 1,

> which indicates we are expanding the actual function.



This looks complicated.  A simpler approach could be to record the AVX state in

the CUMULATIVE_ARGS structure and transfer it to cfun->machine only at the end

of the argument processing.  Comments and code in calls.c appear to guarantee

that



  targetm.calls.function_arg (&args_so_far, VOIDmode, void_type_node, true)



is invoked immediately before the call instruction is emitted.

[Bug target/56263] [avr] Provide strict address-space checking

[gjl at gcc dot gnu.org]

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



--- Comment #6 from Georg-Johann Lay  2013-03-12 
11:42:30 UTC ---

Author: gjl

Date: Tue Mar 12 11:42:26 2013

New Revision: 196611



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196611

Log:

PR target/56263

* config/avr/avr.c (TARGET_CONVERT_TO_TYPE): Define to...

(avr_convert_to_type): ...this new static function.

* config/avr/avr.opt (-Waddr-space-convert): New C option.

* doc/invoke.texi (AVR Options): Document it.





Modified:

trunk/gcc/config/avr/avr.c

trunk/gcc/config/avr/avr.opt

trunk/gcc/doc/invoke.texi

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



--- Comment #17 from Jakub Jelinek  2013-03-12 
11:48:09 UTC ---

Second issue is from caller-save.c (setup_save_areas), again -Werror -O2:



int a, b[53][5], c[53][5];

int bar (void);



void

foo (void)

{

  int i, j, k;

  for (i = 0; i < 53; i++)

for (j = 16 / (((a & 1) != 0) ? 8 : 4); j > 0; j--)

  {

int d = 1;

if (b[i][j] == 0 || c[i][1] != 0)

  continue;

for (k = 0; k < j; k++)

  if (c[i + k][1])

{

  d = 0;

  break;

}

if (!d)

  continue;

c[i][j] = bar ();

  }

}



The problem I have in this testcase is that the undefined behavior isn't known

to happen unconditionally, b or c array content upon entry might very well

prevent it from happening.  So, if we want to warn for those, we'd need to have

two levels of the warning, one enabled perhaps by default, that hopefully

shouldn't have any false positives, and one with a different wording, enabled

perhaps by -Wall or even just -Wextra that would just say that iteration N may

trigger undefined behavior.  Haven't tried to find out if any target could have

problems there.

[Bug rtl-optimization/56571] [4.7/4.8 Regression] ICE in copyprop_hardreg_forward_1, at regcprop.c (insn does not satisfy its constraints !)

[hubicka at gcc dot gnu.org]

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



--- Comment #5 from Jan Hubicka  2013-03-12 
12:13:44 UTC ---

Author: hubicka

Date: Tue Mar 12 12:13:33 2013

New Revision: 196612



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196612

Log:

PR middle-end/56571

* valtrack.c (cleanup_auto_inc_dec): Unshare clobbers originating

from pseudos.

* emit-rtl.c (verify_rtx_sharing): Likewise.

(copy_insn_1): Likewise.

* rtl.c (copy_rtx): Likewise.

PR middle-end/56571

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



Added:

trunk/gcc/testsuite/gcc.c-torture/compile/pr56571.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/emit-rtl.c

trunk/gcc/rtl.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/valtrack.c

[Bug rtl-optimization/56571] [4.7/4.8 Regression] ICE in copyprop_hardreg_forward_1, at regcprop.c (insn does not satisfy its constraints !)

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||hubicka at gcc dot gnu.org

 Resolution||FIXED



--- Comment #6 from Jan Hubicka  2013-03-12 
12:15:16 UTC ---

Fixed.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  2013-03-12 
12:35:59 UTC ---
There is also a problem in unwind-dw2.c, but that looks like something we
should probably fix:
../../../libgcc/unwind-dw2.c: In function ‘execute_cfa_program’:
../../../libgcc/unwind-dw2.c:1133:30: warning: iteration 2ul invokes undefined
behavior [-Waggressive-loop-optimizations]
fs->regs.reg[reg].how = REG_SAVED_OFFSET;
  ^
../../../libgcc/unwind-dw2.c:1131:4: note: containing loop
for (reg = 16; reg < 32; ++reg)
^

case DW_CFA_GNU_window_save:
  /* ??? Hardcoded for SPARC register window configuration.  */
  for (reg = 16; reg < 32; ++reg)
{
  fs->regs.reg[reg].how = REG_SAVED_OFFSET;
  fs->regs.reg[reg].loc.offset = (reg - 16) * sizeof (void *);
}
  break;

but DWARF_FRAME_REGISTERS is 17 on x86_64/i386, so reg[17] is still ok, but
reg[18] is undefined behavior.  Of course it doesn't matter much, because
DW_CFA_GNU_window_save isn't used on non-SPARC, but perhaps we could use
for (reg = 16; reg < MIN (32, DWARF_FRAME_REGISTERS + 1); ++reg)
or similar (I think it wouldn't generate worst code on SPARC, because it would
be still constant folded to 32 there, and to 18 on ix86_64 etc.

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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



--- Comment #13 from Jan Hubicka  2013-03-12 
12:38:54 UTC ---

Author: hubicka

Date: Tue Mar 12 12:38:47 2013

New Revision: 196613



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196613

Log:

PR lto/56557

* lto-streamer-out.c (output_symbol_p): Skip references from

constructors of external variables.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/lto-streamer-out.c

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



--- Comment #19 from Jakub Jelinek  2013-03-12 
12:40:54 UTC ---

On:

int a[18];



void

foo (void)

{

  int i;

  for (i = 16; i < 32; i++)

a[i] = 26;

}

distilled from unwind-dw2.c, I'm just surprised that at -O2

the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265#c15

debugging hack reports that we are in some cases increasing the number of

iterations from 2 to 16, but later on from 1 to 15?  Have we peeled one

iteration or what happened?

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org



--- Comment #35 from Jan Hubicka  2013-03-12 
12:42:34 UTC ---

Jason,

I am still bit confused how keyed construction vtables are supposed to work. 

If I understand it right, and there is no C++ ABI mangling for those, I think

it makes no sense to export them from the unit they are keyed to, since the

other units can not referr them anyway.



So perhaps the construction vtables should be always comdat hidden?

[Bug lto/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



  Component|libstdc++   |lto



--- Comment #14 from Jan Hubicka  2013-03-12 
12:53:17 UTC ---

This is the LTO symbol table I get out of the testcase now:

 U _ZNSdC2Ev

 U _ZNSdD1Ev

 U _ZNSdD2Ev

 U _ZNSiC2Ev

 U _ZNSiD1Ev

 U _ZNSiD2Ev

 U _ZNSoC2Ev

 U _ZNSoD1Ev

 U _ZNSoD2Ev

 U _ZNSt12__basic_fileIcED1Ev

 U _ZNSt13basic_filebufIcSt11char_traitsIcEE5closeEv

 U _ZNSt13basic_filebufIcSt11char_traitsIcEEC1Ev

 U _ZNSt13basic_filebufIcSt11char_traitsIcEED1Ev

 U _ZNSt13basic_fstreamIcSt11char_traitsIcEEC1Ev

 U _ZNSt13basic_fstreamIcSt11char_traitsIcEED1Ev

 U _ZNSt15basic_streambufIcSt11char_traitsIcEED1Ev

 U _ZNSt15basic_streambufIcSt11char_traitsIcEED2Ev

 U _ZNSt6localeD1Ev

 U _ZNSt8ios_baseC2Ev

 U _ZNSt8ios_baseD2Ev

 U _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E

 U _ZNSt9basic_iosIcSt11char_traitsIcEEC2Ev

 U _ZNSt9basic_iosIcSt11char_traitsIcEED1Ev

 U _ZNSt9basic_iosIcSt11char_traitsIcEED2Ev

 U _ZTTSd

 U _ZTTSt13basic_fstreamIcSt11char_traitsIcEE

 U _ZTVSd

 U _ZTVSi

 U _ZTVSo

 U _ZTVSt13basic_filebufIcSt11char_traitsIcEE

 U _ZTVSt13basic_fstreamIcSt11char_traitsIcEE

 U _ZTVSt15basic_streambufIcSt11char_traitsIcEE

 U _ZTVSt9basic_iosIcSt11char_traitsIcEE

 U _ZdlPv

 U __gxx_personality_v0

 T main



So still quite a bit more than w/o LTO:



 U _ZNSt13basic_fstreamIcSt11char_traitsIcEEC1Ev

 U _ZNSt13basic_fstreamIcSt11char_traitsIcEED1Ev

0001 C __gnu_lto_v1

 T main



but the construction vtable is no longer on the list. Those extra symbols are

from virtual functions we hold for possible devirtualization.

We ought to make sure that linkers optimize out the dynamic table entries after

we are done with optimizing them out

[Bug lto/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[hubicka at gcc dot gnu.org]

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



--- Comment #15 from Jan Hubicka  2013-03-12 
13:00:11 UTC ---



Filled in binutils PR http://sourceware.org/bugzilla/show_bug.cgi?id=15270

[Bug c++/56312] Firefox 20.0a1 compilation with enabled LTO fails

[hubicka at gcc dot gnu.org]

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



--- Comment #5 from Jan Hubicka  2013-03-12 
13:03:36 UTC ---

Sadly this problem does not reproduce to me (though I use -fno-fat-lto-objects

that makes the build quite a bit faster).  Can you please upload for me the

files produced by --save-temps -fdump-ipa-all and in gdb output the symbol

passed to can_refer_decl_in_current_unit_p?

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



  Attachment #28931|0   |1

is obsolete||



--- Comment #4 from Marc Glisse  2013-03-12 13:04:28 
UTC ---

Created attachment 29652

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29652

Use tree code to determine the canonical order (2)



With this slight tweak to simplify_associative_operation it now passes

bootstrap+testsuite on x86_64-linux-gnu, both in this order and the reverse

order. I am not sure it is the best way to break the infinite recursion, but it

seems to work.

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[jason at gcc dot gnu.org]

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



--- Comment #36 from Jason Merrill  2013-03-12 
13:05:52 UTC ---

(In reply to comment #35)

> I am still bit confused how keyed construction vtables are supposed to work. 

> If I understand it right, and there is no C++ ABI mangling for those, I think

> it makes no sense to export them from the unit they are keyed to, since the

> other units can not refer them anyway.



Right.



> So perhaps the construction vtables should be always comdat hidden?



Hmm?  My earlier patch made them hidden, and they were already comdat.  Do you

mean something else?

[Bug c++/56597] unaligned local variable used by implicit sse instructions

[kruglinski at gmail dot com]

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



--- Comment #3 from jjwang  2013-03-12 13:24:15 
UTC ---

(In reply to comment #2)

> "but when I try to run a test program compiled by VC++ that use the Dlls

> compiled by gcc"

> 

> so I assume this is on mingw32/64.  Which means that whatever ABI is

> in effect is either violated by VC++ or by GCC.

> 

> CCing win target maintainers.  Please resolve whether this is a GCC or

> a VC++ bug.



This problem are very clear, mingw/gcc 4.7.2 generate implicit SSE2

instructions that require alignment and gcc just leave everything as it is,

then VC++ does not aligns the program's stack and call to the DLLs(shared

library in windows) produced by GCC, finally the program crashed!



In my view I think even VC++ does not aligns the stack, the function exported

by a DLL that compiled by GCC should self-aligned not just leave things as it

is, Specifically when GCC decide to use the vector instructions that require

alignment(just like SSE2), and users never realized it!



I think the bottom line is "program can't just crashed!"



ps:

follow Jakub Jelinek's says I add "-mstackrealign" option, the issue is gone,

so Strictly speaking it can't be a bug, just a Potential issue.



regards



03-12-2013 jjwang

[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

  Component|lto |libstdc++

 Resolution||FIXED



--- Comment #16 from Jakub Jelinek  2013-03-12 
13:29:35 UTC ---

I've verified Honza's patch fixed the problem.

[Bug lto/56578] Testcase behaves differently when compiled with LTO

[d.g.gorbachev at gmail dot com]

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



--- Comment #4 from Dmitry Gorbachev  
2013-03-12 13:30:30 UTC ---

> We could say the bug is in the testcase.  Failing is:

[...]

> that's because you are providing an implementation of

> malloc in libxxx.a a.o from func.c that does not have

> the C standards semantics.



The TC is invalid but it is not buggy, gcc-nm could not even find the "malloc"

symbol in a.o



> You have to compile this module with -fno-builtin-malloc

> (or -fno-builtins).



It is not enough to compile just func.c with -fno-builtin(-malloc), as one

might expect. I have to use it for main.c as well.



> GCC might still optimize the result in an unexpected way

> because it can rely on malloc/free semantics



There is a "volatile" modifier in the TC. It should inhibit such optimizations,

I think?

[Bug c++/56312] Firefox 20.0a1 compilation with enabled LTO fails

[marxin.liska at gmail dot com]

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

--- Comment #6 from Martin Liška  2013-03-12 
13:31:06 UTC ---
Hello Jan, there's a link to dump:

https://mega.co.nz/#!bBF3kBSI!JPkMhRtHgUAx_lUw-VctVB0llul3BSrad2dpF9_6yJQ
(extracted size is about 16GB)

Could you please paste your .mozconfig file and version of binutils you used
for build?

Thanks

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[hubicka at ucw dot cz]

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



--- Comment #37 from Jan Hubicka  2013-03-12 13:32:15 
UTC ---

> > So perhaps the construction vtables should be always comdat hidden?

> 

> Hmm?  My earlier patch made them hidden, and they were already comdat.  Do you

> mean something else?

What I see in the testcase from PR56557 is

_ZTCSt13basic_fstreamIcSt11char_traitsIcEE0_Sd/443 (int (*

std::basic_fstream::_ZTCSt13basic_fstreamIcSt11char_traitsIcEE0_Sd

[15])(...)) @0x7fa754fda3a8

  Type: variable

  Visibility: external public visibility_specified visibility:hidden virtual

artificial

  Aux: @0x7fa754fda410  References: _ZTISd/446 (addr)_ZNSdD1Ev/233

(addr)_ZNSdD0Ev/234 (addr)_ZTISd/446 (addr)_ZThn16_NSdD1Ev/447

(addr)_ZThn16_NSdD0Ev/448 (addr)_ZTISd/446 (addr)_ZTv0_n24_NSdD1Ev/449

(addr)_ZTv0_n24_NSdD0Ev/450 (addr)

  Referring: _ZTTSt13basic_fstreamIcSt11char_traitsIcEE/403

(addr)_ZTTSt13basic_fstreamIcSt11char_traitsIcEE/403

(addr)_ZTTSt13basic_fstreamIcSt11char_traitsIcEE/403 (addr)

  Availability: not-ready

  Varpool flags: initialized analyzed finalized



I.e. it is not COMDAT, but I see it can not be because the class is explicitely

instantiated the

the vtable may refer to stuff that is hidden in libstdc++.



The matching definition in fstream-inst.o is indeed COMDAT:



_ZTCSt13basic_fstreamIcSt11char_traitsIcEE0_Sd/862 (int (*

std::basic_fstream::_ZTCSt13basic_fstreamIcSt11char_traitsIcEE0_Sd

[15])(...)) @0x7fd19064ca28

  Type: variable

  Visibility: force_output public weak comdat

comdat_group:_ZTVSt13basic_fstreamIcSt11char_traitsIcEE one_only

visibility_specified visibility:hidden virtual artificial

  Same comdat group as: _ZTTSt13basic_fstreamIcSt11char_traitsIcEE/861

  Aux: @0x7fd19064ca90  References: _ZTISd/1138 (addr)_ZNSdD1Ev/722

(addr)_ZNSdD0Ev/723 (addr)_ZTISd/1138 (addr)_ZThn16_NSdD1Ev/1139

(addr)_ZThn16_NSdD0Ev/1140 (addr)_ZTISd/1138 (addr)_ZTv0_n24_NSdD1Ev/1141

(addr)_ZTv0_n24_NSdD0Ev/1142 (addr)

  Referring: _ZTTSt13basic_fstreamIcSt11char_traitsIcEE/861

(addr)_ZTTSt13basic_fstreamIcSt11char_traitsIcEE/861

(addr)_ZTTSt13basic_fstreamIcSt11char_traitsIcEE/861 (addr)

  Availability: not-ready

  Varpool flags: initialized analyzed finalized



I assumed it to be public...  So I suppose there is no way to write constructor

of fstream that would not be linked

into libstdc++.so but that is how it is intended to work...



Honza

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[jason at gcc dot gnu.org]

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



--- Comment #38 from Jason Merrill  2013-03-12 
14:03:05 UTC ---

(In reply to comment #37)

> I assumed it to be public...  So I suppose there is no way to write 
> constructor

> of fstream that would not be linked into libstdc++.so but that is how it is

> intended to work...



Other places could emit constructors (just not the VTT).  But they won't,

because of the extern explicit instantiation.

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[rguenth at gcc dot gnu.org]

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



--- Comment #47 from Richard Biener  2013-03-12 
14:05:10 UTC ---

With caching affine-combination compute and ao_ref compute I have it down to



 tree loop invariant motion: 596.91 (79%) usr   0.73 (29%) sys 599.77 (78%)

wall   31135 kB ( 3%) ggc



without limiting anything.  I tried a more intelligent ref_indep_in_loop

(avoiding another quadraticness in loop depth ...) but it gets slower ...



*** ref_indep_loop_p_1 (struct loop *loop, m

*** 2230,2242 

bitmap refs_to_check;

unsigned i;

bitmap_iterator bi;

!   bool ret = true, stored = bitmap_bit_p (ref->stored, loop->num);

mem_ref_p aref;



!   if (stored)

! refs_to_check = memory_accesses.all_refs_in_loop[loop->num];

else

! refs_to_check = memory_accesses.all_refs_stored_in_loop[loop->num];



EXECUTE_IF_SET_IN_BITMAP (refs_to_check, 0, i, bi)

  {

--- 2233,2245 

bitmap refs_to_check;

unsigned i;

bitmap_iterator bi;

!   bool ret = true;

mem_ref_p aref;



!   if (bitmap_bit_p (ref->stored, loop->num))

! refs_to_check = memory_accesses.refs_in_loop[loop->num];

else

! refs_to_check = memory_accesses.refs_stored_in_loop[loop->num];



EXECUTE_IF_SET_IN_BITMAP (refs_to_check, 0, i, bi)

  {

*** ref_indep_loop_p_1 (struct loop *loop, m

*** 2259,2272 

  static bool

  ref_indep_loop_p (struct loop *loop, mem_ref_p ref)

  {

-   bool ret;

-

if (bitmap_bit_p (ref->indep_loop, loop->num))

  return true;

if (bitmap_bit_p (ref->dep_loop, loop->num))

  return false;



!   ret = ref_indep_loop_p_1 (loop, ref);



if (dump_file && (dump_flags & TDF_DETAILS))

  fprintf (dump_file, "Querying dependencies of ref %u in loop %d: %s\n",

--- 2262,2286 

  static bool

  ref_indep_loop_p (struct loop *loop, mem_ref_p ref)

  {

if (bitmap_bit_p (ref->indep_loop, loop->num))

  return true;

if (bitmap_bit_p (ref->dep_loop, loop->num))

  return false;



!   bool ret = true;

!   struct loop *inner = loop->inner;

!   while (inner)

! {

!   if (!ref_indep_loop_p (inner, ref))

!   {

! ret = false;

! break;

!   }

!   inner = inner->next;

! }

!

!   if (ret)

! ret = ref_indep_loop_p_1 (loop, ref);



if (dump_file && (dump_flags & TDF_DETAILS))

  fprintf (dump_file, "Querying dependencies of ref %u in loop %d: %s\n",





with it we can also get rid of the all_refs_in_loop bitmap (only

all_refs_stored_in_loop is then used, by store-motion).



I don't see why the above should result in slower operation :/  It should

save us the time to re-query references in sub-loops (yes, they should

be cached already ... still walking the bitmap is not free).



To mimic parts of this idea the dep_loop/indep_loop checking/setting can

be improved to cover outer loops like with



@@ -2296,7 +2218,12 @@ record_indep_loop (struct loop *loop, me

   if (indep)

 bitmap_set_bit (ref->indep_loop, loop->num);

   else

-bitmap_set_bit (ref->dep_loop, loop->num);

+do

+  {

+   bitmap_set_bit (ref->dep_loop, loop->num);

+   loop = loop_outer (loop);

+  }

+while (loop != current_loops->tree_root);

 }



and



@@ -2339,8 +2266,13 @@ ref_indep_loop_p (struct loop *loop, mem

 {

   bool ret;



-  if (bitmap_bit_p (ref->indep_loop, loop->num))

-return true;

+  struct loop *oloop = loop;

+  do

+{

+  if (bitmap_bit_p (ref->indep_loop, oloop->num))

+   return true;

+  oloop = loop_outer (oloop);

+}

+  while (oloop != current_loops->tree_root);

   if (bitmap_bit_p (ref->dep_loop, loop->num))

 return false;



(no difference in compile-time)



anyway, another obvious improvement is to merge the two two-bitmap

sets (they are tri-state, dependent, independent and unknown).  That's

more cache-friendly (now, where's that tri-state "bitmap" implementation

that also saves the half bit we waste ... ;))  It helps a bit.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



--- Comment #20 from Jakub Jelinek  2013-03-12 
14:13:56 UTC ---

Ok, based on reading what exactly record_estimate does, I've tried:

--- tree-ssa-loop-niter.c.xx2013-03-12 13:47:08.0 +0100

+++ tree-ssa-loop-niter.c2013-03-12 15:01:50.498107788 +0100

@@ -2655,7 +2655,10 @@ record_nonwrapping_iv (struct loop *loop

   && warn_aggressive_loop_optimizations

   && (cfun->curr_properties & PROP_loops) != 0

   && !loop->warned_aggressive_loop_optimizations

-  && max.ucmp (tree_to_double_int (loop->nb_iterations)) < 0)

+  && (upper || realistic)

+  && (max + double_int_one).ucmp (tree_to_double_int

(loop->nb_iterations))

+ < 0

+  && dominated_by_p (CDI_DOMINATORS, loop->latch, gimple_bb (stmt)))

 {

   location_t loop_locus = UNKNOWN_LOCATION;

   edge e = single_exit (loop);



incremental patch (for !upper && !realistic it gives up early, for

!dominated_by_p

it records the bounds, but doesn't call record_niter_bound, and

record_nonwrapping_iv calls unconditionally record_estimate with is_exit=false,

for which it adds double_int_one to the bounds.



With this #c16 and #c17 compile without warnings, unfortunately the testcase in

the patch regresses two tests, fn4 and fn7 (the latter is from the SPEC2k6

issue).



max + double_int_one above is unsafe btw, we'd need something that

record_estimate does to check for overflows.

[Bug c/56602] New: ICE: internal compiler error: in default_no_named_section, at varasm.c:6346

[alanh at fairlite dot co.uk]

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



 Bug #: 56602

   Summary: ICE: internal compiler error: in

default_no_named_section, at varasm.c:6346

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: al...@fairlite.co.uk





Using an m68k machine (using a.out format) trying to compile 4.7.2 and getting

the above crash having built stage1, and trying to build stage2.



It seems related to this PA bug 



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



Maybe something similar didn't happen to m68k ?

[Bug c/56602] ICE: internal compiler error: in default_no_named_section, at varasm.c:6346

[alanh at fairlite dot co.uk]

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



--- Comment #1 from Alan Hourihane  2013-03-12 
14:19:02 UTC ---

configure:3371: /j/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/./gcc/xgcc

-B/j/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/./gcc/

-B/usr/m68k-atari-mint/bin/ -B/usr/m68k-atari-mint/lib/ -isystem

/usr/m68k-atari-mint/include -isystem /usr/m68k-atari-mint/sys-include-o

conftest -g -O2 -pipe   conftest.c -lpthread >&5

conftest.c: In function 'main':

conftest.c:16:1: internal compiler error: in default_no_named_section, at

varasm.c:6346

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)

[danglin at gcc dot gnu.org]

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



--- Comment #5 from John David Anglin  2013-03-12 
14:28:22 UTC ---

With patch, build fails with following error:



/test/gnu/gcc/objdir1/./prev-gcc/xg++ -B/test/gnu/gcc/objdir1/./prev-gcc/

-B/opt

/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/ -nostdinc++

-B/test/gnu/gcc/objdir1/

prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs

-B/test/gnu/gcc/objdir1/prev-h

ppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs

-I/test/gnu/gcc/objdir1/prev-h

ppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11

-I/test/gnu/gcc/

objdir1/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/include

-I/test/gnu/gcc/gcc/libs

tdc++-v3/libsupc++

-L/test/gnu/gcc/objdir1/prev-hppa2.0w-hp-hpux11.11/libstdc++-

v3/src/.libs

-L/test/gnu/gcc/objdir1/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/lib

supc++/.libs -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  

-fno-exce

ptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing

-Wwrite-st

rings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 

-DHAVE_CONFIG_H -I. -Icp -I../../gcc/gcc -I../../gcc/gcc/cp

-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include

-I/opt/gnu/gcc/gmp/include  -I../../gcc/gcc/../libdecnumber

-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber

-I../../gcc/gcc/../libbacktrace../../gcc/gcc/cp/pt.c -o cp/pt.o

../../gcc/gcc/cp/decl.c: In function 'tree_node* register_dtor_fn(tree)':

../../gcc/gcc/cp/decl.c:6864:38: error: 'addr' may be used uninitialized in

this function [-Werror=maybe-uninitialized]

   arg0, arg1, arg2, NULL_TREE);

  ^

cc1plus: all warnings being treated as errors

[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower

[wbrana at gmail dot com]

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



--- Comment #15 from wbrana  2013-03-12 14:28:43 UTC 
---

I can see different results with different linkers - see above.

Your CPU is Nehalem quad core, but my CPU is Sandy Bridge dual core, which have

less L1/L2/L3 cache.

[Bug c++/56597] unaligned local variable used by implicit sse instructions

[kruglinski at gmail dot com]

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



--- Comment #4 from jjwang  2013-03-12 14:31:27 
UTC ---

I think one rule can be add to gcc that is:



if GCC decide to use the vector instructions that require alignment in

condition the users are not realized it, the variable should be aligned

automaticly that referenced by the instructions



jj

[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower

[rguenther at suse dot de]

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



--- Comment #16 from rguenther at suse dot de  
2013-03-12 14:33:52 UTC ---

On Tue, 12 Mar 2013, wbrana at gmail dot com wrote:



> 

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

> 

> --- Comment #15 from wbrana  2013-03-12 14:28:43 UTC 
> ---

> I can see different results with different linkers - see above.



Might be alignment.



> Your CPU is Nehalem quad core, but my CPU is Sandy Bridge dual core, which 
> have

> less L1/L2/L3 cache.



Well, the code is exactly the same, so I can't measure any difference.

[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"

[danglin at gcc dot gnu.org]

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



--- Comment #7 from John David Anglin  2013-03-12 
14:52:11 UTC ---

Created attachment 29653

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29653

Tree dump

[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"

[danglin at gcc dot gnu.org]

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



--- Comment #8 from John David Anglin  2013-03-12 
14:53:13 UTC ---

Created attachment 29654

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29654

Tree dump

[Bug target/56603] New: Different _MM_HINT_TX values from ICC

[hjl.tools at gmail dot com]

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



 Bug #: 56603

   Summary: Different _MM_HINT_TX values from ICC

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: hjl.to...@gmail.com

CC: ubiz...@gmail.com





GCC defines:



/* Constants for use with _mm_prefetch.  */

enum _mm_hint

{

  _MM_HINT_T0 = 3, 

  _MM_HINT_T1 = 2, 

  _MM_HINT_T2 = 1, 

  _MM_HINT_NTA = 0

};



However, ICC defines



_MM_HINT_T0 = 1

_MM_HINT_T1 = 2

_MM_HINT_T2 = 3

_MM_HINT_NTA = 0



It seems a typo in GCC.

[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-12

 CC||ebotcazou at gcc dot

   ||gnu.org

 Ever Confirmed|0   |1



--- Comment #2 from Eric Botcazou  2013-03-12 
16:34:15 UTC ---

The ICE in output_die is a known issue: when LTO puts nested and parent

functions in different partitions, implicit assumptions made in dwarf2out.c are

no longer valid and DIEs end up with no parent.  We use this patch internally:



* dwarf2out.c (fixup_limbo_list): New function extracted from...

In LTO mode, iterate until the list is fully drained.

(dwarf2out_finish): ...here.  Call it both after regular processing

and after the call to resolve_addr in LTO mode.

lto/

* lto.c (lto_register_var_decl_in_symtab): Do not change the assembler

name in LTRANS mode.



to make -g sort of work in LTO mode.  The other issue is new I think.

[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-03-12 
16:45:49 UTC ---

Is there any advantage in putting nested functions in different partition from

the parent function?  I'd say LTO just should try hard to make to put them into

the same partition.

[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



  Attachment #29645|0   |1

is obsolete||



--- Comment #8 from H.J. Lu  2013-03-12 16:48:45 
UTC ---

Created attachment 29655

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29655

A patch



This patch adds callee_pass_avx256_p and callee_return_avx256_p

to ix86_args.  ix86_function_arg copies them to cfun->machine

when ix86_function_arg is called with VOIDmode, which is called

just before emitting call.  cfun->machine->callee_return_avx256_p

is set in init_cumulative_args for ix86_function_ok_for_sibcall.

[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada

[ebotcazou at gcc dot gnu.org]

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



--- Comment #4 from Eric Botcazou  2013-03-12 
16:53:15 UTC ---

> Is there any advantage in putting nested functions in different partition from

> the parent function?  I'd say LTO just should try hard to make to put them 
> into

> the same partition.



That would be an arbitrary restriction though.  This works fine, except that -g

currently breaks, but (1) it doesn't really work with LTO in any case and (2)

nested functions don't really work with -g at high optimization level either.

[Bug objc++/56604] New: Missing obj-c++.srcman target

[pierre.labastie at neuf dot fr]

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



 Bug #: 56604

   Summary: Missing obj-c++.srcman target

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: objc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: pierre.labas...@neuf.fr





According to the doc, there should be a obj-c++.srcman target in

gcc/objcp/Make-lang.in, which is not presently true, and makes

bootstrapping with --enable-languages=...,obj-c++,..

--enable-generated-files-in-srcdir

fail with:

make[3]: *** No rule to make target `obj-c++.srcman', needed by `lang.srcman'.

Correction is easy, just add a line:

obj-c++.srcman:

to gcc/objcp/Make-lang.in

[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX

[ebotcazou at gcc dot gnu.org]

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



--- Comment #9 from Eric Botcazou  2013-03-12 
17:07:40 UTC ---

> This patch adds callee_pass_avx256_p and callee_return_avx256_p

> to ix86_args.  ix86_function_arg copies them to cfun->machine

> when ix86_function_arg is called with VOIDmode, which is called

> just before emitting call.  cfun->machine->callee_return_avx256_p

> is set in init_cumulative_args for ix86_function_ok_for_sibcall.



This looks good to me, but I don't know the i386 back-end much (and of course

cannot approve anything).  Btw, you should add a comment before the new



  if (cum->caller && mode == VOIDmode)



block explaining why you need to do this dance on the caller side.



Thanks for working on this.

[Bug debug/54970] Missing DW_OP_GNU_implicit_pointer in debuginfo

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|RESOLVED|REOPENED

 Resolution|FIXED   |



--- Comment #6 from Steven Bosscher  2013-03-12 
17:09:14 UTC ---

This test case fails on powerpc64 with fc18.

The *p and *q stores are optimized away.

[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #5 from Steven Bosscher  2013-03-12 
17:19:56 UTC ---

(In reply to comment #4)

> > Is there any advantage in putting nested functions in different

> > partition from the parent function?  I'd say LTO just should try

> > hard to make to put them into the same partition.

> 

> That would be an arbitrary restriction though.  This works fine,

> except that -g currently breaks, but (1) it doesn't really work

> with LTO in any case and (2) nested functions don't really work

> with -g at high optimization level either.



What "it" do you mean at (1)?



Putting nested functions in the same partition as the parent is not

really arbitrary.  Nested functions have a limited scope, and AFAIU

are only accessible from the parent function.  There can't be much

for IPA to do with nested functions in another partition.

[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada

[ebotcazou at gcc dot gnu.org]

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



--- Comment #6 from Eric Botcazou  2013-03-12 
17:31:28 UTC ---

> What "it" do you mean at (1)?



-g



> Putting nested functions in the same partition as the parent is not

> really arbitrary.  Nested functions have a limited scope, and AFAIU

> are only accessible from the parent function.  There can't be much

> for IPA to do with nested functions in another partition.



You can do IPA on the parent functions, in particular inline them, without

wanting to drag all the nested functions in the same partition.  Yes, this

would be arbitrary and go against the current design of making nested functions

first class citizens very early in the compilation pipeline.

[Bug target/56602] ICE: internal compiler error: in default_no_named_section, at varasm.c:6346

[alanh at fairlite dot co.uk]

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



--- Comment #2 from Alan Hourihane  2013-03-12 
17:42:39 UTC ---

Created attachment 29656

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29656

non-ELF m68k systems require default .text section for code

[Bug target/56602] ICE: internal compiler error: in default_no_named_section, at varasm.c:6346

[alanh at fairlite dot co.uk]

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



--- Comment #3 from Alan Hourihane  2013-03-12 
17:43:12 UTC ---

I'm trying the attached patch now, but does this look o.k. ?

[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"

[jamborm at gcc dot gnu.org]

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



--- Comment #9 from Martin Jambor  2013-03-12 
17:48:15 UTC ---

I'm just guessing, but is it possible that MAY_HAVE_DEBUG_STMTS is 0

even with -g on hppa-hpux?  If so, that (and I suppose the debug

format) would be the cause and skipping/xfailing the test would indeed

be the right thing to do.

[Bug debug/54970] Missing DW_OP_GNU_implicit_pointer in debuginfo

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|REOPENED|RESOLVED

 Resolution||FIXED



--- Comment #7 from Jakub Jelinek  2013-03-12 
17:50:49 UTC ---

The stores are of course optimized away, everywhere, that is the point of the

testcase.

The problems that cause the debug info to be insufficient on some targets are

tracked e.g. in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971#c13

There is no point to keep this PR open for that.

[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #10 from Jakub Jelinek  2013-03-12 
17:59:47 UTC ---

I think -fvar-tracking-assignments is disabled by default if selective

scheduler is enabled, but I doubt that is the case of pa.  In any case, you

could try

to add -fvar-tracking-assignments explicitly to dg-options.

[Bug middle-end/54896] optimization slowness on large basic blocks

[steven at gcc dot gnu.org]

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



--- Comment #8 from Steven Bosscher  2013-03-12 
18:23:29 UTC ---

With r196576 on x86_64 (gcc17):



at -O1:

 alias stmt walking  :  30.99 (36%) usr

 reload CSE regs :  18.94 (22%) usr

 CSE :  14.94 (17%) usr

 tree DSE:   9.32 (11%) usr



at -O2:

 alias stmt walking  :  46.65 (30%) usr

 reload CSE regs :  37.92 (25%) usr

 CSE 2   :  29.09 (19%) usr

 CSE :  15.02 (10%) usr



at -O3:

 tree slp vectorization  : 129.79 (61%) usr

 alias stmt walking  :  46.52 (22%) usr

[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"

[dave.anglin at bell dot net]

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



--- Comment #11 from dave.anglin at bell dot net 2013-03-12 18:27:01 UTC ---

On 3/12/2013 1:59 PM, jakub at gcc dot gnu.org wrote:

> I think -fvar-tracking-assignments is disabled by default if selective

>

> scheduler is enabled, but I doubt that is the case of pa.  In any case, you

>

> could try

>

> to add -fvar-tracking-assignments explicitly to dg-options.

This does seem to make a difference:



;; Function foo (foo, funcdef_no=0, decl_uid=1351, cgraph_uid=0)



Created a debug-only replacement for s offset: 0, size: 32

Created a debug-only replacement for s offset: 32, size: 8

Created a debug-only replacement for s offset: 40, size: 8

Created a debug-only replacement for s offset: 48, size: 16

foo (int x)

{

   char * p;

   struct S s;



Dave

[Bug debug/54970] Missing DW_OP_GNU_implicit_pointer in debuginfo

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #8 from Steven Bosscher  2013-03-12 
18:55:19 UTC ---

(In reply to comment #7)

> The stores are of course optimized away, everywhere, that is the point

> of the testcase.



I am talking about the debug_stmts for the stores, sorry if that was not

clear.  On x86_64 the test case passes, but on powerpc64 esra does something

it doesn't do on x86_64 and it makes the test case fail.  Is there a known

bug for that already, also?



This is 176 FAILs on powerpc64.  If it's "supposed to not work" there, then

the test case should be XFAIL'ed there.

[Bug rtl-optimization/56605] New: Redundant branch introduced during loop2 phases

[wschmidt at gcc dot gnu.org]

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



 Bug #: 56605

   Summary: Redundant branch introduced during loop2 phases

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: missed-optimization

  Severity: normal

  Priority: P3

 Component: rtl-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: wschm...@gcc.gnu.org

CC: berg...@vnet.ibm.com

  Host: powerpc64-unknown-linux-gnu

Target: powerpc64-unknown-linux-gnu

 Build: powerpc64-unknown-linux-gnu





I've recently noticed that GCC commonly generates redundant branches prior to

vectorized loops, such as:



   cmpwi 7,12,0

...

   beq- 7,.L22

   beq- 7,.L22

   .p2align 4,,15

.L8:

... loop body ...



The branches first appear in the 186r.loop2_doloop debug dump:



(note 260 254 258 23 [bb 23] NOTE_INSN_BASIC_BLOCK)

(insn 258 260 259 23 (set (reg:CC 330)

(compare:CC (subreg:SI (reg:DI 153 [ bnd.10+-4 ]) 4)

(const_int 0 [0]))) -1

 (nil))

(jump_insn 259 258 263 23 (set (pc)

(if_then_else (eq (reg:CC 330)

(const_int 0 [0]))

(label_ref 257)

(pc))) -1

 (expr_list:REG_BR_PROB (const_int 0 [0])

(nil))

 -> 257)

(note 263 259 261 24 [bb 24] NOTE_INSN_BASIC_BLOCK)

(insn 261 263 262 24 (set (reg:CC 331)

(compare:CC (subreg:SI (reg:DI 153 [ bnd.10+-4 ]) 4)

(const_int 0 [0]))) -1

 (nil))

(jump_insn 262 261 257 24 (set (pc)

(if_then_else (eq (reg:CC 331)

(const_int 0 [0]))

(label_ref 257)

(pc))) -1

 (expr_list:REG_BR_PROB (const_int 0 [0])

(nil))

 -> 257)



Subsequently GCC removes the redundant compare, but does not remove the

redundant branch.



Simple test case to reproduce:



#define N 4000

void foo(short* __restrict sb, int* __restrict ia) {

  int i;

  for (i = 0; i < N; i++)

ia[i] = (int) sb[i];

}



$GCC_INSTALL/bin/gcc -S -O3 -mvsx example.c



(-mvsx is necessary to vectorize the loop.  It may also be necessary to add

-mcpu=power7.)

[Bug rtl-optimization/56605] Redundant branch introduced during loop2 phases

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-12

 Ever Confirmed|0   |1

[Bug rtl-optimization/56605] Redundant branch introduced during loop2 phases

[steven at gcc dot gnu.org]

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



--- Comment #1 from Steven Bosscher  2013-03-12 
19:54:05 UTC ---

Confirmed, compiling with -mcpu=power7 -msvx -O3 -fno-unroll-loops



Comes from here:



Breakpoint 8, doloop_modify (loop=0x3fffb5dc0ee0, desc=0x111d6d00,

doloop_seq=0x3fffb5f35780, condition=0x3fffb5fd1680, count=0x3fffb5fd16e0)

at ../../trunk/gcc/loop-doloop.c:505

505   for (; ass; ass = XEXP (ass, 1))

(gdb) p debug_rtx(ass)

(expr_list:REG_DEP_TRUE (eq:SI (subreg:SI (reg:DI 153) 4)

(const_int 0 [0]))

(expr_list:REG_DEP_TRUE (eq:SI (subreg:SI (reg:DI 153) 4)

(const_int 0 [0]))

(nil)))

$51 = void

(gdb) 



These are the noloop_assumptions, and the same assertion appears twice.

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



  Attachment #29650|0   |1

is obsolete||



--- Comment #21 from Jakub Jelinek  2013-03-12 
20:09:58 UTC ---

Created attachment 29657

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29657

gcc48-pr53265.patch



Updated patch that actually passed bootstrap/regtest.  Unfortunately, for fn4

and fn7 in the testcase to pass, I had to give up with only warning in

PROP_loops state, because the cunrolli pass optimizes those loops.



While it bootstrapped fine (with unwind-dw2.c fix I'll attach too), there were

some regressions, some -Waggressive-loop-optimizations warnings during

bootstrap/regtest and also with the additional debugging hack in various places

the number of iterations upper bound increased.



The regressions are:

../../gcc/ada/exp_ch7.adb:3540:11: warning: iteration 2147483646 invokes

undefined behavior [-Waggressive-loop-optimizations]

warning during x86_64 Ada build and:



+FAIL: gcc.dg/torture/pr49518.c  -O3 -fomit-frame-pointer  (test for excess

errors)

+FAIL: gcc.dg/torture/pr49518.c  -O3 -fomit-frame-pointer -funroll-loops  (test

for excess errors)

+FAIL: gcc.dg/torture/pr49518.c  -O3 -fomit-frame-pointer -funroll-all-loops

-finline-functions  (test for excess errors)

+FAIL: gcc.dg/torture/pr49518.c  -O3 -g  (test for excess errors)

+FAIL: g++.dg/opt/longbranch2.C -std=gnu++98 (test for excess errors)

+FAIL: g++.dg/opt/longbranch2.C -std=gnu++11 (test for excess errors)

+FAIL: libmudflap.c/fail37-frag.c (-O2) (test for excess errors)

+FAIL: libmudflap.c/fail37-frag.c (-O3) (test for excess errors)



(longbranch2.C only on i686, not on x86_64).  For fail32-frag.c, I believe we

just want to add asm ("" : "+r" (i)); into the loop to hide stuff from the

optimizers.



With the debugging hack, the cases of increasing number of iterations at the

end of estimate_numbers_of_iterations_loop are (except for pr53265.c, which of

course has tons of them):



64 ../../gcc/ada/exp_ch7.adb:3540 7ffd 0  0

{32,64} /usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr49518.c:10 2 0 fffd 0

32 /usr/src/gcc/gcc/testsuite/g++.dg/opt/longbranch2.C:36 100 0 1ff 0

32 /usr/src/gcc/gcc/testsuite/g++.dg/opt/longbranch2.C:36 ff 0 1fe 0

{32,64} /usr/src/gcc/gcc/testsuite/gfortran.dg/do_1.f90:10 9 0 a 0   

{32,64} /usr/src/gcc/gcc/testsuite/gfortran.dg/do_1.f90:16 4 0 5 0

{32,64} /usr/src/gcc/gcc/testsuite/gfortran.dg/do_1.f90:21 3 0 4 0

{32,64} /usr/src/gcc/libmudflap/testsuite/libmudflap.c/fail37-frag.c:15 4 0 5 0



In exp_ch7.adb it looks like pass ordering, cunrolli is run on dead code there,

*.copyrename2 has:

  [../../gcc/ada/exp_ch7.adb : 3540:11] ind.127_3 = 1;

  [../../gcc/ada/exp_ch7.adb : 3540:11] if (ind.127_3 > 1)

goto ;

  else

goto ;



  :

  # fent_39 = PHI <[../../gcc/ada/exp_ch7.adb : 3535:7] fent_2(2)>

  # j_40 = PHI <[../../gcc/ada/exp_ch7.adb : 3540:11] 1(2)>



  :

  # fent_6 = PHI 

  # j_4 = PHI 

  # DEBUG j => j_4

  # DEBUG fent => fent_6

  [../../gcc/ada/exp_ch7.adb : 3540:11] j_5 = j_4 + 1;

  [../../gcc/ada/exp_ch7.adb : 3540:11] # DEBUG j => j_5

  [../../gcc/ada/exp_ch7.adb : 3541:10] fent_7 = sinfo.next_entity (fent_6);

  [../../gcc/ada/exp_ch7.adb : 3541:10] # DEBUG fent => fent_7

  [../../gcc/ada/exp_ch7.adb : 3540:25] if (ind.127_3 != j_5)

goto ;

  else

goto ;



where both j and ind.127 are signed SImode vars.  number_of_latch_iterations

estimates the bound as 0x, signed overflow decreases that guess, but it

is really in dead code (something visible only through inlining though).

ccp2 immediately after cunrolli would fix this up, but that is too late.



For pr49518.c, I guess it is reasonable to warn, if the loop invariant

conditions are all such that it keeps looping, then the loop indeed triggers

undefined behavior.



Thoughts?

[Bug c++/56606] New: GCC refuses to emit long calls for operator new/delete on PowerPC

[gcc at mrozekma dot com]

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



 Bug #: 56606

   Summary: GCC refuses to emit long calls for operator new/delete

on PowerPC

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: g...@mrozekma.com





-mlongcall seems to have no effect on operator new and operator delete. For

example, given the code:



> extern void foo();

> void bar() {

> foo();

> new char;

> }



A normal run of GCC on PowerPC will generate the (abridged) assembly:



> bl _Z3foov

> bl _Znwj



Running GCC with the -mlongcall option generates:



> lis r9, _Z3foov@ha

> addi r9, r9, _Z3foov@l

> mtctr r9

> bctrl

> bl _Znwj



The branch to foo() was expanded as expected, but the branch to operator new is

still short. Calls to random libc and libstdc++ functions are all converted; so

far operator new and operator delete are the only ones I've seen that don't

work. This seems similar to bug 12769, but that was for generated functions



---



GCC build info:



> Target: ppc-redhat-linux

> Configured with: ./configure --prefix=/opt/gcc-4.7.2-ppc 
> --mandir=/opt/gcc-4.7.2-ppc/share/man --enable-shared --enable-threads=posix 
> --with-system-zlib --enable-languages=c,c++ --build=ppc-redhat-linux 
> --host=ppc-redhat-linux --target=ppc-redhat-linux

> gcc version 4.7.2 (GCC) 



Test compiled with:



> g++ -mlongcall -c -o test.o test.cpp

[Bug target/56263] [avr] Provide strict address-space checking

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



 Status|SUSPENDED   |ASSIGNED



--- Comment #7 from Georg-Johann Lay  2013-03-12 
21:21:19 UTC ---

This patch implements -Waddr-space-convert and will print diagnostics for casts

to non-containing address spaces.



It's just a quick implementation in order to get the patch into 4.8.0 which

will be frozen for release withing the next few days.



Some work still to be done:



- Try to avoid warnings for casts from PSTR ("text") to const __flash char*.

  PSTR is a commonly used idion from AVR-LibC's avr/progmem.h, namely



  #define PSTR(s)\

   (__extension__(   \

  {  \ 

 static const char __c[] __attribute__((__progmem__)) = (s); \

 &__c[0];\

  }))



- Try to distinguish between implicit casts and explicit casts requested

  by the user



- Allow to pick a warning level for the previous kinds of casts





(In reply to comment #5)

> (In reply to comment #4)

> > (In reply to comment #3)

> > 

> > It's a shortcoming in the Embedded C paper and I agree with you that more

> > elaborate Embedded C paper would be more convenient here.

> > 

> > There are two ways out of this:

> > 

> > 1) Extend the Embedded C paper and propose an addendum to the ISO WG14.

> > 

> > 2) Implement this extension no matter whether Embedded C comes with this

> > extension.  Find someone who implements this extension, supports it and

> > makes sure there are no conflicts with the vanilla Embedded C.

> > 

> > Notice that with the extension, in the following example "init" would be

> > located in flash but "assign" would still be located in RAM.

> > 

> > void f_init (void)

> > {

> > const __flash char *str = "init";

> > }

> > 

> > void f_assign (void)

> > {

> > const __flash char *str;

> > str = "assign";

> > }

> 

> In my view, in this situation, the data must be placed in a flash ...

> Standard really needs serious improvement.



ACK.  May be that is the reason for why Embedded-C did not go into C11.



However, waiting until the Embedded-C paper will be extended in that direction

is pointless.  Just try to participate the ISO process; it will take years...



Maybe it's doable in the avr backend, but then we need a proper specification

and enough knowledge to decide whether or not all hooks are guaranteeing that

the BE can take the decision in every case.



> It's logical, when the right-hand and left-hand side of each other have the

> appropriate type. Moreover, for the implementation of this simple idea is not

> objective difficulties.



Sorry? I don't understand you last remark.  Are you saying it is trivial to

implement in the avr backend?



Before implementing it, you'll have to specify it.  What should do this code?



const __flash char* f (int i)

{

const __flash char *p = "Hallo" + i;

return p;

}

[Bug c++/54764] In class initialization of non-static lambda member can't be used in class with default template paramer

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||jason at gcc dot gnu.org

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

   |gnu.org |

[Bug c++/55972] cannot access private member from lambda used in NSDMI

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||jason at gcc dot gnu.org

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

   |gnu.org |

[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count

[jakub at gcc dot gnu.org]

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



--- Comment #22 from Jakub Jelinek  2013-03-12 
21:47:38 UTC ---

Short C testcase reproducing the exp_ch7.adb issue (for -O2):

void bar (int);



__attribute__((noinline)) static int

foo (int x)

{

  int i = 1;

  if (x > 1)

do

  bar (i);

while (++i != x);

}



void

baz (void)

{

  foo (1);

  foo (1);

  foo (1);

}

[Bug fortran/56581] Segfault when reading source file which starts with a byte-order mark (-cpp works)

[tkoenig at gcc dot gnu.org]

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



Thomas Koenig  changed:



   What|Removed |Added



   Keywords||ice-on-invalid-code,

   ||rejects-valid

 Status|UNCONFIRMED |NEW

   Last reconfirmed|2013-03-10 00:00:00 |2013-03-12

 Ever Confirmed|0   |1



--- Comment #8 from Thomas Koenig  2013-03-12 
22:05:12 UTC ---

We try to support this, but apparently it doesn't work

(see line 2015 and following of scanner.c).



Same thing happens for 4.6 and 4.7.



Valgrind tells me



==11226== Memcheck, a memory error detector

==11226== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.

==11226== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info

==11226== Command: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951 ice.f

==11226== 

==11226== Invalid write of size 4

==11226==at 0x580400: load_line(_IO_FILE*, unsigned int**, int*, int

const*) (scanner.c:1646)

==11226==by 0x5811C3: load_file(char const*, char const*, bool)

(scanner.c:2009)

==11226==by 0x582F82: gfc_new_file() (scanner.c:2120)

==11226==by 0x5A1DA7: gfc_init() (f95-lang.c:224)

==11226==by 0x94F286: toplev_main(int, char**) (toplev.c:1700)

==11226==by 0x5A38454: (below main) (in /lib64/libc-2.15.so)

==11226==  Address 0x5ea3e30 is 0 bytes after a block of size 288 alloc'd

==11226==at 0x4C292B8: calloc (in

/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)

==11226==by 0xE54110: xcalloc (xmalloc.c:162)

==11226==by 0x58155E: load_file(char const*, char const*, bool)

(scanner.c:2030)

==11226==by 0x582F82: gfc_new_file() (scanner.c:2120)

==11226==by 0x5A1DA7: gfc_init() (f95-lang.c:224)

==11226==by 0x94F286: toplev_main(int, char**) (toplev.c:1700)

==11226==by 0x5A38454: (below main) (in /lib64/libc-2.15.so)

[Bug c/56607] New: [4.8 regression] GCC fails to warn on division by zero

[ppluzhnikov at google dot com]

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



 Bug #: 56607

   Summary: [4.8 regression] GCC fails to warn on division by zero

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ppluzhni...@google.com





Test:



typedef unsigned long size_t;



#ifdef TEST1

int ShouldntCompile ()

{

  return 1 / ((sizeof(int) / 3) - 1);

}

#endif



#ifdef TEST2

int WontCompile ()

{

  const int x = (sizeof(int) / 3) - 1;

  return 1 / x;

}

#endif



Using gcc-4.7:

gcc -Werror -c -DTEST1 as.c ; echo $?



as.c: In function 'ShouldntCompile':

as.c:6:12: error: division by zero [-Werror=div-by-zero]

cc1: all warnings being treated as errors

1



g++ -Werror -c -DTEST1 as.c ; echo $?

# same as above



gcc -Werror -c -DTEST2 as.c ; echo $?

0   # problem



g++ -Werror -c -DTEST2 as.c ; echo $?



as.c: In function 'int WontCompile()':

as.c:14:14: error: division by zero [-Werror=div-by-zero]

cc1plus: all warnings being treated as errors

1





Using gcc-4.8 (r196619):





gcc -Werror -c -DTEST1 as.c; echo $?



as.c: In function 'ShouldntCompile':

as.c:6:12: error: division by zero [-Werror=div-by-zero]

   return 1 / ((sizeof(int) / 3) - 1);

^

cc1: all warnings being treated as errors

1





g++ -Werror -c -DTEST1 as.c; echo $?

0  # 4.8 regression, used to warn.





gcc -Werror -c -DTEST2 as.c ; echo $?

0   # still a problem





g++ -Werror -c -DTEST2 as.c; echo $?



as.c: In function 'int WontCompile()':

as.c:14:14: error: division by zero [-Werror=div-by-zero]

   return 1 / x;

  ^

cc1plus: all warnings being treated as errors

1

[Bug rtl-optimization/56605] Redundant branch introduced during loop2 phases

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #2 from Steven Bosscher  2013-03-12 
23:00:07 UTC ---

The first assumption is recorded at loop-iv.c:2472:



Breakpoint 7, iv_number_of_iterations (loop=0x3fffb5dc0ee0,

insn=0x3fffb5db6fa8, condition=0x3fffb5fd13c8, desc=0x3fffdf98)

at ../../trunk/gcc/loop-iv.c:2472

2472  alloc_EXPR_LIST (0, assumption,

desc->noloop_assumptions);

(gdb) p assumption

$1 = (rtx) 0x3fffb5fd1410

(gdb) p debug_rtx(assumption)

(eq:SI (subreg:SI (reg:DI 153 [ bnd.10D.2035+-4 ]) 4)

(const_int 0 [0]))

$2 = void

(gdb) cont

Continuing.



The second comes from loop-iv.c:2623:

Breakpoint 8, iv_number_of_iterations (loop=0x3fffb5dc0ee0,

insn=0x3fffb5db6fa8, condition=0x3fffb5fd13c8, desc=0x3fffdf98)

at ../../trunk/gcc/loop-iv.c:2623

2623alloc_EXPR_LIST (0, assumption,

desc->noloop_assumptions);

(gdb) p debug_rtx(assumption)

(gtu:SI (plus:SI (subreg:SI (reg:DI 163 [ ivtmp.33D.2058+-4 ]) 4)

(const_int 1 [0x1]))

(subreg:SI (reg:DI 153 [ bnd.10D.2035+-4 ]) 4))





The second one is simplified using initial values at loop-iv.c:2777:

2777  simplify_using_initial_values (loop, IOR, &desc->noloop_assumptions);

(gdb) p debug_rtx(desc->noloop_assumptions)

(expr_list:REG_DEP_TRUE (gtu:SI (plus:SI (subreg:SI (reg:DI 163 [

ivtmp.33D.2058+-4 ]) 4)

(const_int 1 [0x1]))

(subreg:SI (reg:DI 153 [ bnd.10D.2035+-4 ]) 4))

(expr_list:REG_DEP_TRUE (eq:SI (subreg:SI (reg:DI 153 [ bnd.10D.2035+-4 ])

4)

(const_int 0 [0]))

(nil)))

$15 = void

(gdb) next

2778  simplify_using_initial_values (loop, IOR, &desc->infinite);

(gdb) p debug_rtx(desc->noloop_assumptions)

(expr_list:REG_DEP_TRUE (eq:SI (subreg:SI (reg:DI 153 [ bnd.10D.2035+-4 ]) 4)

(const_int 0 [0]))

(expr_list:REG_DEP_TRUE (eq:SI (subreg:SI (reg:DI 153 [ bnd.10D.2035+-4 ])

4)

(const_int 0 [0]))

(nil)))

$16 = void

(gdb) 



Insofar I can claim to understand loop-iv.c, this is supposed to be

cleaned up by eliminate_implied_conditions.

[Bug rtl-optimization/56605] Redundant branch introduced during loop2 phases

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC|steven at gcc dot gnu.org   |



--- Comment #3 from Steven Bosscher  2013-03-12 
23:14:39 UTC ---

GCC gets to implies_p with:



Breakpoint 11, implies_p (a=0x3fffb5fd1410, b=0x3fffb5fd15c0) at

../../trunk/gcc/loop-iv.c:1499

1499  if (GET_CODE (a) == EQ)

(gdb) p debug_rtx(a)

(eq:SI (subreg:SI (reg:DI 153 [ bnd.10D.2035+-4 ]) 4)

(const_int 0 [0]))

$26 = void

(gdb) p debug_rtx(b)

(eq:SI (subreg:SI (reg:DI 153 [ bnd.10D.2035+-4 ]) 4)

(const_int 0 [0]))

$27 = void

(gdb) 



But implies_p doesn't handle SUBREGs.  If it would allow REGs and SUBREGs

of REGs, it would fold the assumption away:



1504  if (REG_P (op0))

(gdb) p op0

$29 = (rtx) 0x3fffb5fd13e0

(gdb) p debug_rtx(op0)

(subreg:SI (reg:DI 153 [ bnd.10D.2035+-4 ]) 4)

$30 = void

(gdb) p debug_rtx(op1)

(const_int 0 [0])

$31 = void

(gdb) p debug_rtx(simplify_replace_rtx (b, op0, op1))

(const_int 1 [0x1])

$32 = void





Something like the following, perhaps?



Index: loop-iv.c

===

--- loop-iv.c   (revision 196575)

+++ loop-iv.c   (working copy)

@@ -1496,19 +1496,26 @@ implies_p (rtx a, rtx b)

   rtx op0, op1, opb0, opb1, r;

   enum machine_mode mode;



+  if (rtx_equal_p (a, b))

+return true;

+

   if (GET_CODE (a) == EQ)

 {

   op0 = XEXP (a, 0);

   op1 = XEXP (a, 1);



-  if (REG_P (op0))

+  if (REG_P (op0)

+ || (GET_CODE (op0) == SUBREG

+ && REG_P (SUBREG_REG (op0

{

  r = simplify_replace_rtx (b, op0, op1);

  if (r == const_true_rtx)

return true;

}



-  if (REG_P (op1))

+  if (REG_P (op1)

+ || (GET_CODE (op1) == SUBREG

+ && REG_P (SUBREG_REG (op1

{

  r = simplify_replace_rtx (b, op1, op0);

  if (r == const_true_rtx)

[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"

[dave.anglin at bell dot net]

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



--- Comment #12 from dave.anglin at bell dot net 2013-03-13 01:50:05 UTC ---

On 12-Mar-13, at 1:48 PM, jamborm at gcc dot gnu.org wrote:



> I'm just guessing, but is it possible that MAY_HAVE_DEBUG_STMTS is 0

>

> even with -g on hppa-hpux?



Yes, your guess is correct.



1) In dbx_debug_hooks, var_location is debug_nothing_rtx.

2) This causes flag_var_tracking to be set to 0 at toplev.c:1412.

3) flag_selective_scheduling and flag_selective_scheduling2 are

both 0, so flag_var_tracking_assignments is set to flag_var_tracking

at toplev.c:1435.  This only happens when flag_var_tracking_assignments

initially has the AUTODETECT_VALUE.  Explicitly passing the

-fvar_tracking_assignments option overrides this.



--

John David Anglindave.ang...@bell.net

[Bug c++/52374] [C++11] Fails to transform id-expression into dependent base member access in lambda expression

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||jason at gcc dot gnu.org

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

   |gnu.org |

[Bug c/56608] New: built-in floor function returns false results when build with -ffast-math

[udifuchs at gmail dot com]

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



 Bug #: 56608

   Summary: built-in floor function returns false results when

build with -ffast-math

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: udifu...@gmail.com





In some cases floor() seems to return 0 value even if its argument is larger

than 1. This happens when compiling with '-O3 -ffast-math'.



Attached is the smallest code I found, which reproduces the problem. The

comments in the code explain how to reproduces the problem. There is also an

example of how a small tweak hides the problem.



Udi

[Bug c/56608] built-in floor function returns false results when build with -ffast-math

[udifuchs at gmail dot com]

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



--- Comment #1 from udifuchs at gmail dot com 2013-03-13 02:56:37 UTC ---

Created attachment 29659

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29659

Testcase

[Bug c++/55532] Runtime segfault calling mutable lambda wrapped in a non-mutable lambda within a template function

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||jason at gcc dot gnu.org

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

   |gnu.org |

[Bug tree-optimization/56608] SLP seems to produce incorrect value with -ffast-math

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



  Component|c   |tree-optimization

Summary|built-in floor function |SLP seems to produce

   |returns false results when  |incorrect value with

   |build with -ffast-math  |-ffast-math



--- Comment #2 from Andrew Pinski  2013-03-13 
03:27:07 UTC ---

I don't think this has anything to do with floor/ceil folding but rather the

SLP pass is going wrong somewhere.

[Bug fortran/56575] [4.6/4.7 Regression] An invalid OO code causes ICE

[pault at gcc dot gnu.org]

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



--- Comment #7 from Paul Thomas  2013-03-13 05:32:15 
UTC ---

Author: pault

Date: Wed Mar 13 05:32:07 2013

New Revision: 196627



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196627

Log:

2013-03-13  Paul Thomas  



PR fortran/56575

* expr.c (gfc_default_initializer): Check that a class declared

type has any components.

* resolve.c (resolve_fl_derived0): On failing the test for C437

set the type to BT_UNKNOWN to prevent repeat error messages.



2013-03-13  Paul Thomas  



PR fortran/56575

* gfortran.dg/class_56.f90: New test.



Added:

branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/class_56.f90

Modified:

branches/gcc-4_7-branch/gcc/fortran/ChangeLog

branches/gcc-4_7-branch/gcc/fortran/expr.c

branches/gcc-4_7-branch/gcc/fortran/resolve.c

branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug fortran/56575] [4.6 Regression] An invalid OO code causes ICE

[pault at gcc dot gnu.org]

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



--- Comment #8 from Paul Thomas  2013-03-13 06:36:10 
UTC ---

Author: pault

Date: Wed Mar 13 06:36:02 2013

New Revision: 196628



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196628

Log:

2013-03-13  Paul Thomas  



PR fortran/56575

* expr.c (gfc_default_initializer): Check that a class declared

type has any components.

* resolve.c (resolve_fl_derived0): On failing the test for C437

set the type to BT_UNKNOWN to prevent repeat error messages.



2013-03-13  Paul Thomas  



PR fortran/56575

* gfortran.dg/class_56.f90: New test.



Modified:

branches/gcc-4_6-branch/gcc/fortran/ChangeLog

branches/gcc-4_6-branch/gcc/fortran/expr.c

branches/gcc-4_6-branch/gcc/fortran/resolve.c

branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/56575] [4.6 Regression] An invalid OO code causes ICE

[pault at gcc dot gnu.org]

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



Paul Thomas  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #9 from Paul Thomas  2013-03-13 06:37:00 
UTC ---

Fixed on 4.6, 4.7 and 4.8.



Thanks for the report.



Paul

[Bug target/56263] [avr] Provide strict address-space checking

[demiurg_spb at freemail dot ru]

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



--- Comment #8 from demiurg_spb at freemail dot ru 2013-03-13 06:46:40 UTC ---

(In reply to comment #7)

> Sorry? I don't understand you last remark.  Are you saying it is trivial to

> implement in the avr backend?

>

No. Implementation is hard work.

I mean that if we take (typeof(lhs)==typeof(rhs)) axiom in initialization and

assignment: we have no logical problem at all.



> Before implementing it, you'll have to specify it.  What should do this code?

> 

> const __flash char* f (int i)

> {

> const __flash char *p = "Hallo" + i;

> return p;

> }



Yes it's not trivial... But it should be equal to next cases:



const __flash char* f (int i)

{

const __flash char *p = "Hallo"; // flash str

return &p[i];

}



const __flash char* f (int i)

{

return "Hallo" + i;  // flash str

}



const __flash char* f (int i)

{

return &"Hallo"[i];  // flash str

}