[Bug ada/57849] ICE with Convention => C in Ada 2012

2013-07-07 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57849

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0
Summary|With Convention => C causes |ICE with Convention => C in
   |Bug box with -gnat2012  |Ada 2012

--- Comment #1 from Eric Botcazou  ---
Fixed on mainline.


[Bug middle-end/57845] ICE with -freg-struct-return on Sparc target

2013-07-07 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Eric Botcazou  ---
-freg-struct-return isn't supported on the SPARC.


[Bug driver/57784] GCC inadvertedly truncates source text

2013-07-07 Thread glisse at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57784

Marc Glisse  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #2 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #1)
> This is hard to fix and will not be fixed as gcc does not know it is writing
> to a source file or a file you just happen to name to end with .cc .

Uh, what's wrong about using a heuristic and refusing to compile when the name
of the output file ends in .c, .C, .cc, .f90, etc (possibly unless some
-fweird-output-name is also passed) and the file already exists?


[Bug driver/57784] GCC inadvertedly truncates source text

2013-07-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57784

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
This is hard to fix and will not be fixed as gcc does not know it is writing to
a source file or a file you just happen to name to end with .cc . -lstdc++ is
considered an object file enough to link with which is why you see this
behavior with that only.


[Bug tree-optimization/57823] restrict qualifier non effective with pointer returned by new

2013-07-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57823

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Marc Glisse from comment #2)
> Related to PR23383 as well, which could make restrict unnecessary in this
> case.

It is a dup of that bug.

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


[Bug c++/23383] builtin array operator new is not marked with malloc attribute

2013-07-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383

Andrew Pinski  changed:

   What|Removed |Added

 CC||vincenzo.innocente at cern dot 
ch

--- Comment #25 from Andrew Pinski  ---
*** Bug 57823 has been marked as a duplicate of this bug. ***


[Bug target/57848] internal compiler error on build with mingw-w64

2013-07-07 Thread dongsheng.song at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848

--- Comment #1 from Dongsheng Song  ---
x86_64-w64-mingw32 failed with same errors:

$ make  all-am
make[1]: Entering directory
`/home/cauchy/obj/x86_64-w64-mingw32-gcc49/mingw-w64-crt'
x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt  -m64
-I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/include -D_CRTBLD
-I/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include  -pipe
-std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline
-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2
-MT intrincs/lib64_libkernel32_a-__movsb.o -MD -MP -MF
intrincs/.deps/lib64_libkernel32_a-__movsb.Tpo -c -o
intrincs/lib64_libkernel32_a-__movsb.o `test -f 'intrincs/__movsb.c' || echo
'/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/'`intrincs/__movsb.c
In file included from
/home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intrin.h:27:0,
 from
/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/intrin.h:59,
 from
/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/intrincs/__movsb.c:1:
/home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ia32intrin.h:54:9:
internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633
 #pragma GCC target("sse4.2")
 ^
0x5357eb c_builtin_function_ext_scope(tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633
0x75e618 add_builtin_function_common
/home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561
0x75eed3 add_builtin_function_ext_scope(char const*, tree_node*, int,
built_in_class, char const*, tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597
0xa12124 ix86_add_new_builtins
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27199
0xa12124 ix86_valid_target_attribute_tree(tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4512
0x5b5d90 ix86_pragma_target_parse
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386-c.c:385
0x5a65ad handle_pragma_target
/home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-pragma.c:805
0x55b37e c_parser_pragma
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:8749
0x56995b c_parser_external_declaration
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1345
0x56a2c7 c_parser_translation_unit
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1251
0x56a2c7 c_parse_file()
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:11000
0x5a4104 c_common_parse_file()
/home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [intrincs/lib64_libkernel32_a-__movsb.o] Error 1
make[1]: Leaving directory
`/home/cauchy/obj/x86_64-w64-mingw32-gcc49/mingw-w64-crt'
make: *** [all] Error 2


[Bug target/57847] Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot

2013-07-07 Thread lxz at knd dot com.cn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57847

--- Comment #2 from lxz at knd dot com.cn ---
I am using codesourcery and linaro compiler.

