[Bug other/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-18 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-18 09:30:22 UTC --- Few things to cover: - The changes need to be approved by one of the maintainers (or is it obvious)? Yes, it's how GCC works. - Except for *really* trivial changes all patches should go through the upstream tree first. That's not acceptable. We don't want to have to go through LLVM to fix issues in GCC, especially for the platforms that LLVM doesn't support, i.e. most of them. - What is the testing procedure when updating from upstream? (e.g. how do we avoid regressions on the platforms to which the maintainers have no access?) Introducing such regressions is acceptable, provided that they can be quickly fixed by the target maintainers. Hence the not acceptable above.
[Bug c++/55377] New: ipa-pure-cont produces wrong code on AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55377
Bug #: 55377
Summary: ipa-pure-cont produces wrong code on AVR
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@d-silva.org
Created attachment 28722
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28722
Preprocessed source exhibiting bad code without -fno-ipa-pure-const
(Sorry I could not produce a simpler test case, when simplified, the problem
did not occur).
GCC Version
C:\tempavr-g++ --version
avr-g++ (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
OS Version (Windows 8 x64)
C:\tempver
Microsoft Windows [Version 6.2.9200]
Configure args
../gcc-${GCC_VERSION}/configure --prefix=$PREFIX --host=i686-pc-mingw32
--target=avr --enable-languages=c,c++ --with-dwarf2
-enable-win32-registry=MHV-AVR-Tools --enable-lto --with-avrlibc=yes
--with-gmp=$LIBPREFIX --with-mpfr=$LIBPREFIX --with-mpc=$LIBPREFIX
--disable-libssp
Compiler output
C:\tempavr-g++ -I. -Wall -g3 -gstabs -Os -fshort-enums -ffunction-sections
-fdata-sections -fmerge-constants -flto -funsigned-char -funsigned-bitfields
-fno-exceptions -Wsuggest-attribute=pure -Wsuggest-attribute=const
-Wsuggest-attribute=noreturn -Wextra -std=c++11 -mmcu=atmega328p
-DF_CPU=2000UL -MMD -MP -MFSerialAsync.d -MTSerialAsync.d -c -o
SerialAsync.o -v -save-temps SerialAsync.cpp
Using built-in specs.
COLLECT_GCC=avr-g++
Target: avr
Configured with: ../gcc-4.7.2/configure
--prefix=/c/mhvavrtools/mhvavrtools/mhvavrtools --host=i686-pc-mingw32
--target=avr --enable-languages=c,c++ --with-dwarf2
-enable-win32-registry=MHV-AVR-Tools --enable-lto --with-avrlibc=yes
--with-gmp=/c/mhvavrtools/mhvavrtools/build/bin
--with-mpfr=/c/mhvavrtools/mhvavrtools/build/bin
--with-mpc=/c/mhvavrtools/mhvavrtools/build/bin --disable-libssp
Thread model: single
gcc version 4.7.2 (GCC)
COLLECT_GCC_OPTIONS='-I' '.' '-Wall' '-g3' '-gstabs' '-Os' '-fshort-enums'
'-ffunction-sections' '-fdata-sections' '-fmerge-constants' '-flto'
'-funsigned-char' '-funsigned-bitfields' '-fno-exceptions'
'-Wsuggest-attribute=pure' '-Wsuggest-attribute=const'
'-Wsuggest-attribute=noreturn' '-Wextra' '-std=c++11' '-mmcu=atmega328p' '-D'
'F_CPU=2000UL' '-MMD' '-MP' '-MF' 'SerialAsync.d' '-MT' 'SerialAsync.d'
'-c' '-o' 'SerialAsync.o' '-v' '-save-temps'
c:/program files (x86)/mhv avr tools/bin/../libexec/gcc/avr/4.7.2/cc1plus.exe
-E -quiet -v -I . -imultilib avr5 -iprefix c:\program files (x86)\mhv avr
tools\bin\../lib/gcc/avr/4.7.2/ -MMD SerialAsync.d -MF SerialAsync.d -MP -MT
SerialAsync.d -dD -D F_CPU=2000UL SerialAsync.cpp -mmcu=atmega328p
-std=c++11 -Wall -Wsuggest-attribute=pure -Wsuggest-attribute=const
-Wsuggest-attribute=noreturn -Wextra -fshort-enums -ffunction-sections
-fdata-sections -fmerge-constants -flto -funsigned-char -funsigned-bitfields
-fno-exceptions -g3 -gstabs -fworking-directory -Os -fpch-preprocess -fno-rtti
-fno-enforce-eh-specs -fno-exceptions -o SerialAsync.ii
ignoring nonexistent directory c:\program files (x86)\mhv avr
tools\bin\../lib/gcc/avr/4.7.2/../../../../avr/include/c++/4.7.2
ignoring nonexistent directory c:\program files (x86)\mhv avr
tools\bin\../lib/gcc/avr/4.7.2/../../../../avr/include/c++/4.7.2/avr/avr5
ignoring nonexistent directory c:\program files (x86)\mhv avr
tools\bin\../lib/gcc/avr/4.7.2/../../../../avr/include/c++/4.7.2/backward
ignoring nonexistent directory c:\program files (x86)\mhv avr
tools\bin\../lib/gcc/avr/4.7.2/../../../../avr/sys-include
ignoring nonexistent directory c:/program files (x86)/mhv avr
tools/lib/gcc/../../lib/gcc/avr/4.7.2/../../../../avr/include/c++/4.7.2
ignoring nonexistent directory c:/program files (x86)/mhv avr
tools/lib/gcc/../../lib/gcc/avr/4.7.2/../../../../avr/include/c++/4.7.2/avr/avr5
ignoring nonexistent directory c:/program files (x86)/mhv avr
tools/lib/gcc/../../lib/gcc/avr/4.7.2/../../../../avr/include/c++/4.7.2/backward
ignoring duplicate directory c:/program files (x86)/mhv avr
tools/lib/gcc/../../lib/gcc/avr/4.7.2/include
ignoring duplicate directory c:/program files (x86)/mhv avr
tools/lib/gcc/../../lib/gcc/avr/4.7.2/include-fixed
ignoring nonexistent directory c:/program files (x86)/mhv avr
tools/lib/gcc/../../lib/gcc/avr/4.7.2/../../../../avr/sys-include
ignoring duplicate directory c:/program files (x86)/mhv avr
tools/lib/gcc/../../lib/gcc/avr/4.7.2/../../../../avr/include
#include ... search starts here:
#include ... search starts here:
.
c:\program files (x86)\mhv avr tools\bin\../lib/gcc/avr/4.7.2/include
c:\program files (x86)\mhv avr
[Bug c/55378] New: Inconsistant double 387 computation when using osthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378 Bug #: 55378 Summary: Inconsistant double 387 computation when using osthread Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: philippe.coust...@gmail.com Created attachment 28723 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28723 Full testcase for win32 and cygwin This program compute a bayes propability and accept one parameter with is used to set up initial weights. The proc ComputeBayes_p is called directly once from the main() and once called within an os thread. The same code is executed in both context. The expected behavior is that the result of computation be the same in both context. The inconsistancy appears depending of the parameter, and of the optimisation level Some low weights bits vary. for low values of the parameter (15) the problem doesn't occurs with low optimization. for higher values (30) the problem appears even with -O0 and -g optimization level There is 2 subdirectory. one named cyg for unix compilation, one named win for windows. The build compile the program with different optimisation levels the test script run the compiled binaries the run-test use the test script with 2 parameter value. The output of the program provide the diag: Global result ./U3 15 ** Thread bug.**. = Details == Difference Dec/Hex (Without / With): 5.421010862427522e-20 / 0X1.P-64 The line with the diag is a copy of the arg line and using the conventions used by the build script, indicate the optimization level. (hehe -O3) the last line is the delta between computation without thread and the computation with thread I have conducted the tests on winxp and seven on two intel processors, amd seems to have same behavior It's reproducible with mingw and with cygwin. The problem doesn't appears with sse math and tests on a true debian linux doesn't exibit the problem. To reproduce the problem, use a windows console or a cygwin terminal Go in the adequate directory run the build script to compile the test, launch the run-test script to produce the RUN-LOG-?? files that trace the problem. The problem seems similar to: http://sourceforge.net/tracker/?func=detailatid=102435aid=3409958group_id=2435
[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2012-11-18 13:15:59 UTC --- I got /tmp/cc5sWfOD.s: Assembler messages: /tmp/cc5sWfOD.s:824391: Error: invalid character (0xf7) in mnemonic make[7]: *** [/tmp/ccpgVF41.ltrans24.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /usr/local/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[6]: *** [cc1] Error 1 make[6]: *** Waiting for unfinished jobs In .section .debug_info,,@progbits, there are 824390 .byte 0x30 824391 ÷ÿÿè^H¨=: 824392 .uleb128 0x7
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||zeratul976 at hotmail dot ||com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-18 13:41:32 UTC --- *** Bug 55373 has been marked as a duplicate of this bug. ***
[Bug c++/55373] Partial ordering of variadic function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55373 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-18 13:41:32 UTC --- Dup *** This bug has been marked as a duplicate of bug 41958 ***
[Bug middle-end/55348] Problem in tree-ssa-pre.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55348 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Component|c++ |middle-end Severity|major |normal --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-18 13:50:54 UTC --- Isn't C++ anyway
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-18 13:52:53 UTC --- Thanks. Closing.
[Bug c++/55319] Using -fwhole-program inhibits optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55319 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-18 14:00:37 UTC --- In order to quickly make progress on the issue, I recommend filing something much smaller and less obfuscated. Also, not using internal stdio interfaces (anyway, very likely i/o itself isn't essential and an assert or an abort would do)
[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55367 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-18 14:04:00 UTC --- Does it happen only on Windows? Which kind of system exactly, mingw, Cygwin? In case should be target, as Component
[Bug c/55378] Inconsistant double 387 computation when using osthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378 philippe.coustaux at gmail dot com changed: What|Removed |Added Target||Mingw, cygwin Host||Windows --- Comment #1 from philippe.coustaux at gmail dot com 2012-11-18 14:16:40 UTC --- This my interpretation: As the values in 'pond' are the same, the loop line 158 will produce 5! (120) the same value in s1 So the problem came from line 165 or 167 under windows threads.
[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932
--- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr
2012-11-18 14:33:49 UTC ---
... in wich case could you, please, update the testcase to be valid and remove
the XFAIL I introduced?
I cannot commit anything, but the XFAIL can be fixed in several ways:
(1) keep the test, but restrict it to option -O0
(2) change the test along the following line to make it valid:
--- ../_clean/gcc/testsuite/gfortran.dg/do_1.f902012-10-18
20:35:25.0 +0200
+++ gcc/testsuite/gfortran.dg/do_1.f902012-10-23 18:31:32.0 +0200
@@ -1,4 +1,4 @@
-! { dg-do run { xfail *-*-* } }
+! { dg-do run }
! XFAIL is tracked in PR 54932
! Program to check corner cases for DO statements.
program do_1
@@ -7,18 +7,18 @@ program do_1
! limit=HUGE(i), step 1
j = 0
- do i = HUGE(i) - 10, HUGE(i), 1
+ do i = HUGE(i) - 11, HUGE(i) - 1, 1
j = j + 1
end do
if (j .ne. 11) call abort
! limit=HUGE(i), step 1
j = 0
- do i = HUGE(i) - 10, HUGE(i), 2
+ do i = HUGE(i) - 11, HUGE(i) - 1, 2
j = j + 1
end do
if (j .ne. 6) call abort
j = 0
- do i = HUGE(i) - 9, HUGE(i), 2
+ do i = HUGE(i) - 10, HUGE(i) - 1, 2
j = j + 1
end do
if (j .ne. 5) call abort
@@ -62,7 +62,7 @@ function test1(r, step)
integer test1, r, step
integer k, n
k = 0
- do n = HUGE(n) - r, HUGE(n), step
+ do n = HUGE(n) - r - 1, HUGE(n) - 1, step
k = k + 1
end do
test1 = k
(tested on darwin),
(3) do (1) and add a new test along (2),
(4) ...
As asked in several other mails, would it be possible that the optimizer emits
a warning/error when it relies on a DETECTED undefined behavior (here the
number of unrolling does not match the number of iterations computed from the
loop bounds)?
[Bug driver/55379] New: -static -static-libasan doesn't create static binary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 Bug #: 55379 Summary: -static -static-libasan doesn't create static binary Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com [hjl@gnu-tools-1 gcc]$ ./xgcc -B./ x.o -o x -faddress-sanitizer -B../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/ -static-libasan [hjl@gnu-tools-1 gcc]$ ldd a.out linux-vdso.so.1 = (0x7fffc6991000) libstdc++.so.6 = /lib64/libstdc++.so.6 (0x00334120) libm.so.6 = /lib64/libm.so.6 (0x00333820) libgomp.so.1 = /lib64/libgomp.so.1 (0x003343e0) libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x00333aa0) libpthread.so.0 = /lib64/libpthread.so.0 (0x003337a0) libc.so.6 = /lib64/libc.so.6 (0x00333720) /lib64/ld-linux-x86-64.so.2 (0x003336e0) librt.so.1 = /lib64/librt.so.1 (0x003337e0) [hjl@gnu-tools-1 gcc]$
[Bug driver/55379] -static -static-libasan doesn't create static binary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-18 14:52:24 UTC --- It should be [hjl@gnu-tools-1 gcc]$ ./xgcc -B./ x.o -o x -faddress-sanitizer -B../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/ -static-libasan -static [hjl@gnu-tools-1 gcc]$ ldd a.out linux-vdso.so.1 = (0x7fff91699000) libstdc++.so.6 = /lib64/libstdc++.so.6 (0x00334120) libm.so.6 = /lib64/libm.so.6 (0x00333820) libgomp.so.1 = /lib64/libgomp.so.1 (0x003343e0) libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x00333aa0) libpthread.so.0 = /lib64/libpthread.so.0 (0x003337a0) libc.so.6 = /lib64/libc.so.6 (0x00333720) /lib64/ld-linux-x86-64.so.2 (0x003336e0) librt.so.1 = /lib64/librt.so.1 (0x003337e0) [hjl@gnu-tools-1 gcc]$
[Bug driver/55379] -static -static-libasan pass -Bdynamic to linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Summary|-static -static-libasan |-static -static-libasan |doesn't create static |pass -Bdynamic to linker |binary | --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-11-18 14:55:57 UTC --- [hjl@gnu-tools-1 gcc]$ ./xgcc -B./ x.o -o x -faddress-sanitizer -B../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/ -static-libasan -static -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /export/gnu/import/git/sources/gcc/configure --enable-languages=c,c++ --disable-bootstrap --prefix=/usr/gcc-4.8.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse : (reconfigured) /export/gnu/import/git/sources/gcc/configure --disable-bootstrap --prefix=/usr/gcc-4.8.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse CFLAGS=-g CXXFLAGS=-g --enable-languages=c,c++,lto --no-create --no-recursion Thread model: posix gcc version 4.8.0 20121117 (experimental) (GCC) COMPILER_PATH=./:../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/ LIBRARY_PATH=./:../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/:/lib/../lib64/:/usr/lib/../lib64/:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B' './' '-o' 'x' '-faddress-sanitizer' '-B' '../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/' '-static-libasan' '-static' '-v' '-mtune=generic' '-march=x86-64' ./collect2 -m elf_x86_64 -static -o x /lib/../lib64/crt1.o /lib/../lib64/crti.o ./crtbeginT.o -L. -L../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs -L/lib/../lib64 -L/usr/lib/../lib64 x.o -Bstatic -lasan -Bdynamic --start-group -lgcc -lgcc_eh -lc --end-group ./crtend.o /lib/../lib64/crtn.o [hjl@gnu-tools-1 gcc]$
[Bug tree-optimization/55350] [4.8 Regression] verify_gimple failed with invalid (pointer) operands to plus/minus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55350 --- Comment #2 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-11-18 15:04:27 UTC --- I'm on vacation this week, but I'll have a look when I get back on the 26th. Sorry for the delay! Bill
[Bug bootstrap/55380] New: All search_line_fast implementations read beyond buffer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55380 Bug #: 55380 Summary: All search_line_fast implementations read beyond buffer Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com Depends on: 54691 Similar to PR 54691, GCC built with -faddress-sanitizer leads to ==7876== ERROR: AddressSanitizer heap-buffer-overflow on address 0x7f3484513ff0 at pc 0x1e792db bp 0x7fffbed86340 sp 0x7fffbed86338 READ of size 16 at 0x7f3484513ff0 thread T0 #0 0x1e792da (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1+0x1e792da) 0x7f3484513ff0 is located 0 bytes to the right of 4021-byte region [0x7f3484513040,0x7f3484513ff5) allocated by thread T0 here: #0 0x1f2d48c (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1+0x1f2d48c) #1 0x1f2609c (/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/cc1+0x1f2609c) Shadow byte and word: 0x1fe6908a27fe: 5 0x1fe6908a27f8: 00 00 00 00 00 00 05 fb [hjl@gnu-tools-1 gcc]$ addr2line -e cc1 0x1e792da /export/gnu/import/git/sources/gcc/libcpp/lex.c:393 [hjl@gnu-tools-1 gcc]$ All search_line_fast implementations read beyond buffer.
[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #11 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-18 16:24:27 UTC --- (In reply to comment #9) Thus, I close the bug as INVALID. ... in wich case could you, please, update the testcase to be valid and remove the XFAIL I introduced? We jump through some hoops in or DO loop code generation to execute a loop until HUGE(i) in a way that somebody who did not read the standard well might expect, but which is actually invalid. If we do not do this any more, then we can probably simplify our DO loops considerably. We should also warn about invalid code in the FE.
[Bug middle-end/55381] New: [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55381 Bug #: 55381 Summary: [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: dnovi...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf Created attachment 28724 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28724 cc1 -fpreprocessed matmul_i1.i -melf -g -O2 -std=gnu99 -version -fcx-fortran-rules -ffunction-sections -fdata-sections -ftree-vectorize -funroll-loops -o matmul_i1.s Revision r193595 caused the build for cris-elf to fail as follows, with host-gcc gcc-4.4.3-4.fc12.x86_64 as well as gcc-4.4.4-10.fc12.x86_64: libtool: compile: /tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc/xgcc -B/tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc/ -nostdinc -B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/newlib/ -isystem /tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem /tmp/hpautotest-gcc0/gcc/newlib/libc/include -B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libgloss/cris -L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libgloss/libnosys -L/tmp/hpautotest-gcc0/gcc/libgloss/cris -B/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/bin/ -B/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/lib/ -isystem /tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/include -isystem /tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/sys-include -DHAVE_CONFIG_H -I. -I/tmp/hpautotest-gcc0/gcc/libgfortran -iquote/tmp/hpautotest-gcc0/gcc/libgfortran/io -I/tmp/hpautotest-gcc0/gcc/libgfortran/../gcc -I/tmp/hpautotest-gcc0/gcc/libgfortran/../gcc/config -I../.././gcc -I/tmp/hpautotest-gcc0/gcc/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -ftree-vectorize -funroll-loops -g -O2 -MT matmul_i1.lo -MD -MP -MF .deps/matmul_i1.Tpo -c /tmp/hpautotest-gcc0/gcc/libgfortran/generated/matmul_i1.c -o matmul_i1.o /tmp/hpautotest-gcc0/gcc/libgfortran/generated/matmul_i1.c: In function 'matmul_i1': /tmp/hpautotest-gcc0/gcc/libgfortran/generated/matmul_i1.c:79:1: internal compiler error: Illegal instruction matmul_i1 (gfc_array_i1 * const restrict retarray, ^ 0x85fbc5 crash_signal /tmp/hpautotest-gcc0/gcc/gcc/toplev.c:334 0xb37574 analyze_overlapping_iterations /tmp/hpautotest-gcc0/gcc/gcc/tree-data-ref.c:2958 0xb381d1 subscript_dependence_tester_1 /tmp/hpautotest-gcc0/gcc/gcc/tree-data-ref.c:3510 0xb383aa subscript_dependence_tester /tmp/hpautotest-gcc0/gcc/gcc/tree-data-ref.c:3561 0xb398b6 compute_affine_dependence(data_dependence_relation*, loop*) /tmp/hpautotest-gcc0/gcc/gcc/tree-data-ref.c:4190 0xb3a38f compute_all_dependences(vecdata_reference*, va_heap, vl_ptr, vecdata_dependence_relation*, va_heap, vl_ptr*, vecloop*, va_heap, vl_ptr, bool) /tmp/hpautotest-gcc0/gcc/gcc/tree-data-ref.c:4259 0xb3a908 compute_data_dependences_for_loop(loop*, bool, vecloop*, va_heap, vl_ptr*, vecdata_reference*, va_heap, vl_ptr*, vecdata_dependence_relation*, va_heap, vl_ptr*) /tmp/hpautotest-gcc0/gcc/gcc/tree-data-ref.c:4545 0xb5de2c vect_analyze_data_refs(_loop_vec_info*, _bb_vec_info*, int*) /tmp/hpautotest-gcc0/gcc/gcc/tree-vect-data-refs.c:2975 0x9fcf40 vect_analyze_loop_2 /tmp/hpautotest-gcc0/gcc/gcc/tree-vect-loop.c:1598 0x9fcf40 vect_analyze_loop(loop*) /tmp/hpautotest-gcc0/gcc/gcc/tree-vect-loop.c:1774 0xa1425b vectorize_loops() /tmp/hpautotest-gcc0/gcc/gcc/tree-vectorizer.c:114 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [matmul_i1.lo] Error 1 make[3]: Leaving directory `/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libgfortran' Committer of r193595 CC:ed. Preprocessed matmul_i1.c attached.
[Bug c++/55368] Comma before semicolon in struct definition is not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55368 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-18 Ever Confirmed|0 |1
[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55381 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-18 17:04:03 UTC --- Random cutnpasted suspicious warning, maybe related: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/tmp/hpautotest-gcc0/gcc/gcc -I/tmp/hpautotest-gcc0/gcc/gcc/build -I/tmp/hpautotest-gcc0/gcc/gcc/../include -I/tmp/hpautotest-gcc0/gcc/gcc/../libcpp/include -I/tmp/hpautotest-gcc0/cris-elf/gccobj/./gmp -I/tmp/hpautotest-gcc0/gcc/gmp -I/tmp/hpautotest-gcc0/cris-elf/gccobj/./mpfr -I/tmp/hpautotest-gcc0/gcc/mpfr -I/tmp/hpautotest-gcc0/gcc/mpc/src -I/tmp/hpautotest-gcc0/gcc/gcc/../libdecnumber -I/tmp/hpautotest-gcc0/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/tmp/hpautotest-gcc0/gcc/gcc/../libbacktrace\ -o build/read-rtl.o /tmp/hpautotest-gcc0/gcc/gcc/read-rtl.c In file included from /tmp/hpautotest-gcc0/gcc/gcc/rtl.h:29, from /tmp/hpautotest-gcc0/gcc/gcc/read-rtl.c:30: /tmp/hpautotest-gcc0/gcc/gcc/vec.h: In static member function 'static size_t vecT, A, vl_embed::embedded_size(unsigned int) [with T = mapping*, A = va_heap]': /tmp/hpautotest-gcc0/gcc/gcc/vec.h:299: instantiated from 'static void va_heap::reserve(vecT, va_heap, vl_embed*, unsigned int, bool) [with T = mapping*]' /tmp/hpautotest-gcc0/gcc/gcc/vec.h:1445: instantiated from 'bool vecT, A, vl_ptr::reserve(unsigned int, bool) [with T = mapping*, A = va_heap]' /tmp/hpautotest-gcc0/gcc/gcc/vec.h:1540: instantiated from 'T* vecT, A, vl_ptr::safe_push(const T) [with T = mapping*, A = va_heap]' /tmp/hpautotest-gcc0/gcc/gcc/read-rtl.c:389: instantiated from here /tmp/hpautotest-gcc0/gcc/gcc/vec.h:1069: warning: invalid access to non-static data member 'vecmapping*, va_heap, vl_embed::data_' of NULL object /tmp/hpautotest-gcc0/gcc/gcc/vec.h:1069: warning: (perhaps the 'offsetof' macro was used incorrectly)
[Bug middle-end/55369] expmed.c is miscompiled in stage1 bootstrap at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55369 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2012-11-18 17:16:53 UTC --- Created attachment 28725 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28725 Reduced testcase Problem occurs because of gcc_assert expression checking. If disabled, the generated code seems correct. /home/gnu64/gcc/gcc-4.6/bin/../libexec/gcc/hppa64-hp-hpux11.11/4.6.3/cc1plus -fpreprocessed xxx.ii -quiet -dumpbase xxx.c -dA -auxbase-strip xxx.o -g -O1 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wno-error -version -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -o xxx.s
[Bug target/55316] gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error Unsupported arch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55316 --- Comment #2 from dave.anglin at bell dot net 2012-11-18 17:18:20 UTC --- On 17-Nov-12, at 3:01 AM, hp at gcc dot gnu.org wrote: This should be fixed now by the general disabling of libsanitizer. In theory, it should be fairly easy to add the support. -- John David Anglindave.ang...@bell.net
[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226 gnzlbg gonzalobg88 at gmail dot com changed: What|Removed |Added CC||gonzalobg88 at gmail dot ||com --- Comment #3 from gnzlbg gonzalobg88 at gmail dot com 2012-11-18 17:38:49 UTC --- Is this a duplicate of Bug 41933 ?
[Bug fortran/55352] Erroneous gfortran warning of unused module variable when variable is only used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55352 --- Comment #5 from AstroFloyd AstroFloyd at gmail dot com 2012-11-18 17:53:36 UTC --- Created attachment 28726 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28726 My adaptation of the patch in #3 This solves the problem for me, thank you very much - I'm impressed by your quick and competent work :-) Somehow, your patch didn't work in my Gentoo version; I applied your changes manually and created the attached patch, which can be added to the Gentoo ebuild for sys-devel/gcc-4.7.2.
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-18 Ever Confirmed|0 |1
[Bug c++/55382] New: Constant class member as alignment specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55382
Bug #: 55382
Summary: Constant class member as alignment specifier
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aanisi...@inbox.ru
Consider the following sample code:
struct A
{
static const unsigned alignment = 32;
char data[1234] __attribute__((aligned(alignment /*+ 0*/)));
} __attribute__((aligned(A::alignment /* + 0 */)));
g++ (r193606) complains that requested alignment is not an integer constant,
but when the + 0 part is uncommented, the requested alignment magically
becomes a constant.
[Bug other/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #3 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-18 18:47:19 UTC --- Are all upstream changes considered reviewed and automatically approved for gcc repo? all upstream changes are pre- or post- reviewed, so my answer here is yes. That's not acceptable. We don't want to have to go through LLVM to fix issues in GCC, especially for the platforms that LLVM doesn't support, i.e. most of them. I've got your point, but please understand mine: if the trees go too much out of sync we (the asan team) will lose control over one of the copies (gcc). It will mean that some one else (not us) will have to work on asan in gcc. Maybe that's not bad, but I don't want it. Syncing the trees in the presence of difference in the comment headers make the syncing task a tiny bit more challenging. I hope that at some point when we get enough contributions to libsanitizer from the GCC community, we will be able to unify the headers by saying This is part of LLVM and GCC projects. WDYT? As I understood from previous e-mails, there are libraries with similar problems in the gcc tree. What are the solutions there? Introducing such regressions is acceptable, provided that they can be quickly fixed by the target maintainers. It's great that such regressions is acceptable, but if there is an infrastructure that allows us to know about possible regressions before the commit (aka try bots), I'd like to know.
[Bug driver/55379] -static -static-libasan pass -Bdynamic to linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||konstantin.s.serebryany at ||gmail dot com --- Comment #3 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-18 18:58:00 UTC --- Note: fully static linking is not supported by libsanitizer at all and I don't think it will. Reason: on linux asan uses dlsym(RTLD_NEXT, ...) and on Mac it uses (will soon use) function inerposition. Neither works for fully static binaries, afaict.
[Bug fortran/55352] Erroneous gfortran warning of unused module variable when variable is only used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55352 --- Comment #6 from janus at gcc dot gnu.org 2012-11-18 19:16:27 UTC --- (In reply to comment #5) This solves the problem for me, thank you very much You're welcome ... I'm impressed by your quick and competent work :-) Thanks! In terms of gfortran bugs, this is certainly one of the easier ones to fix. Somehow, your patch didn't work in my Gentoo version; My patch was against trunk, so it might not apply cleanly to the 4.7 branch. The fix will presumably make it into the 4.8 release, but will probably not be backported to 4.7 (unless you can show that the bug is a regression, i.e. did not occur in a previous release of gfortran - I haven't checked this).
[Bug c/55383] New: -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
Bug #: 55383
Summary: -Wcast-qual reports incorrect message
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com
--
#include string.h
int
main( int argc, char *argv[] )
{
volatile double val;
memset( (void*)val, 0, sizeof(double) );
}
-
gcc -Wcast-qual bug.c
bug.c: In function 'main':
bug.c:7:11: warning: cast discards '__attribute__((noreturn))' qualifier from
pointer target type [-Wcast-qual]
~/j/ge* 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)
[Bug driver/55379] -static -static-libasan pass -Bdynamic to linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-11-18 19:35:21 UTC --- (In reply to comment #3) Note: fully static linking is not supported by libsanitizer at all and I don't think it will. Reason: on linux asan uses dlsym(RTLD_NEXT, ...) and on Mac it uses (will soon use) function inerposition. Neither works for fully static binaries, afaict. Then we should issue an error if -static is used with -faddress-sanitizer.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #9 from Konstantin Serebryany konstantin.s.serebryany at gmail dot
com 2012-11-18 19:35:43 UTC ---
As dvyuokv@ pointed out,
-ftls-model=initial-exec improves the situation, but does not fully help.
Experiment:
% cat x.c
__thread int a;
int foo() {
return a;
}
HORRIBLE: -fPIC -shared
% gcc x.c -O2 -fPIC -shared -o x.so ; objdump -d x.so | grep foo.: -A 5
06e0 foo:
6e0: 66 48 8d 3d f0 08 20lea0x2008f0(%rip),%rdi# 200fd8
_DYNAMIC+0x1b8
6e7: 00
6e8: 66 66 48 e8 10 ff ffcallq 600 __tls_get_addr@plt
6ef: ff
6f0: 8b 00 mov(%rax),%eax
NOT-SO-BAD: -fPIC -shared -ftls-model=initial-exec
% gcc x.c -O2 -fPIC -shared -o x.so -ftls-model=initial-exec ; objdump -d x.so
| grep foo.: -A 5
0630 foo:
630: 48 8b 05 a9 09 20 00mov0x2009a9(%rip),%rax# 200fe0
_DYNAMIC+0x1b8
637: 64 8b 00mov%fs:(%rax),%eax
63a: c3 retq
GOOD: -fPIE
% gcc -c x.c -O2 -fPIE -o x.o ; objdump -d x.o | grep foo.: -A 5
foo:
0: 64 8b 04 25 00 00 00mov%fs:0x0,%eax
7: 00
8: c3 retq
So, while -ftls-model=initial-exec improves the TLS performance, it is still
2x slower than -fPIE.
For tsan, which does this for *every* memory access in the original program,
this will cost 5%-10% slowdown.
For our users this is a big deal, so they will link the static library whenever
possible. Which default is used in gcc -- I don't care that much.
[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55367 --- Comment #2 from walid riabi wriabi at email dot com 2012-11-18 19:41:00 UTC --- I just tried that with the latest version (4.7.2) of MingW under windows 8
[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55367 --- Comment #3 from walid riabi wriabi at email dot com 2012-11-18 19:43:25 UTC --- I just tried that with the latest version (4.7.2) of MingW under windows 8
[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55367 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net --- Comment #4 from Pawel Sikora pluto at agmk dot net 2012-11-18 19:46:59 UTC --- looks like PR55171
[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55381 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-18 19:47:39 UTC --- (In reply to comment #0) /tmp/hpautotest-gcc0/gcc/libgfortran/generated/matmul_i1.c:79:1: internal compiler error: Illegal instruction Not observed with gcc-4.7.2-2.fc17.x86_64. BTW, SIGILL sounds like it's forced by gcc in response to something it sees as invalid, that must not be executed.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-18 19:54:37 UTC --- (In reply to comment #9) NOT-SO-BAD: -fPIC -shared -ftls-model=initial-exec % gcc x.c -O2 -fPIC -shared -o x.so -ftls-model=initial-exec ; objdump -d x.so | grep foo.: -A 5 0630 foo: 630: 48 8b 05 a9 09 20 00mov0x2009a9(%rip),%rax# 200fe0 _DYNAMIC+0x1b8 637: 64 8b 00mov%fs:(%rax),%eax 63a: c3 retq GOOD: -fPIE % gcc -c x.c -O2 -fPIE -o x.o ; objdump -d x.o | grep foo.: -A 5 foo: 0: 64 8b 04 25 00 00 00mov%fs:0x0,%eax 7: 00 8: c3 retq So, while -ftls-model=initial-exec improves the TLS performance, it is still 2x slower than -fPIE. Except obviously you can't use the last code sequence if you want to link it into a shared library. The extra indirection is the standard cost of relocatable code, especially if there are just a few TLS vars in libtsan and they are accessed a lot, that memory (the .got section entry) is in caches most likely and so the indirection can be just a cycle or at most a few of them. No idea how would you plan to compile libtsan with -fPIE flag, for libtsan.so.0 you obviously can't, it would fail to link or load, and for libtsan.a it would make the shared library only usable in executables or PIEs, not from shared libraries.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #11 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-18 19:59:42 UTC --- The above comment is correct. -fPIE is only applicable if we build libtsan.a and link it statically to the pie executable. This mode however, works pretty well and most our users pay this price for performance. On every memory access tsan touches a few (two or three) extra cache lines. Not using -fPIE makes it touch one extra cache line. Even if that line is in L1, it still has a non-zero cost. We will try to provide benchmark numbers next week.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-18
20:09:39 UTC ---
That would effectively require building libtsan as libtsan.so.0, libtsan.a
(both -fPIC built) and libtsan_pie.a (-fPIE built), where the gcc driver would
do:
%{static-libtsan:!shared:-ltsan_pie;:-ltsan} or so. Or there could be even
libtsan_nonpic.a for !shared:!pie, of course everything would need to be done
only given appropriate benchmarks of real-world programs.
[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55381 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-18 20:17:24 UTC --- (In reply to comment #2) (In reply to comment #0) /tmp/hpautotest-gcc0/gcc/libgfortran/generated/matmul_i1.c:79:1: internal compiler error: Illegal instruction Not observed with gcc-4.7.2-2.fc17.x86_64. But does happen with gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) as well as gcc version 4.4.5 (Debian 4.4.5-8). And those are the gcc versions I have at an arm-length. There's more at CFarm, but IIRC most of them are gcc-4.4 era and earlier. Maybe there's some -fpermissive or -fno-strict-aliasing combo to stick there. I don't really like the thought of raising the minimum gcc version already...
[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55367 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-18 21:05:23 UTC --- Indeed it does, but we badly need a mingw maintainer to resolve this (or these) issues
[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-18
CC||manu at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-18
21:15:09 UTC ---
Confirmed. The warning call is wrong:
c/c-typeck.c-4468-/* There are qualifiers present in IN_OTYPE that are not
present
c/c-typeck.c-4469- in IN_TYPE. */
c/c-typeck.c-4470-warning_at (loc, OPT_Wcast_qual,
c/c-typeck.c:4471: cast discards %q#v qualifier from pointer
target type,
c/c-typeck.c-4472- discarded);
c/c-typeck.c-4473-
c/c-typeck.c-4474- if (added || discarded)
It should use %qv for non-function types. Patch:
Index: c/c-typeck.c
===
--- c/c-typeck.c(revision 192847)
+++ c/c-typeck.c(working copy)
@@ -4466,11 +4466,11 @@ handle_warn_cast_qual (location_t loc, t
if (discarded)
/* There are qualifiers present in IN_OTYPE that are not present
in IN_TYPE. */
warning_at (loc, OPT_Wcast_qual,
- cast discards %q#v qualifier from pointer target type,
+ cast discards %qv qualifier from pointer target type,
discarded);
if (added || discarded)
return;
Index: testsuite/c-c++-common/Wcast-qual-1.c
===
--- testsuite/c-c++-common/Wcast-qual-1.c (revision 192847)
+++ testsuite/c-c++-common/Wcast-qual-1.c (working copy)
@@ -83,15 +83,15 @@ f3 (void ***bar)
}
void
f4 (void * const **bar)
{
- const void ***p9 = (const void ***) bar; /* { dg-warning cast } */
+ const void ***p9 = (const void ***) bar; /* { dg-warning cast discards
.const. qualifier } */
void * const **p11 = (void * const **) bar;
- void ** const *p13 = (void ** const *) bar; /* { dg-warning cast } */
+ void ** const *p13 = (void ** const *) bar; /* { dg-warning cast discards
.const. qualifier } */
const void * const **p15 = (const void * const **) bar; /* { dg-warning
cast } */
- const void ** const *p17 = (const void ** const *) bar; /* { dg-warning
cast } */
+ const void ** const *p17 = (const void ** const *) bar; /* { dg-warning
cast discards .const. qualifier } */
void * const * const * p19 = (void * const * const *) bar;
const void * const * const *p21 = (const void * const * const *) bar;
}
[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226 --- Comment #4 from Johannes Schaub schaub.johannes at googlemail dot com 2012-11-18 21:29:15 UTC --- (In reply to comment #3) Is this a duplicate of Bug 41933 ? This looks like a different one. I am not trying to capture a list of variables that result of expansion of a function parameter pack, but I'm just trying to use an element (a type or in this case, a non-type template parameter) of a pack expansion within a lambda. For a real life example, consider http://stackoverflow.com/a/13444602/34509
[Bug bootstrap/55384] New: [4.8 Regresson] VEC merge AIX bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 Bug #: 55384 Summary: [4.8 Regresson] VEC merge AIX bootstrap failure Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org /nasfarm/dje/src/src/gcc/c-family/c-lex.c: In function 'c_fileinfo* get_fileinfo(const char*)': /nasfarm/dje/src/src/gcc/c-family/c-lex.c:107:39: error: overloaded function with no contextual type information /nasfarm/dje/src/src/gcc/tree-dump.c: In function 'void dump_node(const_tree, int, FILE*)': /nasfarm/dje/src/src/gcc/tree-dump.c:759:39: error: address of overloaded function with no contextual type information
[Bug bootstrap/55384] [4.8 Regresson] VEC merge AIX bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org 2012-11-18 22:01:56 UTC --- Created attachment 28727 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28727 c-lex.c preprocessed
[Bug bootstrap/55384] [4.8 Regresson] VEC merge AIX bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org 2012-11-18 22:02:44 UTC --- Created attachment 28728 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28728 tree-dump.c preprocessed
[Bug bootstrap/55384] [4.8 Regresson] VEC merge AIX bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-18 CC||dnovillo at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org 2012-11-18 22:03:32 UTC --- Confirmed.
[Bug bootstrap/55384] [4.8 Regresson] VEC merge AIX bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target||powerpc-ibm-aix* Host||powerpc-ibm-aix* Target Milestone|--- |4.8.0 Build||powerpc-ibm-aix* Severity|normal |critical
[Bug c++/55319] Using -fwhole-program inhibits optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55319 --- Comment #2 from m101010a at gmail dot com 2012-11-18 22:13:23 UTC --- Actually, it does depend on IO; the optimizations aren't performed in either case if I declare but don't define putchar, and if do something simple like assigning to a volatile int in putchar then the optimizations are performed in both cases. If I assert(false) in putchar, gcc optimizes the fwhole-program version to a failed assert, but doesn't without fwhole-program, which is the opposite of what it does with IO.
[Bug c++/55382] Constant class member as alignment specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55382 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-11-18 22:13:37 UTC --- Seems related to PR 53017.
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #4 from Nathan Ridge zeratul976 at hotmail dot com 2012-11-18 22:28:59 UTC --- I filed the same bug for clang, and I was pointed to DR1395 [1]. GCC and clang's behaviour are both in line with the resolution of this DR. I guess this can be closed as invalid then? [1] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1395
[Bug tree-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55006 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-18 23:11:19 UTC --- Reverting the change to gcc/web.c in revision 192526, i.e., re-removing DF_RD_PRUNE_DEAD_DEFS, fixes the miscompilation without regression. Well done to us all for probing until we found the root cause of this bug! (from http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01599.html ) may have been overoptimistic;-(
[Bug c++/55319] Using -fwhole-program inhibits optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55319 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-19 00:16:03 UTC --- If it does depend on I/O please trim down all the rest, and, if at all possible, please use standard functions for that.
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-19 00:21:29 UTC --- Oh yes, nice. I'm only a bit nervous because the status is still drafting but it looks like there is very solid agreement about the issue. Tomorrow I mean to add the testcase to the testsuite and close the PR.
[Bug bootstrap/55384] [4.8 Regresson] VEC merge AIX bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 --- Comment #4 from David Edelsohn dje at gcc dot gnu.org 2012-11-19 00:21:59 UTC --- AIX /usr/include/stdlib.h includes #define vec_free free And vec.h defines two functions named vec_free, which get renamed, causing ambiguity in the splay_tree_new calls. Should vec.h #undef vec_free? Somewhere else?
[Bug c++/55385] New: g++ failed to call final overrider of a virtual function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55385
Bug #: 55385
Summary: g++ failed to call final overrider of a virtual
function.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@g.clemson.edu
The code below is adapted from the example code given in 10.3/2 of the current
standard.
--- BEGIN ---
#include iostream
struct A {
virtual void f() { std::cout A::f std::endl; }
};
struct B : virtual A {
virtual void f() { std::cout B::f std::endl; }
};
struct C : B , virtual A {
using A::f;
};
void foo() {
C c;
c.f();// (1) calls B::f, the final overrider
c.C::f(); // (2) calls A::f because of the using-declaration
}
int main ()
{
foo();
return 0;
}
--- END ---
The standard says that c.f() should call B::f because it is the final overrider
in C of the virtual function f. According to my test on g++-4.7.0, however,
both call A::f.
My compile command line is: ~/gcc/4.7.0/bin/c++ -O3 -Wall -Wextra t.cc
My compiler version is:
Reading specs from /home/meng/gcc/4.7.0/lib/gcc/i686-pc-linux-gnu/4.7.0/specs
COLLECT_GCC=/home/meng/gcc/4.7.0/bin/c++
COLLECT_LTO_WRAPPER=/home/meng/gcc/4.7.0/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/meng/gcc/4.7.0/
--enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug bootstrap/55384] [4.8 Regresson] VEC merge AIX bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 --- Comment #5 from dnovillo at google dot com dnovillo at google dot com 2012-11-19 01:05:32 UTC --- On Sun, Nov 18, 2012 at 7:21 PM, dje at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 --- Comment #4 from David Edelsohn dje at gcc dot gnu.org 2012-11-19 00:21:59 UTC --- AIX /usr/include/stdlib.h includes #define vec_free free Sigh. Silly AIX. And vec.h defines two functions named vec_free, which get renamed, causing ambiguity in the splay_tree_new calls. Should vec.h #undef vec_free? Somewhere else? I suppose it will have to how can I recognize AIX inside vec.h? Diego.
[Bug c++/55386] New: operator void called for class objects converted to void type.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55386
Bug #: 55386
Summary: operator void called for class objects converted to
void type.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@g.clemson.edu
C++11 12.3.2/1 says that:
A conversion function is never used to convert a (possibly cv-qualified) object
to the (possibly cv-qualified) same object type (or a reference to it), to a
(possibly cv-qualified) base class of that type (or a reference to
it), or to (possibly cv-qualified) void.
The standard also puts a note at the end of same page which reads:
A conversion to void does not invoke any conversion function (5.2.9).
But the following program shows that g++ calls operator void for class objects
converted to the void type.
- BEGIN -
#include iostream
struct test
{
operator void () const { std::cout test::operator void () std::endl; }
};
int main ()
{
test const t;
(void)t; // calls test::operator void
return 0;
}
- END -
My command line:~/gcc/4.7.0/bin/c++ -std=c++11 -Wall -Wextra t.cc
My compiler version:~/gcc/4.7.0/bin/c++ -v
Reading specs from /home/meng/gcc/4.7.0/lib/gcc/i686-pc-linux-gnu/4.7.0/specs
COLLECT_GCC=/home/meng/gcc/4.7.0/bin/c++
COLLECT_LTO_WRAPPER=/home/meng/gcc/4.7.0/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/meng/gcc/4.7.0/
--enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug other/55387] New: Build problem: malloc error in genautomata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55387 Bug #: 55387 Summary: Build problem: malloc error in genautomata Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu When attempting to build the latest SVN gcc (4.8.0, rev. 193610), I get the following error: build/genautomata ../.././gcc/config/i386/i386.md \ insn-conditions.md tmp-automata.c genautomata(1500) malloc: *** error for object 0xc1e8b60252d64: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug /bin/sh: line 1: 1500 Abort trap: 6 build/genautomata ../.././gcc/config/i386/i386.md insn-conditions.md tmp-automata.c make[3]: *** [s-automata] Error 134 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 This is on OS X 10.7.5, with the following config options: ./configure CC=gcc -D_FORTIFY_SOURCE=0 \ --build=x86_64-apple-darwin11.4.2 \ --prefix=/Applications/madsdk \ --with-gmp=/Applications/madsdk \ --with-mpfr=/Applications/madsdk \ --with-mpc=/Applications/madsdk \ --enable-languages=c,c++,fortran --disable-multilib
[Bug c++/55386] operator void called for class objects converted to void type.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55386 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|meng at g dot clemson.edu | --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-19 01:36:27 UTC --- This is already fixed in mainline.
[Bug c++/54165] Cast to void should not implicitly call conversion functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54165 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||meng at g dot clemson.edu --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-19 01:39:28 UTC --- *** Bug 55386 has been marked as a duplicate of this bug. ***
[Bug c++/55386] operator void called for class objects converted to void type.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55386 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-19 01:39:28 UTC --- Closing. *** This bug has been marked as a duplicate of bug 54165 ***
[Bug target/55378] Inconsistant double 387 computation when using osthread under windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target|Mingw, cygwin |i?86-*-mingw* ||i?86-*-cygwin-* Component|c |target Host|Windows | Severity|major |normal --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-19 01:55:29 UTC --- The difference is 1ulp correct? Maybe there is different rounding modes are selected for the main thread and the spawned threads. Can you see which mode of i387 is used for each? Maybe the spawned threads are using 80bits while the main thread is using 64bits.
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2012-11-19 01:57:16 UTC --- No. The resolution of 1395 will not make the testcase in #1 valid, only the case where you have a degenerate overload, like templatetypename T, typename... Args int f(const T, Args...); templatetypename T int f(const T); The testcase in #1 should still be rejected as ambiguous.
[Bug bootstrap/55380] All search_line_fast implementations read beyond buffer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55380 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-19 01:59:22 UTC --- All search_line_fast implementations read beyond buffer. Yes and this is one of the false positives really. We might read past the bounds of an array but it is always on an aligned location and not really depends on those reads past the bounds.
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-19 02:11:53 UTC --- I see...
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2012-11-19 03:01:55 UTC --- We could build GCC with -fno-threadsafe-statics, though in general it seems reasonable for to depend on the C++ language support library.
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958
--- Comment #8 from Nathan Ridge zeratul976 at hotmail dot com 2012-11-19
03:49:39 UTC ---
(In reply to comment #6)
No. The resolution of 1395 will not make the testcase in #1 valid, only the
case where you have a degenerate overload, like
templatetypename T, typename... Args
int f(const T, Args...);
templatetypename T
int f(const T);
The testcase in #1 should still be rejected as ambiguous.
The note describing the resolution of 1395 says preferring an omitted
parameter over a parameter pack.
The way I read that, in the testcase in comment 1, the second overload has an
omitted parameter ('d'), and the first overload has a parameter pack, so
the secodn overload would be preferred.
Am I misreading it?
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #13 from Konstantin Serebryany konstantin.s.serebryany at gmail
dot com 2012-11-19 04:13:23 UTC ---
of course everything would need to be done only given appropriate benchmarks
of real-world programs.
We have a synthetic benchmark which perfectly reflects the only major hot spot
in tsan: the set of functions __tsan_{read,write}{1,2,4,8} that are called on
every memory access.
When building libtsan as a shared library (for which I had to hack our assembly
blobs a bit) we get two sources of slowdown:
1. __tsan_read8 and friends are called through PLT
2. __tsan_read8 and friends use one extra load to get to TLS
The result is 10% slowdown.
[Bug target/55377] ipa-pure-cont produces wrong code on AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55377
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-19
04:36:36 UTC ---
This looks correct as the only thing as:
while (!serial.canWrite()) {}
cannot change its state once in that loop as far as I can tell. There are no
volatile variables read either.
canWrite is inlined which was:
bool canWrite() {
return !(_txPointers.full(sizeof(TXBuffer)));
}
And we decided mhvlib::RingBuffer::full only reads from its arguments which are
not volatile.
full does:
bool full(uint8_t blockLength) {
return length() (_size - 1 - blockLength);
}
Where length was:
uint8_t length() {
int16_t length = _head - _tail;
if (length 0) {
length = (_size - _tail) + _head + 1;
}
return (uint8_t) length;
}
And both _head and _tail are not marked as volatile so we only need to read
them once (including through the loop).
So the code that ipa-pure-const is producing is correct.
The reason why you can't produce a simpler testcase is because it depends on
other optimization chooses that the compiler has decided to take.
So in conclusion, I think you are missing some variables marked as volatile in
the RingBuffer implementation and/or Device_TXImplementation implementation.
[Bug target/55378] Inconsistant double 387 computation when using osthread under windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378 --- Comment #3 from philippe.coustaux at gmail dot com 2012-11-19 05:00:07 UTC --- Hi, The difference is not always 1ulp. If you look at 'RUN-LOG-30.txt' output file you can see that its 3ulp. If you ran the binary with a value of 100 the difference grows to 5ulp. tcc generated code don't present the bug even with very high values of the parameter. Regarding my tests, the result closest to the 'right' value is always given by the main thread. When in a spawned thread, result loose accuracy. Regarding of using 64bits or 80bits I dont't know. How can I check that ? How can I change the rounding mode ?
[Bug target/55378] Inconsistant double 387 computation when using osthread under windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378 --- Comment #4 from philippe.coustaux at gmail dot com 2012-11-19 05:19:07 UTC --- Ok, I have found for the rouding mode.
[Bug other/55353] [asan] the flag for asan should match the one used in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||wmi at gcc dot gnu.org --- Comment #1 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-19 05:20:24 UTC --- Wei, this needs to happen ASAP, otherwise there will be too many places with the old flag.
[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051 --- Comment #30 from tejohnson at gcc dot gnu.org 2012-11-19 05:21:06 UTC --- Author: tejohnson Date: Mon Nov 19 05:20:59 2012 New Revision: 193612 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193612 Log: This patch addresses the bogus Invocation mismatch messages seen in parallel profiledbootstrap builds of gcc. See PR bootstrap/55051 for a discussion of why this is occurring and why this checking is inaccurate. Leave it in when !GCOV_LOCKED, to warn about concurrent update issues requiring locking. 2012-11-18 Teresa Johnson tejohn...@google.com PR bootstrap/55051 * libgcov.c (gcov_exit): Remove merged program summary comparison unless !GCOV_LOCKED. Modified: trunk/libgcc/ChangeLog trunk/libgcc/libgcov.c
[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55381 Venkataramanan venkataramanan.kumar at amd dot com changed: What|Removed |Added CC||venkataramanan.kumar at amd ||dot com --- Comment #4 from Venkataramanan venkataramanan.kumar at amd dot com 2012-11-19 05:45:35 UTC --- I could get this problem with my native build. gcc version used for build is 4.3.4 [gcc-4_3-branch revision 152973]
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #2 from Vladimir volodya at netfolder dot ru 2012-11-19 05:47:19 UTC --- What does 'rejects-valid' keywords mean? 18.11.2012 22:05 пользователь redi at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org написал: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-18 Ever Confirmed|0 |1 -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug other/55353] [asan] the flag for asan should match the one used in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 --- Comment #2 from wmi at google dot com 2012-11-19 05:54:44 UTC --- Hi Kostya, Ok, I will extract the change from the tsan patch and send out a separate patch about it. Regards, Wei. On Sun, Nov 18, 2012 at 9:20 PM, konstantin.s.serebryany at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||wmi at gcc dot gnu.org --- Comment #1 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-19 05:20:24 UTC --- Wei, this needs to happen ASAP, otherwise there will be too many places with the old flag. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug target/55378] Inconsistant double 387 computation when using osthread under windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378 --- Comment #5 from philippe.coustaux at gmail dot com 2012-11-19 06:05:17 UTC --- I have added a #include fenv.h and calls to fegetround The return value is 0 in thread or in main. Reproducible with cygwin and mingw
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-11-19 07:26:11 UTC --- (In reply to comment #2) What does 'rejects-valid' keywords mean? It means that the compiler rejects valid code, see http://gcc.gnu.org/bugzilla/describekeywords.cgi
[Bug other/55353] [asan] the flag for asan should match the one used in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-19 07:45:31 UTC --- Yes, please. But make sure to update all the spots where -faddress-sanitizer is used in the tree (e.g. gcc/testsuite/lib/asan-dg.exp, gcc/doc/*, etc.).
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #4 from Vladimir volodya at netfolder dot ru 2012-11-19 07:56:26 UTC --- Sorry for stupid questions :) Is this bug planned to be fixed in future? Can I help in any way to do that? 2012/11/19 daniel.kruegler at googlemail dot com gcc-bugzi...@gcc.gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-11-19 07:26:11 UTC --- (In reply to comment #2) What does 'rejects-valid' keywords mean? It means that the compiler rejects valid code, see http://gcc.gnu.org/bugzilla/describekeywords.cgi -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
