[Bug c/36482] New: cris gcc 4.2.3 -Os causes internal compiler error (-O0 works)
This was created by a toolchain for cris architecture: gcc-4.2.3,
uClibc-0.9.29, binutils-2.17 compiling openssl-0.9.8h.
[EMAIL PROTECTED]
/work/stage/openwrt2/build_dir/cris/openssl-0.9.8h/crypto/cast $
cris-linux-uclibc-gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC
-DZLIB_SHARED -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H
-I/work/stage/openwrt2/staging_dir/cris/usr/include
-I/work/stage/openwrt2/staging_dir/cris/include -DOPENSSL_SMALL_FOOTPRINT
-DOPENSSL_NO_ERR -DTERMIO -Os -fhonour-copts -fomit-frame-pointer -Wall -c -o
c_skey.o c_skey.c -v -save-temps
Using built-in specs.
Target: cris-linux-uclibc
Configured with:
/work/stage/openwrt-trunk/build_dir/toolchain-cris_gcc4.2.3/gcc-4.2.3/configure
--prefix=/work/stage/openwrt-trunk/staging_dir/toolchain-cris_gcc4.2.3
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=cris-linux-uclibc
--enable-languages=c --enable-shared --disable-__cxa_atexit
--enable-target-optspace --with-gnu-ld --disable-nls --disable-libmudflap
--disable-multilib
Thread model: posix
gcc version 4.2.3
/work/stage/openwrt-trunk/staging_dir/toolchain-cris_gcc4.2.3/libexec/gcc/cris-linux-uclibc/4.2.3/cc1
-E -quiet -v -I.. -I../.. -I../../include
-I/work/stage/openwrt2/staging_dir/cris/usr/include
-I/work/stage/openwrt2/staging_dir/cris/include -D__arch_v10
-D__CRIS_arch_version=10 -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DDSO_DLFCN
-DHAVE_DLFCN_H -DOPENSSL_SMALL_FOOTPRINT -DOPENSSL_NO_ERR -DTERMIO c_skey.c
-march=v10 -Wall -fPIC -fhonour-copts -fomit-frame-pointer -Os -fpch-preprocess
-o c_skey.i
ignoring nonexistent directory
"/work/stage/openwrt-trunk/staging_dir/toolchain-cris_gcc4.2.3/lib/gcc/cris-linux-uclibc/4.2.3/../../../../cris-linux-uclibc/include"
#include "..." search starts here:
#include <...> search starts here:
..
../..
../../include
/work/stage/openwrt2/staging_dir/cris/usr/include
/work/stage/openwrt2/staging_dir/cris/include
/work/stage/openwrt-trunk/staging_dir/toolchain-cris_gcc4.2.3/lib/gcc/cris-linux-uclibc/4.2.3/include
/work/stage/openwrt-trunk/staging_dir/toolchain-cris_gcc4.2.3/lib/gcc/cris-linux-uclibc/4.2.3/../../../../cris-linux-uclibc/sys-include
End of search list.
/work/stage/openwrt-trunk/staging_dir/toolchain-cris_gcc4.2.3/libexec/gcc/cris-linux-uclibc/4.2.3/cc1
-fpreprocessed c_skey.i -march=v10 -quiet -dumpbase c_skey.c -auxbase-strip
c_skey.o -Os -Wall -version -fPIC -fhonour-copts -fomit-frame-pointer -o
c_skey.s
GNU C version 4.2.3 (cris-linux-uclibc)
compiled by GNU C version 4.1.2 (Gentoo 4.1.2 p1.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 410ae2227399308839bfc41a0a91c8c4
c_skey.c: In function 'CAST_set_key':
c_skey.c:165: error: insn does not satisfy its constraints:
(insn 2072 1053 2073 10 (set (reg:SI 9 r9)
(zero_extend:SI (reg:HI 17 mof))) 53 {zero_extendhisi2} (nil)
(expr_list:REG_DEAD (reg:HI 17 mof)
(nil)))
c_skey.c:165: internal compiler error: in copyprop_hardreg_forward_1, at
regrename.c:1613
Please submit a full bug report,
with preprocessed source if appropriate.
See https://dev.openwrt.org/> for instructions.
--
Summary: cris gcc 4.2.3 -Os causes internal compiler error (-O0
works)
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hinko dot kocevar at cetrtapot dot si
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: cris-linux-uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36482
[Bug c/36482] cris gcc 4.2.3 -Os causes internal compiler error (-O0 works)
--- Comment #1 from hinko dot kocevar at cetrtapot dot si 2008-06-10 07:31 --- Created an attachment (id=15744) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15744&action=view) preprocessed source that caused the internal compiler error Created with: cris-linux-uclibc-gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -I/work/stage/openwrt2/staging_dir/cris/usr/include -I/work/stage/openwrt2/staging_dir/cris/include -DOPENSSL_SMALL_FOOTPRINT -DOPENSSL_NO_ERR -DTERMIO -Os -fhonour-copts -fomit-frame-pointer -Wall -c -o c_skey.o c_skey.c -v -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36482
[Bug c/36166] Use of the 'nonnull' attribute breaks code
--- Comment #1 from pgut001 at cs dot auckland dot ac dot nz 2008-06-10 07:48 --- This is actually a lot more serious than just a documentation issue (I've changed it from a doc issue to a gcc issue) in that the use of this annotation by the optimizer will break correctly-functioning code by silently removing any checks for NULL pointers. To summarise the original issue: There are cases where no warning about use of a NULL pointer is issued because the analysis required to reveal this would have to be done by the back-end, but the back-end optimiser still changes the code that it generates under the assumption that the pointer is never null. In other words use of this annotation to warn about NULL pointers results in code that segfaults if the pointer ever does happen to be NULL, even though the compiler doesn't (reliably) warn about use of a NULL pointer in the first place. Because of this it's just too dangerous to use, if the compiler can't reliably warn about use of NULL pointers then it shouldn't then use this unreliable information to change the behaviour of generated code. The problem is compounded by the way the attribute is used, for __unused__ the attribute is placed in front of the variable that it affects but for __nonnull__ it's necessary to tediously hand-count parameters and then provide a list of index values for the attribute. When annotating a function with several pointers, some of which can be null and some of which can't, it's very easy to lose track and supply an off-by-one index, which gcc uses to remove NULL pointer checks resulting in segfaults in apparently-correct code. Is there any reason why __nonnull__ can't work the same way as __unused__? -- pgut001 at cs dot auckland dot ac dot nz changed: What|Removed |Added Severity|minor |normal Component|web |c Summary|Documentation for the |Use of the 'nonnull' |'nonnull' attribute is a bit|attribute breaks code |misleading | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug c++/36483] New: Getting an address of a byte-aligned field declared as a bit-field should be allowed
gcc produces an error for the code below:
bit-field.C:6: error: attempt to take address of bit-field structure member
'S::j'
In this case field j is guaranteed to be byte-aligned.
gcc shouldn't have such a rigid requirement that one can't get an address of
any bit field variable but should allow getting such address when it's actually
possible.
For example I've set bit field attribute (:8) to limit some small enum-typed
field to just 8 bits. And after this I couldn't get it's address as of uint8_t
value.
--- code ---
struct S {
int j:8;
};
char& cc(S *s) {
return ((char&)s->j);
}
--
Summary: Getting an address of a byte-aligned field declared as a
bit-field should be allowed
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36483
[Bug fortran/36476] ICE: len=* CHARACTER array with separate PARAMETER statement
--- Comment #2 from walter dot zimmer at dlr dot de 2008-06-10 08:11 --- The workaround works fine, many thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36476
[Bug target/36450] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem
--- Comment #4 from aldot at gcc dot gnu dot org 2008-06-10 08:18 --- pristine trunk is also broken: sort.i:10318: internal compiler error: in insert_save, at caller-save.c:787 -- aldot at gcc dot gnu dot org changed: What|Removed |Added Summary|[IRA] ICE in insert_restore |ICE in |with GET_MODE_ALIGNMENT mem |insert_restore/insert_save ||with GET_MODE_ALIGNMENT mem Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug middle-end/36166] Use of the 'nonnull' attribute breaks code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-10 08:25 --- No this is not a non documentation bug as non-null attribute says that the argument has to be non null to work correctly. So if you pass a NULL argument to the function, it will crash. So optimizing out the check for NULLness is correct really as the function is already expecting nonNULL. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug c++/36483] Getting an address of a byte-aligned field declared as a bit-field should be allowed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:25 --- This is required by the C/C++ standards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36483
[Bug target/36482] cris gcc 4.2.3 -Os causes internal compiler error (-O0 works)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36482
[Bug target/36484] New: g++ generates code with illegal instruction on Pentium D / x86_64
To reproduce the bug, get MPFR trunk, compile with CC=g++ (with or without optimizations) and make check. The crash occurs on tprintf (and tsprintf and tfprintf). I could reproduce it with both g++-4.2 (GCC) 4.2.4 (Debian 4.2.4-2) g++.real (Debian 4.3.1-1) 4.3.1 No problem with gcc. (gdb) run Starting program: /home/vlefevre/software/mpfr/tests/.libs/lt-tprintf Program received signal SIGILL, Illegal instruction. 0x7f65b27c5556 in __gmpfr_vasprintf (ptr=0x7fffbac424b0, fmt=0x404de4 "A, b. %Fe, c. %i%zn\n", ap=0x7fffbac424f0) at vasprintf.c:1845 1845 ++fmt; Current language: auto; currently c++ (gdb) bt #0 0x7f65b27c5556 in __gmpfr_vasprintf (ptr=0x7fffbac424b0, fmt=0x404de4 "A, b. %Fe, c. %i%zn\n", ap=0x7fffbac424f0) at vasprintf.c:1845 #1 0x7f65b27c1671 in __gmpfr_vprintf ( fmt=0x404dde "a. %R*A, b. %Fe, c. %i%zn\n", ap=0x7fffbac424f0) at printf.c:85 #2 0x004028f4 in check_vprintf ( fmt=0x404dde "a. %R*A, b. %Fe, c. %i%zn\n") at tprintf.c:67 #3 0x00402c27 in check_mixed () at tprintf.c:192 #4 0x0040312b in main (argc=1, argv=0x7fffbac427d8) at tprintf.c:361 And with valgrind: vin:...ftware/mpfr/tests> ./tprintf.vg ==19537== Memcheck, a memory error detector. ==19537== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==19537== Using LibVEX rev 1804, a library for dynamic binary translation. ==19537== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==19537== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework. ==19537== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==19537== For more details, rerun with: -v ==19537== vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0x48 0x83 ==19537== valgrind: Unrecognised instruction at address 0x4E46556. ==19537== Your program just tried to execute an instruction that Valgrind ==19537== did not recognise. There are two possible reasons for this. ==19537== 1. Your program has a bug and erroneously jumped to a non-code ==19537==location. If you are running Memcheck and you just saw a ==19537==warning about a bad jump, it's probably your program's fault. ==19537== 2. The instruction is legitimate but Valgrind doesn't handle it, ==19537==i.e. it's Valgrind's fault. If you think this is the case or ==19537==you are not sure, please let us know and we'll try to fix it. ==19537== Either way, Valgrind will now raise a SIGILL signal which will ==19537== probably kill your program. ==19537== ==19537== Process terminating with default action of signal 4 (SIGILL): dumping core ==19537== Illegal opcode at address 0x4E46556 ==19537==at 0x4E46556: __gmpfr_vasprintf (vasprintf.c:1845) ==19537==by 0x4E42670: __gmpfr_vprintf (printf.c:85) ==19537==by 0x4028F3: check_vprintf(char*, ...) (tprintf.c:67) ==19537==by 0x402C26: check_mixed() (tprintf.c:192) ==19537==by 0x40312A: main (tprintf.c:361) ==19537== ==19537== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1) ==19537== malloc/free: in use at exit: 6,832 bytes in 14 blocks. ==19537== malloc/free: 646 allocs, 632 frees, 390,447 bytes allocated. ==19537== For counts of detected errors, rerun with: -v ==19537== searching for pointers to 14 not-freed blocks. ==19537== checked 209,424 bytes. ==19537== ==19537== LEAK SUMMARY: ==19537==definitely lost: 0 bytes in 0 blocks. ==19537== possibly lost: 0 bytes in 0 blocks. ==19537==still reachable: 6,832 bytes in 14 blocks. ==19537== suppressed: 0 bytes in 0 blocks. ==19537== Rerun with --leak-check=full to see details of leaked memory. zsh: illegal hardware instruction ./tprintf.vg -- Summary: g++ generates code with illegal instruction on Pentium D / x86_64 Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:52 --- Your configure line should not have LD_LIBRARY_PATH set. Also this works for me ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:54 --- You should try out 4.3.1. Also this is not a good testcase, we need the preprocesed source that is producing the error with the exact command line that is used to compile that file. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug middle-end/36166] Use of the 'nonnull' attribute breaks code
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-06-10 09:07 --- The GCC attribute is an extension. What it is about is saying if it is NULL then the program/function will crash and is not expecting a NULL argument. So if you mark a function argument as non NULL, then the optimizer can optimize it based on that fact. Even though the C standards committee is proposing something different, that will be handled differently from the GCC attribute extension anyways. So again there is no changed needed really to the GCC extension as it is defined as one that will crash if supplied with a NULL argument. Think printf with %s where it is supplied with a NULL argument or puts with a NULL argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #2 from vincent at vinc17 dot org 2008-06-10 09:09 --- (In reply to comment #1) > You should try out 4.3.1. As I said, I could reproduce the problem with this version too (but there's a bug in gmp.h, so I was not sure). -- vincent at vinc17 dot org changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug middle-end/36166] Use of the 'nonnull' attribute breaks code
--- Comment #3 from pgut001 at cs dot auckland dot ac dot nz 2008-06-10 09:02 --- It's more than just a documentation bug, two different portions of gcc are interpreting this attribute in completely different ways, and the interaction between the two breaks otherwise perfectly valid code. The intended use of the nonnull attribute is to warn, at compile time, against the inadvertent use of NULL pointers where they should be nonnull. By overloading it to also change the way code generation works gcc is making it far too dangerous to use and more or less destroying its usefulness for its original application - a single error in counting parameters or applying the annotation and your otherwise fully correct code suddenly breaks. In fact gcc seems to be doing the opposite of what ISO WG 14 is proposing for this attribute, which was to add extra checking to make sure the attribute isn't NULL. gcc instead *removes* extra checking to make sure the attribute isn't NULL. As it stands, gcc's interpretation of nonnull is unsafe at any speed, it doesn't reliably warn about NULL pointers, but it does reliably break your code when used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug middle-end/36166] Use of the 'nonnull' attribute breaks code
--- Comment #5 from pgut001 at cs dot auckland dot ac dot nz 2008-06-10 09:15 --- >Think printf with %s where it is supplied with a NULL argument or puts >with a NULL argument. Sure, I understand how that part of it works, but gcc doesn't just use it for that, it applies two often mutually exclusive interpretations to the same attribute. Warning about inadvertent use of NULL is useful for developers, so there's a temptation to annotate code with it to warn at compile time of errors (and that seems to be the intended use of stdc_nonnull). However the opposite interpretation of the attribute is that if you do inadvertently pass a NULL pointer to annotated code, gcc may not warn about it but will cause your code to crash. The single attribute shouldn't be used to perform two mutually exclusive (and in one case, dangerous) actions, it's like storing rat poison in a fruit juice bottle... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug middle-end/36166] Use of the 'nonnull' attribute breaks code
--- Comment #7 from pgut001 at cs dot auckland dot ac dot nz 2008-06-10 09:27 --- >The developer of the API says that it must be non-NULL so when the developer >of the API then tests for NULLness he is either being stupid or really just >thinking that the user will not use it correctly but since the warning is >there But the warning *isnt't* there, gcc doesn't reliably warn about incorrect use of a NULL pointer. If gcc could reliably detect use of a NULL pointer and warn about it, and *then* remove the NULL pointer checks that'd be fine. At the moment gcc doesn't warn about NULL pointer use but does remove code that would catch inadvertent NULL pointer use, and that's my complaint with the way the attribute works - it's what James Reason (who specialises in safety engineering) would call a latent pathogen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug middle-end/36166] Use of the 'nonnull' attribute breaks code
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-06-10 09:19 --- >gcc doesn't just use it for that, it applies two often mutually exclusive >interpretations to the same > attribute. They are no mutually exclusive at all. Think of it is this way. The developer of the API says that it must be non-NULL so when the developer of the API then tests for NULLness he is either being stupid or really just thinking that the user will not use it correctly but since the warning is there, there is no reason for the function itself to test for NULLness which is why GCC optimizes away the check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug c++/36478] [4.3/4.4 regression] warning not emitted when code expanded from macro
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-10 09:50 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-06-10 09:50:40 date|| Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36478
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-10 09:54 --- Waiting for a testcase. Also, can you show disassembly of the relevant region of code? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.
--- Comment #15 from cnstar9988 at gmail dot com 2008-06-10 10:07 --- I build gcc 4.3.1 with --with-cld ./src/configure --prefix=/opt/gcc-4.3.1 --with-gmp=/opt/gcc-4.3.1/gmp --with-mpfr=/opt/gcc-4.3.1/mpfr --enable-languages=c,c++ --disable-nls --enable-bootstrap --disable-shared --enable-threads=posix --enable-checking=release --enable-cld --with-system-zlib --enable-__cxa_atexit --with-cpu=generic I test it with /opt/gcc-4.3.1/bin/gcc -v test.c but I can't see any -mcld? /opt/gcc-4.3.1/libexec/gcc/i686-pc-linux-gnu/4.3.1/cc1 -quiet -v test.c -quiet -dumpbase test.c -mtune=generic -auxbase test -version -o /tmp/ccVgUf0W.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079
[Bug middle-end/36166] Use of the 'nonnull' attribute breaks code
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-06-10 09:56 --- This works as designed (and documented). Whether the design is the best possible one is another question. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug c++/36483] Getting an address of a byte-aligned field declared as a bit-field should be allowed
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-10 09:51 --- The diagnostic is required by the standard. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36483
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #10 from bunk at stusta dot de 2008-06-10 10:11 --- Created an attachment (id=15745) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15745&action=view) Mirco's usbcore.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #11 from bunk at stusta dot de 2008-06-10 10:28 --- (In reply to comment #7) > Looking at http://www.readcode.org/code/linux-2.6.20/include/linux/log2.h it > seems that either the argument to ilog _is_ zero or the compiler thinks so. If you disassemble Mirco's usbcore.o you'll see why I said "I'd have said your gcc has a bug regarding __builtin_constant_p()": The compiler does not think the argument to ilog() was zero - it expanded _all_ the code for the case when __builtin_constant_p(n) returns true. -- bunk at stusta dot de changed: What|Removed |Added CC||bunk at stusta dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug target/36473] Generate bit test (bt) instructions
--- Comment #3 from uros at gcc dot gnu dot org 2008-06-10 10:30 --- Subject: Bug 36473 Author: uros Date: Tue Jun 10 10:29:36 2008 New Revision: 136615 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136615 Log: PR target/36473 * config/i386/i386.c (ix86_tune_features) [TUNE_USE_BT]: Add m_CORE2 and m_GENERIC. * config/i386/predicates.md (bt_comparison_operator): New predicate. * config/i386/i386.md (*btdi_rex64): New instruction pattern. (*btsi): Ditto. (*jcc_btdi_rex64): New instruction and split pattern. (*jcc_btsi): Ditto. (*jcc_btsi_1): Ditto. (*btsq): Fix Intel asm dialect operand order. (*btrq): Ditto. (*btcq): Ditto. testsuite/ChangeLog: PR target/36473 * testsuite/gcc.target/i386/bt-1.c: New test. * testsuite/gcc.target/i386/bt-2.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/i386/bt-1.c trunk/gcc/testsuite/gcc.target/i386/bt-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/predicates.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36473
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #12 from aldot at gcc dot gnu dot org 2008-06-10 11:07 ---
smallish testcase, fwiw.
$ gcc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -fno-stack-protector
-mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686
-ffreestanding -pipe -fno-asynchronous-unwind-tables -mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -O2 -c -o pr.o pr36359.c
$ nm pr.o
U argh
T foo
U urb
$ cat pr36359.c
extern int urb;
int argh(void);
void foo(void)
{
if (urb <= 0)
return;
urb = __builtin_constant_p(urb) ? 0x0815 : argh();
}
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
CC||aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.
--- Comment #16 from rguenther at suse dot de 2008-06-10 10:56 --- Subject: Re: [4.3/4.4 Regression] cld instruction is not emitted anymore. On Tue, 10 Jun 2008, cnstar9988 at gmail dot com wrote: > --- Comment #15 from cnstar9988 at gmail dot com 2008-06-10 10:07 --- > I build gcc 4.3.1 with --with-cld > ./src/configure --prefix=/opt/gcc-4.3.1 --with-gmp=/opt/gcc-4.3.1/gmp > --with-mpfr=/opt/gcc-4.3.1/mpfr --enable-languages=c,c++ --disable-nls > --enable-bootstrap --disable-shared --enable-threads=posix > --enable-checking=release --enable-cld --with-system-zlib > --enable-__cxa_atexit > --with-cpu=generic > > I test it with /opt/gcc-4.3.1/bin/gcc -v test.c > but I can't see any -mcld? > > /opt/gcc-4.3.1/libexec/gcc/i686-pc-linux-gnu/4.3.1/cc1 -quiet -v test.c -quiet > -dumpbase test.c -mtune=generic -auxbase test -version -o /tmp/ccVgUf0W.s It only turns the option on in the backend, it doesn't pass it from the driver. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #13 from aldot at gcc dot gnu dot org 2008-06-10 11:20 ---
should have been
int argh(void) __attribute__((error ("dce?")));
works without __builtin_constant_p and fails even with
-Os -ftree-dce -fweb -ftree-fre -ftree-pre
pr36359.c: In function 'foo':
pr36359.c:7: error: call to 'argh' declared with attribute error: dce?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug driver/36485] New: gcc driver incorrectly assumes existence of $(prefix)/usr/lib
i've configured gcc in this way: $ ./xgcc -B. -v Reading specs from ./specs Target: x86_64-gnu-linux Configured with: ../configure --target=x86_64-gnu-linux --with-arch=k8 --prefix=/local/devel/toolchain43/x86_64-gnu-linux --with-sysroot=/local/devel/toolchain43/x86_64-gnu-linux --libdir=/local/devel/toolchain43/x86_64-gnu-linux/lib64 --libexecdir=/local/devel/toolchain43/x86_64-gnu-linux/lib64 --with-slibdir=/local/devel/toolchain43/x86_64-gnu-linux/lib64 --with-gmp-include=/home/users/builder/toolchain/trunk/linux/gcc-math-runtime/include --with-gmp-lib=/home/users/builder/toolchain/trunk/linux/gcc-math-runtime/lib64 --with-mpfr-include=/home/users/builder/toolchain/trunk/linux/gcc-math-runtime/include --with-mpfr-lib=/home/users/builder/toolchain/trunk/linux/gcc-math-runtime/lib64 --disable-multilib --disable-nls --disable-libgomp --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-c99 --enable-long-long --enable-linux-futex --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++ --enable-symvers=gnu --with-long-double-128 --disable-cld --disable-bootstrap Thread model: posix gcc version 4.3.1 (GCC) afaics, the collect2 contains LIBRARY_PATH=./: /local/devel/toolchain43/x86_64-gnu-linux/usr/lib/../lib64/: /local/devel/toolchain43/x86_64-gnu-linux/usr/lib/ which uses $(prefix)/usr/lib directory (which may not exist in sysroot!) to access stuff in lib64. in my case, this directory doesn't exist, linker fails and libstdc++ configure reports errors. imho using $(readlink -m) to canonicalize builtin search paths is a good solution. -- Summary: gcc driver incorrectly assumes existence of $(prefix)/usr/lib Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36485
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #4 from vincent at vinc17 dot org 2008-06-10 11:26 --- cmpb$42, -481(%rbp) je .L458 jmp .L456 .L463: cmpb$85, -481(%rbp) je .L461 cmpb$90, -481(%rbp) je .L462 jmp .L456 .L458: .loc 1 1845 0 addq$1, -336(%rbp) .loc 1 1846 0 .value 0x0b0f .L459: .loc 1 1849 0 addq$1, -336(%rbp) .loc 1 1850 0 movl$3, -224(%rbp) jmp .L455 I've just noticed the following warning: vasprintf.c:1846: warning: 'mpfr_rnd_t' is promoted to 'int' when passed through '...' vasprintf.c:1846: note: (so you should pass 'int' not 'mpfr_rnd_t' to 'va_arg') vasprintf.c:1846: note: if this code is reached, the program will abort I don't know if this is related, because the program dies with a SIGILL, not a SIGABRT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug middle-end/36166] Use of the 'nonnull' attribute breaks code
--- Comment #9 from joseph at codesourcery dot com 2008-06-10 11:53 --- Subject: Re: Use of the 'nonnull' attribute breaks code On Tue, 10 Jun 2008, pgut001 at cs dot auckland dot ac dot nz wrote: > fully correct code suddenly breaks. In fact gcc seems to be doing the > opposite > of what ISO WG 14 is proposing for this attribute, which was to add extra > checking to make sure the attribute isn't NULL. gcc instead *removes* extra > checking to make sure the attribute isn't NULL. If WG14 is proposing incompatible attribute semantics, that's ignoring the C1X Charter (N1250) - we agreed at the London meeting that one of the main problems with C99 and reasons for it not being widely implemented, that should be avoided for C1x, was invention and being incompatible with existing practice. (Some subsequent minutes suggest that the idea has since been adopted that C++0x can invent something and then C1x can take C++0x as existing practice for C; not a good idea in my view.) 13. Unlike for C9X, the consensus at the London meeting was that there should be no invention, without exception. Only those features that have a history and are in common use by a commercial implementation should be considered. Also there must be care to standardize these features in a way that would make the Standard and the commercial implementation compatible. Do you have a reference to the incompatible proposal? I sent N1259 a while back warning about incompatibilities in syntax; perhaps a paper is needed on incompatible semantics as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #5 from ubizjak at gmail dot com 2008-06-10 11:58 --- (In reply to comment #4) > vasprintf.c:1846: note: (so you should pass 'int' not 'mpfr_rnd_t' to > 'va_arg') > vasprintf.c:1846: note: if this code is reached, the program will abort > > I don't know if this is related, because the program dies with a SIGILL, not a > SIGABRT. This is correct, since __builtin_trap emits ud2 insn (0x0b0f) that generates SIGILL. Closed as INVALID. -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #6 from vincent at vinc17 dot org 2008-06-10 12:37 --- OK, but shouldn't g++ generate a SIGABRT instead of a illegal instruction? I've never had thought that a compiler should generate an illegal instruction on purpose, so making me think that the problem comes from the compiler. Also, is it a problem specific to g++ and is it invalid C++? "gcc -std=c99 -Wc++-compat -pedantic -Wextra" doesn't emit any warning about this code (but it was said that -Wc++-compat was incomplete). If this is specific to g++, then the SIGILL is not acceptable. Otherwise -Wc++-compat needs to be improved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #7 from ubizjak at gmail dot com 2008-06-10 13:33 ---
Here is a short explanation from config/i386/i386.md on this matter:
--cut here--
;; We used to use "int $5", in honor of #BR which maps to interrupt vector 5.
;; That, however, is usually mapped by the OS to SIGSEGV, which is often
;; caught for use by garbage collectors and the like. Using an insn that
;; maps to SIGILL makes it more likely the program will rightfully die.
;; Keeping with tradition, "6" is in honor of #UD.
(define_insn "trap"
[(trap_if (const_int 1) (const_int 6))]
""
{ return ASM_SHORT "0x0b0f"; }
[(set_attr "length" "2")])
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #8 from vincent at vinc17 dot org 2008-06-10 14:02 --- I agree about SIGSEGV. But what about abort()? Wouldn't this be cleaner? This builtin trap is quite similar to a failed assertion (often used to avoid undefined behavior), isn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-10 14:38 --- Calling abort() doesn't work with free-standing environments. To answer the other questions we still need a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug c++/36486] New: g++ accepts code with ambiguous overloading
g++ (at least versions 3.3.5, 3.4.4 and 4.1.1) accepts the following code,
which I think is ill-formed:
template struct F {};
template
int f(R (C::*f)() const, const F &n = F()) { return 0; } // f0
template
int f(const R &(C::*f)() const, const F &n = F()) { return 1; } // f1
struct X { const X &foo() const { return *this; } };
int main() { return f(&X::foo); }
Here, g++ is presumably deciding that f1 is more specialized than f0, despite
f0's arguments not being deducible from f1 (indeed, there is no pair of
argument types (T1, T2) which both f0 and f1 accept).
EDG's frontend rejects the above code.
--
Summary: g++ accepts code with ambiguous overloading
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richard-gccbugzilla at metafoo dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
[Bug c++/36486] g++ accepts code with ambiguous overloading
--- Comment #1 from richard-gccbugzilla at metafoo dot co dot uk 2008-06-10 14:51 --- FWIW, Microsoft's recent compilers agree that this is ill-formed also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #10 from vincent at vinc17 dot org 2008-06-10 14:52 --- (In reply to comment #9) > Calling abort() doesn't work with free-standing environments. OK, but how about using an illegal instruction with free-standing environments and abort() with hosted ones? After all, the abort() way is documented in the GCC manual (under __builtin_trap) and IMHO, abort() would provide a better QoI for hosted environments. Now, concerning the warning "note: if this code is reached, the program will abort", could "with __builtin_trap" be added so that the user could look at the right place in the manual? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36484] g++ generates code with illegal instruction on Pentium D / x86_64
--- Comment #11 from vincent at vinc17 dot org 2008-06-10 15:21 ---
Here's the testcase (I've never used va_list and so on myself, so I hope it is
correct; at least it shows the missing warning problem). With gcc -Wall
-std=c99 -Wc++-compat -pedantic -Wextra, I don't get any warning concerning the
incompatibility with C++.
#include
#include
typedef enum { ELEM = 17 } en_t;
void vafoo (int i, va_list ap1)
{
en_t x;
x = va_arg (ap1, en_t);
if (x != ELEM)
exit (1);
}
void foo (int i, ...)
{
va_list ap;
va_start (ap, i);
vafoo (i, ap);
va_end (ap);
}
int main ()
{
foo (0, ELEM);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
[Bug target/36134] GCC creates suboptimal ASM : usage of ADDA.L where LEA could be used
--- Comment #5 from gunnar at greyhound-data dot com 2008-06-10 15:24 --- (In reply to comment #4) > Could you please submit your patch to [EMAIL PROTECTED], including a > ChangeLog entry and stating how you tested it. > As requested I did send the email last week. Do you need anything else from me to work on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36134
[Bug c/36487] New: Generated 68K code bad for pipelining
The code generation by GCC 4.4 (trunk) for 68K/Coldfire will run slow on the
SuperScalar pipelines of the 68060 and Coldfire V4/V5 cores.
if you compilining this example:
uint32_t fletcher( uint16_t *data, size_t len )
{
uint32_t sum1 = 0x, sum2 = 0x;
while (len) {
unsigned tlen = len > 360 ? 360 : len;
len -= tlen;
do {
sum1 += *data++;
sum2 += sum1;
} while (--tlen);
sum1 = (sum1 & 0x) + (sum1 >> 16);
sum2 = (sum2 & 0x) + (sum2 >> 16);
}
/* Second reduction step to reduce sums to 16 bits */
sum1 = (sum1 & 0x) + (sum1 >> 16);
sum2 = (sum2 & 0x) + (sum2 >> 16);
return sum2 << 16 | sum1;
}
with
"m68k-linux-gnu-gcc -mcpu=68060 -fomit-frame-pointer -O3 -S -o example.s
example.c"
Then you will see that this defination will generate the below code:
{
uint32_t sum1 = 0x, sum2 = 0x;
}
moveq #0,%d2
not.w %d2
move.l %d2,%d3
That are THREE depending instructions in a row.
Even with result forwarding these THREE instruction will need 3 clocks to
execute. Instead writing the above in three lines the compiler could have
generated two lines like this:
move.l #0x,%d2
move.l #0x,%d3
Or the compiler could have put other independing instructions between those.
GCC does not try to reduce the instruction dependencies.
The Code that GCC generates does not follow the scheduling recommendation for
68040/68060 and above multiscalar CPUs.
Please be so kind and correct this.
--
Summary: Generated 68K code bad for pipelining
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
GCC host triplet: m68k-linux-gnu
GCC target triplet: m68k-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36487
[Bug testsuite/36285] gcc.dg/compat/struct-by-value-xxx improper test for AVR target
--- Comment #3 from eric dot weddington at atmel dot com 2008-06-10 15:43 --- Fixed for 4.4.0. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36285
[Bug middle-end/36447] [4.4 Regression] simplify_subreg ICE with right shift more than length type AVR
--- Comment #5 from eric dot weddington at atmel dot com 2008-06-10 15:43 --- Fixed for 4.4.0. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36447
[Bug c/36488] New: Generated 68K code bad for pipelining (case swap)
+++ This bug was initially created as a clone of Bug #36487 +++
The code generation by GCC 4.4 (trunk) for 68K/Coldfire will run slow on the
SuperScalar pipelines of the 68060 and Coldfire V4/V5 cores.
if you compilining this example:
uint32_t fletcher( uint16_t *data, size_t len )
{
uint32_t sum1 = 0x, sum2 = 0x;
while (len) {
unsigned tlen = len > 360 ? 360 : len;
len -= tlen;
do {
sum1 += *data++;
sum2 += sum1;
} while (--tlen);
sum1 = (sum1 & 0x) + (sum1 >> 16);
sum2 = (sum2 & 0x) + (sum2 >> 16);
}
/* Second reduction step to reduce sums to 16 bits */
sum1 = (sum1 & 0x) + (sum1 >> 16);
sum2 = (sum2 & 0x) + (sum2 >> 16);
return sum2 << 16 | sum1;
}
with
"m68k-linux-gnu-gcc -mcpu=54470 -fomit-frame-pointer -O3 -S -o example.s
example.c"
Then you will see that this code is created:
1 clr.w %d3
2 swap %d3
3 clr.w %d4
4 swap %d4
Instruction 2 depends on instruction 1
Instruction 4 depends on instruction 3
A simple reorder of the code to have the instruction in that order
would double the performance as now Superscaler design as 68060 or V5 Coldfire
can execute more instruction in parrallel
1 clr.w %d3
2 clr.w %d4
3 swap %d3
4 swap %d4
GCC does not try to reduce the instruction dependencies.
The Code that GCC generates does not follow the scheduling recommendation for
68040/68060 and above multiscalar CPUs.
Can you please be so kind and correct this?
--
Summary: Generated 68K code bad for pipelining (case swap)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
GCC host triplet: m68k-linux-gnu
GCC target triplet: m68k-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36488
[Bug target/25128] [m68k] Suboptimal comparisons against 65536
--- Comment #2 from gunnar at greyhound-data dot com 2008-06-10 16:02 --- > Note that > > cmp.l #65535,%d0 > jbhi .L10 > > can be replaced with > > swap %d0 > tst.w %d0 > jbne .L10 > > A similar trick can be applied to signed comparisons as well. But this "trick" will run slower on the higher 68k CPUs. On 68040 or 68060 or SuperScalar Coldfire its better to generate less instructions that do not have dependancies. I think "cmp.l #65535,%d0" is the code that should be generated by "O2" as its faster on many 68K models. The shorter two instruction trick might be an option for compile optiont "Os" Kind regards Gunnar von Boehn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25128
[Bug c/36489] New: Warning "initialized field overwritten" wrongly triggers with multidimensional arrays
Hi,
This code :
int t[10][10] = {
[1][2] = 1,
[1][3] = 2
};
warns with "initialized field overwritten" under -Wextra with gcc 4.3.0,
although it's perfectly valid.
Antoine Levitt
--
Summary: Warning "initialized field overwritten" wrongly triggers
with multidimensional arrays
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smeuuh at gmail dot com
GCC build triplet: i386-pc-linux
GCC host triplet: i386-pc-linux
GCC target triplet: i386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36489
[Bug c++/36490] New: Attempt to copy a temporary object during passing it to a function as a const reference
gcc returns:
niko.cpp: In function 'int gun()':
niko.cpp:7: error: 'A::A(const A&)' is private
niko.cpp:20: error: within this context
when compiling:
struct A {
A() ;
int fun() const ;
private:
A( const A& ) ;
} ;
int hun( const A& a ) {
return a.fun()*4 ;
}
int gun() {
return 4+5*hun(A()) ;
}
MSVC 2008 and COMEAU compile this program flawlessly.
--
Summary: Attempt to copy a temporary object during passing it to
a function as a const reference
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dervih at interia dot pl
GCC host triplet: Windows XP, x86, gcc 4.2.3 ; Red Hat 2.6, x86, gcc
4.1.2 ; ALL
GCC target triplet: Windows XP, x86, gcc 4.2.3 ; Red Hat 2.6, x86, gcc
4.1.2 ; ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36490
[Bug tree-optimization/30052] [4.2 Regression] points-to analysis slow and memory hungry
--- Comment #60 from giovannibajo at libero dot it 2008-06-10 17:26 --- If a knowledgable GCC developer could suggest *any* workaround at -O1 for this bug in 4.2 (including disabling whatever alias analysys causes the problem), it might be proposed as a fix within distros at least. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug c/36491] New: Command line macro fails if definition contains spaces
Gcc 4.2.4 (also 4.2.3) built for Solaris versions 2.5.1, 8 and 10 does not handle a command line macro if the definition contains spaces. This was discovered while building Ghostscript. Following is an example. > gcc -DGX_COLOR_INDEX_TYPE="unsigned long long" test.c gcc: long: No such file or directory gcc: long: No such file or directory Note that the definition is quoted. -- Summary: Command line macro fails if definition contains spaces Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schulz at adi dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36491
[Bug fortran/36492] New: incorrect error when compiling
I'm using the latest trunk version of gfortran. File gcc-trunk-x86_64.tar.gz.
Downloaded today, Tues., June 10, 2008.
For this line of code:
CHARACTER (MAX_FLD_HED, ASCIICharacterKind) :: DWFdHd(MAXFLD) = [(" ", i =
1, MAXFLD)]
the compiler issues the following error message:
Error: The CHARACTER elements of the array constructor at (1) must have the
same length (1/40)
/home/norm/design/source/windataM.f90:72.70:
CHARACTER (MAX_FLD_HED, ASCIICharacterKind) :: DWFdHd(MAXFLD) = [(" ", i =
The code is correct. (The following compilers all compile this code correctly:
NAG, Intel, g95)
Thank you for your attention.
Norm Clerman
--
Summary: incorrect error when compiling
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: clerman at fuse dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
[Bug target/36450] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem
--- Comment #5 from vmakarov at gcc dot gnu dot org 2008-06-10 19:02 --- Subject: Bug 36450 Author: vmakarov Date: Tue Jun 10 19:01:37 2008 New Revision: 136638 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136638 Log: 2008-06-10 Vladimir Makarov <[EMAIL PROTECTED]> PR target/36450 * caller-save.c (insert_restore, insert_save): Don't require alignment more than PREFERRED_STACK_BOUNDARY in asserts. Modified: branches/ira/gcc/ChangeLog branches/ira/gcc/caller-save.c branches/ira/gcc/ira-int.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug target/36450] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem
--- Comment #6 from aldot at gcc dot gnu dot org 2008-06-10 19:34 --- Can you please also fix trunk? Thanks alot -- aldot at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-10 19:34:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug target/36028] [IRA] ICE in reload_cse_simplify_operands
--- Comment #6 from aldot at gcc dot gnu dot org 2008-06-10 19:42 --- Fixed on the IRA branch. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36028
[Bug tree-optimization/36493] New: [4.3/4.4 Regression] vectorizer aliasing bug
The following code aborts if built for i686-pc-linux-gnu with -msse2 -O3.
extern void abort (void);
int
main (void)
{
int i;
long x[12] __attribute__((aligned(16)));
x[0] = 1;
for (i = 0; i < 12; i++)
x[i] = i;
if (x[0] != 0)
abort ();
return 0;
}
The loop gets vectorized using "vector int *" pointers, and then the compiler
decides that "vector int" writes don't conflict with "long" reads. (If an
array of int is used instead, the test passes.)
(Not x86-specific; originally observed as a failure of
gcc.c-torture/execute/loop-13.c on SPE with an unsubmitted patch to support
autovectorization there.)
--
Summary: [4.3/4.4 Regression] vectorizer aliasing bug
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493
[Bug driver/36491] Command line macro fails if definition contains spaces
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 20:18 --- Are you sure that your gcc program is not a shell script that calls the real gcc program. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36491
[Bug driver/36491] Command line macro fails if definition contains spaces
--- Comment #2 from schulz at adi dot com 2008-06-10 20:45 --- I just checked and it is a shell script. I should have thought of that. Sorry for the noise. -- schulz at adi dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36491
[Bug c/36494] New: Char arrays gets corrupted in avr programs.
I've seen this bug in 4.1.2, 4.2.0, 4.2.1, 4.2.2, 4.3.0 and 4.3.1 (and at least
with the version 4.1.2 and 4.3.0 of the avr-gcc-c++-compiler). What happens is
that when a char array gets a value assigned through a quoted string, the data
gets corrupted (or lost) in the compilation, but if it's initialized with an
array of numbers it gets the correct value. I've created a small example:
#include
int main ()
{
char a[] = ":";
char b[] = { 0x3a, 0 };
int result = 0;
if (a[0] == 0x3a) result |= 1;
if (b[0] == 0x3a) result |= 2;
DDRC = 0x0f;
PORTC = result;
return 0;
}
The expected result is of course 3 (which I get if I compile a slightly
modified program for i386) but what I get is 2. In my world that's not quite
accepted, I hope you all concur. The include file and the macros for DDRC and
PORTC doesn't matter, I've verified with dummy values that they're ok.
[EMAIL PROTECTED] ~]$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../gcc-4.3.1/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls
--disable-libssp --with-system-zlib --enable-version-specific-runtime-libs
Thread model: single
gcc version 4.3.1 (GCC)
[EMAIL PROTECTED] ~]$ uname -a
Linux chip.chaos 2.6.24.7-92.fc8 #1 SMP Wed May 7 16:50:09 EDT 2008 i686 athlon
i386 GNU/Linux
Flags used while compiling are -mmcu=atmega48 -Wall. Optimization doesn't seem
to make any difference. The .i-file looks like this:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/io.h" 1 3
# 87 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/io.h" 3
# 1 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/sfr_defs.h" 1 3
# 126 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/sfr_defs.h" 3
# 1 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/inttypes.h" 1 3
# 37 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/inttypes.h" 3
# 1 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/stdint.h" 1 3
# 121 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/stdint.h" 3
typedef int int8_t __attribute__((__mode__(__QI__)));
typedef unsigned int uint8_t __attribute__((__mode__(__QI__)));
typedef int int16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned int uint16_t __attribute__ ((__mode__ (__HI__)));
typedef int int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned int uint32_t __attribute__ ((__mode__ (__SI__)));
typedef int int64_t __attribute__((__mode__(__DI__)));
typedef unsigned int uint64_t __attribute__((__mode__(__DI__)));
# 142 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/stdint.h" 3
typedef int16_t intptr_t;
typedef uint16_t uintptr_t;
# 159 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/stdint.h" 3
typedef int8_t int_least8_t;
typedef uint8_t uint_least8_t;
typedef int16_t int_least16_t;
typedef uint16_t uint_least16_t;
typedef int32_t int_least32_t;
typedef uint32_t uint_least32_t;
typedef int64_t int_least64_t;
typedef uint64_t uint_least64_t;
# 213 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/stdint.h" 3
typedef int8_t int_fast8_t;
typedef uint8_t uint_fast8_t;
typedef int16_t int_fast16_t;
typedef uint16_t uint_fast16_t;
typedef uint64_t uint_least64_t;
# 213 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/stdint.h" 3
typedef int8_t int_fast8_t;
typedef uint8_t uint_fast8_t;
typedef int16_t int_fast16_t;
typedef uint16_t uint_fast16_t;
typedef int32_t int_fast32_t;
typedef uint32_t uint_fast32_t;
typedef int64_t int_fast64_t;
typedef uint64_t uint_fast64_t;
# 273 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/stdint.h" 3
typedef int64_t intmax_t;
typedef uint64_t uintmax_t;
# 38 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/inttypes.h" 2 3
# 77 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/inttypes.h" 3
typedef int32_t int_farptr_t;
typedef uint32_t uint_farptr_t;
# 127 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/sfr_defs.h" 2 3
# 88 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/io.h" 2 3
# 290 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/io.h" 3
# 1 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/iom48.h" 1 3
# 36 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/iom48.h" 3
# 1 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/iomx8.h" 1 3
# 37 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/iom48.h" 2 3
# 291 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/io.h" 2 3
# 360 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/io.h" 3
# 1 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/portpins.h" 1 3
# 361 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/io.h" 2 3
# 370 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/io.h" 3
# 1 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/version.h" 1 3
# 371 "/usr/lib/gcc/avr/4.3.1/../../../../avr/include/avr/io.h" 2 3
# 2 "test.c" 2
int main ()
{
char a[] = ":";
char b[] = { 0x3a, 0 };
int result = 0;
[Bug c++/36486] g++ accepts code with ambiguous overloading
--- Comment #2 from peterbindels at gmail dot com 2008-06-10 21:32 --- It's still warning free on 4.3.1 (except with all turned on, when ti complains about unused parameters but nothing else). As far as I can tell the second template matches the subset of the matches for the first template where R would be an const ? &, with the second parameter matching a different but still default constructed type. It's not ambiguous because of the const at least. I don't see why this would not work? Do you have an std reference for why this would be ill-formed? -- peterbindels at gmail dot com changed: What|Removed |Added CC||peterbindels at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
[Bug target/36494] Char arrays gets corrupted in avr programs.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |target GCC target triplet||avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36494
[Bug target/36450] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem
--- Comment #7 from hjl dot tools at gmail dot com 2008-06-10 22:05 --- Please note that some mode alignments are the hard requirement. This problem will go away after stack branch is merged with trunk. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug preprocessor/36453] PR36320 breaks boost
--- Comment #2 from mueller at gcc dot gnu dot org 2008-06-10 22:14 --- so the code should be changed to #elif defined(BOOST_PP_ITERATION_DEPTH) && BOOST_PP_ITERATION_DEPTH() == 1 ? it is confusing that #elif behaves more like "#if" and not like "#else\n#if" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #2 from david dot kirkby at onetel dot net 2008-06-10 22:37 --- Subject: Re: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr pinskia at gcc dot gnu dot org wrote: > --- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:52 > --- > Your configure line should not have LD_LIBRARY_PATH set. > > Also this works for me ... > > > Can you tell me what I should set? Previous versions have worked with far less messing around with flags to configure. If you can suggest a set of flags which will work, I will try that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor
--- Comment #20 from jorg dot brown at gmail dot com 2008-06-11 00:07
---
Interesting, but I'm not sure this can legally be done.
Consider:
struct POD {
int x;
int y;
};
struct nonPOD {
int x;
int y;
nonPOD(int xx, int yy) : x(xx), y(yy) { }
};
I, for one, would love to see "nonPOD foo(1, 2);" be treated as efficiently as
"POD foo = {1, 2};", and I would argue that the case that should be optimized
is when the arguments to the constructor are known at compile time, the body of
the constructor is completely empty, and all the member variables are POD.
However let us consider this example program, starting with the definitions
above and the requisite header files and then:
extern const PODpod;
extern const nonPOD nonpod;
std::string podStr(pod.x, '*');
std::string nonpodStr(nonpod.x, '*');
const POD pod = {1, 2};
const nonPOD nonpod(1, 2);
int main(int argc, char *argv[]) {
std::cout << "podStr = '" << podStr << "'\n";
std::cout << "nonpodStr = '" << nonpodStr << "'\n";
return 0;
}
Now, the order of construction is well-defined, and that is why the program
produces:
podStr = '*'
nonpodStr = ''
That is, the nonPOD is still zero-filled when the constructor for nonpodStr
runs, so nonpodStr ends up empty.
I believe that if you change nonPOD so that it sits in .rodata, then it has to
be initialized prior to nonpodStr. This changes the behavior of this perfectly
valid program. No?
(Just for the record, I would whole-heartedly endorse a change to the C++
standard to allow this optimization)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug testsuite/36440] [4.4 Regression] FAIL: g++.dg/cdce3.C on powerpc-apple-darwin8.5.0
--- Comment #4 from kkojima at gcc dot gnu dot org 2008-06-11 01:27 --- Created an attachment (id=15746) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15746&action=view) patch >From the reports on gcc-testresults, cdce3.C fails on some other targets: arm-none-linux-gnueabi http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00404.html powerpc64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00430.html sh4-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00494.html powerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00508.html i386-unknown-freebsd6.2 http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00522.html mipsel-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00555.html though now cdce3.C test is skipped on darwin. It fails also for some *-elf embedded targets. For these *-linux* and *-elf targets, it seems that the lack of 'l' suffixed math functions causes errors. How about the attached patch? It tests long double math functions only for the targets having true long double and skips tests for pow10*/exp10* functions which are gnu extensions on *-*-darwin*. It's tested for i686-pc-linux-gnu, powerpc-apple-darwin9.0.0, sh-unknown-elf and sh4-unknown-linux-gnu. I'm not sure how this test fails on AIX and FreeBSD, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36440
[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor
--- Comment #21 from pinskia at gcc dot gnu dot org 2008-06-11 02:17 --- Well if done correctly the compiler would see that nonpod.x was used for the initialization and inline it as zero :). So really this can be still done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug target/36494] Char arrays gets corrupted in avr programs.
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2008-06-11 02:35 --- Please post command line used to compile and assembler produced. I cannot reproduce this on 4.4 or 4.2.2. At high optimisation (-Os) it compiles to load PORTC with 3 directly. (as one would expect): 13/* prologue: frame size=0 */ 14/* prologue end (size=0) */ 15 8FE0 ldi r24,lo8(15) 16 0002 87B9 out 39-0x20,r24 17 0004 83E0 ldi r24,lo8(3) 18 0006 90E0 ldi r25,hi8(3) 19 0008 88B9 out 40-0x20,r24 20 000a 80E0 ldi r24,lo8(0) 21 000c 90E0 ldi r25,hi8(0) 22/* epilogue: frame size=0 */ 23 000e 0895 ret -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added CC||eric dot weddington at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36494
[Bug middle-end/36166] Use of the 'nonnull' attribute breaks code
--- Comment #10 from pgut001 at cs dot auckland dot ac dot nz 2008-06-11 03:47 --- >13. Unlike for C9X, the consensus at the London meeting was that there should >be no invention, without exception. Only those features that have a history >and are in common use by a commercial implementation should be considered. >Also there must be care to standardize these features in a way that would >make the Standard and the commercial implementation compatible. Well they've done exactly that, it's perfectly compatible with VC++ (via PREfast), which is a widely-used commercial implementation :-). >Do you have a reference to the incompatible proposal? I sent N1259 a while >back warning about incompatibilities in syntax; perhaps a paper is needed on >incompatible semantics as well. I'm using N1273, which seems to be the only published statement on the use of attributes. For stdc_nonnull it describes the proposed semantics as: To be discussed[[the implementation may/it is implementation defined add assertions to ensure the runtime values of the variables are not null pointers] OTOH the gcc interpretation of this seems to be: To be discussed[[the implementation may/it is implementation defined *remove* assertions that ensure the runtime values of the variables are not null pointers] If the current gcc behaviour is regarded as correct and appropriate then maybe the docs need to be updated (which is why I originally reported this as a doc. bug, I wasn't sure which of the two was definitive). Currently the docs say something to the effect of: The compiler WILL issue warnings and MAY change its code generation when it sees this attribute. when in fact what it really does is: The compiler WILL change its code generation and MAY issue warnings when it sees this attribute. So the proposed change would be to substitute, in place of the current ... causes the compiler to check that, in calls to my_memcpy, arguments dest and src are non-null. If the compiler determines that a null pointer is passed in an argument slot marked as non-null, and the -Wnonnull option is enabled, a warning is issued. The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null. the new text: ... causes the compiler to make optimizations based on the knowledge that certain function arguments will not be null. The compiler may also choose to check that, in calls to my_memcpy, arguments dest and src are non-null. If the compiler determines that a null pointer is passed in an argument slot marked as non-null, and the -Wnonnull option is enabled, a warning is issued. This more accurately reflects the actual behaviour of the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
[Bug fortran/36492] incorrect error when compiling
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-11 05:36 --- Can you post a *complete* example? I tried to create a program based on your single line, but here it simply works. I tried both (gfortran -v) 4.4.0 20080609 [trunk revision 136577] and 4.4.0 20080610 [trunk revision 136611] (my x86_64-unknown-linux-gnu builds). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
[Bug target/36494] Char arrays gets corrupted in avr programs.
--- Comment #2 from eric dot weddington at atmel dot com 2008-06-11 05:50 --- Compiling code with -O0 (so it doesn't optimize the program away) and running it through the debugger in AVR Studio still shows that main returns a 3, which indicates that both conditions (testing a[0] and b[0] for equality with 0x3a) are true. This is with WinAVR 20080610 (4.3.0 + patches). Please give us more information to be able to reproduce the problem. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36494
[Bug libgomp/36469] bootstrap broken on HPUX PA
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:27 --- Subject: Bug 36469 Author: jakub Date: Wed Jun 11 06:27:04 2008 New Revision: 136650 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136650 Log: PR libgomp/36469 * configure.ac: Add AC_CHECK_FUNCS (strtoull). * configure: Regenerated. * config.h.in: Regenerated. * env.c (strtoull): Define to strtoul if HAVE_STRTOULL is not defined. Modified: trunk/libgomp/ChangeLog trunk/libgomp/config.h.in trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/env.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36469
[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-11 06:31 --- Subject: Bug 36408 Author: jakub Date: Wed Jun 11 06:30:55 2008 New Revision: 136651 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136651 Log: PR c++/36408 * semantics.c (stmt_expr_value_expr): Don't crash on empty STATEMENT_LIST. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug libgomp/36208] Boolean type discrepancy between gfortran and libgomp
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:44 --- This ought to be fixed on the trunk - BT_BOOL is the C _Bool type even in Fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36208
[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-11 06:48 --- Subject: Bug 36408 Author: jakub Date: Wed Jun 11 06:47:36 2008 New Revision: 136652 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136652 Log: PR c++/36408 * semantics.c (stmt_expr_value_expr): Don't crash on empty STATEMENT_LIST. Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/semantics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
[Bug libgomp/35881] OMP wrong results for omp_get_max_threads
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-11 06:48 --- Fixed on the trunk as part of the OpenMP 3.0 support. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35881
[Bug libgomp/35644] omp_set_num_threads not working?
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:53 --- That's correct actually. omp_set_num_threads sets the NTHREADS_VAR ICV, i.e. something that will be used to determine the number of threads of the next #pragma omp parallel. omp_get_num_threads returns the number of threads in the current team, as you call it in sequential code, that has to be always 1. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35644