lxz@cdserver:~$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/arm/eabi/bin/../libexec/gcc/arm-none-eabi/4.7.3/lto-wrapper
Target: arm-none-eabi
Configured with:
/scratch/jbrown/2013.05-arm-eabi-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2013
-D__CS_SOURCERYGXX_MIN__=5 -D__CS_SOURCERYGXX_REV__=23
%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}'
--enable-languages=c,c++ --disable-shared --enable-lto --with-newlib
--with-pkgversion='Sourcery CodeBench Lite 2013.05-23'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/arm-none-eabi
--with-build-sysroot=/scratch/jbrown/2013.05-arm-eabi-release/install/arm-none-eabi
--with-gmp=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-libelf=/scratch/jbrown/2013.05-arm-eabi-release/obj/pkg-2013.05-23-arm-none-eabi/arm-2013.05-23-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --enable-poison-system-directories
--with-build-time-tools=/scratch/jbrown/2013.05-arm-eabi-release/install/arm-none-eabi/bin
--with-build-time-tools=/scratch/jbrown/2013.05-arm-eabi-release/install/arm-none-eabi/bin
Thread model: single
gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-23)

lxz@lxzlinux:~/gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux/bin$
./arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=./arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/lxz/gcc-linaro-arm-linux-gnueabihf-4.8-2013.05_linux/bin/../libexec/gcc/arm-linux-gnueabihf/4.8.1/lto-wrapper
Target: arm-linux-gnueabihf
Configured with:
/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/gcc-linaro-4.8-2013.05/configure
--build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu
--target=arm-linux-gnueabihf
--prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/install
--with-sysroot=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc
--enable-languages=c,c++,fortran --enable-multilib --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
--with-pkgversion='crosstool-NG linaro-1.13.1-4.8-2013.05 - Linaro GCC 2013.05'
--with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit
--enable-libmudflap --enable-libgomp --enable-libssp
--with-gmp=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-mpfr=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-mpc=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-isl=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-cloog=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-libelf=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id
--enable-gold
--with-local-prefix=/cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc
--enable-c99 --enable-long-long --with-mode=thumb
Thread model: posix
gcc version 4.8.1 20130506 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.05
- Linaro GCC 2013.05)

