[Bug c/60578] wrong code (that hangs) at -O0 on x86_64-linux-gnu (affecting all gcc versions)

2014-03-19 Thread su at cs dot ucdavis.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60578

--- Comment #3 from Zhendong Su su at cs dot ucdavis.edu ---
 (because (c ^ 0L)  -1 is true in 64-bit, so the code returns)

Or perhaps not, as -1 should actually be promoted to signed long, so the
comparison becomes 0L  -1L, and is thus false and triggers the undefined
behavior?


[Bug c/60578] wrong code (that hangs) at -O0 on x86_64-linux-gnu (affecting all gcc versions)

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60578

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
But why do you think (c ^ 0L)  -1 is 1 for 64-bit mode?
From C99, 6.3.1.8, different paragraphs apply:
Otherwise, if the type of the operand with signed integer type can represent
all of the values of the type of the operand with unsigned integer type, then
the operand with unsigned integer type is converted to the type of the
operand with signed integer type.

Otherwise, both operands are converted to the unsigned integer type
corresponding to the type of the operand with signed integer type.

For 64-bit mode, the first cited paragraph applies, because 64-bit long int can
represent all of values of 32-bit unsigned int, so it is
(((long int) 0) ^ 0L)  -1L and thus 0L  -1L and therefore false.

For 32-bit mode, the second cited paragraph applies, because 32-bit long int
can't represent all of values of 32-bit unsigned int, so it is
(((unsigned long int) 0) ^ 0UL)  -1UL and thus 0UL  -1UL and therefore true.


[Bug c/60578] wrong code (that hangs) at -O0 on x86_64-linux-gnu (affecting all gcc versions)

2014-03-19 Thread su at cs dot ucdavis.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60578

--- Comment #5 from Zhendong Su su at cs dot ucdavis.edu ---
(In reply to Jakub Jelinek from comment #4)
 But why do you think (c ^ 0L)  -1 is 1 for 64-bit mode?
 From C99, 6.3.1.8, different paragraphs apply:
 Otherwise, if the type of the operand with signed integer type can represent
 all of the values of the type of the operand with unsigned integer type, then
 the operand with unsigned integer type is converted to the type of the
 operand with signed integer type.
 
 Otherwise, both operands are converted to the unsigned integer type
 corresponding to the type of the operand with signed integer type.
 
 For 64-bit mode, the first cited paragraph applies, because 64-bit long int
 can
 represent all of values of 32-bit unsigned int, so it is
 (((long int) 0) ^ 0L)  -1L and thus 0L  -1L and therefore false.
 
 For 32-bit mode, the second cited paragraph applies, because 32-bit long int
 can't represent all of values of 32-bit unsigned int, so it is
 (((unsigned long int) 0) ^ 0UL)  -1UL and thus 0UL  -1UL and therefore
 true.

Thanks Jakub!  Sorry for the invalid report.


[Bug tree-optimization/54733] Missing opportunity to optimize endian independent load/store

2014-03-19 Thread thomas.preudhomme at arm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54733

Thomas Preud'homme thomas.preudhomme at arm dot com changed:

   What|Removed |Added

 CC||thomas.preudhomme at arm dot 
com

--- Comment #2 from Thomas Preud'homme thomas.preudhomme at arm dot com ---
A patch to fix this is currently under discussion on gcc-patches at:

http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00925.html


[Bug c++/60572] [4.9 Regression] ICE deriving from class with invalid member

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60572

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-19
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Started with r199779.


[Bug c++/60572] [4.9 Regression] ICE deriving from class with invalid member

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60572

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 32386
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32386action=edit
gcc49-pr60572.patch

Untested fix.  Whether you want to fix it this way not sure.


[Bug lto/60571] FTBFS on hurd-i386

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60571

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Wed Mar 19 07:18:46 2014
New Revision: 208675

URL: http://gcc.gnu.org/viewcvs?rev=208675root=gccview=rev
Log:
PR lto/60571
* lto.c (wait_for_child): Define WCONTINUED if not defined to 0.
Fix formatting.

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


[Bug lto/60571] FTBFS on hurd-i386

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60571

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Fixed.


[Bug c++/60054] [c++1y] ICE with auto* cast

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60054

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Both testcases fixed by r208415.


[Bug c++/60332] [c++1y] ICE with auto in function-pointer cast

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60332

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Well, since r208415 is rejected as invalid.


[Bug c++/59114] [c++1y] ICE using auto in conversion operator

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59114

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
This one got fixed with r208414.


[Bug c++/60579] New: Segmentation fault on variadic 'using' within variadic template class

2014-03-19 Thread charlie at charliedyson dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60579

Bug ID: 60579
   Summary: Segmentation fault on variadic 'using' within variadic
template class
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: charlie at charliedyson dot net

The following causes a segfault on gcc 4.8.1 and earlier versions:

template typename... Args
struct X
{
  template typename Head, typename... Tail
  using First = Head;

  using Y = FirstArgs...;
};

Steps to reproduce: http://goo.gl/bBYNJU (GCC Explorer)


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Created attachment 32387
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32387action=edit
unreduced testcase

I've narrowed it down to a single file. Can't say I understand
the issue fully yet.

Bad:
x4 kparts # g++ -c -O2 part.ii  nm part.o | grep N6KParts13ReadWritePartD
4d50 T _ZN6KParts13ReadWritePartD0Ev
4d00 T _ZN6KParts13ReadWritePartD1Ev
4cd0 T _ZN6KParts13ReadWritePartD2Ev

Good:
x4 kparts # /var/tmp/gcc_test/usr/local/bin/g++ -c -O2 part.ii  nm part.o |
grep N6KParts13ReadWritePartD 
4d70 T _ZN6KParts13ReadWritePartD0Ev
4d00 T _ZN6KParts13ReadWritePartD1Ev
4cd0 T _ZN6KParts13ReadWritePartD2Ev
4da0 T _ZThn16_N6KParts13ReadWritePartD0Ev
4d60 T _ZThn16_N6KParts13ReadWritePartD1Ev
4d90 T _ZTv0_n24_N6KParts13ReadWritePartD0Ev
4d50 T _ZTv0_n24_N6KParts13ReadWritePartD1Ev


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
--- part_good.s 2014-03-19 08:57:10.100342064 +0100
+++ part_bad.s  2014-03-19 08:56:50.134141664 +0100
@@ -13466,49 +13466,10 @@
.text
 .LHOTE151:
.section.text.unlikely
+   .align 2
 .LCOLDB152:
.text
 .LHOTB152:
-   .p2align 4,,15
-   .globl  _ZTv0_n24_N6KParts13ReadWritePartD1Ev
-   .type   _ZTv0_n24_N6KParts13ReadWritePartD1Ev, @function
-_ZTv0_n24_N6KParts13ReadWritePartD1Ev:
-.LFB6687:
-   .cfi_startproc
-   movq(%rdi), %r10
-   addq-24(%r10), %rdi
-   jmp _ZN6KParts13ReadWritePartD1Ev
-   .cfi_endproc
-.LFE6687:
-   .size   _ZTv0_n24_N6KParts13ReadWritePartD1Ev,
.-_ZTv0_n24_N6KParts13ReadWritePartD1Ev
-   .section.text.unlikely
-.LCOLDE152:
-   .text
-.LHOTE152:
-   .section.text.unlikely
-.LCOLDB153:
-   .text
-.LHOTB153:
-   .p2align 4,,15
-   .globl  _ZThn16_N6KParts13ReadWritePartD1Ev
-   .type   _ZThn16_N6KParts13ReadWritePartD1Ev, @function
-_ZThn16_N6KParts13ReadWritePartD1Ev:
-.LFB6688:
-   .cfi_startproc
-   subq$16, %rdi
-   jmp _ZN6KParts13ReadWritePartD1Ev
-   .cfi_endproc
-.LFE6688:
-   .size   _ZThn16_N6KParts13ReadWritePartD1Ev,
.-_ZThn16_N6KParts13ReadWritePartD1Ev
-   .section.text.unlikely
-.LCOLDE153:
-   .text
-.LHOTE153:
-   .section.text.unlikely
-   .align 2
-.LCOLDB154:
-   .text
-.LHOTB154:
.align 2
.p2align 4,,15
.globl  _ZN6KParts13ReadWritePartD0Ev
@@ -13529,53 +13490,14 @@
 .LFE5572:
.size   _ZN6KParts13ReadWritePartD0Ev, .-_ZN6KParts13ReadWritePartD0Ev
.section.text.unlikely
-.LCOLDE154:
-   .text
-.LHOTE154:
-   .section.text.unlikely
-.LCOLDB155:
-   .text
-.LHOTB155:
-   .p2align 4,,15
-   .globl  _ZTv0_n24_N6KParts13ReadWritePartD0Ev
-   .type   _ZTv0_n24_N6KParts13ReadWritePartD0Ev, @function
-_ZTv0_n24_N6KParts13ReadWritePartD0Ev:
-.LFB6689:
-   .cfi_startproc
-   movq(%rdi), %r10
-   addq-24(%r10), %rdi
-   jmp _ZN6KParts13ReadWritePartD0Ev
-   .cfi_endproc
-.LFE6689:
-   .size   _ZTv0_n24_N6KParts13ReadWritePartD0Ev,
.-_ZTv0_n24_N6KParts13ReadWritePartD0Ev
-   .section.text.unlikely
-.LCOLDE155:
-   .text
-.LHOTE155:
-   .section.text.unlikely
-.LCOLDB156:
-   .text
-.LHOTB156:
-   .p2align 4,,15
-   .globl  _ZThn16_N6KParts13ReadWritePartD0Ev
-   .type   _ZThn16_N6KParts13ReadWritePartD0Ev, @function
-_ZThn16_N6KParts13ReadWritePartD0Ev:
-.LFB6690:
-   .cfi_startproc
-   subq$16, %rdi
-   jmp _ZN6KParts13ReadWritePartD0Ev
-   .cfi_endproc
-.LFE6690:
-   .size   _ZThn16_N6KParts13ReadWritePartD0Ev,
.-_ZThn16_N6KParts13ReadWritePartD0Ev
-   .section.text.unlikely
...
.section.rodata
.align 32
.type  
_ZZN6KParts13ReadWritePart11setModifiedEbE19__PRETTY_FUNCTION__, @object
@@ -18015,8 +17937,8 @@
.quad   _ZNK6KParts13ReadWritePart10metaObjectEv
.quad   _ZN6KParts13ReadWritePart11qt_metacastEPKc
.quad   _ZN6KParts13ReadWritePart11qt_metacallEN11QMetaObject4CallEiPPv
-   .quad   _ZN6KParts13ReadWritePartD1Ev
-   .quad   _ZN6KParts13ReadWritePartD0Ev
+   .quad   __cxa_pure_virtual
+   .quad   __cxa_pure_virtual
.quad   _ZN7QObject5eventEP6QEvent
.quad   _ZN7QObject11eventFilterEPS_P6QEvent
.quad   _ZN7QObject10timerEventEP11QTimerEvent
@@ -18050,8 +17972,8 @@
.quad   16
.quad   -16
.quad   _ZTIN6KParts13ReadWritePartE
-   .quad   _ZThn16_N6KParts13ReadWritePartD1Ev
-   .quad   _ZThn16_N6KParts13ReadWritePartD0Ev
+   .quad   __cxa_pure_virtual
+   .quad   __cxa_pure_virtual
.quad   _ZN6KParts8PartBase16setComponentDataERK14KComponentData
.quad   _ZN6KParts8PartBase16setComponentDataERK14KComponentDatab
.quad   0
@@ -18070,8 +17992,8 @@
.quad   -32
.quad   -32
.quad   _ZTIN6KParts13ReadWritePartE
-   .quad   _ZTv0_n24_N6KParts13ReadWritePartD1Ev
-   .quad   _ZTv0_n24_N6KParts13ReadWritePartD0Ev
+   .quad   __cxa_pure_virtual
+   .quad   __cxa_pure_virtual
.quad   _ZNK13KXMLGUIClient6actionERK11QDomElement
.quad   _ZNK13KXMLGUIClient16actionCollectionEv
.quad   _ZNK13KXMLGUIClient13componentDataEv
@@ -18137,5 +18059,5 @@
 _ZN6KParts4Part25staticMetaObjectExtraDataE:
.quad   0
.quad  
_ZN6KParts4Part18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv
-   .ident  GCC: (GNU) 4.9.0 20140314 (experimental)
+   .ident  GCC: (GNU) 4.9.0 20140318 (experimental)
.section.note.GNU-stack,,@progbits


[Bug c++/60579] Segmentation fault on variadic 'using' within variadic template class

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60579

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
This got fixed with r201469 on the trunk.


[Bug target/60580] New: aarch64 generates wrong code for __attribute__ ((optimize(no-omit-frame-pointer)))

2014-03-19 Thread chemobejk at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60580

Bug ID: 60580
   Summary: aarch64 generates wrong code for __attribute__
((optimize(no-omit-frame-pointer)))
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chemobejk at gmail dot com

Created attachment 32388
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32388action=edit
Example C code used i the command lines

We have a piece of code that we compile with -fomit-frame-pointer. The
exception is one low-level function that *MUST NOT* rely on the SP register,
i.e. that one function must be compiled with -fno-omit-frame-pointer. This
works fine with the GCC ARM backend, i.e. we have in the C code the following
function attribute:

 /*
  * This function calls XXX(), which modifies SP. This is incompatible to
  * -fomit-frame-pointer generated code as SP is used to access the frame.
  */
 __attribute__ ((optimize(no-omit-frame-pointer)))
 void some_low_level_function()


We are now trying to compile that piece of code with the aarch64 backend and
get incorrect code that uses SP to access the frame. I tried with the following
pre-compiled aarch64 toolchains:


Linaro release 2014.02:
COLLECT_GCC=gcc-linaro-aarch64-linux-gnu-4.8-2014.02_linux/bin/aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/workarea/stefanb/playground/aarch64/gcc-linaro-aarch64-linux-gnu-4.8-2014.02_linux/bin/../libexec/gcc/aarch64-linux-gnu/4.8.3/lto-wrapper
Target: aarch64-linux-gnu
Configured with:
/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/gcc-linaro-4.8-2014.02/configure
--build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu
--target=aarch64-linux-gnu
--prefix=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install
--with-sysroot=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install/aarch64-linux-gnu/libc
--enable-languages=c,c++,fortran --disable-multilib --enable-multiarch
--with-arch=armv8-a --with-pkgversion='crosstool-NG linaro-1.13.1-4.8-2014.02 -
Linaro GCC 2014.02' --with-bugurl=https://bugs.launchpad.net/gcc-linaro
--enable-__cxa_atexit --disable-libmudflap --enable-libgomp --disable-libssp
--with-gmp=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-mpfr=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-mpc=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-isl=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-cloog=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--with-libelf=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static
--enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id
--enable-plugin
--with-local-prefix=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install/aarch64-linux-gnu/libc
--enable-c99 --enable-long-long
Thread model: posix
gcc version 4.8.3 20140203 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.02
- Linaro GCC 2014.02)


