[Bug c++/10291] error referencing a static local from a local struct in template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10291 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-02 11:05:45 UTC --- This is fixed for 4.8.0. I'm adding the testcase and closing the PR.
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688 --- Comment #13 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-03-02 11:17:48 UTC --- Author: paolo Date: Sat Mar 2 11:17:44 2013 New Revision: 196405 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196405 Log: 2013-03-02 Paolo Carlini paolo.carl...@oracle.com PR c++/52688 * g++.dg/template/static33.C: New. * g++.dg/template/static34.C: Likewise. PR c++/10291 * g++.dg/template/static35.C: New. Added: trunk/gcc/testsuite/g++.dg/template/static33.C trunk/gcc/testsuite/g++.dg/template/static34.C trunk/gcc/testsuite/g++.dg/template/static35.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/10291] error referencing a static local from a local struct in template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10291 --- Comment #11 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-03-02 11:17:48 UTC --- Author: paolo Date: Sat Mar 2 11:17:44 2013 New Revision: 196405 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196405 Log: 2013-03-02 Paolo Carlini paolo.carl...@oracle.com PR c++/52688 * g++.dg/template/static33.C: New. * g++.dg/template/static34.C: Likewise. PR c++/10291 * g++.dg/template/static35.C: New. Added: trunk/gcc/testsuite/g++.dg/template/static33.C trunk/gcc/testsuite/g++.dg/template/static34.C trunk/gcc/testsuite/g++.dg/template/static35.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/10291] error referencing a static local from a local struct in template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10291 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-02 11:19:06 UTC --- Done.
[Bug target/56508] New: [SH] Add support for rtv/n instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56508 Bug #: 56508 Summary: [SH] Add support for rtv/n instruction Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh2a*-*-* The SH2A supports a variant of the classical 'rts' instruction which can shorten function returns: ... some code, result value in r3 ... rts mov r3,r0 on SH2A can be done in one instruction: rtv/n r3
[Bug c/56507] GCC -march=native for Core2Duo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56507 --- Comment #2 from Alexander bratsinot at gmail dot com 2013-03-02 13:49:39 UTC --- (In reply to comment #1) (In reply to comment #0) GCC -march=native includes only flags: -mmmx -msse -msse2 -msse3 -mssse3 but some Core2Duo processors have -msse4 -msse4.1. But yours must not. GCC's -march=native uses cpuid's flags field to see if sse4/sse4.1 is supported. From driver-i386.c: __cpuid (1, eax, ebx, ecx, edx); ... has_sse4_1 = ecx bit_SSE4_1; has_sse4_2 = ecx bit_SSE4_2; ... const char *sse4_2 = has_sse4_2 ? -msse4.2 : -mno-sse4.2; const char *sse4_1 = has_sse4_1 ? -msse4.1 : -mno-sse4.1; I have Core2Duo E8200, this is Wolfdale and this processor include SSE4.1.
[Bug c++/56464] Crashes when using implicit this in a lambda capture in member initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56464 poenitz at htwm dot de changed: What|Removed |Added CC||poenitz at htwm dot de --- Comment #4 from poenitz at htwm dot de 2013-03-02 15:16:54 UTC --- I am afraid I don't understand the process. How can an ice-on-valid-code be a duplicate of a ice-on-invalid-code? Yes, the cause for the crash might technically be the same, but in the other case it might be covered by undefined behaviour, here not.
[Bug rtl-optimization/55757] Suboptimal interrupt prologue/epilogue for ARMv7-M (Cortex-M3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757 Timmy Brolin web at brolinembedded dot se changed: What|Removed |Added CC||web at brolinembedded dot ||se --- Comment #7 from Timmy Brolin web at brolinembedded dot se 2013-03-02 15:23:11 UTC --- (In reply to comment #2) If you really know that you don't need stack-alignment on an M3, then just remove the interrupt attribute. It really doesn't serve any other purpose on M-profile cores other than to cause the stack realignment. What you suggest requires a change in the C-code depending on the processor. That is, one piece of C-code will not compile optimally for different Cortex-M3 revisions without modifications to the C-code itself. This is not good for code which is intended to be used on multiple platforms. Cortex-M3 r0p0 needs the prologue/epilogue. Cortex-M3 r1p0 has a new configuration bit called STKALIGN which when enabled makes the prologue/epilogue unnecessary. (But the default setting is that it still needs the prologue/epilogue) Cortex-M3 r2p0 changed the default setting of STKALIGN so that the prologue/epilogue are unnecessary by default. I would suggest that the prologue/epilogue should be removed by default when compiling for r2p0 or higher, but be kept by default for older revisions. There should also be a compilation switch to manually enable/disable the prologue/epilogue according to the chosen setting of STKALIGN. Interrupts can often be time critical, so ISR entry is probably the worst possible place for extra instructions.
[Bug bootstrap/56509] New: [4.8 regression] gnattols build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56509 Bug #: 56509 Summary: [4.8 regression] gnattols build failure Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org Target: powerpc-*-* ../../xgcc -B../../ -static-libgcc -I- -I../rts -I. -I/daten/gcc/gcc-20130302/gcc/ada -DIN_GCC -O2 -g -W -Wall -static-libstdc++ -static-libgcc -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o makeutl.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o mlib-tgt-specific.o mlib-utl.o namet.o nlists.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o prj-dect.o prj-env.o prj-conf.o prj-pp.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o urealp.o usage.o widechar.o \ targext.o link.o ../../ggc-none.o ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a ../rts/libgnat.a ../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a ../../libcommon-target.a(opts.o): In function `vec_allocchar*': /daten/gcc/gcc-20130302/Build/gcc/../../gcc/vec.h:1303: undefined reference to `operator new(unsigned int)' collect2: error: ld returned 1 exit status make[3]: *** [../../gnatmake] Error 1 make[3]: Leaving directory `/daten/gcc/gcc-20130302/Build/gcc/ada/tools' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/daten/gcc/gcc-20130302/Build/gnattools' make[1]: *** [all-gnattools] Error 2
[Bug bootstrap/56509] [4.8 regression] gnattols build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56509 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2013-03-02 16:10:15 UTC --- Caused by r196305 which added a dependency of opts-common.o on opts.o (for opts_concat). ../../libcommon-target.a(prefix.o) osint.o (update_path) ../../libcommon-target.a(rs6000-common.o) ../../libcommon-target.a(prefix.o) (targetm_common) ../../libcommon-target.a(params.o) ../../libcommon-target.a(rs6000-common.o) (set_default_param_value(compiler_param, int)) ../../libcommon-target.a(options.o) ../../libcommon-target.a(rs6000-common.o) (global_options) ../../libcommon-target.a(hooks.o) ../../libcommon-target.a(rs6000-common.o) (hook_bool_bool_gcc_optionsp_false(bool, gcc_options*)) ../../libcommon-target.a(common-targhooks.o) ../../libcommon-target.a(rs6000-common.o) (default_except_unwind_info(gcc_options*)) ../../libcommon-target.a(opts-common.o) ../../libcommon-target.a(options.o) (handle_generated_option(gcc_options*, gcc_options*, unsigned int, char const*, int, unsigned int, int, unsigned int, cl_option_handlers const*, diagnostic_context*)) ../../libcommon-target.a(vec.o) ../../libcommon-target.a(opts-common.o) (vec_prefix::calculate_allocation(vec_prefix*, unsigned int, bool)) ../../libcommon-target.a(opts.o) ../../libcommon-target.a(opts-common.o) (opts_concat(char const*, ...))
[Bug target/55303] [SH] Add support for clips / clipu instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55303
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-03-02
AssignedTo|unassigned at gcc dot |olegendo at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2013-03-02 16:16:41
UTC ---
Created attachment 29567
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29567
Working patch with a thinko.
This patch, albeit working, has a thinko.
The idea was to reduce the constraints of the clips/clipu insn comparison
constants by adding/subtracting a constant offset value before/after the actual
clipping insn. For example:
int
test_02 (int a)
{
return max (0, min (255, a));
}
becomes:
_test_02:
movi20 #128,r1
sub r1,r4
mov r4,r0
clips.b r0
rts
add r1,r0
The problem with this is that it won't work for values that will wrap-around
before/after the offset subtraction/addition.
E.g. plugging the value 0x8000 (−2147483648) into the above case:
movi20 #128,r1
sub r1,r4 // r4 = 0x8000 - 128 = 0x7F80
mov r4,r0
clips.b r0// !(r0 -128) (r0 127) - r0 = 127
rts
add r1,r0 // r0 = 127 + 128 = 255
// expected result: 0
Maybe this case could be handled by using subv/addv insns to catch
over/underflows somehow, but probably the resulting code would be more complex
(and thus slower) than two straight forward compare-and-branch sequences.
On the other hand, if it is known that the input value is in a certain range
(e.g. a sign/zero extended HImode or QImode), the offset approach should work
fine.
I will modify the attached patch so that it will allow only the HW clip
constants for now.
[Bug target/55303] [SH] Add support for clips / clipu instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55303
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org 2013-03-02 16:23:57
UTC ---
For non-SH2A targets there is an opportunity to generate better insn sequences
for the special case
unsigned int test (unsigned int a)
{
return a 1 ? 1 : a;
}
on SH2A:
tst r4,r4
movrt r0
if zero-displacement branches are not good:
tst r4,r4
mov #-1,r0
negcr0,r0
if zero-displacement branches are good:
tst r4,r4
bt 0f
mov #1,r1
0f:
This can be done by implementing a pattern
(umin:SI (match_operand:SI 1 arith_reg_operand)
(const_int 1))
as it is already done for SH2A in attachment 29567.
[Bug fortran/55789] [4.6/4.7 Regression] Needless realloc with array constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #13 from Mikael Morin mikael at gcc dot gnu.org 2013-03-02 17:22:28 UTC --- (In reply to comment #10) Fixed on trunk. I will have to do a bit more work to determine if the same fix works correctly for 4.6 and 4.7. Any news?
[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2013-03-02 17:25:25 UTC --- (In reply to comment #5) I'll deal with 4.6 and 4.7 tomorrow Friendly reminder... :-)
[Bug c/56507] GCC -march=native for Core2Duo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56507 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-02 17:41:13 UTC --- Can you invoke the following command: cat /proc/cpuinfo
[Bug c++/56312] Firefox 20.0a1 compilation with enabled LTO fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2013-03-02 17:50:06 UTC --- I see, it looks like a bug when computing the boundary then; if folding is possible through the constructor, the symtab node ought to be shipped into the partition.
[Bug debug/56502] entry-value: Missing DW_AT_linkage_name for C-C++ calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56502 --- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com 2013-03-02 18:19:42 UTC --- FAIL: gcc-4.8.0-0.14.fc19.x86_64 FAIL: GNU C++ 4.7.3 20130221 (prerelease) FAIL: GNU C++ 4.8.0 20130302 (experimental)
[Bug c/56507] GCC -march=native for Core2Duo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56507 --- Comment #4 from Alexander bratsinot at gmail dot com 2013-03-02 18:51:35 UTC --- (In reply to comment #3) Can you invoke the following command: cat /proc/cpuinfo I'm terribly sorry, something went wrong (several times), when I executed gcc -march=native -Q --help=target, and -msse4.1 been unchecked.
[Bug c++/56506] variadic class template specialization not selected as best match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506
--- Comment #1 from Michael Mehlich mmehlich at semanticdesigns dot com
2013-03-02 18:55:43 UTC ---
Some more information using a function template instead of a class template:
-- Additional code
templatetypename ... T void foo(YZT...,T...) {
}
int main() {
YZint,bool,char,int yi;
YZint,bool,char,bool yb;
YZint,bool,char,char yc;
foo(yi,yb,yc);
}
-- Error message from gcc 4.7.2:
test.cpp: In function 'int main()':
test.cpp:31:14: error: no matching function for call to 'foo(YZint, bool,
char, int, YZint, bool, char, bool, YZint, bool, char, char)'
test.cpp:31:14: note: candidate is:
test.cpp:15:31: note: templateclass ... T void foo(YZT ..., T...)
test.cpp:15:31: note: template argument deduction/substitution failed:
test.cpp:31:14: note: deduced conflicting types for parameter 'T' ('int,
bool, char' and 'int')
test.cpp:31:14: note: 'YZint, bool, char, int' is not derived from 'YZT
..., T'
It looks like the compiler decides to bind T to int when handling the
first argument instead of binding a prefix of T to int.
[Bug inline-asm/56479] Register allocator can't allocate two 4-byte variables into 8 registers for inline asm on avr-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56479
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Target||avr
Status|UNCONFIRMED |NEW
Keywords||ice-on-valid-code, ra
Last reconfirmed||2013-03-02
CC||gjl at gcc dot gnu.org
Blocks||56183
Ever Confirmed|0 |1
Known to fail||3.4.6, 4.3.3, 4.5.2, 4.6.2,
||4.7.2, 4.8.0
--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-03-02
19:05:47 UTC ---
Confirmed with 4.8 from 2013-03-01 for any optimization level for the
following, smaller test case:
void asmfoo (long x, long y)
{
asm volatile ( :: a(x), a(y));
}
[Bug libmudflap/44661] Link order (?) might cause threaded libmudflap to assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44661 --- Comment #5 from Georg Sauthoff g_sauthoff at web dot de 2013-03-02 20:42:25 UTC --- I can reproduce this issue on Ubuntu 10.04 (gcc 4.4.3). That means: $ gcc -o foo foo.c -fmudflapth -lpthread -lmudflapth $ ./foo - mf: erroneous reentrancy detected in `__mf_check' $ gcc -o foo foo.c -fmudflapth -pthread -lmudflapth $ ./foo - foo 1 On Fedora 17 (x86-64) (gcc 4.7.2) the issue is not present: $ gcc -lpthread -o foo foo.c -fmudflapth -lpthread -lmudflap $ ./foo - foo 1
[Bug libmudflap/44661] Link order (?) might cause threaded libmudflap to assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44661 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-02 20:44:20 UTC --- I bet the issue is that Ubuntu's GCC passes --as-needed by default (non standard really).
[Bug libmudflap/37927] Mudflap : invalid reads when accessing static objects in shared libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37927
--- Comment #4 from Georg Sauthoff g_sauthoff at web dot de 2013-03-02
20:51:07 UTC ---
Can reproduce this with gcc 4.7.2:
$ cat setl.c
#include locale.h
#include stdio.h
#include string.h
int main()
{
char *s = setlocale(LC_ALL, 0);
char buffer[512] = {0};
strcpy(buffer, s);
printf(LC_ALL: %s\n, buffer);
return 0;
}
$ ./setl
***
mudflap violation 1 (check/read): time=1362257386.022152 ptr=0x3e76776aaf
size=2
pc=0x7f033ef2ade1 location=`(strcpy src)'
/lib64/libmudflap.so.0(__mf_check+0x41) [0x7f033ef2ade1]
/lib64/libmudflap.so.0(__mfwrap_strcpy+0x16e) [0x7f033ef2cd2e]
./setl(main+0x6d) [0x4009a9]
number of nearby objects: 0
LC_ALL: C
Not really a bug - but a possibility how to silent those false-positives would
be great.
[Bug c++/56464] Crashes when using implicit this in a lambda capture in member initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56464 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-02 22:20:44 UTC --- That one's easy, it can be both ice-on-valid-code and ice-on-invalid-code If it crashes in the same place and is fixed by the same fix, it's the same bug, no?
[Bug debug/56510] New: adding -g compiles 'forever' vs 49s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 Bug #: 56510 Summary: adding -g compiles 'forever' vs 49s Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: sam-gcc...@rushing.nightmare.com Created attachment 29568 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29568 repro The file is output from another compiler, in CPS form (i.e., all funs are tail calls). If I leave off '-g' it takes 49 seconds to compile (2.4GHz core i7) If I add '-g' it takes 'forever' ( 90 mins). Reproduced on OS X (10.8.2) x86_64, Linux Ubuntu (w/gcc4.6.3), FreeBSD 7.3. I believe this bug affects gcc going back to 4.6 and earlier. I have a copy of 4.2 sitting around that does not seem to have the problem, though. gcc was configured: ./configure --enable-languages=c,c++ built with make -j 16 command: /usr/local/bin/gcc -std=c99 -O3 -g -I./include self/compile.c -o self/compile
[Bug debug/56510] adding -g compiles 'forever' vs 49s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-03 00:10:49 UTC --- Since you are building the trunk you should do timings only when configure with --enable-checking=release as by default on the trunk, some extra checking is enabled.
[Bug debug/56510] adding -g compiles 'forever' vs 49s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 --- Comment #2 from Sam Rushing sam-gccbug at rushing dot nightmare.com 2013-03-03 00:48:51 UTC --- I recompiled with --enable-checking=release, but I couldn't see any difference. I've attached to the process with gdb and it appears to be stuck forever in cselib.c, often in cselib_lookup().
[Bug debug/56510] adding -g compiles 'forever' vs 49s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2013-03-03 00:57:04 UTC --- Can you add a few options and report back the reports? You can add -ftime-report to the command line to let the compiler dump a report about how much time it spent in different parts of the compiler. With your observation about cselib, I suspect this is another issue with the scalability of var-tracking. Can you try with -g -fno-var-tracking?
[Bug debug/56510] adding -g compiles 'forever' vs 49s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-03 Ever Confirmed|0 |1
[Bug debug/56510] adding -g compiles 'forever' vs 49s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 --- Comment #4 from Sam Rushing sam-gccbug at rushing dot nightmare.com 2013-03-03 01:19:30 UTC --- That did the trick... -fno-var-tracking fixes the issue.
[Bug c++/56485] [cilkplus] internal compiler error: in cdtor_comdat_group, at cp/optimize.c: 186
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56485 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored -Wundef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Markus F.X.J. Oberhumer markus at oberhumer dot com changed: What|Removed |Added CC||markus at oberhumer dot com --- Comment #2 from Markus F.X.J. Oberhumer markus at oberhumer dot com 2013-03-03 04:09:42 UTC --- Still NOT fixed in gcc-4.8-20130210.
[Bug tree-optimization/56145] [4.8 Regression] Use of too much optimizations -O2 -ffast-math -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56145 --- Comment #5 from Vincent vchou79 at gmail dot com 2013-03-03 05:00:12 UTC --- The problem started with (ppl changeover to isl) this revision http://gcc.gnu.org/viewcvs?view=revisionrevision=189156
[Bug rtl-optimization/56511] New: memcpy misses chance to use AVX instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56511
Bug #: 56511
Summary: memcpy misses chance to use AVX instructions
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
When operating on sufficiently aligned storage, memcpy should be able to use
vector instructions.
$ cat test.c
#include string.h
typedef float vec __attribute__((vector_size(32)));
typedef struct S {
vec v;
char __attribute__((aligned(__alignof__(vec c[sizeof(vec)];
} S;
void assign_vec(S* s, const vec* v) { s-v = *v; }
void memcpy_vec(S* s, const vec* v) { memcpy(s-v, v, sizeof(vec)); }
void memcpy_char(S* s, const vec* v) { memcpy(s-c, v, sizeof(vec)); }
$ gcc -mavx -S test.c -O2 -Wall -o -
.file test.c
.text
.p2align 4,,15
.globl assign_vec
.type assign_vec, @function
assign_vec:
.LFB12:
.cfi_startproc
vmovaps (%rsi), %ymm0
vmovaps %ymm0, (%rdi)
vzeroupper
ret
.cfi_endproc
.LFE12:
.size assign_vec, .-assign_vec
.p2align 4,,15
.globl memcpy_vec
.type memcpy_vec, @function
memcpy_vec:
.LFB13:
.cfi_startproc
movq(%rsi), %rax
movq%rax, (%rdi)
movq8(%rsi), %rax
movq%rax, 8(%rdi)
movq16(%rsi), %rax
movq%rax, 16(%rdi)
movq24(%rsi), %rax
movq%rax, 24(%rdi)
ret
.cfi_endproc
.LFE13:
.size memcpy_vec, .-memcpy_vec
.p2align 4,,15
.globl memcpy_char
.type memcpy_char, @function
memcpy_char:
.LFB14:
.cfi_startproc
movq(%rsi), %rdx
movq%rdx, 32(%rdi)
movq8(%rsi), %rdx
movq%rdx, 40(%rdi)
movq16(%rsi), %rdx
movq%rdx, 48(%rdi)
movq24(%rsi), %rdx
movq%rdx, 56(%rdi)
ret
.cfi_endproc
.LFE14:
.size memcpy_char, .-memcpy_char
I don't have a gcc-4.8 around to test with, but I believe it's also missing
this optimization.
[Bug rtl-optimization/56511] memcpy misses chance to use AVX instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56511 --- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2013-03-03 06:19:57 UTC --- LLVM catches this optimization.
[Bug target/56511] memcpy misses chance to use AVX instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56511 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Component|rtl-optimization|target --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-03 06:50:09 UTC --- This is a target specific optimization. PPC uses VMX/altivec for all of these already.
