[Bug debug/47794] [4.6 Regression] New debug failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47794 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||WORKSFORME --- Comment #2 from Jakub Jelinek 2011-02-18 07:55:13 UTC --- Can't reproduce, on both Fedora 13 and Fedora 14, the only vla* failures I get before and after this commit are: FAIL: gcc.dg/guality/vla-1.c -O1 line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O2 line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O3 -fomit-frame-pointer line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O3 -g line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -Os line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O2 -flto -flto-partition=none line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O2 -flto -flto-partition=none line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O2 -flto line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O2 -flto line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-2.c -O2 -flto -flto-partition=none line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 -flto -flto-partition=none line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 -flto line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 -flto line 25 sizeof (a) == 6 * sizeof (int) for -m64 and none for -m32.
[Bug c/47796] The code to write to a bit_field data strucuture will be removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796
--- Comment #2 from qihua.dai at intel dot com 2011-02-18 07:54:15 UTC ---
(In reply to comment #1)
> You are violating C/C++ aliasing rules:
> pData = (unsigned int *)pTmp;
> data = *pData;
> printf("data = 0x%x\n", data);
> You access a tmp_t via an unsigned int which is undefined.
But why does gcc 4.4.0 have no this problem?
gcc 4.5 does not report warning like "break strict-aliasing rule" for this
code.
If accessing tmp_t via an unsigned int is illegal, does it mean we cannot write
c code to w/r bits in unsigned int?
[Bug web/47718] bugzilla: commit mails mentioning binutils PR wrongly linked to GCC bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47718 Ralf Wildenhues changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.18 07:52:04 Ever Confirmed|0 |1 --- Comment #4 from Ralf Wildenhues 2011-02-18 07:52:04 UTC --- You don't see many complaints because it is rare that a patch mentions a binutils (or gdb) PR and is committed to both the GCC and the src repository. Those are typically patches to toplevel or other synced files, IOW often build system patches. It is not a big problem (I mean, it's probably the most annoying for the people involved in said old bug reports), but I'm pretty sure that this used to work.
[Bug web/47718] bugzilla: commit mails mentioning binutils PR wrongly linked to GCC bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47718 Frédéric Buclin changed: What|Removed |Added CC||LpSolit at netscape dot net --- Comment #3 from Frédéric Buclin 2011-02-18 07:43:17 UTC --- In that case, it makes sense for it to send emails to this Bugzilla, as it's the biggest of the two (and so it's more likely to be correct). Is it the first time someone commit a patch for binutils since October or what? Nobody complained before.
[Bug c/47796] The code to write to a bit_field data strucuture will be removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #1 from Andrew Pinski 2011-02-18
05:52:18 UTC ---
You are violating C/C++ aliasing rules:
pData = (unsigned int *)pTmp;
data = *pData;
printf("data = 0x%x\n", data);
You access a tmp_t via an unsigned int which is undefined.
[Bug c/47796] New: The code to write to a bit_field data strucuture will be removed unexpectedly with gcc 4.5.1 -O2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47796
Summary: The code to write to a bit_field data strucuture will
be removed unexpectedly with gcc 4.5.1 -O2 option
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: qihua@intel.com
Created attachment 23393
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23393
sample code for this problem
The code "tmp.a = 0xc;" and "tmp.d = 0x1;" is to write to a bit_field data
strucuture. They will be removed unexpectedly with gcc 4.5.1 -O2 option if
there is the same code in "if" condition before them, and using unsigned int
pointer to access the bit_field data strcuture after them. See below:
{
..
if(rev==0x0)
{
..
}
else
{
tmp.a = 0xc;
tmp.d = 0x1;
pData = (unsigned int *)pTmp;
data = *pData;
..
}
tmp.a = 0xc; // this code line is removed unexpected after -O2 optimization
tmp.d = 0x1; // this code line is removed unexpected after -O2 optimization
pData = (unsigned int *)pTmp;
data = *pData;
..
}
This issue only occurs when using -O2 gcc 4.5 option for bit_field c code.
On Fedora 11 (kernel 2.6.29.4-167). gcc 4.4.0 has no this problem.
On Fedora 14 (kernel 2.6.35.6-45). gcc 4.5.1 has no this problem.
Attached file includes the sample code tmp.c, and its assemle files built with
-O0 and -O2.
tmp_bit_field_O0.s is assemble file generated by -O0
tmp_bit_field_O2.s is assemble file generated by -O2
reproduce steps:
1, gcc -O0 tmp.c
2, ./a.out
3, the correct result below is printed:
data = 0x800c
rev_data = 0x11
4, gcc -O2 tmp.c
5, ./a.out
6, the incorrect result below is printed:
data = 0x0
rev_data = 0x11
[Bug objc/47784] Internal compiler error in dot notation assignment of const value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784 Nicola Pero changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.18 03:03:14 CC||nicola at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.6.0 --- Comment #1 from Nicola Pero 2011-02-18 03:03:14 UTC --- Yes, confirmed. Thanks
[Bug driver/47795] New: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have error_mark in finish_non_static_data_member, at cp/semantics.c:1513
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47795 Summary: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have error_mark in finish_non_static_data_member, at cp/semantics.c:1513 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: naddi...@gmail.com Created attachment 23392 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23392 Test case There's probably a better title, but a minimal testcase is attached. $ /usr/lib/gcc-snapshot/bin/g++ -std=c++0x main.cpp main.cpp: In lambda function: main.cpp:12:8: error: 'this' was not captured for this lambda function main.cpp:12:8: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have error_mark in finish_non_static_data_member, at cp/semantics.c:1513 $ /usr/lib/gcc-snapshot/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.6.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 20101004-0ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.0 20101004 (experimental) [trunk revision 164952] (Ubuntu 20101004-0ubuntu1)
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 --- Comment #8 from John David Anglin 2011-02-18 02:50:28 UTC --- Correcting the typo fixes the error.
[Bug debug/47794] [4.6 Regression] New debug failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47794 --- Comment #1 from joseph at codesourcery dot com 2011-02-18 02:24:58 UTC --- This commit should not affect anything not using -Ofast, and I get identical before/after code with -m32 when I tested vla-1.c. Could you give example source and cc1 options that generate different code before/after for you (and provide the resulting before/after .s files)? Otherwise I suspect some nondeterminism in GDB.
[Bug target/47715] [x32] TLS doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715 --- Comment #6 from hjl at gcc dot gnu.org 2011-02-18 02:23:39 UTC --- Author: hjl Date: Fri Feb 18 02:23:35 2011 New Revision: 170267 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170267 Log: Always use legitimized plus const symbol reference. gcc/ 2011-02-17 H.J. Lu PR target/47715 * config/i386/i386.c (ix86_expand_move): Always use legitimized plus const symbol reference. gcc/testsuite/ 2011-02-17 H.J. Lu PR target/47715 * gcc.target/i386/pr47715-4.c: New. Added: branches/x32/gcc/testsuite/gcc.target/i386/pr47715-4.c Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/config/i386/i386.c branches/x32/gcc/testsuite/ChangeLog.x32
[Bug debug/47794] New: [4.6 Regression] New debug failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47794 Summary: [4.6 Regression] New debug failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: js...@gcc.gnu.org On Linux/ia32, revision 170259: http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00804.html caused: FAIL: gcc.dg/guality/vla-1.c -O0 line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O0 line 17 sizeof (a) == 6 FAIL: gcc.dg/guality/vla-1.c -O0 line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O0 line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O1 line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O1 line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O2 line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O2 line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O3 -fomit-frame-pointer line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O3 -fomit-frame-pointer line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O3 -g line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -O3 -g line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -Os line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-1.c -Os line 24 sizeof (a) == 17 * sizeof (short) FAIL: gcc.dg/guality/vla-2.c -O0 line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O0 line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O0 line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O0 line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O1 line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O1 line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O1 line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O1 line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O2 line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O3 -fomit-frame-pointer line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O3 -fomit-frame-pointer line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O3 -fomit-frame-pointer line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O3 -fomit-frame-pointer line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O3 -g line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O3 -g line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O3 -g line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -O3 -g line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -Os line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -Os line 16 sizeof (a) == 5 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -Os line 25 sizeof (a) == 6 * sizeof (int) FAIL: gcc.dg/guality/vla-2.c -Os line 25 sizeof (a) == 6 * sizeof (int)
[Bug gcov-profile/47793] New: Relative path in fprofile-use turns into absolute path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47793
Summary: Relative path in fprofile-use turns into absolute path
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: martin.gccb...@gmail.com
I noticed that I was unable to specify a relative path when generating gcda
files:
# ${trunk_gcc} -Wall -fprofile-generate=./fdoprof -fprofile-arcs in.c -o
trunk.out
# ./trunk.out
profiling:/./fdoprof:Cannot create directory
profiling:/./fdoprof/in.gcda:Skip
I believe this was introduced in
http://gcc.gnu.org/viewcvs?view=revision&revision=165596
gcc version 4.6.0 20110211
Target: x86_64-unknown-linux-gnu
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 --- Comment #7 from dave at hiauly1 dot hia.nrc.ca 2011-02-18 01:00:35 UTC --- On Fri, 18 Feb 2011, redi at gcc dot gnu.org wrote: > I suppose the safe thing to would be add the right signature and leave that > there, but I can't imagine anyone's using it with that name I agree. Further, the name isn't present in other thread models. Dave
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.18 00:40:54 Ever Confirmed|0 |1 --- Comment #6 from Jonathan Wakely 2011-02-18 00:40:54 UTC --- I suppose the safe thing to would be add the right signature and leave that there, but I can't imagine anyone's using it with that name
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2011-02-18 00:38:54 UTC --- > Aha! :) > > There's a typo in gthr-dce.h > > __gthread_mutx_destroy (__gthread_mutex_t *__mutex) > > s/mutx/mutex/ Good catch! I wonder how many years it has been there? Dave
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 --- Comment #4 from Jonathan Wakely 2011-02-18 00:32:04 UTC --- Aha! :) There's a typo in gthr-dce.h __gthread_mutx_destroy (__gthread_mutex_t *__mutex) s/mutx/mutex/
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 --- Comment #3 from John David Anglin 2011-02-18 00:29:38 UTC --- 504 (hiauly1)dave> ./xgcc -B./ -v -threads Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa1.1-hp-hpux10.20 Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --enable-shared --prefix=/opt/gnu/gcc/gcc-4.6 --with-gmp=/opt/gnu/gcc/gcc-4.6 --enable-debug=no --disable-nls --enable-languages=c,c++,objc,fortran,obj-c++ Thread model: dce gcc version 4.6.0 20110216 (experimental) [trunk revision 170207] (GCC)
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 --- Comment #2 from Jonathan Wakely 2011-02-18 00:23:32 UTC --- why is __GTHREADS defined for thread model 'single' - is that normal? and why isn't __gthread_mutex_destroy in gthr-single.h in scope?
[Bug libstdc++/47792] [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 --- Comment #1 from Jonathan Wakely 2011-02-18 00:16:20 UTC --- probably caused by my fix for PR 46455
[Bug libstdc++/47792] New: [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47792 Summary: [4.6 Regression] concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 /xxx/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/xxx/gnu/gcc/objdir/./gcc -nostdinc++ -L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/src -L/xxx /gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/src/.libs -B/opt/gnu/g cc/gcc-4.6/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/include -isystem /opt/g nu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/sys-include -threads -x c++-header -nostdin c++ -g -O2 -threads -I/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/include/hppa1.1-hp-hpux10.20 -I/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/thr eads/libstdc++-v3/include -I/xxx/gnu/gcc/gcc/libstdc++-v3/libsupc++ -O2 -g -std= gnu++0x /xxx/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h \-o hppa1.1-hp-hpux10.20/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++ -v3/include/memory:76:0, from /xxx/gnu/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h :81: /xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/include/ext/concurrence.h: In destructor '__gnu_cxx::__mutex::~__mutex()': /xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/include/ext/concur rence.h:171:35: error: '__gthread_mutex_destroy' was not declared in this scope /xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/include/ext/concur rence.h: In static member function 'static typename __gnu_cxx::__enable_if::__value, void>::__type __gnu_cxx::__recursive_mutex::_S_destroy(_Rm*) [with _Rm = CMA_T_HANDLE, typename __gnu_cxx::__enable_if::__value, void>::__type = void]': /xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/include/ext/concurrence.h:229:22: instantiated from here /xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/include/ext/concurrence.h:292:9: error: '__gthread_mutex_destroy' was not declared in this scope make[8]: *** [hppa1.1-hp-hpux10.20/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 make[8]: Leaving directory `/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/include' make[7]: *** [all-recursive] Error 1 504 (hiauly1)dave> gcc/xgcc -Bgcc/ -v Reading specs from gcc/specs COLLECT_GCC=gcc/xgcc COLLECT_LTO_WRAPPER=gcc/lto-wrapper Target: hppa1.1-hp-hpux10.20 Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --enable-shared --prefix=/opt/gnu/gcc/gcc-4.6 --with-gmp=/opt/gnu/gcc/gcc-4.6 --enable-debug=no --disable-nls --enable-languages=c,c++,objc,fortran,obj-c++ Thread model: single gcc version 4.6.0 20110216 (experimental) [trunk revision 170207] (GCC)
[Bug c++/47791] New: finish function is using absolute value instead of the #defined one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47791 Summary: finish function is using absolute value instead of the #defined one Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: bvi...@gmail.com GCC Version: GCC 4.6.0-20101211-experimental In couple places, the parameters passed into "finish_function" is the absolute value and not the "#define"d one. E.g. in the "cp_parser_lambda_body" function, finish function is passed in the number "2" instead of using "SF_INCLASS_INLINE." I think this could cause some problems in future versions. Thanks, Balaji V. Iyer.
[Bug middle-end/47790] [4.5/4.6 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47790 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization See Also||http://gcc.gnu.org/bugzilla ||/show_bug.cgi?id=18030, ||http://gcc.gnu.org/bugzilla ||/show_bug.cgi?id=18029 Target Milestone|--- |4.5.3
[Bug middle-end/47790] New: [4.5/4.6 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47790 Summary: [4.5/4.6 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: pins...@gcc.gnu.org Created attachment 23391 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23391 Patch which needs testing but should fix it Ever since expand-ssa was added optimize_bitfield_assignment_op no longer works. You can see the difference in the code generated in gcc.c-torture/execute/20040629-1.c.
[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47775 Tobias Burnus changed: What|Removed |Added CC||janus at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #6 from Tobias Burnus 2011-02-17 23:55:59 UTC --- Janus, Paul: Do you think the patch in comment 5 (with added "||") is OK? Or does one need to take care about thinks like intrinsics, proc-pointer (components) and type-bound procedures?
[Bug fortran/47775] Wrong code with allocatable function RESULT and GENERIC interfaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47775 --- Comment #5 from Tobias Burnus 2011-02-17 23:45:14 UTC --- If one looks closer at "se->direct_byref" in gfc_conv_procedure_call, one sees that in the generic case "se->direct_byref" is 1 while in the specific-call case it is 0. (Thus, in the specific case, always a temporary is generated.) There might be no need for a temporary, if the LHS is allocatable without the TARGET attribute. I am not sure how far automatic realloc is properly handled for allocatable-returning functions, but there might be room for optimization if the size changes or the LHS is not TARGET. Untested patch: --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -5373,8 +5373,9 @@ arrayfunc_assign_needs_temporary (gfc_expr * expr1, gfc_expr * expr2) return true; /* Functions returning pointers need temporaries. */ - if (expr2->symtree->n.sym->attr.pointer - || expr2->symtree->n.sym->attr.allocatable) + if (expr2->value.function.esym + && (expr2->value.function.esym->attr.pointer + expr2->value.function.esym->attr.allocatable)) return true; /* Character array functions need temporaries unless the
[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 --- Comment #16 from Ulrich Weigand 2011-02-17 23:24:45 UTC --- I tested the patch from comment #12 on spu-elf with no regressions.
[Bug tree-optimization/47404] gcc.dg/pr46909.c FAILs on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47404 Janis Johnson changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #2 from Janis Johnson 2011-02-17 23:22:51 UTC --- This test has failed on all mips, m68k, and powerpc* targets since it was added by: r167800 | jakub | 2010-12-14 06:09:59 -0800 (Tue, 14 Dec 2010) | 15 lines PR tree-optimization/46909 * gimple-fold.c (and_var_with_comparison_1): Save partial result even in the is_and case, if both partial results are the same, return it. (or_var_with_comparison_1): Use is_or predicate instead of innercode == TRUTH_OR_EXPR test. Save partial result even in the is_or case, if both partial results are the same, return it. In the !is_or case when both partial results are the same, return the partial result instead of boolean_true_node. * gcc.c-torture/execute/pr46909-1.c: New test. * gcc.c-torture/execute/pr46909-2.c: New test. * gcc.dg/pr46909.c: New test.
[Bug tree-optimization/47737] [4.6 Regression] wrong code with -funswitch-loops -fno-tree-dominator-opts -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47737 Jeffrey A. Law changed: What|Removed |Added AssignedTo|unassigned at gcc dot |rguenther at suse dot de |gnu.org | --- Comment #3 from Jeffrey A. Law 2011-02-17 22:31:39 UTC --- I can't see any way this code is correct: /* We have to verify that one edge into the PHI node is dominated by the true edge of the predicate block and the other edge dominated by the false edge. This ensures that the PHI argument we are going to take is completely determined by the path we take from the predicate block. */ Consider this CFG fragment. 5 / \ 6-->7 \ / 8 ie edges (5,6) (5,7) (6,7) (6,8) (7,8) Assume we have a PHI with two constant args in block #8 and DOM is block #5. Assume true_edge is (5,7) and false_edge is (5,6). Clearly one can see that the edge (5,7) does _not_ dominate (7,8). However, the code in question gets it wrong. tem = EDGE_PRED (bb, 0); if (tem == true_edge || tem->src == true_edge->dest || dominated_by_p (CDI_DOMINATORS, tem->src, true_edge->dest)) arg0 = PHI_ARG_DEF (phi, tem->dest_idx); else if (tem == false_edge || tem->src == false_edge->dest || dominated_by_p (CDI_DOMINATORS, tem->src, false_edge->dest)) arg1 = PHI_ARG_DEF (phi, tem->dest_idx); else Assume tem is the edge (7,8). Obviously it is not true_edge (5,7). However tem->src == true_edge->dest and we record arg0 and believe we had a dominance relationship between true_edge and tem. Richard, how was this supposed to work?
[Bug target/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43653 --- Comment #18 from uros at gcc dot gnu.org 2011-02-17 22:10:40 UTC --- Author: uros Date: Thu Feb 17 22:10:37 2011 New Revision: 170258 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170258 Log: PR target/43653 * config/i386/i386.c (ix86_secondary_reload): Handle SSE input reload with PLUS RTX. testsuite/ChangeLog: PR target/43653 * gcc.target/i386/pr43653.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43653.c - copied unchanged from r170241, trunk/gcc/testsuite/gcc.target/i386/pr43653.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/i386.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug debug/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47620 Alexandre Oliva changed: What|Removed |Added Attachment #23317|0 |1 is obsolete|| --- Comment #14 from Alexandre Oliva 2011-02-17 21:33:45 UTC --- Created attachment 23390 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23390 Patch that kills the bug harder It turns out that deps from other blocks wouldn't always have tick 0, and debug insns other than the first could have deps other than their immediate preds, that would cause them to be queue for a later tick as well. But then, why bother? If all dependencies of a debug insns are met, just add it to the ready set, without even computing the tick it would get from its deps. Like this patch, that supersedes the earlier on. Jakub, can you give it a spin on the affected platforms, please? I'm bootstrapping it on x86_64-linux-gnu and i686-linux-gnu now.
[Bug target/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43653 --- Comment #17 from uros at gcc dot gnu.org 2011-02-17 21:22:05 UTC --- Author: uros Date: Thu Feb 17 21:22:02 2011 New Revision: 170256 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170256 Log: PR target/43653 * config/i386/i386.c (ix86_secondary_reload): Handle SSE input reload with PLUS RTX. testsuite/ChangeLog: PR target/43653 * gcc.target/i386/pr43653.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr43653.c - copied unchanged from r170241, trunk/gcc/testsuite/gcc.target/i386/pr43653.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/i386.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug target/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43653
--- Comment #16 from Uros Bizjak 2011-02-17 21:05:11
UTC ---
The assembly from -O1 -ftree-vectorize -msse3 shows another opportunity for
enhancement PR19398 (secondary reloads don't consider "m" alternatives):
.LFB0:
.cfi_startproc
subq$416, %rsp
.cfi_def_cfa_offset 424
movq.LC1(%rip), %rax
leaq(%rsp,%rax), %rax
movq%rax, -112(%rsp)
(*)movq-112(%rsp), %xmm1
(*)punpcklqdq%xmm1, %xmm1
movdqa%xmm1, %xmm0
leaq-104(%rsp), %rax
leaq408(%rsp), %rdx
.L2:
Looking at the definition of
(define_insn "*vec_dupv2di_sse3"
[(set (match_operand:V2DI 0 "register_operand" "=x,x")
(vec_duplicate:V2DI
(match_operand:DI 1 "nonimmediate_operand" " 0,m")))]
"TARGET_SSE3"
"@
punpcklqdq\t%0, %0
movddup\t{%1, %0|%0, %1}"
[(set_attr "type" "sselog1")
(set_attr "mode" "TI,DF")])
the two insns marked with (*) can be substituted with the second alternative:
movddup-112(%rsp), %xmm1.
[Bug tree-optimization/47737] [4.6 Regression] wrong code with -funswitch-loops -fno-tree-dominator-opts -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47737 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed|2011-02-17 20:40:52 | CC||rguenther at suse dot de --- Comment #2 from Jeffrey A. Law 2011-02-17 20:53:16 UTC --- Looks like a bug in invariant code motion of PHIs related to: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00121.html
[Bug c++/46472] [4.6 Regression] [C++0X] constexpr is not constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46472 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.6.0
[Bug c++/47783] [4.6 Regression] Warning 'set but not used' [-Wunused-but-set-parameter] incorrectly issued for update through reference wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47783 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2011-02-17 20:48:05 UTC --- Fixed.
[Bug c++/47783] [4.6 Regression] Warning 'set but not used' [-Wunused-but-set-parameter] incorrectly issued for update through reference wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47783 --- Comment #4 from Jakub Jelinek 2011-02-17 20:44:16 UTC --- Author: jakub Date: Thu Feb 17 20:44:14 2011 New Revision: 170255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170255 Log: PR c++/47783 * cvt.c (convert_from_reference): Call mark_exp_read. * g++.dg/warn/Wunused-parm-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-parm-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/47737] [4.6 Regression] wrong code with -funswitch-loops -fno-tree-dominator-opts -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47737 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.17 20:40:52 CC||law at redhat dot com Ever Confirmed|0 |1 --- Comment #1 from Jeffrey A. Law 2011-02-17 20:40:52 UTC --- Looks like a bug in invariant code motion. Evaluating further.
[Bug c++/46472] [4.6 Regression] [C++0X] constexpr is not constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46472
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.17 20:25:58
Summary|[C++0X] constexpr is not|[4.6 Regression] [C++0X]
|constexpr |constexpr is not constexpr
Ever Confirmed|0 |1
--- Comment #2 from Jonathan Wakely 2011-02-17
20:25:58 UTC ---
Marc provided this testcase demonstrating a regression since 4.5
(probably in G++ but possibly libstdc++, a regression either way)
#include
#include
struct A {
A(){}
};
std::array< std::pair, 2> x;
In file included from c.cc:2:0:
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/array:
In constructor ‘constexpr std::array, 2ul>::array()’:
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/array:60:12:
error: ‘constexpr std::pair<_T1, _T2>::pair() [with _T1 = int, _T2 = A]’ is not
‘constexpr’
/home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/array:60:12:
error: non-constant array initialization
c.cc: At global scope:
c.cc:6:34: note: synthesized method ‘std::array,
2ul>::array()’ first required here
[Bug web/47718] bugzilla: commit mails mentioning binutils PR wrongly linked to GCC bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47718 --- Comment #2 from Andrew Pinski 2011-02-17 19:49:45 UTC --- (In reply to comment #1) > Email sent to the wrong email_in.pl script, it looks like. Except there is no way for the svn to know which email to sent it to. The script is very simple of what it matches and does not understand the component part.
[Bug target/43653] [4.3/4.4/4.5/4.6 Regression] ICE at reload1.c:1188 with -O1 -ftree-vectorize and empty struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43653 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.6 |4.6.0 --- Comment #15 from Jeffrey A. Law 2011-02-17 19:46:39 UTC --- Fixed by Uros's patch.
[Bug web/47718] bugzilla: commit mails mentioning binutils PR wrongly linked to GCC bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47718 --- Comment #1 from Frédéric Buclin 2011-02-17 19:46:43 UTC --- Email sent to the wrong email_in.pl script, it looks like.
[Bug tree-optimization/45685] [4.6 Regression] missed conditional move opportunity in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685 Jeffrey A. Law changed: What|Removed |Added Blocks||42632 Target Milestone|4.6.0 |4.7.0 --- Comment #17 from Jeffrey A. Law 2011-02-17 19:41:27 UTC --- Potential fix is attached. Gets the desired code, triggers several hundred times during a bootstrap. Haven't checked compile-time, runtime performance or codesize issues. Did verify bootstrap & regression test were on x86_64-unknown-linux-gnu. Clearly not stage4 material.
[Bug tree-optimization/45685] [4.6 Regression] missed conditional move opportunity in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685 --- Comment #16 from Jeffrey A. Law 2011-02-17 19:39:24 UTC --- Created attachment 23389 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23389 potential fix
[Bug fortran/47667] I/O for reals: READ waits for input after "i" and "n"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47667 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jerry DeLisle 2011-02-17 19:31:58 UTC --- Closing,
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #16 from Jerry DeLisle 2011-02-17 19:30:47 UTC --- Disregard comment #15, typo in PR number
[Bug fortran/47667] I/O for reals: READ waits for input after "i" and "n"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47667 --- Comment #5 from Jerry DeLisle 2011-02-17 19:28:53 UTC --- Manually pasted here, typo on PR number. Author: jvdelisle Date: Thu Feb 17 05:19:50 2011 New Revision: 170239 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170239 Log: 2011-02-16 Jerry DeLisle PR libgfortran/47667 * io/list_read.c (read_logical): Check for end of line before calling eat_line. (read_integer): Likewise. (parse_real): Don't unget the separator. Check for end of line before callingeat_line. (read_complex): Allow line-end before and after parenthesis and comma. Check for end of line before calling eat_line. (read_real): Check for end of line before calling eat_line. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug fortran/47778] reading two arrays of structures from namelist fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47778 --- Comment #2 from Jerry DeLisle 2011-02-17 19:22:31 UTC --- I will try to look at this one this weekend.
[Bug lto/47788] [4.6 Regression] New LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47788 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.17 19:05:04 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.6.0 Ever Confirmed|0 |1
[Bug fortran/47789] New: derived type with no components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47789 Summary: derived type with no components Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: eddyg_61-bugzi...@yahoo.it The following program gives error in compilation module modone type:: one !integer :: b contains procedure :: f end type type, extends(one) :: two real :: a endtype contains subroutine f(this) class(one) :: this print *,'F' end subroutine end module program mmain use modone !type(two) :: wo = two(2,6.7) type(two) :: wo = two(6.7) call wo%f() end program --- type(two) :: wo = two(6.7) 1 Error: Invalid character in name at (1) While after uncommenting integer :: b and exchanging the comments in the two declaration type(two) :: wo = two(2,6.7) !type(two) :: wo = two(6.7) make the program compile and run
[Bug lto/47788] New: [4.6 Regression] New LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47788 Summary: [4.6 Regression] New LTO failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: hubi...@gcc.gnu.org On Linux/x86, revision 170250 gave FAIL: gcc.dg/lto/20081115 c_lto_20081115_0.o-c_lto_20081115_2.o execute -O0 -flto -flto-partition=1to1 FAIL: gcc.dg/lto/20081118 c_lto_20081118_0.o-c_lto_20081118_2.o execute -O0 -flto -flto-partition=1to1 FAIL: gcc.dg/lto/20081201-1 c_lto_20081201-1_0.o-c_lto_20081201-1_2.o execute -O0 -flto -flto-partition=1to1 Revision 170247 is OK. Revision 170249: http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00794.html is the cause.
[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Joseph S. Myers 2011-02-17 18:38:18 UTC --- Fixed for 4.6, though I advise using -rdynamic or -Wl,-export-dynamic instead of this backwards-compatibility support for a previous accident of the implementation.
[Bug driver/47390] [4.6 Regression] Linking with -export-dynamic broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390
--- Comment #8 from Joseph S. Myers 2011-02-17
18:35:44 UTC ---
Author: jsm28
Date: Thu Feb 17 18:35:41 2011
New Revision: 170253
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170253
Log:
PR driver/47390
* common.opt (export-dynamic): New Driver option.
* gcc.c (LINK_COMMAND_SPEC): Add comment about %{e*}.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/gcc.c
[Bug c/47781] warnings from custom printf format specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #4 from joseph at codesourcery dot com 2011-02-17 18:24:25 UTC --- On Thu, 17 Feb 2011, mark-gcc at glines dot org wrote: > I'd like to request a finer grained means of control. A syntactical element > (builtin/pragma/attribute/whatever) to pre-declare a format conversion and the > typedef to check it against would be very nice, if complex. A much simpler > solution would be a -Wno-format-unknown-specifier option, which skips the > argument in the argument list and otherwise ignores conversions it doesn't > recognize. You can't reliably know how many arguments the unknown specifier takes, though assuming them to take one argument would be a reasonable heuristic for such an option. For the general issue, my inclination is that we should add plugin hooks into the format checking machinery that allow plugins to define formats with the full flexibility of all the format checking datastructures in GCC. Using GCC plugins for this avoids problems with defining complicated syntax in the source file to describe the peculiarities of different formats, which might constrain future changes to the format checking implementation by making too much of the internals visible to user source code, because by design GCC plugins can use GCC internals which are free to change incompatibly in ways that require plugin changes.
[Bug c/47786] tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in c_type_hash, at c-family/c-common.c:4066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47786 --- Comment #3 from Dmitry Gorbachev 2011-02-17 17:55:42 UTC --- Thanks!
[Bug driver/47787] New: GCC with -flto combines preprocessed C sources
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47787 Summary: GCC with -flto combines preprocessed C sources Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Compile testcase in attachment 23385 (bug 47786) with `gcc -v -flto -o /dev/null main.i foo.i': /usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1 -fpreprocessed main.i foo.i -quiet -dumpbase main.i -mtune=generic -march=pentiumpro -auxbase main -version -flto -o /tmp/cc3eBz9m.s I don't think it is an intended behavior.
[Bug c++/47783] [4.6 Regression] Warning 'set but not used' [-Wunused-but-set-parameter] incorrectly issued for update through reference wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47783 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek 2011-02-17 17:13:45 UTC --- Created attachment 23388 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23388 gcc46-pr47783.patch Untested fix.
[Bug c/47786] tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in c_type_hash, at c-family/c-common.c:4066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47786 Nathan Froyd changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.17 17:05:22 AssignedTo|unassigned at gcc dot |froydnj at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Nathan Froyd 2011-02-17 17:05:22 UTC --- Created attachment 23387 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23387 untested fix Ugh, DECL_CHAIN fallout. Mine.
[Bug tree-optimization/46639] [4.6 Regression] Missing optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46639 --- Comment #3 from Dmitry Gorbachev 2011-02-17 17:02:20 UTC --- I can't reproduce this bug now.
[Bug c/47786] tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in c_type_hash, at c-family/c-common.c:4066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47786 --- Comment #1 from Dmitry Gorbachev 2011-02-17 16:57:41 UTC --- Created attachment 23386 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23386 backtrace
[Bug c/47786] New: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in c_type_hash, at c-family/c-common.c:4066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47786 Summary: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in c_type_hash, at c-family/c-common.c:4066 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 23385 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23385 gcc -O2 -flto -o /dev/null main.i foo.i Target: i686-pc-linux-gnu Configured with: ../gcc-4.6/configure --enable-languages=c,c++ --enable-version-specific-runtime-libs --enable-checking=yes,fold --disable-nls --disable-shared Thread model: posix gcc version 4.6.0 20110212 (experimental) (GCC)
[Bug debug/47780] [4.5/4.6 Regression] -fcompare-debug failure with -O -fgcse -fgcse-las -fstack-protector-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47780 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.6.0 Summary|-fcompare-debug failure |[4.5/4.6 Regression] |with -O -fgcse -fgcse-las |-fcompare-debug failure |-fstack-protector-all |with -O -fgcse -fgcse-las ||-fstack-protector-all
[Bug driver/47785] New: GCC with -flto does not pass options to the assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 Summary: GCC with -flto does not pass options to the assembler Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 23384 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23384 Testcase
[Bug debug/47780] -fcompare-debug failure with -O -fgcse -fgcse-las -fstack-protector-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47780 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.17 16:43:06 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2011-02-17 16:43:06 UTC --- Created attachment 23383 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23383 gcc46-pr47780.patch Untested fix.
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 --- Comment #6 from Paulo J. Matos 2011-02-17 16:23:47 UTC --- Thanks Paolo, I will take a look at those patches.
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 Paolo Bonzini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Paolo Bonzini 2011-02-17 16:20:43 UTC --- You can look in March to May 2009 at patches with a [cond-optab] tag. Unfortunately "news for developers" have been only introduced in the 4.6 release notes, so it was not written outside the mailing lists. Just like bCC patterns have been replaced by cbranch, sCC have been replaced by cstore. Most conversions should be pretty straightforward: * if you're using a cmpMM pattern that just saves operands and modes, and your bCC pattern calls some routine in your backend's .c file, your cbranch patterns can save the operands and mode, and then call the same routine as your existing bCC pattern. * if your cmpMM and bCC patterns are actually define_insns, your cbranch patterns can be very simple define_expand that generates the same RTL followed by the RTL for bCC. In most cases the conversion will have no real change on assembly, and should cut at least 50-100 lines from your backend (but for some almost 1000 were removed in the GCC sources!). If your backend had been in-tree, I would have fixed it for you. :)
[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47106 --- Comment #15 from Jan Hubicka 2011-02-17 16:18:34 UTC --- Author: hubicka Date: Thu Feb 17 16:18:24 2011 New Revision: 170249 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170249 Log: PR debug/47106 PR debug/47402 * cfgexpand.c (account_used_vars_for_block): Remove. (estimated_stack_frame_size): Use referenced vars. * tree-inline.c (remap_decl): Only mark VAR_DECLs as referenced that were referenced in the original function. Test src_fn rather than cfun. Drop redundant get_var_ann. (setup_one_parameter): Drop redundant get_var_ann. (declare_return_variable): Likewise. (copy_decl_for_dup_finish): Mark VAR_DECLs referenced in src_fn. (copy_arguments_for_versioning): Drop redundant get_var_ann. * ipa-inline.c (compute_inline_parameters): Do not compute disregard_inline_limits here. are not available. (compute_inlinable_for_current, pass_inlinable): New. (pass_inline_parameters): Require PROP_referenced_vars. * cgraphunit.c (cgraph_process_new_functions): Don't run compute_inline_parameters explicitly unless function is in SSA form. (cgraph_analyze_function): Set .disregard_inline_limits. * tree-sra.c (convert_callers): Compute inliner parameters only for functions already in SSA form. * g++.dg/debug/pr47106.C: New. Added: trunk/gcc/testsuite/g++.dg/debug/pr47106.C Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/cgraphunit.c trunk/gcc/ipa-inline.c trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c trunk/gcc/tree-sra.c
[Bug bootstrap/47402] [4.6 Regression] Bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47402 --- Comment #13 from Jan Hubicka 2011-02-17 16:18:34 UTC --- Author: hubicka Date: Thu Feb 17 16:18:24 2011 New Revision: 170249 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170249 Log: PR debug/47106 PR debug/47402 * cfgexpand.c (account_used_vars_for_block): Remove. (estimated_stack_frame_size): Use referenced vars. * tree-inline.c (remap_decl): Only mark VAR_DECLs as referenced that were referenced in the original function. Test src_fn rather than cfun. Drop redundant get_var_ann. (setup_one_parameter): Drop redundant get_var_ann. (declare_return_variable): Likewise. (copy_decl_for_dup_finish): Mark VAR_DECLs referenced in src_fn. (copy_arguments_for_versioning): Drop redundant get_var_ann. * ipa-inline.c (compute_inline_parameters): Do not compute disregard_inline_limits here. are not available. (compute_inlinable_for_current, pass_inlinable): New. (pass_inline_parameters): Require PROP_referenced_vars. * cgraphunit.c (cgraph_process_new_functions): Don't run compute_inline_parameters explicitly unless function is in SSA form. (cgraph_analyze_function): Set .disregard_inline_limits. * tree-sra.c (convert_callers): Compute inliner parameters only for functions already in SSA form. * g++.dg/debug/pr47106.C: New. Added: trunk/gcc/testsuite/g++.dg/debug/pr47106.C Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/cgraphunit.c trunk/gcc/ipa-inline.c trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c trunk/gcc/tree-sra.c
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 --- Comment #4 from Paulo J. Matos 2011-02-17 16:04:36 UTC --- Thanks Andy, was that documented anywhere? It would be interesting for me to know which other stuff became compulsory to implement in the backend.
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 --- Comment #3 from Andrew Pinski 2011-02-17 16:01:49 UTC --- I think cbranch is required in 4.5 where the cleanup happened. And yes we broke backwards compatibility to cleanup the backends.
[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 Steve Ellcey changed: What|Removed |Added CC||sje at cup dot hp.com --- Comment #15 from Steve Ellcey 2011-02-17 15:54:04 UTC --- I tested the patch from comment #12 on ia64-hp-hpux11.23 (in 32 and 64 bit modes) and it looks good. There were no regressions and the test g++.dg/debug/pr47283.C now passes.
[Bug rtl-optimization/43721] Failure to optimise (a/b) and (a%b) into single __aeabi_idivmod call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721 Andrew Pinski changed: What|Removed |Added CC||carrot at google dot com --- Comment #7 from Andrew Pinski 2011-02-17 15:50:30 UTC --- *** Bug 4 has been marked as a duplicate of this bug. ***
[Bug target/47777] use __aeabi_idivmod to compute quotient and remainder at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski 2011-02-17 15:50:30 UTC --- Dup. *** This bug has been marked as a duplicate of bug 43721 ***
[Bug c++/47783] [4.6 Regression] Warning 'set but not used' [-Wunused-but-set-parameter] incorrectly issued for update through reference wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47783 Paolo Carlini changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Paolo Carlini 2011-02-17 15:39:13 UTC --- Let's CC Jakub...
[Bug c++/47783] [4.6 Regression] Warning 'set but not used' [-Wunused-but-set-parameter] incorrectly issued for update through reference wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47783 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #50 from Jan Hubicka 2011-02-17 15:16:19 UTC --- > Thanks, that resolved these issues. However, now my 8GB machine runs > out of memory when linking libxul.so. That is expected. With richard's -g fixes memory usage is slightly over 8GB. Just add some swap, since it get over 8GB for short time during WPA it might not be that bad. Honza
[Bug objc/47784] Internal compiler error in dot notation assignment of const value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784 Christopher Lloyd changed: What|Removed |Added Severity|major |normal
[Bug objc/47784] New: Internal compiler error in dot notation assignment of const value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47784
Summary: Internal compiler error in dot notation assignment of
const value
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: c...@objc.net
Using the new Objective-C 2.0 dot notation syntax, assigning a property with a
'const' value causes an internal compiler error, this is with gcc 4.6.0 SVN
trunk r170061. Built for arm-linux-eabi on OS X 10.6. It doesn't appear to be
anything particular to arm though.
This is a reduced example which triggers the bug, usage of 'const' is the
trigger:
typedef struct {
float x;
} SomeType;
@interface SomeClass
@property(assign,readwrite) SomeType position;
@end
@implementation SomeClass
-(void)example {
// Error only happens when const is used
const SomeType SomeTypeZero = {0.0f};
self.position= SomeTypeZero;
}
@end
This is the compiler error:
main.m: In function '-[SomeClass example]':
main.m:19:4: error: assignment of read-only variable '__objc_property_temp'
main.m:19:4: internal compiler error: tree check: expected class 'expression',
have 'exceptional' (error_mark) in objc_maybe_build_modify_expr, at
objc/objc-act.c:1976
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
It appears a temporary variable is given the same type as the right hand side
and it's all downhill from there. I don't have a fix for this.
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 --- Comment #2 from Paulo J. Matos 2011-02-17 14:56:45 UTC --- Just a note to this... this bug assumes that cbranch4 is _not_ implemented. If cbranch4 is not an optional standard name to implement then this bug is invalid, but we should document this requirement somewhere. I just noticed that optabs.h has the comment before can_compare_p: /* Nonzero if a compare of mode MODE can be done straightforwardly (without splitting it into pieces). */ extern int can_compare_p (enum rtx_code, enum machine_mode, enum can_compare_purpose); By this I assume that cbranch should be implemented if there is an instruction that performs a compare and branch in one go without ''splitting it into pieces''. However, by looking at the vax case (which I think it does not have such an intruction) cbranch is implemented as: (define_expand "cbranch4" [(set (cc0) (compare (match_operand:VAXint 1 "nonimmediate_operand" "") (match_operand:VAXint 2 "general_operand" ""))) (set (pc) (if_then_else (match_operator 0 "ordered_comparison_operator" [(cc0) (const_int 0)]) (label_ref (match_operand 3 "" "")) (pc)))] "") which ends up expanding it into multiple insns... I can do the same on my side. However, that makes cbranch non-optional which is not-documented and breaks backward compatibility (in the sense that in previous gcc versions the lack of a cbranch implementation didn't seem to trigger any strange bug).
[Bug c++/47783] [4.6 Regression] Warning 'set but not used' [-Wunused-but-set-parameter] incorrectly issued for update through reference wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47783 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.17 14:32:03 Summary|Warning 'set but not used' |[4.6 Regression] Warning |[-Wunused-but-set-parameter |'set but not used' |] incorrectly issued for|[-Wunused-but-set-parameter |update through reference|] incorrectly issued for |wrapper |update through reference ||wrapper Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2011-02-17 14:32:03 UTC --- confirmed - no warning with 4.4 or 4.5
[Bug target/47715] [x32] TLS doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715
--- Comment #5 from H.J. Lu 2011-02-17 14:31:59
UTC ---
Another one:
[hjl@gnu-33 ilp32-23]$ cat x.i
struct gomp_team_state
{
struct gomp_team_state *prev_ts;
unsigned team_id;
unsigned level;
};
struct gomp_thread
{
void *data;
struct gomp_team_state ts;
};
extern __thread struct gomp_thread gomp_tls_data;
int
foo (int level)
{
struct gomp_team_state *ts = &gomp_tls_data.ts;
if (level < 0 || level > ts->level)
return -1;
for (level = ts->level - level; level > 0; --level)
ts = ts->prev_ts;
return ts->team_id;
}
[hjl@gnu-33 ilp32-23]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O2 -g x.i
x.i: In function \u2018foo\u2019:
x.i:22:1: error: unrecognizable insn:
(insn 11 10 12 6 (set (reg:SI 78)
(const:SI (plus:SI (symbol_ref:SI ("gomp_tls_data") [flags 0x60]
)
(const_int 4 [0x4] x.i:19 -1
(nil))
x.i:22:1: internal compiler error: in extract_insn, at recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make: *** [x.s] Error 1
[hjl@gnu-33 ilp32-23]$
[Bug c++/47783] New: Warning 'set but not used' [-Wunused-but-set-parameter] incorrectly issued for update through reference wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47783
Summary: Warning 'set but not used'
[-Wunused-but-set-parameter] incorrectly issued for
update through reference wrapper
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dev.li...@jessamine.co.uk
Compiling the following program with warning options -W -Wall yields
: In function ‘void f(ref_wrapper)’:
:6:6: warning: parameter ‘ref’ set but not used
[-Wunused-but-set-parameter]
If the reference-to-int is replaced with a pointer-to-int and dereference and
address-of operators are used in the appropriate places the warning does not
occur.
In all cases and at all optimization levels the resulting program returns 7 as
expected.
struct ref_wrapper
{
int& i;
};
void f( ref_wrapper ref )
{
ref.i = 7;
}
int main()
{
int x = 1;
ref_wrapper xref = {x};
f(xref);
return x;
}
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642 --- Comment #23 from Jakub Jelinek 2011-02-17 13:42:32 UTC --- Created attachment 23382 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23382 tst-strtod.c Testcase for strtoflt128 (adapted from glibc/stdlib/tst-strtod.c).
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642 --- Comment #22 from Jakub Jelinek 2011-02-17 13:41:23 UTC --- Created attachment 23381 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23381 gcc46-strtoflt128.patch To shorten up the agony of gdtoa, here is a patch to yank it and replace even the str to __float128 code by glibc code. The .text of libquadmath.so.0 shrinks (because quite a bit (mpn) can be shared with the printf stuff).
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #49 from Martin Jambor 2011-02-17 13:15:48 UTC --- (In reply to comment #48) > Updated mozilla patch fixing the undefined symbols Martin reported. > Sorry, had it in tree for a while, but didn't noticed PR is out of date. Thanks, that resolved these issues. However, now my 8GB machine runs out of memory when linking libxul.so.
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #14 from Jerry DeLisle 2011-02-17 12:54:58 UTC --- In reply to comment #13: Well, I was thinking fbuf_seek. I came to the conclusion that I do not want to change the API for read_sf for the reasons you state. I am now focusing on read_sf.
[Bug target/47719] ICE compiling libavcodec/adxdec.c (FFmpeg) for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47719 --- Comment #2 from Mans Rullgard 2011-02-17 12:46:24 UTC --- I can confirm this patch makes the file build without error. I have not tested the compiled code for correctness.
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 --- Comment #4 from Jonathan Wakely 2011-02-17 12:14:17 UTC --- I think this is a dup of bug 46472
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #13 from Janne Blomqvist 2011-02-17 12:13:53 UTC --- (In reply to comment #12) > the "file" is not seekable so the position eturne by seek always returns > zero. If you mean sseek(), don't count on that; the unix.c:raw_*() functions are more-or-less 1:1 mappings to the POSIX IO API, where the lseek() documentation http://pubs.opengroup.org/onlinepubs/9699919799/functions/lseek.html says "The behavior of lseek() on devices which are incapable of seeking is implementation-defined. The value of the file offset associated with such a device is undefined." and also in the errors section there is: [ESPIPE] The fildes argument is associated with a pipe, FIFO, or socket. FWIW, the need to handle seeking within a record (due to T* and some other edit descriptors) was one of the main motivations to introduce the fbuf layer in the first place. > I plane to see if we can do something with the seek to get it to return a > position within fbuf. If that does not seem reasonable, I will go with the > fbuf_fgetc approach which should be fairly efficient. As I recall, the problem with using fbuf_getc() in read_sf() is that the read_sf() API change would propagate such that one would need to modify all the read_x() functions in read.c to pass a buffer as a parameter rather than getting a pointer into the fbuf buffer to read from. I suspect this particular bug could be fixed by some smallish changes to read_sf() to handle short reads better, but perhaps we need to more fundamentally think about what kind of API we want to have for formatted IO?
[Bug c/47781] warnings from custom printf format specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #3 from Mark Glines 2011-02-17 12:00:40 UTC --- (In reply to comment #1) > I think a patch that adds -Wno-format-unknown-specifier would be accepted if > properly submitted: Okay, I'll take a look at putting together a patch. Thanks!
[Bug c/47781] warnings from custom printf format specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #2 from Mark Glines 2011-02-17 11:58:22 UTC --- Created attachment 23380 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23380 47781.c Here's a rather silly test case that demonstrates the problem with a simple "bool" type. $ gcc -O2 -Wall -o 47781 47781.c 47781.c: In function ‘main’: 47781.c:12: warning: unknown conversion type character ‘b’ in format 47781.c:12: warning: unknown conversion type character ‘b’ in format 47781.c:12: warning: too many arguments for format $ ./47781 true bool: TRUE false bool: FALSE $ (That's on x86-64 linux with gcc 4.4.4-14ubuntu5 and libc6 2.12.1-0ubuntu10.2.)
[Bug c/47781] warnings from custom printf format specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez 2011-02-17 11:57:54 UTC --- Which project is this? I think a patch that adds -Wno-format-unknown-specifier would be accepted if properly submitted: http://gcc.gnu.org/contribute.html See how the other Wformat-* options are defined in gcc/c-family/c.opt. Then, grep for unknown conversion type character, and just change OPT_Wformat in the warning call. You'll have to add new testcases and adjust existing ones.
[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 --- Comment #1 from Paulo J. Matos 2011-02-17 11:55:32 UTC --- Created attachment 23379 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23379 source code to reproduce bug
[Bug middle-end/47782] New: Infinite cycle generates segmentation fault in targets without cbranch support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47782 Summary: Infinite cycle generates segmentation fault in targets without cbranch support Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com Created attachment 23378 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23378 patch to assert !can_compare_p I have tested this with gcc 4.5.2. It doesn't happen in 4.4.4. There's a possibility for an infinite loop between two dojump.c functions: do_jump_by_parts_greater_rtx and do_compare_rtx_and_jump One condition needs to be met: !can_compare_p(code, mode, ccp_jump). As far as I understand from the code this is when the target doesn't implement cbranch. Unfortunately you can't reproduce it straightforwardly with i386 since it implements cbranch but by patching gcc with the no-cbranch.patch you can make gcc think there's no cbranch. The minimized and modified testcase is _mulhi3.i. You'll be able to reproduce this on a 64bit. If you have a 32bit you might reproduce it without any changes but you can also try (but it is untested) the substitutions s/DI/SI and s/TI/DI. Run the line: /cc1 -O2 _muldi3.i I have seen two behaviours... either you get a segmentation fault or an infinite loop that will eat all your memory if you don't limit it. In the meantime I am trying to sort out what the problem is.
[Bug c/47781] New: warnings from custom printf format specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 Summary: warnings from custom printf format specifiers Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: mark-...@glines.org Glibc allows a project to define custom printf conversions, via one of two APIs: register_printf_function, and more recently, register_printf_specifier. For instance, my project has a custom %v conversion, which takes a pointer to a vector structure that is heavily used within the project, and pretty-prints it. The problem is, every time the custom format conversion is used, gcc (which is invoked with -Wall) generates warnings. test.c:198: warning: unknown conversion type character ‘v’ in format test.c:198: warning: too many arguments for format I can get rid of the warnings with -Wno-format, but that also disables the rest of gcc's format string checking (which is very helpful!). I'd like to request a finer grained means of control. A syntactical element (builtin/pragma/attribute/whatever) to pre-declare a format conversion and the typedef to check it against would be very nice, if complex. A much simpler solution would be a -Wno-format-unknown-specifier option, which skips the argument in the argument list and otherwise ignores conversions it doesn't recognize. Any solution along those lines would be very helpful.
[Bug debug/47780] New: -fcompare-debug failure with -O -fgcse -fgcse-las -fstack-protector-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47780 Summary: -fcompare-debug failure with -O -fgcse -fgcse-las -fstack-protector-all Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: aol...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23377 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23377 reduced testcase Compiler output: $ gcc -O -fgcse -fgcse-las -fstack-protector-all -fno-tree-ccp -fno-tree-dominator-opts -fcompare-debug testcase.c testcase.c: In function 'foo': testcase.c:3:6: note: The ABI for passing parameters with 128-byte alignment has changed in GCC 4.6 gcc: error: testcase.c: -fcompare-debug failure (length) Generated code is different with/without -g. Tested revisions: r170243 - fail 4.5 r170013 - fail
[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47774 Adam Butcher changed: What|Removed |Added CC||jason at gcc dot gnu.org See Also||http://gcc.gnu.org/bugzilla ||/show_bug.cgi?id=46472 --- Comment #3 from Adam Butcher 2011-02-17 11:00:01 UTC --- Added Jason to CC and referenced bug 46472. The code stated in 46472 works on current GCC though but the description is similar to this.
[Bug fortran/47778] reading two arrays of structures from namelist fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47778 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org, ||jvdelisle at gcc dot ||gnu.org --- Comment #1 from Tobias Burnus 2011-02-17 10:40:18 UTC --- At line 27 of file test.f90 (unit = 10, file = '/tmp/gfortrantmp2WKkUW') Fortran runtime error: Cannot match namelist object name 2 I get the same error with gfortran 4.1.2 20080704 (Red Hat 4.1.2-48) Thus, it does not seem to be a regression. It works with ifort 11.1, pgf90 10.1-0 and pathscale 3.2.99. * * * type field_descr integer number end type type fsetup type (field_descr) :: vel(1) type (field_descr) :: scal(1) end type &nl_setup" field_setup%vel(1)%number= 3, field_setup%scal(1)%number= 2 / For this variant, the error message for the second line of the namelist is some uninitialized garbage: At line 23 of file foobar.f90 (unit = 10, file = '/tmp/gfortrantmpMxI6TY') Fortran runtime error: L�7� The namelist reading works, if "scal" is a scalar instead of an array. However, if "vel" is a scalar and "scal" an array, it fails - unless one swaps the "vel" and "scal" lines in the input file.
[Bug bootstrap/47779] New: Problem cross-compiling trunk for bfin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47779 Summary: Problem cross-compiling trunk for bfin Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: stuart.hender...@analog.com I'm seeing a failure cross-compiling trunk for Blackfin (bfin-uclinux) with uClibc, and it doesn't appear to have worked for quite some time. My system is x86_64-suse-linux, although that shouldn't be relevant in this case. The first problem I'm seeing is when building unwind-dw2.c. After installing target/uclibc headers for the sysroot, I configure gcc: /home/shender/gnu/toolchain/gcc-4.6/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=bfin-uclinux --prefix=/home/shender/gnu/toolchain/bfin-uclinux --disable-libstdcxx-pch --with-sysroot=/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/runtime --enable-threads=posix --enable-languages=c --disable-threads --disable-libmudflap --disable-libgomp --disable-shared --enable-clocale=generic --disable-symvers --disable-libssp --disable-libffi --disable-libgcj --enable-version-specific-runtime-libs --enable-__cxa_atexit and then make, which fails with: /home/shender/gnu/toolchain/gcc_build-4.6/./gcc/xgcc -B/home/shender/gnu/toolchain/gcc_build-4.6/./gcc/ -B/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/bin/ -B/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/lib/ -isystem /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/include -isystem /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include-g -O2 -mcpu=bf532-none -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../../.././gcc -I/home/shender/gnu/toolchain/gcc-4.6/libgcc -I/home/shender/gnu/toolchain/gcc-4.6/libgcc/. -I/home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc -I/home/shender/gnu/toolchain/gcc-4.6/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc/unwind-dw2.c In file included from /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include/ucontext.h:25:0, from /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include/signal.h:351, from /home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc/config/bfin/linux-unwind.h:31, from /home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc/unwind-dw2.c:333: /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include/sys/ucontext.h:39:3: error: expected identifier before numeric constant make[4]: *** [unwind-dw2.o] Error 1 make[4]: Leaving directory `/home/shender/gnu/toolchain/gcc_build-4.6/bfin-uclinux/bf532-none/libgcc' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/home/shender/gnu/toolchain/gcc_build-4.6/bfin-uclinux/libgcc' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/home/shender/gnu/toolchain/gcc_build-4.6/bfin-uclinux/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/home/shender/gnu/toolchain/gcc_build-4.6' make: *** [all] Error 2 The problem seems to be caused by a change in the generation of tm.h in the following check in: r160579 | rsandifo | 2010-06-10 21:23:43 +0100 (Thu, 10 Jun 2010) | 7 lines gcc/ * configure.ac (tm_include_list): Add insn-constants.h. * configure: Regenerate. * Makefile.in (GTM_H): Move insn-constants.h here from... (TM_H): ...here. * mkconfig.sh: Remove special handling for insn-constants.h. The change moves the inclusion of "insn-constants.h" from being conditional on: #if defined IN_GCC && !defined GENERATOR_FILE && !defined USED_FOR_TARGET to just: #if defined IN_GCC This causes insn-constants.h to be included here which defines various register macros that can then clash with the enum (of registers in the gregset_t array) in uClibc's sys/ucontext.h. Although I've only hit this with bfin, it seems like it could easily hit other architectures.
[Bug fortran/47768] ICE: printing a derived-type variable with proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47768 --- Comment #4 from janus at gcc dot gnu.org 2011-02-17 10:35:04 UTC --- (In reply to comment #3) > Here is a patch for rejecting PPCs: This patch regtests cleanly. Will commit as obvious.
