[Bug c/57571] linux kernel function memcpy() execute with low efficiency on Intel Ivybridge platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57571 --- Comment #1 from phoenix --- Sorry, correct a description, GCC 4.3.4's configuration is wrong. GCC 4.3.4 Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux Thread model: posix
[Bug target/57571] linux kernel function memcpy() execute with low efficiency on Intel Ivybridge platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57571 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c |target --- Comment #2 from Andrew Pinski --- Can you provide the preprocessed source which is used to generate memcpy here? Are you sure that the kernel is not generating memcpy at runtime?
[Bug target/57571] linux kernel function memcpy() execute with low efficiency on Intel Ivybridge platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57571 --- Comment #3 from phoenix --- 1. "Can you provide the preprocessed source" Sorry,I trace the linux source code, the kernel used __builtin___memcpy() to replace memcpy(). I can't find the __builtin___memcpy() source code in the linux source code. It seems it is processed by GCC. 2. "the kernel is not generating memcpy at runtime?" Could you give me a little explanation about this? Thank you very much!
[Bug target/57571] linux kernel function memcpy() execute with low efficiency on Intel Ivybridge platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57571 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Have you actually measured any slowdown, or you just think that rep movsd must be 8 times faster than rep movsb? If you look at http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf look at 3-91 there, IvyBridge CPUs and higher are supposed to have ERMSB feature where rep movsb is always suppoed to be faster than rep movsd + movsb.
[Bug c++/57509] Segmentation fault when using __builtin_shuffle in templated class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57509 --- Comment #5 from Paolo Carlini --- Detail: normally we just pass around tsubst_flags_ts, no complain & tf_error to bool, etc.
[Bug target/57571] linux kernel function memcpy() execute with low efficiency on Intel Ivybridge platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57571 --- Comment #5 from phoenix --- (In reply to Jakub Jelinek from comment #4) > Have you actually measured any slowdown, or you just think that rep movsd > must be 8 times faster than rep movsb? Yes, actually I first measured the Flash Read(which execute with memcpy()) speed has a sharp down, and then find the kernel memcpy() efficiency problem. After, I test memcpy() with other methods, further confirmed the reuslt.
[Bug c++/57509] Segmentation fault when using __builtin_shuffle in templated class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57509 --- Comment #6 from Marc Glisse --- (In reply to Paolo Carlini from comment #5) > Detail: normally we just pass around tsubst_flags_ts, no complain & tf_error > to bool, etc. Those flags are not available in c-family, this is not the first place where we pass a bool in this case.
[Bug target/57571] linux kernel function memcpy() execute with low efficiency on Intel Ivybridge platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57571 --- Comment #6 from Jakub Jelinek --- Anyway, please see http://gcc.gnu.org/bugs.html, without preprocessed source and gcc options passed to it this report is useless. Also, if it is a memcpy into a hardware device area, perhaps the kernel shouldn't use memcpy for that but some routine optimized for device memory access, the compiler isn't told in any way that it isn't normal memory and all it can do is choose best memcpy strategy for host memory to memory copies.
[Bug c++/57509] Segmentation fault when using __builtin_shuffle in templated class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57509 --- Comment #7 from Paolo Carlini --- I see, I never fiddled with those.
[Bug target/57516] [avr] Incorrect fixed-point rounding result in the overflow case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57516 --- Comment #1 from Georg-Johann Lay --- Created attachment 30282 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30282&action=edit lib1funcs-fixed.S.diff: libgcc part of the patch
[Bug tree-optimization/57322] [4.9 Regression] Segfault at -O1 in build_and_add_sum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57322 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marc Glisse --- Looks like it was fixed just a few days later. Please re-open if I got it wrong.
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541 --- Comment #3 from Balaji V. Iyer --- Hello, This issue should be fixed in trunk revision 199837. Please let me know otherwise. Thanks, Balaji V. Iyer.
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541 --- Comment #4 from Balaji V. Iyer --- Hello, This issue should be fixed in trunk revision 199837. Please let me know otherwise. Thanks, Balaji V. Iyer.
[Bug c++/57572] New: vector operators don't participate in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57572
Bug ID: 57572
Summary: vector operators don't participate in overload
resolution
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
typedef int vec __attribute__((vector_size(4*sizeof(int;
struct A{
operator vec()const;
};
vec f(vec x, A y){
return x
[Bug c++/32081] Conflicting exception specifications not rejected in template specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32081 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org| Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #2 from Paolo Carlini --- Fixed in 4.8.0.
[Bug c++/33677] [DR 80] Member with same name as class is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33677 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org| Known to work||4.7.3, 4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #8 from Paolo Carlini --- 4.5.x implemented the resolution of DR80, thus both test1.cc and test2.cc are accepted.
[Bug c++/37404] ICE on va_arg and template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37404 Paolo Carlini changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code CC|gcc-bugs at gcc dot gnu.org| Target Milestone|--- |4.8.0 --- Comment #2 from Paolo Carlini --- Changing to ice-on-invalid-code. Fixed in 4.8.0 and mainline. I'm adding the testcase and closing the PR.
[Bug c++/37404] ICE on va_arg and template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37404 Paolo Carlini changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #3 from Paolo Carlini --- Constructing a valid variant was easy.
[Bug tree-optimization/57534] [4.8/4.9 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 --- Comment #6 from ncahill_alt at yahoo dot com --- Created attachment 30283 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30283&action=edit Smaller testcase
[Bug c++/37404] ICE on va_arg and template deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37404 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paolo Carlini --- Done.
[Bug rtl-optimization/57568] [4.8/4.9 Regression] wrong code for assignment in conditional at -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57568 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sun Jun 9 18:30:01 2013 New Revision: 199870 URL: http://gcc.gnu.org/viewcvs?rev=199870&root=gcc&view=rev Log: PR target/57568 * config/i386/i386.md (TARGET_READ_MODIFY_WRITE peepholes): Ensure that operands[2] doesn't overlap with operands[0]. * gcc.c-torture/execute/pr57568.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57568.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog Author: jakub Date: Sun Jun 9 18:33:32 2013 New Revision: 199871 URL: http://gcc.gnu.org/viewcvs?rev=199871&root=gcc&view=rev Log: PR target/57568 * config/i386/i386.md (TARGET_READ_MODIFY_WRITE peepholes): Ensure that operands[2] doesn't overlap with operands[0]. * gcc.c-torture/execute/pr57568.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57568.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog Author: jakub Date: Sun Jun 9 18:37:51 2013 New Revision: 199872 URL: http://gcc.gnu.org/viewcvs?rev=199872&root=gcc&view=rev Log: PR target/57568 * config/i386/i386.md (TARGET_READ_MODIFY_WRITE peepholes): Ensure that operands[2] doesn't overlap with operands[0]. * gcc.c-torture/execute/pr57568.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr57568.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/i386.md branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/57291] Failure in build stages 2 and 3 concerning pseudo-op: .balign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57291 ncahill_alt at yahoo dot com changed: What|Removed |Added CC||ncahill_alt at yahoo dot com --- Comment #1 from ncahill_alt at yahoo dot com --- I see from the binutils changelog that .balign was added to the GNU assembler in April 1995, so 18 years ago. Your assembler must be from around that time. I suggest updating binutils to 2.23 or newer if possible. This is a good idea in general and may fix other, yet to be discovered problems. Neil Cahill.
[Bug rtl-optimization/57568] [4.8/4.9 Regression] wrong code for assignment in conditional at -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57568 --- Comment #4 from Dara Hazeghi --- Wow, that was fast! Confirmed fixed, thanks.
[Bug rtl-optimization/57568] [4.8/4.9 Regression] wrong code for assignment in conditional at -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57568 --- Comment #5 from Jakub Jelinek --- Thanks for the report (and other reports).
[Bug c++/57570] Deduction succeeds despite type mismatch of non-type template parameter and deduced argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57570 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- The problem also exists for gcc 4.9.0 20130519 (experimental) (tested on mingw-64 bit)
[Bug target/6526] [SH4] sdivsi3_i4 can clobber xd0/xd2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6526 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED CC||olegendo at gcc dot gnu.org Resolution|--- |FIXED --- Comment #13 from Oleg Endo --- Fixed in 4.9. by picking up the suggestions from comment #3. http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=199873 PR target/6526 * config/sh/lib1funcs.S (sdivsi3_i4, udivsi3_i4): Do not change bits other than FPSCR.PR and FPSCR.SZ. Add SH4A implementation. PR target/6526 * gcc.target/sh/pr6526.c: New.
[Bug tree-optimization/56547] [SH] missed opportunity for fmac with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547 --- Comment #3 from Oleg Endo --- Fixed for SH on 4.8: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=199874 PR target/56547 * config/sh/sh.md (fmasf4): Remove empty constraints strings. (*fmasf4, *fmasf4_media): New insns. gcc/testsuite/ChangeLog: PR target/56547 * gcc.target/sh/pr56547-1.c: New. * gcc.target/sh/pr56547-2.c: New.
[Bug c++/38634] ICE with wrong number of template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38634 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org, | |jason at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini --- On it.
[Bug c++/57573] New: [C++1y] bogus "taking address of temporary" error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57573
Bug ID: 57573
Summary: [C++1y] bogus "taking address of temporary" error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
struct A { };
struct B { A a; };
void f(A*) { }
template
void g()
{
B b;
f(&(b.a));
}
This compiles OK with -std=c++98 or -std=c++11 but not -std=c++1y:
$ g++11 f.cc -std=c++1y -c
f.cc: In function ‘void g()’:
f.cc:10:10: error: taking address of temporary [-fpermissive]
f(&(b.a));
^
It also compiles OK if g() is not a template.
This causes an error in in C++1y mode:
/home/redi/gcc/4.x/include/c++/4.9.0/mutex: In function ‘void
std::call_once(std::once_flag&, _Callable&&, _Args&& ...)’:
/home/redi/gcc/4.x/include/c++/4.9.0/mutex:786:48: error: lvalue required as
unary ‘&’ operand
int __e = __gthread_once(&(__once._M_once), &__once_proxy);
^
I don't know why those parentheses are there in so they just can be
removed to fix the problem.
[Bug c/57574] New: -std=c99 inline function incorrectly has external linkage with prior static declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57574
Bug ID: 57574
Summary: -std=c99 inline function incorrectly has external
linkage with prior static declaration
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nszabolcs at gmail dot com
gcc emits incorrect warning for inline function with internal linkage:
$ cat example.c
static int n;
static inline int f(void);
inline int f(void) {return n;}
int g(){return f();}
$ gcc-4.8 -std=c99 -c example.c
example.c:3:28: warning: 'n' is static but used in inline function 'f' which is
not static [enabled by default]
inline int f(void) {return n;}
^
$ nm example.o
U f
T g
b n
according to C99 6.2.2p4 the linkage of an identifier
is determined by the prior declaration
(internal in this case, inline does not change that)
referencing static objects from an inline definition
only violates the constraint in C99 6.7.4p3 if the
function has external linkage
(so the diagnostic is unjustified)
it seems from the warning that gcc thinks that f
is not static, this can break code:
the inline definition of f does not provide an
external definition and if the compiler choose
not to inline then the code has undefined f symbol
if the compiler thinks f has external linkage
(as demonstrated by nm above)
[Bug c++/57575] New: lvalue function accepted as an rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57575
Bug ID: 57575
Summary: lvalue function accepted as an rvalue
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anass.lasram at gmail dot com
// the following code compiles but it should not
float f() { return 0.f; }
template
void take_f(F&& f) {}
int main()
{
// this is OK. reference collapsing
take_f(f);
// next line compiles but it should not: f is not an rvalue !
take_f(f);
return 0;
}
[Bug target/57540] stack pointer related loop invariants after reload for ARM mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540 --- Comment #3 from bin.cheng --- I think this should be handled in expand. During expanding, GCC tries "base + scaled_offset + offset" pattern, which is invalid for targets like arm. At this point we still have a chance to refactor "base + offset" and force it into register, thus generating "reg + scaled_offset". By doing this, 1) "base + offset" can be kept as loop invariant; 2) the multiplication is done by scaled address, saving another add instruction. I am testing a patch and will send it for review once it passes tests.
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 Anthony Falzone changed: What|Removed |Added CC||prop_design at yahoo dot com --- Comment #12 from Anthony Falzone --- Hi Guys, I'm the developer of PROP_DESIGN. I originally posted on the Google GCC Graphite Group. Thanks Tobias for creating this bug and realizing the root issue. I originally thought auto-parallelization would be of benefit. However, I recently starting experimenting with the Intel Fortran compiler and have found some things that may help you out. I have found Intel Fortran IPO, auto-vectorization, and/or auto-parallelization are of no benefit to PROP_DESIGN. I also found, as Tobias mentioned here, that gfortran creates significantly slower executable files than Intel Fortran. I have narrowed it down to just the basic optimizations. It does not have to do with anything else. If you compare gfortran -03 optimizations versus Intel Fortran /O3 optimizations, you see a big difference. One case I ran shows about 38.65% faster executable files, if you use Intel Fortran with /O3 optimizations compared to gfortran with -O3 optimizations. I have a measle AMD C-60 processor and use Windows 7 64-bit. I have tried many other gfortran for Windows compilers in the past, but I'm currently using the latest version of TDM-GCC. I have also tried Linux but am not currently using it. I have not tried Intel Fortran on Linux. I am not much of a programmer, so I can't say why gfortran -O3 is making slower executable files than Intel Fortran /O3. Perhaps you guys would know. I thought this information might help you out. If I can be of any help to you, let me know. My website has the latest version of PROP_DESIGN. Polyhedron refuses to update the version I sent them years ago. It would probably be better if you used the latest version for testing your software. Sincerely, Anthony Falzone http://propdesign.weebly.com/