(In reply to Andrew Pinski from comment #1)
> I have used GCC 4.7.0 with Linux 3.10 with the SLUB allocator and it works
> just fine.
> 
> Can you provide the exact options you configured GCC with?


[Bug ada/57849] New: With Convention => C causes Bug box with -gnat2012

2013-07-07 Thread prosfilaes at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57849

Bug ID: 57849
   Summary: With Convention => C causes Bug box with -gnat2012
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prosfilaes at gmail dot com

$ gcc -gnatd.n -gnat2012 -c -Wall g.adb
/home/prosfilaes/bin/gcc-4.8.0/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/adainclude/system.ads
g.adb
+===GNAT BUG DETECTED==+
| 4.8.0 (x86_64-unknown-linux-gnu) GCC error:  |
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:336   |
| Error detected at g.adb:3:48 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

g.adb

g.adb:3:04: warning: constant "AR" is not referenced
compilation abandoned

$ cat g.adb 
procedure g is
   type Glp_Matrix_Values_Array is array (Natural range <>) of Long_Float;
   AR : constant Glp_Matrix_Values_Array (0 .. 12) := (others => 1.0)
 with Convention => C;
begin
null;
end g;


[Bug target/57848] internal compiler error on build with mingw-w64

2013-07-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target
   Severity|blocker |normal


[Bug c/57848] New: internal compiler error on build with mingw-w64

2013-07-07 Thread dongsheng.song at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848

Bug ID: 57848
   Summary: internal compiler error on build with mingw-w64
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dongsheng.song at gmail dot com

$ svn info mingw-w64/trunk/ gcc/trunk/
Path: mingw-w64/trunk
URL: svn://svn.code.sf.net/p/mingw-w64/code/trunk
Repository Root: svn://svn.code.sf.net/p/mingw-w64/code
Repository UUID: 4407c894-4637-0410-b4f5-ada5f102cad1
Revision: 5938
Node Kind: directory
Schedule: normal
Last Changed Author: sezero
Last Changed Rev: 5936
Last Changed Date: 2013-07-07 17:12:42 +0800 (Sun, 07 Jul 2013)

Path: gcc/trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 200744
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 200744
Last Changed Date: 2013-07-08 03:06:45 +0800 (Mon, 08 Jul 2013)

$ make  all-am
make[1]: Entering directory
`/home/cauchy/obj/i686-w64-mingw32-gcc49/mingw-w64-crt'
i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt  -m32
-I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/include -D_CRTBLD
-I/home/cauchy/cross/i686-windows-gcc49/i686-w64-mingw32/include  -pipe
-std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline
-Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2
-MT intrincs/lib32_libkernel32_a-__movsb.o -MD -MP -MF
intrincs/.deps/lib32_libkernel32_a-__movsb.Tpo -c -o
intrincs/lib32_libkernel32_a-__movsb.o `test -f 'intrincs/__movsb.c' || echo
'/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/'`intrincs/__movsb.c
In file included from
/home/cauchy/cross/i686-windows-gcc49/lib/gcc/i686-w64-mingw32/4.9.0/include/x86intrin.h:27:0,
 from
/home/cauchy/cross/i686-windows-gcc49/i686-w64-mingw32/include/intrin.h:59,
 from
/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/intrincs/__movsb.c:1:
/home/cauchy/cross/i686-windows-gcc49/lib/gcc/i686-w64-mingw32/4.9.0/include/ia32intrin.h:54:9:
internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633
 #pragma GCC target("sse4.2")
 ^
0x531e8b c_builtin_function_ext_scope(tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633
0x755f28 add_builtin_function_common
/home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561
0x7567e3 add_builtin_function_ext_scope(char const*, tree_node*, int,
built_in_class, char const*, tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597
0xa04fc4 ix86_add_new_builtins
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27199
0xa04fc4 ix86_valid_target_attribute_tree(tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4512
0x5b22a0 ix86_pragma_target_parse
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386-c.c:385
0x5a2abd handle_pragma_target
/home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-pragma.c:805
0x557a1e c_parser_pragma
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:8749
0x565ffb c_parser_external_declaration
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1345
0x566967 c_parser_translation_unit
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1251
0x566967 c_parse_file()
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:11000
0x5a0614 c_common_parse_file()
/home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [intrincs/lib32_libkernel32_a-__movsb.o] Error 1
make[1]: Leaving directory
`/home/cauchy/obj/i686-w64-mingw32-gcc49/mingw-w64-crt'
make: *** [all] Error 2


[Bug target/57847] Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot

2013-07-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57847

--- Comment #1 from Andrew Pinski  ---
I have used GCC 4.7.0 with Linux 3.10 with the SLUB allocator and it works just
fine.

Can you provide the exact options you configured GCC with?


[Bug c/57847] New: Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot

2013-07-07 Thread lxz at knd dot com.cn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57847

Bug ID: 57847
   Summary: Compile ARM linux kernel with configuration of SLUB
allocator, kernel failed to boot
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lxz at knd dot com.cn

Tested kernel version is 3.2.21 and 3.2. Kernel encounters "data abort" during
initiation.
Problem exists in gcc 4.7.3 and 4.8.1, but 4.6.3 works fine.
Changing kernel configuration to SLAB allocator is a workaround.


[Bug c++/57846] New: CRTP, templates, metaprogramming, forwarding and static member

2013-07-07 Thread vince.rev at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57846

Bug ID: 57846
   Summary: CRTP, templates, metaprogramming, forwarding and
static member
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vince.rev at gmail dot com

This code (I could not find a simpler example) does not compile under g++ for
some obscure reasons (tested with 4.8.1 and 4.7.2) (see the related discussion
on stack overflow here :
http://stackoverflow.com/questions/17515079/crtp-templates-metaprogramming-forwarding-and-static-member-a-bug-in-g-4-8):

-
#include 
#include 
#include 
#include 
#include 

template  struct Base
{
template  >::type> inline const Type&
get() const {return std::get(data);}
template  >::type> inline Crtp& set(const
Type& value) {std::get(data) = value; return static_cast(*this);}
std::tuple data;
};

template  struct Derived : public
Base, std::array>
{
template , std::array>>().template
get<0>(std::declval()...))> inline Template test(Args&&... args) const
{return this->template get<0>(std::forward(args)...);} 
template , std::array>>().template
set<0>(std::declval()...))> inline Derived& test(Args&&...
args) {return this->template set<0>(std::forward(args)...);} 
static void check() {Derived derived;
std::cout< derived; std::cout<::check(); // Not working: error: no match for
‘operator[]’ (operand types are ‘Derived’ and ‘int’)
return 0;
}

-

[Bug target/57722] Floating point problems when building with no-sse and no-mmx

2013-07-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57722

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
Well using -mno-sse breaks printf as that thinks the floating point value is in
the xmm register.


[Bug c++/57845] New: ICE with -freg-struct-return on Sparc target

2013-07-07 Thread adam at os dot inf.tu-dresden.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845

Bug ID: 57845
   Summary: ICE with -freg-struct-return on Sparc target
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at os dot inf.tu-dresden.de
  Host: x86_64
Target: sparc

The following code produces an ICE for a Sparc target, with 4.9.0. Also tested
4.7.4 and 4.8.2 with same result. No ICE for target x86 for any version tested.
No ICE with-freg-struct-return removed.

class foo
{
public:
  struct r { };
};

class c
{ 
  foo::r func(foo::r);
};

foo::r c::func(foo::r x)
{
  return x;
}

$ sparc-linux-g++ -m32 -c  -freg-struct-return  x.i
x.i: In member function ‘foo::r c::func(foo::r)’:
x.i:15:10: internal compiler error: in emit_move_insn, at expr.c:3486
   return x;
  ^
0x85ba84 emit_move_insn(rtx_def*, rtx_def*)
/tmp/gcc/head/gcc/gcc/expr.c:3485
0xa80620 expand_value_return
/tmp/gcc/head/gcc/gcc/stmt.c:1460
0x78f5f1 expand_gimple_stmt_1
/tmp/gcc/head/gcc/gcc/cfgexpand.c:2248
0x78f5f1 expand_gimple_stmt
/tmp/gcc/head/gcc/gcc/cfgexpand.c:2370
0x7910a7 expand_gimple_basic_block
/tmp/gcc/head/gcc/gcc/cfgexpand.c:4204
0x793806 gimple_expand_cfg
/tmp/gcc/head/gcc/gcc/cfgexpand.c:4723
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Adam

[Bug target/57722] Floating point problems when building with no-sse and no-mmx

2013-07-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57722

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu
  Component|translation |target

--- Comment #1 from Andrew Pinski  ---
>I want to prevent gcc from generating code with xmm registers on 64bit system.

Does that even make sense since the ABI requires using those registers.


[Bug c++/57842] for statement not terminating properly

2013-07-07 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842

--- Comment #3 from Jonathan Wakely  ---
http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html

select isn't broken, neither is 'for'


[Bug middle-end/56977] gcc -Og incorrectly warns about 'constant zero length parameter'

2013-07-07 Thread bastiaan at bjacques dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977

Bastiaan Jacques  changed:

   What|Removed |Added

 CC||bastiaan at bjacques dot org

--- Comment #7 from Bastiaan Jacques  ---
The following program fd.cc:

#include 

int some_socket = 0;

void
foo()
{
fd_set fdset;
struct timeval tval;

FD_ZERO(&fdset);
FD_SET(some_socket, &fdset);
}

When compiled with:

g++ -c -o fd.o fd.cc  -D_FORTIFY_SOURCE=2  -Og

Generates the following warning:

fd.cc:12:219: warning: call to ‘__fdelt_warn’ declared with attribute warning:
bit outside of fd_set selected [enabled by default]
 FD_SET(some_socket, &fdset);

I think this might be another instance of this bug, because it goes away when
switching to -O2 (but I don't have a 4.8 branch handy to test whether the fix
also resolved this case).

[Bug libstdc++/57844] New: avr-unknown-elf libstdc++v3 build causes internal compiler error: in extract_insn, at recog.c:2150

2013-07-07 Thread bugzilla.gcc at buszta dot info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57844

Bug ID: 57844
   Summary: avr-unknown-elf libstdc++v3 build causes internal
compiler error: in extract_insn, at recog.c:2150
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzilla.gcc at buszta dot info

Trying to compile GCC 4.8.1 (SVN trunk also applies) toolchain for
avr-unknown-elf target with standard C++ library support.

Configuration options:
../gcc-4.8.1/configure
--prefix=/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf
--target=avr-unknown-elf --disable-__cxa_atexit --disable-nls --disable-threads
--disable-shared --enable-static --with-dwarf2 --with-gmp=/usr/local
--with-mpfr=/usr/local --with-mpc=/usr/local --with-ppl=/usr/local
--enable-libstdcxx --enable-languages=c,c++ --with-newlib
--disable-sjlj-exceptions

Build with:
binutils 2.23.2
gmp 5.0.5
mpc 0.9
mpfr 3.1.2
ppl 0.12.1
newlib 1.20.0

Host GCC:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)


