[Bug other/53285] libibiberty's md5.c builds with warnings with 4.7 and trunk

2012-05-27 Thread doko at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53285

--- Comment #2 from Matthias Klose  2012-05-28 
06:42:37 UTC ---
the patch is incomplete.

the patch from glibc is found at
http://sourceware.org/git/?p=glibc.git;a=patch;h=7dc6bd90c569c49807462b0740b18e32fab4d8b7

using anonymous unions which cannot be used for stage1. The original patch is
http://sourceware.org/ml/libc-alpha/2011-07/msg00085.html

A third approach from gnulib is pointed out in
http://sourceware.org/ml/libc-alpha/2011-07/msg00093.html


[Bug libstdc++/53504] New: configure script of platform TLS support.

2012-05-27 Thread lyricconch at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53504

 Bug #: 53504
   Summary: configure script of platform TLS support.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lyricco...@gmail.com


file: gcc-4.70/stdc++v3/configure
line: 51506

#include 
__thread int a;
static int *volatile a_in_other_thread;
static void *
thread_func (void *arg)
{
  a_in_other_thread = &a;
  return (void *)0;
}
int
main ()
{
pthread_t thread;
void *thread_retval;
int *volatile a_in_main_thread;
a_in_main_thread = &a;
if (pthread_create (&thread, (pthread_attr_t *)0,
thread_func, (void *)0))
  return 0;
if (pthread_join (thread, &thread_retval))
  return 0;
return (a_in_other_thread == a_in_main_thread);
  ;
  return 0;
}
_ACEOF
if ac_fn_c_try_run "$LINENO"; then :
  gcc_cv_have_tls=yes
else
  gcc_cv_have_tls=no
fi

1. if we have TLS support, &a will be difference value in main() and
hread_func(), which means (a_in_other_thread == a_in_main_thread) eval to
false.
so, with TLS support => program exit with 0.

2. if "pthread_create" or "pthread_join" fails, program also exit with 0. "no
threads, no TLS". 
so, without TLS support => program exit with 0.

whatever ac_fn_c_try_run get, this can not be right.


[Bug other/53285] libibiberty's md5.c builds with warnings with 4.7 and trunk

2012-05-27 Thread doko at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53285

--- Comment #1 from Matthias Klose  2012-05-28 
04:38:50 UTC ---
Created attachment 27511
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27511
patch taken from glibc

the md5.c copy in glibc was fixed with the attached patch


[Bug c++/53503] New: [4.7 Regression] [C++0x] unexpected AST of kind ltgt_expr

2012-05-27 Thread liling at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53503

 Bug #: 53503
   Summary: [4.7 Regression] [C++0x] unexpected AST of kind
ltgt_expr
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lil...@gmail.com


Created attachment 27510
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27510
Preporcessed source

G++ 4.7 can't compile a one-line file with both -std=c++0x and
-fno-trapping-math:

$ cat a.cpp
#include 
$ g++ -fno-trapping-math -std=c++0x -c a.cpp
In file included from a.cpp:1:0:
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/cmath: In
function ‘constexpr bool std::islessgreater(float, float)’:
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/cmath:764:47:
sorry, unimplemented: unexpected AST of kind ltgt_expr
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/cmath:764:
confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccGqxqjD.out file, please attach this to
your bugreport.

I was using GCC 4.7.0 20120507 on Fedora 17.


