[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191 --- Comment #13 from Jakub Jelinek 2011-06-26 07:58:23 UTC --- Author: jakub Date: Sun Jun 26 07:57:30 2011 New Revision: 175408 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175408 Log: 2011-06-26 Jakub Jelinek PR tree-optimization/48377 * gcc.dg/vect/pr48377.c: Add dg-require-effective-target non_strict_align. 2011-06-26 Steve Ellcey PR middle-end/49191 * lib/target-supports.exp (check_effective_target_non_strict_align): New. * gcc.dg/memcpy-3.c: Add dg-require-effective-target non_strict_align. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/memcpy-3.c trunk/gcc/testsuite/gcc.dg/vect/pr48377.c trunk/gcc/testsuite/lib/target-supports.exp
[Bug tree-optimization/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #46 from Jakub Jelinek 2011-06-26 07:58:18 UTC --- Author: jakub Date: Sun Jun 26 07:57:30 2011 New Revision: 175408 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175408 Log: 2011-06-26 Jakub Jelinek PR tree-optimization/48377 * gcc.dg/vect/pr48377.c: Add dg-require-effective-target non_strict_align. 2011-06-26 Steve Ellcey PR middle-end/49191 * lib/target-supports.exp (check_effective_target_non_strict_align): New. * gcc.dg/memcpy-3.c: Add dg-require-effective-target non_strict_align. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/memcpy-3.c trunk/gcc/testsuite/gcc.dg/vect/pr48377.c trunk/gcc/testsuite/lib/target-supports.exp
[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445 Mark A. Gibbs changed: What|Removed |Added CC||indi.in.the.wired at gmail ||dot com --- Comment #6 from Mark A. Gibbs 2011-06-26 08:37:09 UTC --- (In reply to comment #5) > You are right, I thought it worked for all fundamental types but reviewing the > proposal [1] makes me realise I was wrong. It remains unclear wether user > defined enums should work ... According to 29.5.1 in the draft standard i have (n3242): "There is a generic class template atomic. The type of the template argument T shall be trivially copyable (3.9)." That wording is in several older drafts, too, going back to at least March 2010, so it's not new and probably won't change. So it *should* work for all fundamental types, and even user-defined types (classes) provided they're trivially copyable. Both float and scoped enums are trivially copyable, so atomic and atomic should work. What the standard says about integral types is just that specializations already exist for them (like specialization atomic exists, and publicly inherits from atomic_int).
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #8 from Georg-Johann Lay 2011-06-26 09:57:36 UTC --- *** Bug 49530 has been marked as a duplicate of this bug. ***
[Bug target/49530] Segmentation fault with -mint8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49530 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Georg-Johann Lay 2011-06-26 09:57:36 UTC --- Bug already closed as WONTFIX *** This bug has been marked as a duplicate of bug 46261 ***
[Bug debug/49407] unusable debuginfo for dll-imported functions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49407 Pawel Sikora changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Pawel Sikora 2011-06-26 10:48:46 UTC --- finally, not a bug. i've missed gdb warning: Could not load shared library symbols for 5 libraries, e.g. C:\Windows\system32\ntdll.dll. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? (gdb) info sharedlibrary >FromTo Syms Read Shared Object Library No C:\Windows\system32\ntdll.dll No C:\Windows\syswow64\kernel32.dll No C:\Windows\syswow64\KernelBase.dll No C:\Windows\syswow64\msvcrt.dll No D:\mingw.tests\d.dll setting solib-search-path fixes the issue.
[Bug c++/49525] [4.4] wrong code and wrong warning for bitfield related operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49525 --- Comment #11 from Marcin Ślusarz 2011-06-26 12:48:05 UTC --- Ok, you are right. I didn't know about these patches. Now I compiled gcc-4.4.5 with "vanilla" USE flag - which disables all these patches - and it still fails at runtime.
[Bug debug/49532] New: Dwarf Error: wrong version in compilation unit header (is 1024, should be 2, 3, or 4) [in module D:\mingw.tests\l.dll]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49532 Summary: Dwarf Error: wrong version in compilation unit header (is 1024, should be 2, 3, or 4) [in module D:\mingw.tests\l.dll] Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net Target: i686-pc-mingw32 loading m.exe into ming32/gdb.exe ends with undebuggable l.dll: (...) Error while reading shared library symbols for D:\mingw.tests\l.dll: Dwarf Error: wrong version in compilation unit header (is 1024, should be 2, 3, or 4) [in module D:\mingw.tests\l.dll] (gdb) info sharedlibrary >FromTo Syms Read Shared Object Library 0x77841000 0x779a5d24 Yes (*) C:\Windows\system32\ntdll.dll 0x76e71000 0x76f6bd50 Yes (*) C:\Windows\syswow64\kernel32.dll 0x75c51000 0x75c95982 Yes (*) C:\Windows\syswow64\KernelBase.dll 0x768f1000 0x7699b2bc Yes (*) C:\Windows\syswow64\msvcrt.dll 0x62a81000 0x62a96ab4 No D:\mingw.tests\l.dll 0x6fc41000 0x6fd1e218 Yes D:\mingw.tests\libstdc++-6.dll 0x6cec1000 0x6cedd4bc Yes D:\mingw.tests\libgcc_s_sjlj-1.dll 0x76c41000 0x76d24198 Yes (*) C:\Windows\syswow64\user32.dll 0x75af1000 0x75b6292c Yes (*) C:\Windows\syswow64\gdi32.dll 0x74f91000 0x74f992f8 Yes (*) C:\Windows\syswow64\lpk.dll 0x759e1000 0x75a7c9fc Yes (*) C:\Windows\syswow64\usp10.dll 0x753c1000 0x7545f04c Yes (*) C:\Windows\syswow64\advapi32.dll 0x75461000 0x75478ed8 Yes (*) C:\Windows\SysWOW64\sechost.dll 0x75711000 0x757e5e04 Yes (*) C:\Windows\syswow64\rpcrt4.dll 0x74f31000 0x74f721f0 Yes (*) C:\Windows\syswow64\sspicli.dll 0x74f21000 0x74f2b474 Yes (*) C:\Windows\syswow64\cryptbase.dll 0x75bd1000 0x75c11ce0 Yes (*) C:\Windows\SysWOW64\imm32.dll 0x76da1000 0x76e6bebc Yes (*) C:\Windows\syswow64\msctf.dll (*): Shared library is missing debugging information.
[Bug debug/49532] Dwarf Error: wrong version in compilation unit header (is 1024, should be 2, 3, or 4) [in module D:\mingw.tests\l.dll]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49532 --- Comment #1 from Pawel Sikora 2011-06-26 13:19:26 UTC --- testcase: http://pluto.agmk.net/mingw/tls-test.boost.tar.bz2
[Bug c++/49051] [C++0x] Doesn't SFINAE away an invalid substitution into toplevel parameter type "T[N]"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051
--- Comment #5 from Johannes Schaub
2011-06-26 13:40:34 UTC ---
(In reply to comment #4)
> Hmm, the example in 14.8.2p8 does seem to contradict my interpretation of the
> normative wording. I'll raise this with core.
A related question, if in the end we in fact don't SFINAE or error out with
"T[N]" is, whether substitution for "N" is done at all. Because the type would
be "T*", not "T[N]" anymore.
template
void f(char[T::size]);
int main() { f(); }
Does the substitution succeed?
[Bug c++/49528] [4.6/4.7 regression] g++ fails to destroy temporary object when subobject is used to initialize a reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49528 --- Comment #2 from Jason Merrill 2011-06-26 14:00:37 UTC --- Author: jason Date: Sun Jun 26 14:00:33 2011 New Revision: 175409 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175409 Log: PR c++/49528 * semantics.c (potential_constant_expression_1): A TARGET_EXPR with a cleanup isn't constant. (cxx_eval_constant_expression): Likewise. * init.c (expand_default_init): Use maybe_constant_init. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-cleanup.C trunk/gcc/testsuite/g++.dg/init/ref19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/49445] Undefined reference to std::atomic "operator float"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49445 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW Severity|major |normal --- Comment #7 from Jonathan Wakely 2011-06-26 14:06:49 UTC --- Yup, it should work, but it's not fully implemented yet Severity is not "major" though, it's a missing feature in the experimental C++0x mode, let's not pretend it's a serious problem for anyone.
[Bug libstdc++/49506] reusing a file stream object will always get eof after openning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49506 --- Comment #2 from Jonathan Wakely 2011-06-26 15:36:45 UTC --- This was DR 409, which wasn't resolved when GCC 3.3 was released http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3286.html#409
[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #12 from Iain Sandoe 2011-06-26 16:25:32 UTC --- Author: iains Date: Sun Jun 26 16:25:29 2011 New Revision: 175410 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175410 Log: PR target/47997 * config/darwin.c (darwin_mergeable_string_section): Place string constants in '.cstring' rather than '.const' when CF/NSStrings are active. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c
[Bug c++/46400] g++ Segmentation Fault on heavily templated project.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46400 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #12 from Jakub Jelinek 2011-06-26 16:52:03 UTC --- Fixed. I'll adjust chain_next to use inline as requested by rth as a follow-up.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
Iain Sandoe changed:
What|Removed |Added
Target|powerpc-apple-darwin9.8.0 |*-apple-darwin{8,9,10}
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.06.26 17:37:00
Component|bootstrap |target
CC||dominiq at lps dot ens.fr
Host|powerpc-apple-darwin9.8.0 |*-apple-darwin{8,9,10}
AssignedTo|unassigned at gcc dot |iains at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
Summary|libstdc++ (dylib) is built |gcc emits frame (epilogue)
|with an erroneous |info incompatible with the
|dependency towards /usr/lib |darwin
||{8,9}-unwinder,10-compacter
Build|powerpc-apple-darwin9.8.0 |*-apple-darwin{8,9,10}
--- Comment #16 from Iain Sandoe 2011-06-26 17:37:00
UTC ---
This bug has been around since part way through 4.5.
Unfortunately, it is somewhat hidden in the test-suite since the latter
interposes the newly-built libgcc ahead of the system version (because
DYLD_LIBRARY_PATH is set to point to ./gcc, of necessity).
There are two steps needed to deal with this fully:
(a) fix things so we don't emit epilogue info in unwind frames for darwin 8,9
and 10 (compacter).
The patch currently attached is OK on 4.6.x - but the emitting of unwind frames
has been recently vec-ified which means it will need some re-work for trunk.
(b) fix the darwin libgcc build process so that we only export the _ext symbols
from newly-built libgcc when this is only supporting the ext.
* (b) will also solve the library ordering issues when -{force}_flat_namespace
is used.
I have another patch in progress that is a first attempt at (b) - (not yet
ready to post).
[Bug tree-optimization/49094] ARM aligned(1) attribute is sometimes dropped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49094 --- Comment #5 from Martin Jambor 2011-06-26 18:25:16 UTC --- I have submitted a fix for this bug to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01941.html
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
Georg-Johann Lay changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|RESOLVED|NEW
Last reconfirmed||2011.06.26 19:41:11
Resolution|WONTFIX |
Ever Confirmed|0 |1
Known to fail||4.5.2, 4.6.1
--- Comment #9 from Georg-Johann Lay 2011-06-26
19:41:11 UTC ---
(In reply to comment #1)
> The -mint8 option also does not work with building avr-libc. There has been
> discussion (on the avr-gcc-list mailing list) about eventually removing this.
> There has been no interest by the AVR port maintainers (that I'm aware of) in
> continuing to maintain this switch.
>
> Closed as WONTFIX.
I strongly oppose the WON'T FIX.
Either we keep that option and is is functional.
Or we keep it and say sorry("-mint8 is discontinued") when it is used.
Or we remove it.
By no means the compiler is supposet to run into ICE/segfault, so allow me to
reopen this issue.
[Bug other/49533] New: Firefox profiled build issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533 Summary: Firefox profiled build issues Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de Created attachment 24602 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24602 ipa-pure-const.c fix The latest Firefox from http://hg.mozilla.org/mozilla-central/ fails to build during a profiled-build. /usr/bin/python2.7 /var/tmp/mozilla-central/js/src/config/pythonpath.py -I../config /var/tmp/mozilla-central/js/src/config/expandlibs_exec.py --uselist -- c++ -o js -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native -ffunction-sections -fdata-sections -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-generate -O3 js.o jsworkers.o -lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory,--gc-sections,--icf=all,--icf-iterations=3 -fprofile-generate -Wl,-rpath-link,/bin -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/lib -L../../../dist/bin -L../../../dist/lib -L/var/tmp/mozilla-central/moz-build-dir/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../editline/libeditline.a ../libjs_static.a -ldl /var/tmp/mozilla-central/moz-build-dir/js/src/shell/jsworkers.o:jsworkers.cpp:function js::workers::Worker::processOneEvent(): warning: relocation refers to discarded section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: hidden symbol 'JSAutoRequest::~JSAutoRequest()' is not defined locally /var/tmp/mozilla-central/moz-build-dir/js/src/shell/jsworkers.o:jsworkers.cpp:function js::workers::ThreadPool::start(JSContext*): warning: relocation refers to discarded section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: hidden symbol 'JSAutoSuspendRequest::JSAutoSuspendRequest(JSContext*)' is not defined locally ../libjs_static.a(jsapi.o):jsapi.cpp:function StartRequest(JSContext*): warning: relocation refers to discarded section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: hidden symbol 'js::AutoLockGC::~AutoLockGC()' is not defined locally ../libjs_static.a(jsapi.o):jsapi.cpp:function StopRequest(JSContext*): warning: relocation refers to discarded section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: hidden symbol 'js::AutoLockGC::~AutoLockGC()' is not defined locally ../libjs_static.a(jsapi.o):jsapi.cpp:function JS_ConvertArgumentsVA: warning: relocation refers to discarded section ... This is caused by commit 8c1fce46fc and the attached patch fixes this. Even with this patch applied, libxul fails to link later: usr/bin/python2.7 /var/tmp/mozilla-central/config/pythonpath.py -I../../config /var/tmp/mozilla-central/config/expandlibs_exec.py --uselist -- c++ -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native -ffunction-sections -fdata-sections -fno-strict-aliasing -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-generate -O3 -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsRDFResource.o -lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory,--gc-sections,--icf=all,--icf-iterations=3 -fprofile-generate -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin -Wl,-rpath-link,/usr/lib ../../toolkit/xre/libxulapp_s.a ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libstartupcache.a ../../staticlib/components/libpref.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libgkgfx.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libcomposer.a ../../staticlib/components/libjetpack_s.a ../../staticlib/components/libtelemetry.a ../../staticlib/components/libjsctypes.a ../../staticlib/components/libjsperf.a ../../staticlib/components/libgkplugin.a ../../staticlib/componen
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #106 from Markus Trippelsdorf 2011-06-26 19:50:20 UTC --- I've opened a new bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533 with a patch that fixes the issue seen in Comment 99.
[Bug java/49534] New: gcj segfaults on a program from stdin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49534
Summary: gcj segfaults on a program from stdin
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: radf...@blackbean.org
The following command
echo 'class Hello {public static void main(String[] args)
{System.out.println("hello, world");}}' | gcj -x java --main=Hello - -o Hello
gives
jc1: warning: no input file specified
jc1: internal compiler error: Segmentation fault
The equivalent C program works when piped to gcc.
[Bug target/49468] SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
Oleg Endo changed:
What|Removed |Added
Attachment #24560|0 |1
is obsolete||
--- Comment #4 from Oleg Endo 2011-06-26 20:48:19 UTC
---
Created attachment 24603
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24603
Proposed patch
Thanks for checking.
I missed to tell the expanders that the T bit is clobbered by insns such as
negdi2 and abssi2 / absdi2. The negdi2 expander that I have changed caused the
libstdc++ tests to fail when formatting a -1LL.
Another (reduced) example:
long long x (long long i, int j, long long k)
{
if (j & 5)
return -i;
return -k;
}
..ended up as (the "j & 5" got lost)...
mov.l@(4,r15),r1
clrt
mov.l@r15,r2
negcr1,r1
negcr2,r0
bt/s.L8
clrt
negcr5,r1
negcr4,r0
.L8:
rts
nop
[Bug libstdc++/49269] wifstream::tellg reports invalid stream position after reading single wchar_t character with NullCodecvt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49269 --- Comment #1 from Michael Kochetkov 2011-06-26 21:04:34 UTC --- Created attachment 24604 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24604 UCS2 encoded sample file for the test case samples.txt is the ucs2 encoded text file for the test case.
[Bug middle-end/49439] [4.7 Regression] 471.omnetpp in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49439 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from H.J. Lu 2011-06-26 21:31:46 UTC --- Fixed as of revision 175371.
[Bug libstdc++/49269] wifstream::tellg reports invalid stream position after reading single wchar_t character with NullCodecvt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49269 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini 2011-06-26 22:30:15 UTC --- Granted, the Standard leaves quite a bit of room for implementation defined behavior in this area, but for sure this codecvt is not going to work with our implementation for what you want (and never did). First, do_always_noconv returns true, thus you are already screwed, because this implies that all the other codecvt members will not be used at all. Even if you fix that, do_in still needs work, because, still according to the standard, if it returns noconv, it means _To and _E are the same type, something certainly not true here.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #5 from Oleg Endo 2011-06-26 22:30:05 UTC
---
> Yes, that peephole doesn't catch all the patterns which could
> make tst #imm8,r0 use. Perhaps it would be a good idea to get
> numbers for the test like CSiBE test with the vanilla and new
> insns/peepholes patched compilers. Something covers 80% of
> the possible cases in the usual working set, it would be enough
> successful for such a micro-optimization, I guess.
I'd also like to see some numbers on those micro-improvements. I'll have a look
at CSiBE.
Anyway, why not just add all the currently known-to-work cases? What are your
concerns regarding that? I can imagine that it is a maintenance burden to keep
all those definitions and special cases in the MD up-to-date (bit rot etc). Do
you have anything other than that in mind?
It seems that others have been trying to solve the same problem in a very
similar way: http://patchwork.ozlabs.org/patch/58832/ ;)
I've figured that the following pattern works quite well for this particular
case. It seems to catch all the bit patterns. (sh_tst_const_ok and
sh_zero_extract_val are added functions in sh.c)
(define_insn_and_split "*tstsi3"
[(set (reg:SI T_REG)
(zero_extract:SI (match_operand:SI 0 "arith_reg_operand" "")
(match_operand:SI 1 "const_int_operand")
(match_operand:SI 2 "const_int_operand")))]
"TARGET_SH1 && sh_tst_const_ok (sh_zero_extract_val (operands[1],
operands[2]))"
"#"
"&& 1"
[(const_int 0)]
"{
int tstval = sh_zero_extract_val (operands[1], operands[2]);
emit_insn (gen_tstsi (operands[0], GEN_INT (tstval)));
DONE;
}"
)
...however, the problem with that one is that the T bit is inverted afterwards,
and thus the following branch logic (or whatever) gets inverted as well. One
option could be to emit some T bit inversion insn after gen_tstsi and then
optimize it away later on with e.g. a peephole (?), but I haven't tried that
yet.
The actual "problem" is that the combine pass first sees the andsi, eq, ...
insns and correctly matches them to those in the MD. But instead of continuing
to match patterns from the MD it expands the and insn into something like
zero_extract, which in turn will never be combined back into the tst insn.
Isn't there a way to tell the combine pass not to do so, but instead first look
deeper at what is in the MD?
Regarding the peephole:
> (satisfies_constraint_I08 (operands[1])
> || satisfies_constraint_K08 (operands[1])
I guess this might generate wrong code for e.g. "if (x & -2)". When x has any
bits[31:1] set this must return true. The code after the peephole optimization
will look only at the lower 8 bits and would possibly return false for x =
0xFF00, which is wrong. So it should be satisfies_constraint_K08 only,
shouldn't it?
>
> Cost patch looks fine to me. Could you propose it as a separate
> patch on gcc-patches list with an appropriate ChangeLog entry?
> When proposing it, please refer how you've tested it. Also
> the numbers got with the patch are highly welcome.
>
> BTW, do you have FSF copyright assignment for your GCC work?
> Although the cost patch itself is essentially several lines which
> doesn't require copyright assignment, the other changes you've
> proposed clearly require the paper work, I think.
I'll contact you directly regarding that.
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #12 from Paolo Carlini 2011-06-26 22:39:20 UTC --- Dave, do you have an opinion about this issue? I'm tempted to close it as WONTFIX, frankly, I don't think we want to go beyond the #undefs we already have got in c++config, I would even do less (but probably code is already relying on that),
[Bug c/49535] New: __builtin_object_size incorrect for array arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49535
Summary: __builtin_object_size incorrect for array arguments
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mse...@gmail.com
When compiled with gcc 4.4 and 4.5 (at -O1 or above) the program below prints
the following output:
800 800 800 800
800 800 800 800
800 800 800 800
800 800 800 800
When compiled with 4.6 (regardless of the -O setting) it prints this instead:
800 800 800 800
18446744073709551615 18446744073709551615 0 0
18446744073709551615 18446744073709551615 0 0
18446744073709551615 18446744073709551615 0 0
I believe the first output is expected and the second is wrong.
extern int printf (const char* fmt, ...);
#define BOS(a) \
printf ("%zu %zu %zu %zu\n", \
__builtin_object_size (a, 0), \
__builtin_object_size (a, 1), \
__builtin_object_size (a, 2), \
__builtin_object_size (a, 3))
inline void f0 (int *a) { BOS (a); }
inline void f1 (int a[20]) { BOS (a); }
inline void f2 (int a[10][20]) { BOS (a); }
int main (void) {
int a[10][20];
BOS (a);
f0 (a[0]);
f1 (a[0]);
f2 (a);
}
[Bug middle-end/49536] New: latent bug in FSF gcc with creation of vector of arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49536
Summary: latent bug in FSF gcc with creation of vector of
arrays
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu
Duncan Sands has determined that http://llvm.org/bugs/show_bug.cgi?id=10042
exposes a bug in FSF gcc where vectors of arrays are being created. He proposes
that the following patch to FSF gcc exposes the latent issue...
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c(revision 174743)
+++ tree-vect-data-refs.c(working copy)
@@ -2734,6 +2734,10 @@
scalar_type = TREE_TYPE (DR_REF (dr));
STMT_VINFO_VECTYPE (stmt_info) =
get_vectype_for_scalar_type (scalar_type);
+ gcc_assert(!STMT_VINFO_VECTYPE (stmt_info) ||
+ TREE_CODE (STMT_VINFO_VECTYPE (stmt_info)) != VECTOR_TYPE ||
+ TREE_CODE (TREE_TYPE (STMT_VINFO_VECTYPE (stmt_info)))
+ != ARRAY_TYPE);
if (!STMT_VINFO_VECTYPE (stmt_info))
{
if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
by triggering an assertion failure when the tree-vectorizer tries to form a
vector of arrays.
[Bug debug/49537] New: cross-check DW_AT_name vs. demangling of linkage names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49537 Summary: cross-check DW_AT_name vs. demangling of linkage names Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.kratoch...@redhat.com CC: do...@gcc.gnu.org PR debug/49408 shows DW_AT_name "K<&S::m>" vs. demangled DW_AT_MIPS_linkage_name prefix "K<&(S::m(int))>". This was due to a bug in libiberty/cp-demangle.c. http://gcc.gnu.org/ml/gcc/2011-06/msg00308.html On Wed, Jun 22, 2011 at 10:42 AM, Jason Merrill wrote: > Well, the basic issue is that the "linkage name" is produced > by libiberty/cp-demangle.c and the DW_AT_name is produced by gcc/cp/error.c, > and they don't always agree on the same pretty-printed representation > of a C++ expression. Therefore I believe there could be compile time sanity cross-check with ICE in such cases, maybe more such bugs exist there already.
[Bug c++/49528] [4.6 regression] g++ fails to destroy temporary object when subobject is used to initialize a reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49528 --- Comment #3 from Jason Merrill 2011-06-27 01:07:38 UTC --- Author: jason Date: Mon Jun 27 01:07:34 2011 New Revision: 175417 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175417 Log: PR c++/49528 * semantics.c (potential_constant_expression_1): Check for non-literality rather than cleanup. (cxx_eval_constant_expression): Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-cleanup.C
[Bug c++/49440] [4.5/4.6/4.7 regression] Invalid dynamic_cast for unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49440 --- Comment #5 from Jason Merrill 2011-06-27 01:13:36 UTC --- Author: jason Date: Mon Jun 27 01:13:33 2011 New Revision: 175418 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175418 Log: PR c++/49440 * class.c (set_linkage_according_to_type): Hand off to determine_visibility. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/rtti/anon-ns1.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/class.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug c++/49440] [4.6 regression] Invalid dynamic_cast for unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49440 Jason Merrill changed: What|Removed |Added Target Milestone|--- |4.5.4
[Bug testsuite/49529] FAIL: gcc.dg/ipa/ipa-pta-17.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49529 --- Comment #2 from John David Anglin 2011-06-27 03:13:58 UTC --- Author: danglin Date: Mon Jun 27 03:13:55 2011 New Revision: 175420 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175420 Log: PR testsuite/49529 * gcc.dg/ipa/ipa-pta-17.c: Use dg-require-alias. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-17.c
[Bug testsuite/49529] FAIL: gcc.dg/ipa/ipa-pta-17.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49529 --- Comment #3 from John David Anglin 2011-06-27 03:23:15 UTC --- Dominique, if the failure is resolved on darwin, please close.
[Bug c++/45923] constexpr diagnostics, more more
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.27 04:09:51 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #6 from Kazumoto Kojima 2011-06-27 05:14:36 UTC --- (In reply to comment #5) > Anyway, why not just add all the currently known-to-work cases? What are your > concerns regarding that? I can imagine that it is a maintenance burden to keep > all those definitions and special cases in the MD up-to-date (bit rot etc). Do > you have anything other than that in mind? Yep, maintenance burden but I don't mean ack/nak for anything. If it's enough fruitful, we should take that route. When it gives 5% improvement in the usual working set like as CSiBE, hundreds lines would be OK, but if it's ~0.5% or less, it doesn't look worth to add many patterns for that. > Isn't there a way to tell the combine pass not to do so, but instead first > look > deeper at what is in the MD? I don't know how to do it cleanly. > I guess this might generate wrong code for e.g. "if (x & -2)". When x has any > bits[31:1] set this must return true. The code after the peephole optimization > will look only at the lower 8 bits and would possibly return false for x = > 0xFF00, which is wrong. So it should be satisfies_constraint_K08 only, > shouldn't it? You are right. That peephole was simply 'something like this'.
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
--- Comment #10 from Eric Weddington
2011-06-27 05:43:20 UTC ---
Hi All,
Johann is correct in his comment to bug #46261 (below).
The -mint8 compiler switch is now causing the compiler to give an ICE.
We need to finally make a decision from one of these options:
1. Fix ICE, leave -mint8 in the compiler, don't do anything with avr-libc, even
though avr-libc doesn't build with it.
2. Fix ICE, leave -mint8 in the compiler, work on avr-libc to also build with
-mint8 (eventually).
3. Remove -mint8, because avr-libc will never be changed to work with it.
Or suggest an alternative option.
Personally, I vote for #3. What's your option?
Thanks,
Eric Weddington
> -Original Message-
> From: gjl at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org]
> Sent: Sunday, June 26, 2011 1:42 PM
> To: Weddington, Eric
> Subject: [Bug target/46261] avr-gcc: Segfaults when compiled with the -
> mint8 option
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
>
> Georg-Johann Lay changed:
>
>What|Removed |Added
> --
> --
>Keywords||ice-on-valid-code
> Status|RESOLVED|NEW
>Last reconfirmed||2011.06.26 19:41:11
> Resolution|WONTFIX |
> Ever Confirmed|0 |1
> Known to fail||4.5.2, 4.6.1
>
> --- Comment #9 from Georg-Johann Lay 2011-06-26
> 19:41:11 UTC ---
> (In reply to comment #1)
> > The -mint8 option also does not work with building avr-libc. There has
> been
> > discussion (on the avr-gcc-list mailing list) about eventually removing
> this.
> > There has been no interest by the AVR port maintainers (that I'm aware
> of) in
> > continuing to maintain this switch.
> >
> > Closed as WONTFIX.
>
> I strongly oppose the WON'T FIX.
>
> Either we keep that option and is is functional.
> Or we keep it and say sorry("-mint8 is discontinued") when it is used.
> Or we remove it.
>
> By no means the compiler is supposet to run into ICE/segfault, so allow me
> to
> reopen this issue.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
[Bug target/49468] SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
--- Comment #5 from Kazumoto Kojima 2011-06-27
06:39:40 UTC ---
Argh, I also missed clobbers. Looks fine to me now, except
that insn_and_split "*negdi2" forgot to set constraints and
some minor coding style issues below.
The first comment should be started with a capital letter and
ended with a period. Also please follow GCC C coding style
even for C program segments in .md file. C lines in the patch
are started with a tab instead of 2 spaces. A long conditional
should be broken like as
(cond
? value0
: value1)
instead of
(cond ?
value0 :
value1)
Please use braces
"
{
int low_word = ...
...
emit_insn (...
DONE;
}")
instead of
"
int low_word = ...
...
emit_insn (...
DONE;
")
especially when new variables are used, though those braces
aren't required with the current gen* tools.
> + emit_insn (gen_negsi_cond (operands[0], operands[1], operands[1],
> + GEN_INT (1)));
The first line has an extra space after the last comma and
the indentation of the 2nd line doesn't match with GCC coding
standard. BTW, you could use const[01]_rtx for GEN_INT ([01]):
emit_insn (gen_negsi_cond (operands[0], operands[1], operands[1],
const1_rtx));
There are similar extra white space + broken indentation issues:
> +(define_insn_and_split "negsi_cond"
> + [(set (match_operand:SI 0 "arith_reg_dest" "=r,r")
> + (if_then_else:SI (eq:SI (reg:SI T_REG)
> + (match_operand:SI 3
> "const_int_operand" "M,N"))
...
> + emit_label_after (skip_neg_label,
> + emit_insn (gen_negsi2
> (operands[0], operands[1])));
...
Perhaps mail or editor problem?
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #11 from chertykov at gmail dot com 2011-06-27 06:41:24 UTC --- 2011/6/27 Weddington, Eric : > Hi All, > > Johann is correct in his comment to bug #46261 (below). > > The -mint8 compiler switch is now causing the compiler to give an ICE. > > We need to finally make a decision from one of these options: > > 1. Fix ICE, leave -mint8 in the compiler, don't do anything with avr-libc, > even though avr-libc doesn't build with it. > > 2. Fix ICE, leave -mint8 in the compiler, work on avr-libc to also build with > -mint8 (eventually). > > 3. Remove -mint8, because avr-libc will never be changed to work with it. > > Or suggest an alternative option. > > Personally, I vote for #3. What's your option? Let's remove it. Denis.