Building make all-target-libstdc++-v3 gives error:

(...)
Making all in c++11
make[8]: Entering directory
`/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src/c++11'
/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile
/home/abuszta/Development/avr/gcc-4.8.1-build/./gcc/xgcc -shared-libgcc
-B/home/abuszta/Development/avr/gcc-4.8.1-build/./gcc -nostdinc++
-L/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src
-L/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src/.libs
-B/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/bin/
-B/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/lib/
-isystem
/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/include
-isystem
/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/sys-include
 -msp8 -I/home/abuszta/Development/avr/gcc-4.8.1/libstdc++-v3/../libgcc
-I/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/include/avr-unknown-elf
-I/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/include
-I/home/abuszta/Development/avr/gcc-4.8.1/libstdc++-v3/libsupc++  -std=gnu++11 
 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
-fdiagnostics-show-location=once   -ffunction-sections -fdata-sections 
-frandom-seed=debug.lo -g -O2  -msp8  -c -o debug.lo
../../../../../../gcc-4.8.1/libstdc++-v3/src/c++11/debug.cc
libtool: compile:  /home/abuszta/Development/avr/gcc-4.8.1-build/./gcc/xgcc
-shared-libgcc -B/home/abuszta/Development/avr/gcc-4.8.1-build/./gcc
-nostdinc++
-L/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src
-L/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/src/.libs
-B/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/bin/
-B/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/lib/
-isystem
/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/include
-isystem
/home/abuszta/Development/avr/gcc-4.8.1-avr-unknown-elf/avr-unknown-elf/sys-include
-msp8 -I/home/abuszta/Development/avr/gcc-4.8.1/libstdc++-v3/../libgcc
-I/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/include/avr-unknown-elf
-I/home/abuszta/Development/avr/gcc-4.8.1-build/avr-unknown-elf/tiny-stack/libstdc++-v3/include
-I/home/abuszta/Development/avr/gcc-4.8.1/libstdc++-v3/libsupc++ -std=gnu++11
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=debug.lo -g -O2 -msp8 -c
../../../../../../gcc

[Bug c++/54310] Order of operations during overload resolution

2013-07-07 Thread zeratul976 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54310

--- Comment #1 from Nathan Ridge  ---
Richard Smith has suggested that GCC is actually allowed not to instantiate
'meta' as per [temp.inst]/p6:

"If the overload resolution process can determine the correct function to call
without instantiating a class template definition, it is unspecified whether
that instantiation actually takes place."

If this is really what's happening - GCC is not instantiating 'meta'
because it can determine without doing so that the first overload of 'foo' will
not be chosen - then I guess we can close this PR as INVALID.


[Bug fortran/57843] New: Polymorphic assignment for derived type is resolved with parent's generic instead of its own

2013-07-07 Thread jwmwalrus at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57843

Bug ID: 57843
   Summary: Polymorphic assignment for derived type is resolved
with parent's generic instead of its own
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwmwalrus at gmail dot com

The code below does not do what's expected when compiled with gfortran-4.9
(i.e., to print "this is right" instead of "what am I doing here?" every time
the polymorphic assignment is invoked, and also printing the assigned values at
the end, instead of the default ones.

Maybe I still don't understand the semantics behind Fortran 2003+'s type-bound
assignment (so I apologize in advance if this is not a bug), but it seems to me
that the assign_itemType procedure is being used for assignment, even though it
doesn't satisfy the requirement of exact type for the "right" argument ---is
polymorphism being resolved at compile time even for dynamic cases?

By commenting out the line marked with "!*", I get an ICE with ifort
13.1.3, so I have no way to compare behavior.



!-test_assign.f90
module mod1
implicit none

type :: itemType
contains
procedure :: assign_itemType
generic :: assignment(=) => assign_itemType
end type

type, abstract :: tableType
class(itemType), allocatable :: table(:)
contains
procedure :: process
procedure(i_setItem), nopass, deferred :: setItem
end type

abstract interface
subroutine i_setItem(array, item)
import
character(*), intent(IN) :: array(:)
class(itemType), allocatable, intent(OUT) :: item
end subroutine
end interface

contains
subroutine process(this)
class(tableType), intent(INOUT) :: this
integer :: i, j, n
character(5), allocatable :: array(:)
class(itemType), allocatable :: item, aux(:)

do i = 1, 3
print '(/,"item ",I0)', i
array = [character(5) :: 'abc', '1', '12.3']
call this%setItem(array, item)

if (ALLOCATED(this%table)) then
n = SIZE(this%table)
call MOVE_ALLOC(this%table, aux)
allocate (this%table(n+1), MOLD = item)
print *, 'table is same type as aux?:', &
SAME_TYPE_AS(this%table, aux)

do j = 1, n
this%table(j) = aux(j)
enddo
this%table(n+1) = item
else
allocate (this%table(1), SOURCE = item)
endif
print *, 'table is same type as item?:', &
SAME_TYPE_AS(this%table, item)
print *, 'table is same type as itemType?:', &
SAME_TYPE_AS(this%table, itemType())!*
print *, 'table extends type itemType?:', &
EXTENDS_TYPE_OF(this%table, itemType())
enddo
end subroutine

subroutine assign_itemType(left, right)
class(itemType), intent(OUT) :: left
type(itemType), intent(IN) :: right

print *, 'what am I doing here?'
end subroutine
end module mod1

module mod2
use mod1
implicit none

type, extends(itemType) :: myItem
character(3) :: name = ''
integer :: num = 0
real :: val = 0
contains
procedure :: assign_myItem
generic :: assignment(=) => assign_myItem
end type

type, extends(tableType) :: myTable
contains
procedure, nopass :: setItem
procedure :: output
end type

contains
subroutine setItem(array, item)
character(*), intent(IN) :: array(:)
class(itemType), allocatable, intent(OUT) :: item

allocate (myItem :: item)
select type (item)
type is (myItem)
print *, 'setting...'
item%name = array(1)
read (array(2), *) item%num
read (array(3), *) item%val
end select
end subroutine

subroutine assign_myItem(left, right)
class(myItem), intent(OUT) :: left
type(myItem), intent(IN) :: right

print *, 'this is right'
left%name = right%name
left%num = right%num
left%val = right%val
end subroutine

subroutine output(this)
class(myTable), intent(IN) :: this
integer :: i

do i = 1, SIZE(this%table)
select type (item => this%table(i))
type is (myItem)
print *, i, item%name, item%num, item%val
end select
enddo
end subroutine
end module mod2

use mod2
implicit none

type(myTable) :: table
call table%process()
call table%output()
end
!-test_assign.f90



The output obtained is:

...:~$ gfor

[Bug c++/57842] for statement not terminating properly

2013-07-07 Thread groundup2360917182914017 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842

--- Comment #2 from Anthony Brown  
---
I see the problem with my code.  There is no bug. The second if should be
else if.  Sorry.


On Sun, Jul 7, 2013 at 12:15 PM, pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842
>
> Andrew Pinski  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |RESOLVED
>  Resolution|--- |INVALID
>
> --- Comment #1 from Andrew Pinski  ---
> The reason why it prints 11 is because the second if is true after the
> first
> loop.
>
> --
> You are receiving this mail because:
> You reported the bug.
>


[Bug c++/57842] for statement not terminating properly

2013-07-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
The reason why it prints 11 is because the second if is true after the first
loop.


[Bug c++/57842] New: for statement not terminating properly

2013-07-07 Thread groundup2360917182914017 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57842

Bug ID: 57842
   Summary: for statement not terminating properly
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: groundup2360917182914017 at gmail dot com

In the program below.  If I enter 0 through 10 it should print
0
1
2
3
4
5
6
7
8
9
10

But it doesn't.  I think what it print is a error.
0
1
2
3
4
5
6
7
8
9
10
10
11

Source Code is
#include 

int main()
{
   int number1, number2;

   std::cout << "Enter two numbers to print the numbers between: ";

   std::cin >> number1 >> number2;

   if(number1 < number2)
   {
  for(; number1 <= number2; number1++)
  {
 std::cout << number1 << std::endl;
  }
   }

   if(number1 > number2)
   {
  for(; number2 <= number1; number2++)
  {
 std::cout << number2 << std::endl;
  }
   }

   if(number1 == number2)
   {
  std::cout << number1 << std::endl;
   }

   return 0;
}


[Bug target/57841] Assembler error on gcc for ARM

2013-07-07 Thread a.livenets at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57841

Alexander Livenets  changed:

   What|Removed |Added

 Target||arm-linux
   Host||x86-64

--- Comment #2 from Alexander Livenets  ---
binutils version 2.20.1a

(In reply to Andrew Pinski from comment #1)
> What binutils version?


[Bug target/57841] Assembler error on gcc for ARM

2013-07-07 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57841

--- Comment #1 from Andrew Pinski  ---
What binutils version?


[Bug c++/54588] Improved error messages by dropping out types

2013-07-07 Thread glisse at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54588

--- Comment #6 from Marc Glisse  ---
(In reply to Manuel López-Ibáñez from comment #5)
> But in this specific case, how can the type of VeryComplicatedType change
> anything about the convertibility of A<...> to 'int'? Sorry if I lack
> imagination...

'A' could have partial/full specializations, it could have a conversion
operator to a type that depends on the parameter, etc.

[Bug c++/54588] Improved error messages by dropping out types

2013-07-07 Thread manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54588

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Marc Glisse from comment #4)
> 
> or maybe it does. I'd be very careful about removing information from the
> diagnostics. I find cases where we are missing information (PR53822 for

I didn't say it was easy ;-) but clang shows that it is possible in some cases
to elide things that don't matter and point out exactly the differences that
matter.

And there are even more clear-cut cases like PR43113

> instance) much worse than those where we need to ignore a number of lines to
> find the right message. I can read a few more lines, I cannot invent what
> isn't there. So if there is any chance it might be useful, please at least
> keep it under some -fdetailed-diagnostic flag.

Clang has some specific flags controlling this, I guess for the same reasons
that you give.

But in this specific case, how can the type of VeryComplicatedType change
anything about the convertibility of A<...> to 'int'? Sorry if I lack
imagination...

[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range

2013-07-07 Thread tomga at wp dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477

--- Comment #11 from Tomasz Gajewski  ---
Created attachment 30474
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30474&action=edit
Patch that fixes all testcases added by me in previous patch to simple.cc


[Bug c++/51786] [c++0x] Invalid declaration with decltype accepted

2013-07-07 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51786

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #7 from Paolo Carlini  ---
On it.


[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range

2013-07-07 Thread tomga at wp dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477

--- Comment #10 from Tomasz Gajewski  ---
Created attachment 30473
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30473&action=edit
Patch to pretty printers testsuite to expose some problems

This patch adds into the testsuite additional cases with typedefs and
references to variables. This exposes problem described in this bug.

My proposed earlier patch to 'printers.py' fixes some new testcases from this
patch but not all of them.


[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary

2013-07-07 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763

--- Comment #12 from Uroš Bizjak  ---
(In reply to stevenb@gmail.com from comment #11)
> > --- Comment #9 from Uroš Bizjak  ---
> > I have tried to compile gcc.dg/comp-goto-1.c with the patched gcc, but
> > compilation failed with:
> 
> Huh, worked for me. What revision, what compiler options did you use?

I have tried to bootstrap current mainline natively on alpha, the bootstrap
failed when checking for sjlj exceptions:

--cut here--
/* confdefs.h */
#define PACKAGE_NAME "GNU C Runtime Library"
#define PACKAGE_TARNAME "libgcc"
#define PACKAGE_VERSION "1.0"
#define PACKAGE_STRING "GNU C Runtime Library 1.0"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
#define SIZEOF_DOUBLE 8
#define SIZEOF_LONG_DOUBLE 16
#define HAVE_GETIPINFO 1
/* end confdefs.h.  */

void bar ();
void clean (int *);
void foo ()
{
  int i __attribute__ ((cleanup (clean)));
  bar();
}
--cut here--

just try to compile this source without any options.

[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary

2013-07-07 Thread stevenb.gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763

--- Comment #11 from stevenb.gcc at gmail dot com  ---
> --- Comment #9 from Uroš Bizjak  ---
> I have tried to compile gcc.dg/comp-goto-1.c with the patched gcc, but
> compilation failed with:

Huh, worked for me. What revision, what compiler options did you use?

[Bug fortran/57839] Reallocate on assignment does not work properly

2013-07-07 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57839

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #2 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #1)
> I think that's effectively a duplicate of PR57456.
Scratch that. I misread the example.

The example seems to work with GCC 4.7, but I get valgrind warnings for all
  list = [list, item]
assignments: "Conditional jump or move depends on uninitialised value". I
haven't tried 4.8/4.9, yet.


[Bug fortran/57839] Reallocate on assignment does not work properly

2013-07-07 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57839

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
I think that's effectively a duplicate of PR57456.


[Bug target/54531] vpermilpd(x, 2 or 10) is a move

2013-07-07 Thread glisse at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54531

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Marc Glisse  ---
We now generate optimal (empty) code with -mavx or -mavx2.


[Bug c/57841] New: Assembler error on gcc for ARM

2013-07-07 Thread a.livenets at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57841

Bug ID: 57841
   Summary: Assembler error on gcc for ARM
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a.livenets at gmail dot com

Created attachment 30472
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30472&action=edit
Source file with compilation errors

$ arm-cortex_a8-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-cortex_a8-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/chogori/x-tools/arm-cortex_a8-linux-gnueabi/libexec/gcc/arm-cortex_a8-linux-gnueabi/4.7.2/lto-wrapper
Target: arm-cortex_a8-linux-gnueabi
Configured with:
/home/chogori/arm-linux-toolchain/.build/src/gcc-4.7.2/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu
--target=arm-cortex_a8-linux-gnueabi
--prefix=/home/chogori/x-tools/arm-cortex_a8-linux-gnueabi
--with-sysroot=/home/chogori/x-tools/arm-cortex_a8-linux-gnueabi/arm-cortex_a8-linux-gnueabi/sysroot
--enable-languages=c,c++ --with-arch=armv7-a --with-cpu=cortex-a8
--with-tune=cortex-a8 --with-fpu=neon --with-float=softfp
--with-pkgversion='crosstool-NG 1.18.0' --disable-sjlj-exceptions
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp
--disable-libquadmath --disable-libquadmath-support
--with-gmp=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-mpfr=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-mpc=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-ppl=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-cloog=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-libelf=/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm
-L/home/chogori/arm-linux-toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools/lib
-lpwl' --enable-threads=posix --enable-target-optspace --enable-linker-build-id
--with-system-zlib --enable-multilib
--with-local-prefix=/home/chogori/x-tools/arm-cortex_a8-linux-gnueabi/arm-cortex_a8-linux-gnueabi/sysroot
--enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.2 (crosstool-NG 1.18.0) 

The gcc cross-compiler for ARM fails to compile the attached source file

The error is following:
Assembler messages:
Error: ']' expected -- `vst2.32 {d16-d17},[r3:64]'

arm-gcc cross-compilation flags: -c -O3 -march=armv7a -mtune=cortex-a8
-mfpu=neon -mfloat-abi=softfp

When using -O2 flag or uncommenting the string 1, the compilation is
successful.


[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary

2013-07-07 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763

--- Comment #10 from Uroš Bizjak  ---
Program received signal SIGSEGV, Segmentation fault.
0x000120345388 in fixup_reorder_chain () at
../../gcc-svn/trunk/gcc/cfgrtl.c:3436
3436  if (BB_HEADER (bb))
(gdb) bt
#0  0x000120345388 in fixup_reorder_chain () at
../../gcc-svn/trunk/gcc/cfgrtl.c:3436
#1  0x0001203472d0 in cfg_layout_finalize () at
../../gcc-svn/trunk/gcc/cfgrtl.c:4055
#2  0x000120344f64 in outof_cfg_layout_mode () at
../../gcc-svn/trunk/gcc/cfgrtl.c:3295
#3  0x00012079a52c in execute_one_pass (pass=0x1212d8a30
) at ../../gcc-svn/trunk/gcc/passes.c:2337

(gdb) p bb
$1 = (basic_block) 0x1