Android AOSP:

COLLECT_GCC=prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.8/bin/aarch64-linux-android-gcc
 
COLLECT_LTO_WRAPPER=/workarea/stefanb/repos/tmake-only/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.8/bin/../libexec/gcc/aarch64-linux-android/4.8/lto-wrapper
 
Target: aarch64-linux-android   
Configured with: /tmp/AOSP-toolchain/build/../gcc/gcc-4.8/configure
--prefix=/tmp/toolchain-build-aarch64-linux-4.8/prefix
--target=aarch64-linux-android --host=x86_64-linux-gnu --build=x86_64-linux-gnu
--with-gnu-as --with-gnu-ld --enable-languages=c,c++
--with-gmp=/tmp/toolchain-build-aarch64-linux-4.8/temp-install
--with-mpfr=/tmp/toolchain-build-aarch64-linux-4.8/temp-install
--with-mpc=/tmp/toolchain-build-aarch64-linux-4.8/temp-install
--with-cloog=/tmp/toolchain-build-aarch64-linux-4.8/temp-install
--with-isl=/tmp/toolchain-build-aarch64-linux-4.8/temp-install
--with-ppl=/tmp/toolchain-build-aarch64-linux-4.8/temp-install
--disable-ppl-version-check --disable-cloog-version-check
--disable-isl-version-check --enable-cloog-backend=isl
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--disable-libssp --enable-threads --disable-nls --disable-libmudflap
--disable-libgomp --disable-libstdc__-v3 --disable-sjlj-exceptions
--disable-shared --disable-tls --disable-libitm --enable-initfini-array
--disable-nls --prefix=/tmp/toolchain-build-aarch64-linux-4.8/prefix
--with-sysroot=/tmp/toolchain-build-aarch64-linux-4.8/prefix/sysroot
--with-binutils-version=2.23 