[Bug c/53502] [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx

2012-05-27 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53502

--- Comment #2 from Andrew Pinski  2012-05-27 
23:42:17 UTC ---
The warning is correct, the typedef is unused.  The enum is not but the typedef
to the enum is unused.


[Bug c/53502] [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx

2012-05-27 Thread tkoenig at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53502

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to work||4.6.2
   Target Milestone|--- |4.8.0
  Known to fail||4.8.0

--- Comment #1 from Thomas Koenig  2012-05-27 
23:25:50 UTC ---
Better with source to the test case...

int bar(void)
{
  typedef enum
  {
ZERO=0, ONE
  } foo;

  return ONE;
}


[Bug c/53502] New: [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx

2012-05-27 Thread tkoenig at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53502

 Bug #: 53502
   Summary: [4.8 Regression] Bootstrap broken with
--disable-build-poststage1-with-cxx
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org


../trunk/configure --prefix=$HOME --enable-languages=c,fortran
--disable-build-poststage1-with-cxx

The error was:

../../trunk/gcc/fortran/decl.c: In function 'match_attr_spec':
../../trunk/gcc/fortran/decl.c:3276:3: error: typedef 'decl_types' locally
defined but not used [-Werror=unused-local-typedefs]
decl_types;
^
cc1: all warnings being treated as errors
make[3]: *** [fortran/decl.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory `/home/ig25/Gcc/trunk-bin/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/ig25/Gcc/trunk-bin'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/ig25/Gcc/trunk-bin'
make: *** [all] Error 2

Reduced test case:

ig25@linux-fd1f:~/Krempel/Boot> gcc -Werror -Wall foo.c
foo.c: In function 'bar':
foo.c:6:5: error: typedef 'foo' locally defined but not used
[-Werror=unused-local-typedefs]
   } foo;
 ^
cc1: all warnings being treated as errors
ig25@linux-fd1f:~/Krempel/Boot> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/home/ig25
--enable-languages=c,fortran
Thread model: posix
gcc version 4.8.0 20120527 (experimental) (GCC) 
ig25@linux-fd1f:~/Krempel/Boot> 

4.6.2 doesn't warn.


[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo

2012-05-27 Thread steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474

Steven Bosscher  changed:

   What|Removed |Added

   Keywords||patch
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-05/msg01813.htm
   ||l

--- Comment #52 from Steven Bosscher  2012-05-27 
23:15:19 UTC ---
Patch set posted by matz.


[Bug middle-end/51389] GCC uses up to 75GB of virtual memory

2012-05-27 Thread steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51389

--- Comment #6 from Steven Bosscher  2012-05-27 
23:14:03 UTC ---
If this is fixed for GCC 4.7, why leave the bug report open? Do you plan to
back-port a similar fix to older release branches?


[Bug tree-optimization/18687] >200% compile time regression compared to gcc-3.4

2012-05-27 Thread steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #55 from Steven Bosscher  2012-05-27 
23:11:06 UTC ---
Some new timings:

hashes.c -O0:
3.4.64.2.44.3.34.4.74.6.3
user0.020760.020370.019720.022910.02286
sys0.003830.004830.004680.005830.00568

hashes.c -O1:
3.4.64.2.44.3.34.4.74.6.3
user0.02780.04720.04590.05390.0572
sys0.00460.00550.00660.00750.0082

hashes.c -O2:
3.4.64.2.44.3.34.4.74.6.3
user0.04520.07000.07440.07730.0842
sys0.00470.00650.00600.00830.0086


infcodes.c -O0:
3.4.64.2.44.3.34.4.74.6.3
user0.03740.03960.04210.04990.0490
sys0.00460.00590.00650.00640.0071

infcodes.c -O1:
3.4.64.2.44.3.34.4.74.6.3
user0.04810.08860.08210.09500.0849
sys0.00460.00740.00660.00920.0070

infcodes.c -O2:
3.4.64.2.44.3.34.4.74.6.3
user0.07450.13030.13060.13890.1354
sys0.00540.00960.00960.00880.0091


[Bug bootstrap/53343] [4.8 regression] options.c:9944:1: error: no previous prototype for 'common_handle_option_auto' breaks bootstrap

2012-05-27 Thread tkoenig at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53343

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  2012-05-27 
23:11:28 UTC ---
See also

http://gcc.gnu.org/ml/fortran/2012-05/msg00152.html


[Bug tree-optimization/53501] New: incorrect loop optimization with -O2

2012-05-27 Thread misof at gcc dot ksp.sk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53501

 Bug #: 53501
   Summary: incorrect loop optimization with -O2
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gcc.ksp.sk


Created attachment 27509
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27509
preprocessed file for which the bug manifests

Sorry if this is a duplicate or if I miscategorized it (my first bug report
here, I did search for this and found nothing similar enough).

This bug appears both in gcc and g++, my best guess is that it has to do with
incorrect optimization of a loop. Bug present at amd64, gcc versions 4.6.3
(Ubuntu) and 4.7.0 (compiled), details follow:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

$ ./gcc -v # my build of 4.7.0
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/home/misof/Desktop/newgcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/misof/Desktop/newgcc/
--disable-multilib
Thread model: posix
gcc version 4.7.0 (GCC) 

Here is the offending source code:
$ cat bug.c
#include 

int e[100], n;

void foo(void) {
int i, k = 0;
for (i = 0; i < n; ++i) { e[k] = 10; ++k; e[k] = 10; ++k; }
for (i = 0; i < k; ++i) printf("%d\n",e[i]);
printf("k=%d\n",k);
}

int main(void) {
n = 10;
foo();
return 0;
}

Up to my best knowledge this should be valid C code. When compiled without
optimizations or with -O1, everything works as expected:

$ gcc -Wall -Wextra bug.c && ./a.out
10
10
10
10
k=4

However, once -O2 or more is used, the second for-cycle seems to be incorrectly
optimized away:
$ gcc -Wall -Wextra -O2 bug.c && ./a.out
k=4

Interestingly, -fwrapv does make a difference, even though there seem to be no
integer overflows in the code:
$ gcc -Wall -Wextra -O2 -fwrapv bug.c && ./a.out 
10
10
10
10
k=4

Below is the complete stdout of
$ gcc -v -save-temps -Wall -Wextra -O2 bug.c 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O2' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.6/cc1 -E -quiet -v -imultilib . -imultiarch
x86_64-linux-gnu bug.c -mtune=generic -march=x86-64 -Wall -Wextra -O2
-fpch-preprocess -fstack-protector -o bug.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/x86_64-linux-gnu
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-O2' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.6/cc1 -fpreprocessed bug.i -quiet -dumpbase
bug.c -mtune=generic -march=x86-64 -auxbase bug -O2 -

[Bug bootstrap/53343] [4.8 regression] options.c:9944:1: error: no previous prototype for 'common_handle_option_auto' breaks bootstrap

2012-05-27 Thread mikpe at it dot uu.se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53343

--- Comment #4 from Mikael Pettersson  2012-05-27 
21:05:27 UTC ---
(In reply to comment #3)
> >--disable-build-poststage1-with-cxx
> 
> Is there a reason why you are using this option?

Yes,

1. It's a valid option, and it doesn't disable any functionality in the final
compiler.

2. Bootstrapping in C++ mode has been reported to increase bootstrap time, I
don't have any numbers, but this was mentioned last year around the time the
default was changed.  As I bootstrap more or less continuously on fairly
underpowered boxes (arm, m68k, even my dual-cpu sparc64 SunBlade2500 is too
slow compared to my x86 boxes), I don't want to spend cycles (and generate
heat) on something that is of no value to me.

3. The C++ FE has repeatedly failed to warn on some forms of code that the C FE
does warn about, allowing dodgy (for a C-centric definition of dodgy) code to
enter the gcc code base.  Bootstrapping in C mode ensures that such regressions
are detected.


[Bug c++/53500] internal compiler error in joust()

2012-05-27 Thread pogonyshev at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500

--- Comment #6 from Paul Pogonyshev  2012-05-27 
20:03:40 UTC ---
Created attachment 27508
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27508
much reduced testcase not using any libraries other than libstdc++

gcc-4.7 -std=c++11 -save-temps -I. -DBOOST_TEST_DYN_LINK=1 -c
tests/map-insert.cpp -o tests/map-insert.o
tests/map-insert.cpp: In function ‘void foo()’:
tests/map-insert.cpp:41:60: internal compiler error: in joust, at
cp/call.c:8014

Command line is the same as before, but it shouldn't matter.


[Bug c++/53500] internal compiler error in joust()

2012-05-27 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500

--- Comment #5 from Andrew Pinski  2012-05-27 
19:57:45 UTC ---
Though with -ftime-report I get an internal error:
/usr/include/c++/4.7/bits/alloc_traits.h:48:11: internal compiler error: in
timevar_start, at timevar.c:344


[Bug c++/53500] internal compiler error in joust()

2012-05-27 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500

--- Comment #4 from Andrew Pinski  2012-05-27 
19:56:43 UTC ---
It compiles on the trunk.  Though takes a long time.


[Bug c++/53500] internal compiler error in joust()

2012-05-27 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500

--- Comment #3 from Paolo Carlini  2012-05-27 
19:49:56 UTC ---
Please do your best to reduce the testcase, normally less than ~100 lines are
enough:

http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

In any case a preprocessed .ii must be attached, possibly compressed with, eg,
bzip2, for the PR to be valid. Thanks.


[Bug c++/53500] internal compiler error in joust()

2012-05-27 Thread pogonyshev at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500

--- Comment #2 from Paul Pogonyshev  2012-05-27 
19:33:35 UTC ---
(In reply to comment #1)
> I don't see it being attached.

Apparently it got eaten as too large.  Please see http://rghost.net/38322304


[Bug c++/53500] internal compiler error in joust()

2012-05-27 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-27
 Ever Confirmed|0   |1


[Bug c++/53500] internal compiler error in joust()

2012-05-27 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500

--- Comment #1 from Andrew Pinski  2012-05-27 
19:11:41 UTC ---
> I attached the /tmp/... file.

I don't see it being attached.


[Bug c++/53500] internal compiler error in joust()

2012-05-27 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500

Andrew Pinski  changed:

   What|Removed |Added

   Severity|major   |normal


[Bug c++/53500] New: internal compiler error in joust()

2012-05-27 Thread pogonyshev at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53500

 Bug #: 53500
   Summary: internal compiler error in joust()
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pogonys...@gmx.net


Version:
gcc-4.7 (Debian 4.7.0-9) 4.7.0
x86_64-linux-gnu

Here is the command and console compiler output:

gcc-4.7 -std=c++11 -save-temps -I. -DBOOST_TEST_DYN_LINK=1 -c
tests/map-insert.cpp -o tests/map-insert.o
tests/map-insert.cpp: In instantiation of ‘void
map_insert::test_map_insert_initializers_1::test_method() [with
implementation = HugeForwardMap]’:
tests/map-insert.cpp:155:124:   required from ‘static void
map_insert::test_map_insert_initializers_1_invoker::run(boost::type*)
[with TestType = HugeForwardMap]’
/usr/local/include/boost/test/unit_test_suite_impl.hpp:357:25:   required from
‘void boost::unit_test::ut_detail::test_case_template_invoker::operator()() [with TestCaseTemplate =
map_insert::test_map_insert_initializers_1_invoker; TestType = HugeForwardMap]’
/usr/local/include/boost/test/utils/callback.hpp:56:35:   required from
‘boost::unit_test::ut_detail::unused
boost::unit_test::ut_detail::invoker::invoke(Functor&)
[with Functor =
boost::unit_test::ut_detail::test_case_template_invoker]’
/usr/local/include/boost/test/utils/callback.hpp:89:58:   required from ‘R
boost::unit_test::ut_detail::callback0_impl_t::invoke() [with R =
boost::unit_test::ut_detail::unused; Functor =
boost::unit_test::ut_detail::test_case_template_invoker]’
tests/map-insert.cpp:215:94:   required from here
tests/map-insert.cpp:162:3: internal compiler error: in joust, at
cp/call.c:8014
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccR3ebge.out file, please attach this to
your bugreport.

I attached the /tmp/... file.


[Bug c/53467] xgcc:Internal error: Bus error (program cc1)

2012-05-27 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53467

--- Comment #6 from Jonathan Wakely  2012-05-27 
16:45:29 UTC ---
The core file was not generated by gcc, as gdb says it came from cc1


[Bug c++/53498] Compiler crashes during C++11 template magic compilation

2012-05-27 Thread daniel.kruegler at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53498

--- Comment #3 from Daniel Krügler  
2012-05-27 16:09:04 UTC ---
(In reply to comment #2)
> As you mention it, you don't accidently know, how a correct version would 
> look? 

This request would be off-topic here, but I responded off-list to you. 

> I want to test, if the class U has a method print compatible with the given
> ARGS.

Your example does not perform any kind of "test", so I'm not sure that I
understand your question correctly [But keep in mind that any responses to that
issue here should concentrate on the bug report, not on details of C++
programming techniques].


[Bug c/53467] xgcc:Internal error: Bus error (program cc1)

2012-05-27 Thread dokumentarfilme at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53467

--- Comment #5 from martin  2012-05-27 
16:06:59 UTC ---
Comment on attachment 27506
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27506
core - debug for gdb

gdb $(which gcc) ./core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-linux"...Using host libthread_db library
"/lib/libthread_db.so.1".


warning: core file may not match specified executable file.
Core was generated by `/backup/gcc-4.3.0-compiled/./gcc/cc1 -E -quiet -iprefix
/c/backup/gcc-4.3.0-com'.
Program terminated with signal 10, Bus error.
#0  0x2000ab58 in ?? ()
Breakpoint 1 at 0x13214: file ../../gcc-4.0.0/gcc/gcc.c, line 6733.
Function "internal_error" not defined.
Breakpoint 2 at 0x37348
Breakpoint 3 at 0x37210


[Bug c/53467] xgcc:Internal error: Bus error (program cc1)

2012-05-27 Thread dokumentarfilme at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53467

--- Comment #4 from martin  2012-05-27 
16:03:35 UTC ---
Created attachment 27507
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27507
df-core.o debug for gdb


[Bug c/53467] xgcc:Internal error: Bus error (program cc1)

2012-05-27 Thread dokumentarfilme at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53467

--- Comment #3 from martin  2012-05-27 
16:01:23 UTC ---
Created attachment 27506
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27506
debug for gdb

created with ulimit -c unlimited & make --debug CFLAGS='-g -O0'


[Bug c++/53498] Compiler crashes during C++11 template magic compilation

2012-05-27 Thread o.mangold at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53498

--- Comment #2 from o.mangold at googlemail dot com 2012-05-27 15:33:16 UTC ---
(In reply to comment #1)
> While the test code is somewhat broken, 

Yes, I'm not surprised, this template stuff is a complete nightmare to me. As
you mention it, you don't accidently know, how a correct version would look? I
want to test, if the class U has a method print compatible with the given ARGS.


[Bug c++/53498] Compiler crashes during C++11 template magic compilation

2012-05-27 Thread daniel.kruegler at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53498

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-05-27 14:32:40 UTC ---
While the test code is somewhat broken, I found some suspicious compiler
behaviour when rewriting this into the following form, compiled with 
-std=c++11 -Wall using gcc 4.8.0 20120520 (experimental):

//
template
struct A
{
  template
  static
  auto a(const U& u, const Args&... args, int) -> decltype(u.print(args...))
  {
return u.print(args...);
  }
  template
  static
  int a(const U& u, const Args&... args, ...)
  {
return 0;
  }
};

template
struct B
{
  template
  static
  void b(const U& u, const Args&... args, decltype(A::a(u, args...,
0)) dummy)
  {
  }
};

int main() {
  A::a(0, 0, 0); // OK
  B::b(0, 0, 0); // ?
}
// 

On my mingw build there is no diagnostics and no binary output produced except
that the compiler does not return successfully due to the last line
instantiating B. In my experience that gives a seg fault on other systems,
so I recommend to run it through another system.


[Bug c++/53499] Incorrect partial ordering result with member vs non-member

2012-05-27 Thread schaub.johannes at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499

--- Comment #1 from Johannes Schaub  
2012-05-27 14:00:20 UTC ---
Sorry, GCC picks the same function (non-member) disregarding of the C++
Standards mode. The comments were a left-over from a clang bug report.


[Bug c++/53499] New: Incorrect partial ordering result with member vs non-member

2012-05-27 Thread schaub.johannes at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499

 Bug #: 53499
   Summary: Incorrect partial ordering result with member vs
non-member
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com


I think that this is ambiguous for partial ordering ambiguities, but GCC
accepts this code, selecting the non-member

template 
class ptr
{
public:
  // Picked in C++11 mode.
  template
  void operator- (T) const   
  {  static_assert(sizeof(T) == 0, "#1"); }
};

// Picked in default C++ mode.
template
void operator- (const ptr&, const ptr&)
{  static_assert(sizeof(T1) == 0, "#2"); }

int
main ()
{
  ptr  a, b;
  (void) (b - a);
}


[Bug c++/53498] New: Compiler crashes during C++11 template magic compilation

2012-05-27 Thread o.mangold at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53498

 Bug #: 53498
   Summary: Compiler crashes during C++11 template magic
compilation
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o.mang...@googlemail.com


I was trying to create some template magic to create a check for the existence
of a function with variable number of arguments in C++11. Honestly, I don't
know, if my code should compile through, as the problem happened when I was
trying to figure out how to make it work. I got a compiler crash (which I guess
shouldn't happen in any case). I cooked it down to the example below:

> g++ -std=c++11 Crash.cxx

g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
kiwi/SafePrintf$g++ -std=c++11 Crash.cxx 
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
---

--- Crash.cxx ---
template
class A
{
public:
  template
  auto a(const U& u,const ARGS&... args,int) -> decltype(u.print(args...))

  {
  }
  template
  int a(const U& u,const ARGS&... args,...)

  {
  }

};

template
class B
{
public:
  template static void
  b(const U& u,const ARGS&... args,
decltype(A::a(u,args...,0)) dummy)
  {
  }
};

int main() {

  B dummy;

  return 0;
}


[Bug c++/53439] g++ generates buggy code with optimisation flags

2012-05-27 Thread christophe.prudhomme at feelpp dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53439

--- Comment #3 from Christophe Prud'homme  2012-05-27 11:59:46 UTC ---
the preprocessed sources files are here (about 3MB)
 http://feelpp.googlecode.com/files/feel-gcc-ifiles.tar.gz

see initial email


[Bug c++/53497] New: Partial ordering of function templates does not order lvalue/rvalue references correctly

2012-05-27 Thread vlukas at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53497

 Bug #: 53497
   Summary: Partial ordering of function templates does not order
lvalue/rvalue references correctly
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vlu...@gmx.de


Following defect report 1164
(http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1164) a rule was
added to partial ordering of function templates, so that parameters declared as
lvalue-references are considered more specialized than those declared as
rvalue-references. GCC does not implement this, i.e.
---
template
void t(T&);
template
void t(T&&);

int x;
void f() {
  t(x);
}
---
is rejected by GCC 4.7.0 and a 4.8.0 prerelease. Diagnostic for the latter is:
-
c++ -std=c++11 -c ref_binding.cc
ref_binding.cc: In function ‘void f()’:
ref_binding.cc:8:6: error: call of overloaded ‘t(int&)’ is ambiguous
   t(x);
  ^
ref_binding.cc:8:6: note: candidates are:
ref_binding.cc:2:6: note: void t(T&) [with T = int]
 void t(T&);
  ^
ref_binding.cc:4:6: note: void t(T&&) [with T = int&]
 void t(T&&);
  ^
-

Full compiler identification:
-
c++ -v
Using built-in specs.
COLLECT_GCC=/home/lima/vanilla_installs/gcc_and_tools/bin/c++
COLLECT_LTO_WRAPPER=/home/lima/vanilla_installs/gcc_and_tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc_svn/configure
--prefix=/home/lima/vanilla_installs/gcc_and_tools --enable-threads
--enable-__cxa_atexit --enable-languages=c,c++
--enable-version-specific-runtime-libs --disable-multilib
Thread model: posix
gcc version 4.8.0 20120526 (experimental) (GCC)


DR 1164 appears to have made it into the standard, it is marked FDIS and I find
it in both the N3290 and N3376 drafts of C++.


[Bug ada/50934] Attribute Max_Size_In_Storage_Elements is wrong for controlled types

2012-05-27 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50934

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-c
   ||vs/2011-11/msg00869.html
 CC||ebotcazou at gcc dot
   ||gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #5 from Eric Botcazou  2012-05-27 
11:00:27 UTC ---
Indeed.


[Bug ada/50934] Attribute Max_Size_In_Storage_Elements is wrong for controlled types

2012-05-27 Thread simon at pushface dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50934

--- Comment #4 from simon at pushface dot org 2012-05-27 10:22:42 UTC ---
This problem has been fixed in the released 4.7.0.