[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined

2014-03-19 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-19
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
Confirmed.  Will look into it.


[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined

2014-03-19 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0


[Bug middle-end/54561] incorrect setjmp -Wclobber diagnostics

2014-03-19 Thread mikpelinux at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54561

--- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com ---
(In reply to Matthieu Patou from comment #3)
   volatile proto_tree *tmptree = NULL;

Try

proto_tree * volatile tmptree = NULL;

It's the variable itself that needs to be volatile, not the memory it points
to.


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.0


[Bug c/60581] New: gcc doesn't isssue a strict aliasing warning on a code that seems to break it

2014-03-19 Thread galtgendo at o2 dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60581

Bug ID: 60581
   Summary: gcc doesn't isssue a strict aliasing warning on a code
that seems to break it
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: galtgendo at o2 dot pl

The problem is described here: https://bugs.gentoo.org/show_bug.cgi?id=505026
The code to trigger comes from a launchpad bug:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1072650

As you may notice, it's acros distros and affects many compiler versions
(confirmed for 4.6.3 on ubuntu, 4.7.3 and 4.8.2 on Gentoo).

Following code (AFAICT) violates strict aliasing rules:
#include stdio.h

struct psuedo_hdr
{
  int saddr;
  int daddr;
  char zero;
  char protocol;
  short len;
} __attribute__((packed));

int main()
{
  unsigned int i;
  unsigned int sum = 0;
  struct psuedo_hdr hdr;

  hdr.saddr = 0xaabbccdd;
  hdr.daddr = 0x11223344;
  hdr.zero = 0;
  hdr.protocol = 6;
  hdr.len = 2;
  for (i = 0; i  sizeof(hdr); i += 2)
sum += *(short *)((char *)(hdr) + i);
  printf(0x%x\n, sum);
  return 0;
}

however, '-O2 -Wall' doesn't result in the strict aliasing warning.


[Bug tree-optimization/60559] [4.9 Regression] g++.dg/vect/pr60023.cc fails with -fno-tree-dce (ICE)

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60559

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Wed Mar 19 09:13:32 2014
New Revision: 208676

URL: http://gcc.gnu.org/viewcvs?rev=208676root=gccview=rev
Log:
PR tree-optimization/60559
* vectorizable_mask_load_store): Replace scalar MASK_LOAD
with build_zero_cst assignment.

* g++.dg/vect/pr60559.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/vect/pr60559.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c


[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543

--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Wed Mar 19 09:22:15 2014
New Revision: 208677

URL: http://gcc.gnu.org/viewcvs?rev=208677root=gccview=rev
Log:
2014-03-19  Richard Biener  rguent...@suse.de

PR lto/59543
* lto-streamer-in.c (input_function): In WPA stage do not drop
debug stmts.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c


[Bug fortran/60582] New: gfortran.dg/fmt_en.f90 FAILs on Solaris 9/x86

2014-03-19 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60582

Bug ID: 60582
   Summary: gfortran.dg/fmt_en.f90 FAILs on Solaris 9/x86
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: dominiq at lps dot ens.fr, jvdelisle at gcc dot gnu.org
  Host: i386-pc-solaris2.9
Target: i386-pc-solaris2.9
 Build: i386-pc-solaris2.9

As already reported in PR fortran/60128, the new gfortran.dg/fmt_en.f90
testcase
FAILs on Solaris 9/x86:

FAIL: gfortran.dg/fmt_en.f90  -O0  execution test
FAIL: gfortran.dg/fmt_en.f90  -O1  execution test
FAIL: gfortran.dg/fmt_en.f90  -O2  execution test
FAIL: gfortran.dg/fmt_en.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/fmt_en.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/fmt_en.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/fmt_en.f90  -O3 -g  execution test
FAIL: gfortran.dg/fmt_en.f90  -Os  execution test

Some analysis has already been done in that PR; I won't repeat it here.

One additional data point: unlike Solaris 10+, Solaris 9 lacks fenv.h.

  Rainer


[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org ---
Fixed.


[Bug fortran/60582] gfortran.dg/fmt_en.f90 FAILs on Solaris 9/x86

2014-03-19 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60582

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0


[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

2014-03-19 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE ---
 --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 Rainer,

 can you test the following patch?

 --- _clean/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-04
 17:51:04.0 +0100
 +++ work/gcc/testsuite/gfortran.dg/fmt_en.f902014-03-18 18:08:22.0
 +0100
 @@ -128,6 +128,9 @@ contains
else if (i == 3) then
  write(s, fmt) real(x,kind=j(3))
else if (i == 4) then
 +! skip if real(16) are not rounded to nearest (Solaris 9/x86)
 +write(s, '(F3.1)') real(9.4905,kind=j(4))
 +if (s /= '9.5') exit
  write(s, fmt) real(x,kind=j(4))
end if
n_tst = n_tst + 1

This passes on both i386-pc-solaris2.9 and i386-pc-solaris2.11.

Rainer


[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

2014-03-19 Thread ro at CeBiTec dot Uni-Bielefeld.DE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128

--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE ---
 --- Comment #25 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
 (In reply to Dominique d'Humieres from comment #21)
  We can xfail the test case if we are certain of the problem.
 
 What I don't see is how to xfail only some tests for real(16). Anyway,
 Rainer could open a new PR for the solaris issue and close this one as FIXED?

 What we should do is break the test case into two test cases one for quad16 
 and
 the other for the rest.  Then we XFAIL the quad16 one for solaris.  I think we

Agreed, that's better than silently exiting a test in certain
conditions, making it seem that it works while it actually doesn't.

 also need a new PR that is platform specific.  There may be some configury
 magic that needs to be done for Solaris to work correctly.

I've now filed PR fortran/60582.

Rainer


[Bug libstdc++/54316] [C++11] move constructor for stringstream

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316

--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
That would be very welcome, thanks, Howard.

We hope to complete the C++11 library for the next major release after 4.9, but
there's still quite a lot to do. I haven't even analysed what we need to do to
add move support to our streams (maybe Paolo has done).


[Bug fortran/60576] [4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
I can't reproduce it, in any case, this seems to have been broken before as
well
and starting with 208668 I get valgrind error about memcpy with overlapping
arguments.
The bug seems in:
class.5._data.dim[0 ...] = at.dim[0 ...];
at apparently has dim FIELD_DECL as array of 2 (24-byte) structs, i.e. 48 bytes
long, while the ARRAY_RANGE_REF around it accesses 7 24-byte structs, i.e. 168
bytes.


[Bug fortran/60576] [4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0


[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined

2014-03-19 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569

--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
struct A
{
  void foo ();
  struct
  {
int i;
void bar () { i = 0; }
  } s;
};

void A::foo () { s.bar (); }


[Bug c++/60574] [4.9 Regression] [c++1y] ICE with deduced return type in virtual function and LTO

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60574

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Hmm, so maybe we should reject it again?


[Bug c++/60572] [4.9 Regression] ICE deriving from class with invalid member

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60572

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5


[Bug c/60581] gcc doesn't isssue a strict aliasing warning on a code that seems to break it

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60581

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||alias, diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-19
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
The strict-aliasing warnings are broken - they are too easily to silence (the
(char *) cast for example).  Generally warning for TBAA violations is very hard
if you want to avoid gazillions of false positives or gazillions of false
negatives.  The present warning code delivers neither :/


[Bug tree-optimization/60577] [4.9 Regression] inefficient FDO instrumentation code

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-03-19
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
Summary|inefficient FDO |[4.9 Regression]
   |instrumentation code|inefficient FDO
   ||instrumentation code
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
I will have a look.


[Bug fortran/60576] [4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
at's dim array is created by:
#6  0x006fc242 in gfc_get_array_descriptor_base (dimen=2, codimen=0,
restricted=true, akind=GFC_ARRAY_ALLOCATABLE)
at ../../gcc/fortran/trans-types.c:1754
where the dimen=2 causes the dim array to be sized with 2 elements only, while
the larger ARRAY_REF comes from:
#4  0x00e58b85 in build4_stat (code=ARRAY_RANGE_REF, tt=array_type
0x719f0540, arg0=component_ref 0x71a08510, 
arg1=integer_cst 0x718afa00, arg2=tree 0x0, arg3=tree 0x0) at
../../gcc/tree.c:4241
#5  0x006a8a72 in build4_stat_loc (loc=2692, code=ARRAY_RANGE_REF,
type=array_type 0x719f0540, arg0=component_ref 0x71a08510, 
arg1=integer_cst 0x718afa00, arg2=tree 0x0, arg3=tree 0x0) at
../../gcc/tree.h:3499
#6  0x006a98ff in class_array_data_assign (block=0x7fffd810,
lhs_desc=component_ref 0x71a08390, 
rhs_desc=var_decl 0x71a052f8 at, lhs_type=true) at
../../gcc/fortran/trans-expr.c:318
#7  0x006a9ef5 in gfc_conv_derived_to_class (parmse=0x7fffd9a0,
e=0x1cd0640, class_ts=..., vptr=tree 0x0, optional=false, 
optional_alloc_ptr=false) at ../../gcc/fortran/trans-expr.c:427
#8  0x006b3d51 in gfc_conv_procedure_call (se=0x7fffdbe0,
sym=0x1ccc570, args=0x1c63760, expr=0x0, append_args=0x0)
at ../../gcc/fortran/trans-expr.c:4039

The bug is in there already in r189800:
./f951.189800 -quiet -O2 assumed_rank_7.f90 -mstringop-strategy=libcall;
gfortran -o assumed_rank_7{,.s}; valgrind ./assumed_rank_7; echo $?
==7529== Memcheck, a memory error detector
==7529== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7529== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==7529== Command: ./assumed_rank_7
==7529== 
==7529== Source and destination overlap in memcpy(0xfff0001b8, 0xfff000168,
168)
==7529==at 0x4A0A403: memcpy@@GLIBC_2.14 (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7529==by 0x400F5B: MAIN__ (in /usr/src/gcc-test/obj/gcc/assumed_rank_7)
==7529==by 0x4007AC: main (in /usr/src/gcc-test/obj/gcc/assumed_rank_7)
and r189600 still rejected this code, so to me this doesn't look like a
regression, but miscompilation from the day one when this particular feature
has been enabled.


[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault

2014-03-19 Thread jamborm at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419

--- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org ---
Good job reducing the testcase to something this small!

Anyway, Jakub's analysis of what is going on is still correct and all
the high level decisions that we do are IMHO correct too.  The
invocation of symtab_remove_unreachable_symbols that removes the
callers is called with before_inlining_p set to false, even though
that is not technically right, we are still in the middle of inlining
because we are about to inline functions which are called only once.
But the comment in function ipa_inline says this is deliberate because
it helps to find the functions which are only called once.

However, this means that when symtab_remove_unreachable_symbols
correctly figures out that we can devirtualize to the offending thunk,
it assumes that cannot lead to any further inlining.  Because the
thunk is keyed in another compilation unit, it decides it only needs
to keep the symtab node but not the body.  In its terminology, the
node is in the boundary.  The way the function cripples these
boundary nodes is actually the problem because it removes all callees
but not the thunk flag.  This leaves us with a thunk with no callee,
something that should not happen (and there is even a bit in the call
graph verifier that checks it).  Later on, we do perform this
devirtualization during inlining of functions only called once and
connect the crippled thunk to the call graph.  The first time we want
to follow through it, we segfault.

I believe that we do not want to allow thunks with no callees.  This
would mean changing every user of cgraph_function_node so that it can
cope with NULL return value and that is ugly and inconvenient.  This
leaves us with two options.  Either we make
symtab_remove_unreachable_symbols keep callees of thunks when it keeps
the thunk or we simply clear the thunk_p flag.  Given that thunks and
aliases are quite similar and we do clear the alias flag, and that
this should only ever affect nodes that we are not going to output, I
tend to believe the second approach is OK and of course it is much
simpler.  But before I propose the following fix on the mailing list,
I'll try to build some big C++ application with it:

diff --git a/gcc/ipa.c b/gcc/ipa.c
index 572dba1..164de0d 100644
--- a/gcc/ipa.c
+++ b/gcc/ipa.c
@@ -488,6 +488,7 @@ symtab_remove_unreachable_nodes (bool before_inlining_p,
FILE *file)
  node-definition = false;
  node-cpp_implicit_alias = false;
  node-alias = false;
+ node-thunk.thunk_p = false;
  node-weakref = false;
  if (!node-in_other_partition)
node-local.local = false;


[Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nathan at acm dot org

--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
In 4.6 for some unknown reason we are able to disambiguate

  *.LPBX1[0] and p_3(D)-buf and *D.1606_14

we built the static decls with !TREE_ADDRESSABLE, but starting with
4.7 we unconditionally set TREE_ADDRESSABLE on the decl (which formerly
was only set in case we asked for the address of it via
tree_coverage_counter_addr).

This happened with the big re-org in r181105 but undoing that change
does not fix the regression.  This is because the TREE_ADDRESSABLE
flag is set again in canonicalize_constructor_val:

#0  0x00932775 in canonicalize_constructor_val (
cval=addr_expr 0x76d74900, from_decl=tree 0x0)
at /space/rguenther/src/svn/trunk/gcc/gimple-fold.c:207
#1  0x00798015 in record_reference (tp=0x76d73698, 
walk_subtrees=0x7fffd858, data=0x7fffdb50)
at /space/rguenther/src/svn/trunk/gcc/cgraphbuild.c:62
#2  0x00e6859f in walk_tree_1 (tp=0x76d73698, 
func=0x797fdd record_reference(tree*, int*, void*), data=0x7fffdb50, 
pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10921
#3  0x00e6892c in walk_tree_1 (tp=0x76d736d0, 
func=0x797fdd record_reference(tree*, int*, void*), data=0x7fffdb50, 
pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10998
#4  0x00e6892c in walk_tree_1 (tp=0x76d78808, 
func=0x797fdd record_reference(tree*, int*, void*), data=0x7fffdb50, 
pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10998
#5  0x00e6892c in walk_tree_1 (tp=0x76d788a0, 
func=0x797fdd record_reference(tree*, int*, void*), data=0x7fffdb50, 
pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10998
#6  0x00798d82 in record_references_in_initializer (
decl=var_decl 0x76d78850 __gcov_.access_buf, only_vars=false)
at /space/rguenther/src/svn/trunk/gcc/cgraphbuild.c:435
#7  0x00eac7fa in varpool_analyze_node (node=0x76d498f0)
at /space/rguenther/src/svn/trunk/gcc/varpool.c:398

thus we _do_ take the address of the variable, from the global
constructor of __gcov.access_buf which looks like

{.D.1783=*.LPBX0, .D.1784=1, .D.1785=4186437761, .D.1786=449688241,
.D.1787={{.D.1780=3, .D.1781=__gcov0.access_buf}, {.D.1780=1,
.D.1781=__gcov8.access_buf}}}

thus indeed p-buf may point to __gcov0.access_buf[1] and we can't optimize
those accesses.  This object was simply not present in GCC 4.6 and thus
TREE_ADDRESSABLE was never set and thus we could optimize this.

Which means the revision cited doesn't cause the regression (I highly doubt
so at least), but instead whoever added code to build that record or
whoever added code to record references in initializers (and set
TREE_ADDRESSABLE in that path... - coverage.c fails to do that and builds
a lot of addresses from the counters in places).

The idea of canonicalize_constructor_value is that the result will end up
in actual stmts, thus the addressable flag is important.  In this case
we only record references for the IPA references struct - thus setting
the flag there isn't important (well, that's not entirely true ... alias
disambiguation depends on the order of processing functions then).

Fixing both fixes the regression.

Index: gcc/coverage.c
===
--- gcc/coverage.c  (revision 208642)
+++ gcc/coverage.c  (working copy)
@@ -466,6 +466,8 @@ tree_coverage_counter_addr (unsigned cou
   gcc_assert (no  fn_n_ctrs[counter] - fn_b_ctrs[counter]);
   no += fn_b_ctrs[counter];

+  TREE_ADDRESSABLE (fn_v_ctrs[counter]) = 1;
+
   /* no here is an array index, scaled to bytes later.  */
   return build_fold_addr_expr (build4 (ARRAY_REF, gcov_type_node,
   fn_v_ctrs[counter],
@@ -720,7 +722,6 @@ build_var (tree fn_decl, tree type, int
   memcpy (buf + len, fn_name, fn_name_len + 1);
   DECL_NAME (var) = get_identifier (buf);
   TREE_STATIC (var) = 1;
-  TREE_ADDRESSABLE (var) = 1;
   DECL_ALIGN (var) = TYPE_ALIGN (type);

   return var;
Index: gcc/gimple-fold.h
===
--- gcc/gimple-fold.h   (revision 208642)
+++ gcc/gimple-fold.h   (working copy)
@@ -22,6 +22,7 @@ along with GCC; see the file COPYING3.
 #ifndef GCC_GIMPLE_FOLD_H
 #define GCC_GIMPLE_FOLD_H

+extern tree canonicalize_constructor_val_1 (tree, tree, bool);
 extern tree canonicalize_constructor_val (tree, tree);
 extern tree get_symbol_constant_value (tree);
 extern void gimplify_and_update_call_from_tree (gimple_stmt_iterator *, tree);
Index: 

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703

--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
This is just totally broken and not supportable with LTO.  We'd need to amend
toplevel asm syntax to list defined and used symbols, but that doesn't fix
existing uses.

The proper fix is to excempt these files from LTO or move those assembler
functions to separate TUs (preferably assembler TUs...).

Honza also had the idea of trying to parse the assembler string for
obvious symbol definitions / uses.


[Bug c++/60583] New: Garbled data, temporary bound ... only persists until the constructor exits, fine with clang++

2014-03-19 Thread andreaskem at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60583

Bug ID: 60583
   Summary: Garbled data, temporary bound ... only persists until
the constructor exits, fine with clang++
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andreaskem at web dot de

Created attachment 32389
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32389action=edit
Problematic code

Hello,

I have a problem with the following code (boiled down from a larger source file
exhibiting the problem):

//
#include iostream

using namespace std;

struct Vector {
  double x;
  double y;
  double z;
};

class Baz {
  private:
Vector r;
Vector u;

  public:
Baz(const Vector p, const Vector v) : r{p.x,p.y,p.z}, u{v.x,v.y,v.z} {}

const Vector get_u() const {
  return(u);
};

void write() const {
  cout  r:   r.x  ,  r.y  ,  r.z  ; u:   u.x  ,
 u.y  ,  u.z  endl;
};
};

class Foo {
  private:
const Baz b;

  public:
Foo(const Baz b_) : b{b_} {}
void bar();
};

void Foo::bar() {
  b.write();
  int iters{10};
  b.write();
}

int main(void) {
  Baz b{Vector{0.5, 0.5, 0.5}, Vector{1e6, 0.1, 0.1}};
  Foo f{b};
  f.bar();
}
//

Compiling this with
---
$ g++ -Wall -Wextra -std=c++11 ~/test.cpp
---
leads to the following warnings:
---
***test.cpp: In constructor ‘Foo::Foo(const Baz)’:
***test.cpp:33:27: warning: a temporary bound to ‘Foo::b’ only persists until
the constructor exits [-Wextra]
***test.cpp: In member function ‘void Foo::bar()’:
***test.cpp:41:6: warning: unused variable ‘iters’ [-Wunused-variable]
---
and running the program shows that the data is garbled:
---
$ ./a.out
r: 6.95315e-310,2.07351e-317,0.5; u: 6.95315e-310,0.1,0.1
r: 6.95315e-310,2.07352e-317,0.5; u: 6.95315e-310,0.1,2.24932e-313
---

Using b(b_) instead of b{b_} seems to fix the first warning and the output. I
don't quite understand what is happening here. Moreover, clang++ (3.3 or 3.4)
does not print such a warning (it only complains about the unused iters
variable) and the output is not garbled:
---
$ clang++ -Wall -Wextra -std=c++11 ~/test.cpp; ./a.out
***test.cpp:41:6: warning: unused variable 'iters' [-Wunused-variable]
int iters{10};
^
1 warning generated.
r: 0.5,0.5,0.5; u: 1e+06,0.1,0.1
r: 0.5,0.5,0.5; u: 1e+06,0.1,0.1
---

What is going on here?

I tried two gcc versions, 4.7.2 and 4.8.2.
gcc version 4.7.2 (Debian 4.7.2-5)
(I am currently at work and have to use gcc 4.7.2 to create the .ii file
attached to my report)
I first noticed the problem on my home computer with
gcc version 4.8.2 20140206 (prerelease) (GCC)


Details:
gcc version 4.8.2 20140206 (prerelease) (GCC)
gcc version 4.7.2 (Debian 4.7.2-5)
clang version 3.4 (tags/RELEASE_34/final)
clang version 3.3 (tags/RELEASE_33/final)
Linux 3.13.6-1-ARCH #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014 x86_64 GNU/Linux

[Bug lto/60567] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-03-19
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Works for me - any more specifics?  Host/target?


[Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577

--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
So - if we delay marking any decl addressable during IPA reference recording
then we need an IPA pass that computes whether any of the taken IPA_REF_ADDR
may leak into the IL.  We need to do that conservatively before any alias
queries (thus eventually again at WPA stage to optimize more).

So if there isn't any reference to __gcov_.access_buf inside the program
this would make us optimize things again.

But there is one from .LPBX1 in the testcase which is refered to from .LPBX0
which is refered from _GLOBAL__sub_I_65535_0_access_buf, so it doesn't
help ... (and it seems it really is necessary to have those addresses)

Considering LTO-ing libgcov there is no way we can magically mark those decls
to be disregarded from alias analysis either.

Which leaves the possibility of more cleverly instrumenting the program
in the first place ...


[Bug c++/60584] New: std::vector::emplace_back(...) use move constructor

2014-03-19 Thread ruslan at mullakh dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60584

Bug ID: 60584
   Summary: std::vector::emplace_back(...) use move constructor
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ruslan at mullakh dot com

Created attachment 32390
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32390action=edit
sample code

the attached peace of code does not compile. complains on deleted move
constructor.

clang compile this sample, and as far as I understand standard it is valid
c++11.


build cmd:

g++-4.8 -std=c++11 /tmp/test.cpp


[Bug c++/60584] std::vector::emplace_back(...) use move constructor

2014-03-19 Thread ruslan at mullakh dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60584

--- Comment #1 from Ruslan Mullakhmetov ruslan at mullakh dot com ---
Created attachment 32391
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32391action=edit
compiler output


[Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577

--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
 Which leaves the possibility of more cleverly instrumenting the program
 in the first place ...

Which shouldn't be so hard as we are in SSA form and have loop structures
set up.  But it's of course old code (profile.c:branch_prob) which was
written with only a CFG in mind.  Unfortunately the code chooses
to instrument a non-latch edge in the testcase (loop latches would have
been easy to special-case in gimple_gen_edge_profiler).  This is the
other edge out of a block with a loop exit - so we can special-case
single-exit loops that have such edge instrumented where the edge source
dominates the loop latch.  Or find some even more clever way of placing
the loads / stores (you can always use a scalar as counter and load/store
in a dominating / post-dominating block of course, but that may have
detrimental effects on register pressure ...).  Maybe still do that, but
only if the counter update is in a loop.  Note that applying store motion
here may introduce no-op load/store which may have issues with thread
safety.


[Bug c++/60585] New: Virtual function related memory access errors with multiple virtual inheritance

2014-03-19 Thread andris.pavenis at iki dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585

Bug ID: 60585
   Summary: Virtual function related memory access errors with
multiple virtual inheritance
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andris.pavenis at iki dot fi

Created attachment 32392
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32392action=edit
Simplified C++ test example

The attached reduced example causes valgrind to complain about access to
uninitialized value when built with gcc-4.9.0 20140318 on Linux (both i86 and
x86_64, included output is from 32 bit version):

andpav@andris-HP-Z230:~/Tests/2014-03-18$ g++-4.9 -O2 -Wall -Wextra virtual.cpp 
andpav@andris-HP-Z230:~/Tests/2014-03-18$ valgrind ./a.out 
==10812== Memcheck, a memory error detector
==10812== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10812== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==10812== Command: ./a.out
==10812== 
==10812== Use of uninitialised value of size 4
==10812==at 0x80484C6: virtual thunk to F::f() const (in
/home/andpav/Tests/2014-03-18/a.out)
==10812==by 0x8048379: main (in /home/andpav/Tests/2014-03-18/a.out)
==10812== 
==10812== 
==10812== HEAP SUMMARY:
==10812== in use at exit: 0 bytes in 0 blocks
==10812==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==10812== 
==10812== All heap blocks were freed -- no leaks are possible
==10812== 
==10812== For counts of detected and suppressed errors, rerun with: -v
==10812== Use --track-origins=yes to see where uninitialised values come from
==10812== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
andpav@andris-HP-Z230:~/Tests/2014-03-18$ g++-4.9 -v
Using built-in specs.
COLLECT_GCC=g++-4.9
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.9.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.9-20140318/configure --program-suffix=-4.9
--enable-languages=c,c++ --enable-lto
Thread model: posix
gcc version 4.9.0 20140318 (experimental) (GCC) 

There are also ocasional crashes (SIGSEGV) in real software from which the
reduced example has been created.

Also reproduced with gcc-4.8 (Fedora 20 x86_64 and Ubuntu 13.10 i686) and
gcc-4.7 (Ubuntu-13.10 i686). Does not happen with gcc-4.6 (Ubuntu 12.04)

Also specifying -fno-inline-small-functions together with -O2 or -O3 for
affected gcc versions make the problem not happen (both reduced example and
real software)


[Bug lto/60567] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233

2014-03-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567

--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
 Works for me - any more specifics?  Host/target?

gcc version 4.9.0 20140319, r208679.
Target: x86_64-unknown-linux-gnu
CentOS 6.5, glibc-2.12-1.132, binutils-2.20.51.0.2-5.36

Seems to be a problem of Binutils. If I use the current Binutils from
binutils-gdb git (= 2.24.51.20140319), it works.


The question is whether one can do something about it instead of ICEing. And
whether the other PRs (PR56775, PR56963 and PR57715) might have the same
problem.


[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined

2014-03-19 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569

--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Wed Mar 19 12:25:04 2014
New Revision: 208681

URL: http://gcc.gnu.org/viewcvs?rev=208681root=gccview=rev
Log:
PR sanitizer/60569
* ubsan.c (ubsan_type_descriptor): Check that DECL_NAME is nonnull
before accessing it.
testsuite/
* g++.dg/ubsan/pr60569.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr60569.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c


[Bug sanitizer/60569] Segfault with -flto and -fsanitize=undefined

2014-03-19 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60569

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Fixed.


[Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577

--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 32393
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32393action=edit
hack

Like this (hack alert).  Applies store motion one level for a restricted set
of loops.  Requires us to add preheaders and record exits (and disambiguate
multiple latches) and compute dominators.


[Bug middle-end/60586] New: [Cilk+] Parameters evaluation happens inside spawn worker

2014-03-19 Thread izamyatin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60586

Bug ID: 60586
   Summary: [Cilk+] Parameters evaluation happens inside spawn
worker
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com

Following test (compiled with eg -O2 -fcilkplus -lcilkrts)

#include stdio.h
#include cilk/cilk.h 
#include unistd.h 

int noop(int x)
{
return x;
}

int post_increment(int *x)
{
sleep(1);
return (*x)++;
}

int main(int argc, char *argv[])
{
int m = 5;
int n = m;
int r = cilk_spawn noop(post_increment(n));
int n2 = n;
cilk_sync;

printf(After sync: m = %d, n = %d, r = %d, n2 = %d\n, m, n, r, n2);

if (r != m || n2 != m + 1)
printf(FAILED\n);
else
printf(PASSED\n);

return 0;
}
outputs

After sync: m = 5, n = 6, r = 5, n2 = 5
FAILED

That happens because post_increment is called inside spawn worker which is
incorrect.


[Bug target/60580] aarch64 generates wrong code for __attribute__ ((optimize(no-omit-frame-pointer)))

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60580

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
This is a complete mess, what aarch64 backend does is completely incompatible
with optimize attribute.  I've tried to fix this up:
--- gcc/config/aarch64/aarch64.opt.jj2014-01-20 14:50:22.0 +0100
+++ gcc/config/aarch64/aarch64.opt2014-03-19 11:52:29.963772607 +0100
@@ -59,6 +59,11 @@ const char *aarch64_cpu_string
 Variable
 const char *aarch64_tune_string

+; Did we set flag_omit_frame_pointer just so aarch64_frame_pointer_required
+; would be called?
+Variable
+bool faked_omit_frame_pointer
+
 mbig-endian
 Target Report RejectNegative Mask(BIG_END)
 Assume target CPU is configured as big endian
--- gcc/config/aarch64/aarch64.c.jj2014-03-18 12:26:13.0 +0100
+++ gcc/config/aarch64/aarch64.c2014-03-19 12:20:19.471504562 +0100
@@ -315,10 +315,6 @@ static GTY(()) int gty_dummy;
 #define AARCH64_NUM_BITMASKS  5334
 static unsigned HOST_WIDE_INT aarch64_bitmasks[AARCH64_NUM_BITMASKS];

-/* Did we set flag_omit_frame_pointer just so
-   aarch64_frame_pointer_required would be called? */
-static bool faked_omit_frame_pointer;
-
 typedef enum aarch64_cond_code
 {
   AARCH64_EQ = 0, AARCH64_NE, AARCH64_CS, AARCH64_CC, AARCH64_MI, AARCH64_PL,
@@ -5278,7 +5274,11 @@ aarch64_override_options (void)
 static void
 aarch64_override_options_after_change (void)
 {
-  faked_omit_frame_pointer = false;
+  if (global_options_set.x_flag_omit_frame_pointer)
+{
+  faked_omit_frame_pointer = false;
+  global_options_set.x_faked_omit_frame_pointer = false;
+}

   /* To omit leaf frame pointers, we need to turn flag_omit_frame_pointer on
so
  that aarch64_frame_pointer_required will be called.  We need to remember
@@ -5288,6 +5288,9 @@ aarch64_override_options_after_change (v
 {
   flag_omit_frame_pointer = true;
   faked_omit_frame_pointer = true;
+  global_options_set.x_faked_omit_frame_pointer
+= global_options_set.x_flag_omit_frame_pointer;
+  global_options_set.x_flag_omit_frame_pointer = false;
 }
 }

but while that fixes some of the cases, it doesn't fix everything, the problem
is that the non-TargetVariable Variables aren't actually Saved.

Now, i386 backend seems to handle it differently, instead of adding a
faked_omit_frame_pointer variable (which, as this PR suggests would need to be
handled as an Optimization Saved variable, but supposedly the opts framework
doesn't allow it yet), it clears omit_leaf_frame_pointer flag if
flag_omit_frame_pointer is true:
  /* Keep nonleaf frame pointers.  */
  if (opts-x_flag_omit_frame_pointer)
opts-x_target_flags = ~MASK_OMIT_LEAF_FRAME_POINTER;
  else if (TARGET_OMIT_LEAF_FRAME_POINTER_P (opts-x_target_flags))
opts-x_flag_omit_frame_pointer = 1;
but does that only in in override_options hook.  That means that
say for -fomit-frame-pointer -momit-leaf-frame-pointer on the command line
supposedly that turns off TARGET_OMIT_LEAF_FRAME_POINTER and when some function
has __attribute__((optimize (no-omit-frame-pointer))) and is leaf, frame
pointer will not be omitted there.  But for -fno-omit-frame-pointer
-momit-leaf-frame-pointer on the command line and __attribute__((optimize
(no-omit-frame-pointer))) supposedly it will not have frame pointer if it is
leaf.
The primary issue is that flag_omit_frame_pointer is Optimization Save flag,
while omit-leaf-frame-pointer is typcially Target Save, the former optimize
attribute thing, the latter target attribute thing.

Not sure what is the best way out of this, but I guess doing in aarch64 what
i386 does would be significant progress.


[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553

--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
I've posted the patches but I'm curious if the 2nd change alone helps enough. 
The first is somewhat handwaving (because we also have type_non_common which
breaks the argument of the former).


[Bug c++/60583] Garbled data, temporary bound ... only persists until the constructor exits, fine with clang++

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60583

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
This got fixed with r207164 on the trunk, whether that change is backportable
and desirable for 4.8 I'll leave to Jason.


[Bug fortran/60549] [4.9 Regression] Run time doubled for fatigue.f90 due to SAVE changes

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60549

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
The change has been reverted, therefore the regression should be gone.


[Bug c++/60583] Garbled data, temporary bound ... only persists until the constructor exits, fine with clang++

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60583

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
As this is DR1288 it's a dup of PR50025


[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025

--- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org ---
For the record, I think r207164 fixed this


[Bug tree-optimization/60559] [4.9 Regression] g++.dg/vect/pr60023.cc fails with -fno-tree-dce (ICE)

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60559

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Fixed.


[Bug c++/60583] Garbled data, temporary bound ... only persists until the constructor exits, fine with clang++

2014-03-19 Thread andreaskem at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60583

--- Comment #3 from andreaskem at web dot de ---
Thank you.

I looked around but did not find those reports. Sorry for that.


[Bug libstdc++/60584] std::vector::emplace_back(...) use move constructor

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60584

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
I don't know what clang does to compile it, but the code is not valid.

vectorT::emplace_back requires that T is MoveInsertable into the vector. Foo
fails that requirement because it has a deleted copy constructor and deleted
move constructor, because NonCopyable has a user-provided copy constructor
defined as deleted.

If you want NonCopyable to be movable then you need to do this:

class NonCopyable
{
public:
NonCopyable(){}
NonCopyable(const NonCopyable ) = delete;
NonCopyable(NonCopyable ) = default;
};

With that move constructor the code works.


[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used

2014-03-19 Thread mpolacek at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
If the warning is present with .i but not with .c, then we can't do much about
it without the .c file with its headers.


[Bug c++/60585] Virtual function related memory access errors with multiple virtual inheritance

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-19
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.0


[Bug libstdc++/60587] New: debug-mode -std=c++11 vector::insert(pos, begin, end) dereferences begin too eagerly

2014-03-19 Thread sbergman at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60587

Bug ID: 60587
   Summary: debug-mode -std=c++11 vector::insert(pos, begin, end)
dereferences begin too eagerly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com

At least on recent trunk (r208675),

 $ cat test.cc
 #define _GLIBCXX_DEBUG
 #include vector
 int main() {
 std::vectorint a, b;
 a.push_back(1);
 a.insert(a.end(), b.begin(), b.end());
 }
 $ ~/gcc/trunk/inst/g++ -std=c++11 test.cc
 $ ./a.out
 ~/gcc/trunk/inst/include/c++/4.9.0/debug/safe_iterator.h:261:
 error: attempt to dereference a past-the-end iterator.

 Objects involved in the operation:
 iterator this @ 0x0x7fff0d764060 {
 type = 
 N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPiNSt9__cxx19986vectorIiSaIiENSt7__debug6vectorIiS6_
  (mutable iterator);
   state = past-the-end;
   references sequence with type `NSt7__debug6vectorIiSaIiEEE' @ 
 0x0x7fff0d764be0
 }

which

 Index: libstdc++-v3/include/debug/macros.h
 ===
 --- libstdc++-v3/include/debug/macros.h   (revision 208675)
 +++ libstdc++-v3/include/debug/macros.h   (working copy)
 @@ -106,7 +106,7 @@
  #define __glibcxx_check_insert_range(_Position,_First,_Last) \
  __glibcxx_check_valid_range(_First,_Last);   \
  __glibcxx_check_insert(_Position);   \
 -_GLIBCXX_DEBUG_VERIFY(__gnu_debug::__foreign_iterator(_Position,_First),\
 +_GLIBCXX_DEBUG_VERIFY(_First==_Last||__gnu_debug::__foreign_iterator(_Position,_First),\
 _M_message(__gnu_debug::__msg_insert_range_from_self)\
 ._M_iterator(_First, #_First) \
 ._M_iterator(_Last, #_Last)   \

works around for me.

[Bug target/60588] New: AVR target does not support init_priority attribute

2014-03-19 Thread senthil_kumar.selvaraj at atmel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60588

Bug ID: 60588
   Summary: AVR target does not support init_priority attribute
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: senthil_kumar.selvaraj at atmel dot com

The AVR target does not support init_priority attribute. This makes it hard to
control initialization order of global objects across translation units.

Was originally requested at
http://lists.nongnu.org/archive/html/avr-gcc-list/2014-03/msg5.html


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

--- Comment #3 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #2)
 --- part_good.s 2014-03-19 08:57:10.100342064 +0100
 +++ part_bad.s  2014-03-19 08:56:50.134141664 +0100
 -   .quad   _ZN6KParts13ReadWritePartD1Ev
 -   .quad   _ZN6KParts13ReadWritePartD0Ev
 +   .quad   __cxa_pure_virtual
 +   .quad   __cxa_pure_virtual

I have trouble believing this is causing the problem you are seeing; if
something were actually calling through this vtable slot it would write pure
virtual method called to stderr and then terminate.


[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used

2014-03-19 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749

--- Comment #4 from Martin Husemann martin at netbsd dot org ---
Yes - I'm still trying to reduce it to a reasonable test case, but in general
it works - so I am confused big time.
Also Julio (the ATF author) claims the same test works on FreeBSD with a very
similar compiler version.


[Bug other/60589] New: Parallel install fails

2014-03-19 Thread y.gribov at samsung dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60589

Bug ID: 60589
   Summary: Parallel install fails
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: y.gribov at samsung dot com
CC: burnus at gcc dot gnu.org

GCC parallel install has been broken for a couple of days. Symptoms:

test -z
/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk
|| /bin/mkdir -p
/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk
test -z
/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk
|| /bin/mkdir -p
/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk
 /usr/bin/install -c -m 644
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk_api.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk_api_linux.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk_stub.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk_undocumented.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/common.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/holder.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/hyperobject_base.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/metaprogramming.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_file.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_list.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_max.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_min.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_min_max.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opadd.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opand.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opmul.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opor.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_opxor.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_ostream.h
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/reducer_string.h
'/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk'
 /usr/bin/install -c -m 644
/home/ygribov/src/gcc-master/libcilkrts/include/cilk/cilk.h
'/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk'
/usr/bin/install: cannot change permissions of
`/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/cilk/cilk.h':
No such file or directory
make[3]: *** [install-nodist_cilkincludeHEADERS] Error 1
make[3]: *** Waiting for unfinished jobs

It looks like libcilkrts Makefile tries to install cilk.h twice in parallel (in
install-nodist_cilkinclude_HEADERS and install-cilkincludeHEADERS) and runs
into a conflict.

The error was probably introduced in r208440.

BTW could someone add libcilkrts to list of components?


[Bug testsuite/60590] New: Can't recreate the same executable in testsuite

2014-03-19 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60590

Bug ID: 60590
   Summary: Can't recreate the same executable in testsuite
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

On Linux, one can't run the command found in testsuite/gcc/gcc.log
to recreate the same executable since lib/target-libpath.exp sets
LD_RUN_PATH, which makes ld to set DT_RPATH.  But LD_RUN_PATH is
recorded in testsuite/gcc/gcc.log.  We may not set LD_RUN_PATH
when run the command to recreate the same executable.  As the result,
the executable generated by hand doesn't have DT_RPATH.


[Bug other/60589] Parallel install fails

2014-03-19 Thread y.gribov at samsung dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60589

Yury Gribov y.gribov at samsung dot com changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #1 from Yury Gribov y.gribov at samsung dot com ---
Created attachment 32394
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32394action=edit
Draft patch

Perhaps it's enough to simply remove cilk.h from cilkinclude_HEADERS? Attaching
draft patch.


[Bug libstdc++/54316] [C++11] move constructor for stringstream

2014-03-19 Thread howard.hinnant at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316

--- Comment #8 from Howard Hinnant howard.hinnant at gmail dot com ---
Here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.4.4%20-%20Class%20template%20basic_ios

is a good list of what needs to be done.  It is an old paper, so it needs to be
cross-checked against N3936.  But the differences (if any) should be few and
minor.

The changes in this part of the standard are confusing to understand, because
of the use of virtual inheritance.  However if one just blindly follows the
recipe, backed up by a few unit tests, things will just work.  The more
difficult parts are the concrete streambufs:  basic_filebuf and
basic_streambuf.  Once those are in place, the streams just fall into place
with very little code.


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

--- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #3)
 (In reply to Markus Trippelsdorf from comment #2)
  --- part_good.s 2014-03-19 08:57:10.100342064 +0100
  +++ part_bad.s  2014-03-19 08:56:50.134141664 +0100
  -   .quad   _ZN6KParts13ReadWritePartD1Ev
  -   .quad   _ZN6KParts13ReadWritePartD0Ev
  +   .quad   __cxa_pure_virtual
  +   .quad   __cxa_pure_virtual
 
 I have trouble believing this is causing the problem you are seeing; if
 something were actually calling through this vtable slot it would write
 pure virtual method called to stderr and then terminate.

part.ii is part of a library called libkparts.so.4.12.3.
When I compile part.cpp with a compiler before r208573 and link the 
library (all other objects files for the lib are unchanged) and then install
the library to my system /usr/lib folder, Okular starts and works fine.

If I compile part.cpp with a compiler _after_ r208573 and link the 
library and install it, Okular shows a popup Unable to find the Okular 
component.


[Bug c++/60332] [c++1y] ICE with auto in function-pointer cast

2014-03-19 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60332

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
I'm adding it to the testsuite.


[Bug fortran/60576] [4.8/4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.8.3
Summary|[4.9 Regression] FAIL:  |[4.8/4.9 Regression] FAIL:
   |gfortran.dg/assumed_rank_7. |gfortran.dg/assumed_rank_7.
   |f90 |f90


[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

2014-03-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553

--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Wed Mar 19 15:37:28 2014
New Revision: 208682

URL: http://gcc.gnu.org/viewcvs?rev=208682root=gccview=rev
Log:
2014-03-19  Richard Biener  rguent...@suse.de

PR middle-end/60553
* tree-core.h (tree_type_common): Re-order pointer members
to reduce recursion depth during GC walks.

lto/
* lto-tree.h (lang_tree_node): For types use TYPE_NEXT_VARIANT 
instead of TREE_CHAIN as chain_next.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-tree.h
trunk/gcc/tree-core.h


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #4)
 If I compile part.cpp with a compiler _after_ r208573 and link the 
 library and install it, Okular shows a popup Unable to find the Okular 
 component.

So, can you perhaps with the part_good.s put a breakpoint on the 2 dtors and 4
thunks to those, and see if they are ever called during the startup of Okular?
For the 2 dtors perhaps always look at the caller if it was a direct call or
call through vtable?


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

--- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Looking at the library, the only difference are four additional
symbols in the good version:

_ZThn16_N6KParts13ReadWritePartD0Ev
_ZThn16_N6KParts13ReadWritePartD1Ev
_ZTv0_n24_N6KParts13ReadWritePartD0Ev
_ZTv0_n24_N6KParts13ReadWritePartD1Ev


[Bug libstdc++/60587] [4.9 Regression] debug-mode -std=c++11 vector::insert(pos, begin, end) dereferences begin too eagerly

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60587

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-19
  Known to work||4.8.2
Version|unknown |4.9.0
   Target Milestone|--- |4.9.0
Summary|debug-mode -std=c++11   |[4.9 Regression] debug-mode
   |vector::insert(pos, begin,  |-std=c++11
   |end) dereferences begin too |vector::insert(pos, begin,
   |eagerly |end) dereferences begin too
   ||eagerly
 Ever confirmed|0   |1


[Bug middle-end/60591] New: Report enum conversions as part of Wconversion

2014-03-19 Thread pmatos at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60591

Bug ID: 60591
   Summary: Report enum conversions as part of Wconversion
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pmatos at gcc dot gnu.org

enum xpto
{
  A = 0,
  B = 1,
  X = 512
};
extern void print (unsigned int);

unsigned char bar (enum xpto a)
{
   return a;
}


We don't get currently a warning for this return conversion if we use
--short-enums. With -O2 --short-enums, sizeof enum xpto == 2, but sizeof
unsigned char == 1, therefore we should warn the user there's loss of
precision.


[Bug c++/60332] [c++1y] ICE with auto in function-pointer cast

2014-03-19 Thread paolo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60332

--- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Mar 19 15:48:39 2014
New Revision: 208684

URL: http://gcc.gnu.org/viewcvs?rev=208684root=gccview=rev
Log:
2014-03-19  Paolo Carlini  paolo.carl...@oracle.com

PR c++/60332
* g++.dg/cpp1y/pr60332.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr60332.C
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug other/60133] [4.8/4.9 Regression] wrong multiarch name on aarch64-linux-gnu

2014-03-19 Thread mshawcroft at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133

mshawcroft at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mshawcroft at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from mshawcroft at gcc dot gnu.org ---
Fixed for 4.9 and back ported for 4.8.3 by the commits Jakub listed above.
Closed.


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

--- Comment #7 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #4)
 part.ii is part of a library called libkparts.so.4.12.3.
 When I compile part.cpp with a compiler before r208573 and link the 
 library (all other objects files for the lib are unchanged) and then install
 the library to my system /usr/lib folder, Okular starts and works fine.
 
 If I compile part.cpp with a compiler _after_ r208573 and link the 
 library and install it, Okular shows a popup Unable to find the Okular 
 component.

Just to be clear, you've tested specifically 208572 vs 208573?  Recompiling
just that one file?

 Looking at the library, the only difference are four additional
 symbols in the good version:
 
 _ZThn16_N6KParts13ReadWritePartD0Ev
 _ZThn16_N6KParts13ReadWritePartD1Ev
 _ZTv0_n24_N6KParts13ReadWritePartD0Ev
 _ZTv0_n24_N6KParts13ReadWritePartD1Ev

These are thunks to the destructor, which are unneeded if the (constructor)
vtable doesn't refer to them anymore.

(In reply to Jakub Jelinek from comment #5)
 So, can you perhaps with the part_good.s put a breakpoint on the 2 dtors and
 4 thunks to those, and see if they are ever called during the startup of
 Okular?

Or with part_bad, put a breakpoint on __cxa_pure_virtual?


[Bug target/60568] lto1: internal compiler error: in insn_min_length, at config/i386/i386.md:1599

2014-03-19 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60568

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Also, your command line lists -m32, but the preprocessed file is clearly 64-bit
(-m64) produced.  And, if it is only reproduceable with -flto, we need all *.ii
files through which it can be reproduced (perhaps link with -r -nostdlib -flto
and try to remove unneeded objects).


[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

2014-03-19 Thread marxin.liska at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553

--- Comment #10 from Martin Liška marxin.liska at gmail dot com ---
Second part of suggested patch is sufficient.

ps auxf:
marxin   20293  0.0  0.0   8604  1200 pts/0S17:27   0:00  |   \_
c++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L.
-Wl,-uIsHeapProfilerRunning,-uProfilerStart
-Wl,-u_Z21InitialMallocHook_NewPKvj,-u_Z22Init
marxin   20294  0.0  0.0   8128   692 pts/0S17:27   0:00  |  
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/collect2
-plugin /home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.
marxin   20295  1.1  7.2 3881556 1181360 pts/0 S17:27   0:03  |
  \_
/home/marxin/Programming/bin/gcc/lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/bin/ld
-plugin /home/marxin/Programming/bi
marxin   20412  0.0  0.1  34448 27212 pts/0S17:28   0:00  |
  \_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
@/tmp/ccw1zmZQ
marxin   20413  0.0  0.0  12060  4548 pts/0S17:28   0:00  |
  \_ c++ @/tmp/ccH68rYD.args
marxin   20414 23.7 33.4 5533676 5489912 pts/0 t17:28   0:54  |
  \_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x8

ps ax | grep 20414:
20414 pts/0t  0:54
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x86-64 -msse2
-mssse3 -msse -mmmx -m64 -mtune=generic -march=x86-64 -auxbase
chrome_initial.chrome_exe_main_aura -O3 -fno-trapv -fno-exceptions -fPIC
-fno-fat-lto-objects -fltrans-output-list=/tmp/ccqDrHsV.ltrans.out -fwpa=9
-fresolution=/tmp/ccufR16A.res @/tmp/cc13JyyZ

GDB:
#1409777 0x006b3b11 in gt_ggc_m_P9tree_node4htab (x_p=0x7f0f55752850)
at gtype-desc.c:3185
(gdb) p *x
$2 = {hash_f = 0x75a1f0 libfunc_decl_hash(void const*), eq_f = 0x75a200
libfunc_decl_eq(void const*, void const*), del_f = 0x0, entries =
0x7f0f54390a00, size = 61, n_elements = 17, n_deleted = 0, searches = 17,
collisions = 4, 
  alloc_f = 0x681250 ggc_cleared_alloc_ptr_array_two_args(unsigned long,
unsigned long), free_f = 0x549db0 ggc_free(void*), alloc_arg = 0x0,
alloc_with_arg_f = 0x0, free_with_arg_f = 0x0, size_prime_index = 3}
down iterations:
(gdb) p x-generic-base-code
$7 = FUNCTION_DECL
$8 = FUNCTION_TYPE
$9 = INTEGER_TYPE
$10 = INTEGER_CST
$11 = INTEGER_TYPE
$12 = INTEGER_CST
$13 = INTEGER_TYPE
$14 = POINTER_TYPE
$15 = POINTER_TYPE
$16 = POINTER_TYPE
$17 = POINTER_TYPE
$18 = POINTER_TYPE
$19 = INTEGER_TYPE

Hope it will help.
Martin

[Bug testsuite/60590] Can't recreate the same executable in testsuite

2014-03-19 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60590

--- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed Mar 19 16:59:18 2014
New Revision: 208685

URL: http://gcc.gnu.org/viewcvs?rev=208685root=gccview=rev
Log:
Log environment variables in set_ld_library_path_env_vars

GNU linker sets DT_RPATH from the environment variable LD_RUN_PATH.
set_ld_library_path_env_vars sets a few environment variables including
LD_RUN_PATH.  This patch logs all environment variables set by
set_ld_library_path_env_vars so that one can recreate the same
executable as make check run.

PR testsuite/60590
* lib/target-libpath.exp (set_ld_library_path_env_vars): Log
LD_LIBRARY_PATH, LD_RUN_PATH, SHLIB_PATH, LD_LIBRARY_PATH_32,
LD_LIBRARY_PATH_64 and DYLD_LIBRARY_PATH.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-libpath.exp


[Bug testsuite/60590] Can't recreate the same executable in testsuite

2014-03-19 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60590

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #3 from H.J. Lu hjl.tools at gmail dot com ---
Fixed.


[Bug target/60556] tip of tree crash with mips compiler

2014-03-19 Thread reed.kotler at imgtec dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60556

--- Comment #14 from reed kotler reed.kotler at imgtec dot com ---
(In reply to Andrew Pinski from comment #13)
 (In reply to reed kotler from comment #12)
  
  Do you know where the original line was that made it fail in the .ii?
 
 Yes:
 # 227 /home/rkotler/llvm_trunk/lib/ExecutionEngine/RTDyldMemoryManager.cpp
   if (Name == stat) return (uint64_t)stat;
   if (Name == fstat) return (uint64_t)fstat;
   if (Name == lstat) return (uint64_t)lstat;
   if (Name == stat64) return (uint64_t)stat64;
   if (Name == fstat64) return (uint64_t)fstat64;
   if (Name == lstat64) return (uint64_t)lstat64;
   if (Name == atexit) return (uint64_t)atexit;
   if (Name == mknod) return (uint64_t)mknod;
 # 254 /home/rkotler/llvm_trunk/lib/ExecutionEngine/RTDyldMemoryManager.cpp
   if (Name == __main) return (uint64_t)jit_noop;
 
 
 You can just cast them to unsigned long before casting them to uint64_t for
 the work around.

Great!

This code is from LLVM. By making this change I can build a working llvm using
gcc cross and native.

Do we have any idea when the gcc will be fixed so I don't need to this
workaround?


[Bug target/60556] tip of tree crash with mips compiler

2014-03-19 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60556

--- Comment #15 from H.J. Lu hjl.tools at gmail dot com ---
This is related to PR 54037.


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

--- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #7)
 (In reply to Markus Trippelsdorf from comment #4)
  part.ii is part of a library called libkparts.so.4.12.3.
  When I compile part.cpp with a compiler before r208573 and link the 
  library (all other objects files for the lib are unchanged) and then install
  the library to my system /usr/lib folder, Okular starts and works fine.
  
  If I compile part.cpp with a compiler _after_ r208573 and link the 
  library and install it, Okular shows a popup Unable to find the Okular 
  component.
 
 Just to be clear, you've tested specifically 208572 vs 208573?  Recompiling
 just that one file?

Yes. I compile kdelibs with 208573 and recompile that single file with
208572 and this fixes the issue. 
(I also have to revert r208556 in both cases, otherwise kdelibs won't compile).

  Looking at the library, the only difference are four additional
  symbols in the good version:
  
  _ZThn16_N6KParts13ReadWritePartD0Ev
  _ZThn16_N6KParts13ReadWritePartD1Ev
  _ZTv0_n24_N6KParts13ReadWritePartD0Ev
  _ZTv0_n24_N6KParts13ReadWritePartD1Ev
 
 These are thunks to the destructor, which are unneeded if the (constructor)
 vtable doesn't refer to them anymore.
 
 (In reply to Jakub Jelinek from comment #5)
  So, can you perhaps with the part_good.s put a breakpoint on the 2 dtors and
  4 thunks to those, and see if they are ever called during the startup of
  Okular?
 
 Or with part_bad, put a breakpoint on __cxa_pure_virtual?

Not much luck with breakpoints thus far.


[Bug libstdc++/60592] New: std::array is unable to be brace/universally initialized

2014-03-19 Thread mjbshaw at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60592

Bug ID: 60592
   Summary: std::array is unable to be brace/universally
initialized
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjbshaw at hotmail dot com

After a QA on StackOverflow[1], it seems there is a bug in libstdc++ (though I
suppose it could be in the gcc front end instead of libstdc++; I'm assuming
libstdc++) that prevents std::array from being brace-initialized. Consider the
following:

std::arrayint, 2 a = {1, 2};
std::arrayint, 2 b{a}; // error: cannot convert ‘std::arrayint, 2u’ to
‘int’ in initialization std::arrayint, 2 b{a};
std::arrayint, 2 b(a); // works

b{a} is trying to initialize b by creating an initializer list with a in it
[2], as opposed to using brace/universal initialization (which would be
equivalent to b(a), which works as expected [3]).

b{a} ought to work, as far as I understand things, and this error represents a
bug.

[1]:
http://stackoverflow.com/questions/22495624/why-does-this-compile-with-visual-studio-2013-but-not-g-4-8-1
[2]: http://ideone.com/C3NJbA
[3]: http://ideone.com/zjyTr8

[Bug libstdc++/60592] std::array is unable to be brace/universally initialized

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60592

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1467


[Bug libstdc++/60592] std::array is unable to be brace/universally initialized

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60592

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
If it's that DR, then this is a dup of my PR51747


[Bug target/60568] lto1: internal compiler error: in insn_min_length, at config/i386/i386.md:1599

2014-03-19 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60568

--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
Can you please post complete command line that triggers the bug, as outlined in
[1]? Something like:

g++ ... options ... -fpreprocessed TEncSbac.ii

Please also use -march=some arch instead of -march=native. You can see which
architecture -march=native is compiling for by adding -### to the command line.

[1] http://gcc.gnu.org/bugs/

[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED


[Bug fortran/60593] New: ICE with deferred length variable in FORALL

2014-03-19 Thread kargl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60593

Bug ID: 60593
   Summary: ICE with deferred length variable in FORALL
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org


[Bug libstdc++/60592] std::array is unable to be brace/universally initialized

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60592

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
definitely the same issue

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


[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization

2014-03-19 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mjbshaw at hotmail dot com

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
*** Bug 60592 has been marked as a duplicate of this bug. ***


[Bug fortran/60593] ICE with deferred length variable in FORALL

2014-03-19 Thread kargl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60593

kargl at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||4.9.0

--- Comment #1 from kargl at gcc dot gnu.org ---
% gfc4x -c -Wall h.f90
h.f90: In function 'c2fchar':
h.f90:29:0: internal compiler error: Segmentation fault
   forall (i = 1:c_str_len) res(i:i) = string_p(i)
 ^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.

% cat h.f90

module stringhelper_m

  implicit none

  type :: string_t
 character(:), allocatable :: string
  end type

  interface len
 function strlen(s) bind(c,name='strlen')
   use iso_c_binding
   implicit none
   type(c_ptr), intent(in), value :: s
   integer(c_size_t) :: strlen
 end function
  end interface

  contains

function C2FChar(c_charptr) result(res)
  use iso_c_binding
  type(c_ptr), intent(in) :: c_charptr
  character(:), allocatable :: res
  character(kind=c_char,len=1), pointer :: string_p(:)
  integer i, c_str_len
  c_str_len = int(len(c_charptr))
  call c_f_pointer(c_charptr, string_p, [c_str_len])
  allocate(character(c_str_len) :: res)
  forall (i = 1:c_str_len) res(i:i) = string_p(i)
end function

end module

(gdb) run h.f90
Starting program:
/home/sgk/work/4x/libexec/gcc/x86_64-unknown-freebsd11.0/4.9.0/f951 h.f90
 c2fchar
Program received signal SIGSEGV, Segmentation fault.
0x007abaf4 in contains_struct_check (__s=optimized out, 
__f=optimized out, __l=optimized out, __g=optimized out, 
__t=optimized out, __s=optimized out, __f=optimized out, 
__l=optimized out, __g=optimized out) at ../../gcc4x/gcc/tree.h:2822
2822  if (tree_contains_struct[TREE_CODE (__t)][__s] != 1)
(gdb) bt
#0  0x007abaf4 in contains_struct_check (__s=optimized out, 
__f=optimized out, __l=optimized out, __g=optimized out, 
__t=optimized out, __s=optimized out, __f=optimized out, 
__l=optimized out, __g=optimized out) at ../../gcc4x/gcc/tree.h:2822
#1  fold_convert_loc (loc=0, type=0x202c2d7e0, arg=0x0)
at ../../gcc4x/gcc/fold-const.c:1956
#2  0x006501f3 in allocate_temp_for_forall_nest_1 (type=0x202d6a930, 
size=0x202d77130, block=0x7fffce40, ptemp1=0x7fffca50)
at ../../gcc4x/gcc/fortran/trans-stmt.c:3288
#3  0x00650949 in allocate_temp_for_forall_nest (
nested_forall_info=optimized out, type=optimized out, 
inner_size=optimized out, inner_size_body=optimized out, 
block=optimized out, ptemp1=optimized out, 
nested_forall_info=optimized out, type=optimized out, 
inner_size=optimized out, inner_size_body=optimized out, 
block=optimized out, ptemp1=optimized out)
at ../../gcc4x/gcc/fortran/trans-stmt.c:3319
#4  gfc_trans_assign_need_temp (expr1=0x2034ac300, expr2=0x2034ac540, 
wheremask=0x0, invert=false, nested_forall_info=0x2034d13c0, 
block=0x7fffce40) at ../../gcc4x/gcc/fortran/trans-stmt.c:3408
#5  0x0064ccb2 in gfc_trans_forall_1 (code=0x2034ac840, 
nested_forall_info=optimized out)
at ../../gcc4x/gcc/fortran/trans-stmt.c:3886
#6  0x005eb15e in trans_code (code=optimized out, cond=0x0)
at ../../gcc4x/gcc/fortran/trans.c:1786
#7  0x006127cc in gfc_generate_function_code (ns=0x20344b400)
at ../../gcc4x/gcc/fortran/trans-decl.c:5610
#8  0x005eb5ae in gfc_generate_module_code (ns=optimized out)
at ../../gcc4x/gcc/fortran/trans.c:1972
#9  0x0058eb95 in translate_all_program_units (
gfc_global_ns_list=optimized out, main_in_tu=optimized out)
at ../../gcc4x/gcc/fortran/parse.c:4523
#10 gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:4733
#11 0x005d72ea in gfc_be_parse_file ()
at ../../gcc4x/gcc/fortran/f95-lang.c:188
#12 0x00a0978a in compile_file () at ../../gcc4x/gcc/toplev.c:548
#13 0x00a0958b in do_compile () at ../../gcc4x/gcc/toplev.c:1914
#14 toplev_main (argc=2, argv=0x7fffd4d8) at ../../gcc4x/gcc/toplev.c:1990
#15 0x005134af in _start ()


[Bug lto/60567] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233

2014-03-19 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #2)
 Seems to be a problem of Binutils. If I use the current Binutils from
 binutils-gdb git (= 2.24.51.20140319), it works.

But only for the test case of comment 0. It still fails for the big program and
for the following test case. [I wonder whether you can reproduce this one.]


Using either CentOS 6's Binutils or the git-trunk of Binutils
(2.24.51.20140319), the following fails for me:


$ g++ -Wfatal-errors -std=c++11 -r -nostdlib -flto test15.ii
lto1: internal compiler error: in add_symbol_to_partition, at
lto/lto-partition.c:233
0x5b4d44 add_symbol_to_partition
../../gcc/lto/lto-partition.c:231


//--
#pragma implementation
#pragma interface
class MutableError { };
class MutableSelector { };
template class CONVERTER class MutableValueHolder {
  virtual MutableError
  isValidNativeValue(const typename CONVERTER::Value_t) const {}
};
class MutableNumericTaggedType : virtual public MutableSelector {
};
class MutableNumericType : public virtual MutableNumericTaggedType { };
class MutableIntegerConverter {
   public:
 typedef int Value_t;
};
class MutableIntegerValue
  : public MutableNumericType,
protected MutableValueHolderMutableIntegerConverter {
  virtual MutableError
  isValidNativeValue(const MutableIntegerConverter::Value_t value) const {}
};


[Bug c++/60566] [4.9 Regression] r208573 miscompiles kdelibs

2014-03-19 Thread trippels at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566

--- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Running nm on all my libs shows:
...
kde4/notepadpart.so
 U _ZThn16_N6KParts13ReadWritePartD0Ev
...
kde4/okularpart.so
 U _ZThn16_N6KParts13ReadWritePartD0Ev
...
libkatepartinterfaces.so
 U _ZThn16_N6KParts13ReadWritePartD0Ev
libkatepartinterfaces.so.4
 U _ZThn16_N6KParts13ReadWritePartD0Ev
libkatepartinterfaces.so.4.12.3
 U _ZThn16_N6KParts13ReadWritePartD0Ev
...
libktexteditor.so
 U _ZThn16_N6KParts13ReadWritePartD0Ev
libktexteditor.so.4
 U _ZThn16_N6KParts13ReadWritePartD0Ev
libktexteditor.so.4.12.3
 U _ZThn16_N6KParts13ReadWritePartD0Ev

So maybe okular and katepart just need to be recompiled?
Let me try this.


  1   2   >