[Bug target/65924] [6 Regression] ICE const_int_operand failed on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65924 Yvan Roux changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Yvan Roux --- Yes it is. Sorry for the delay
[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66605 --- Comment #11 from Dominique d'Humieres --- > (It would be interesting to know at which GCC version or revision > the warning started appearing). The warning for unused parameters appeared at r126486 (pr31129) and -Wunused-parameter at r126486. -Wunused-dummy-argument appeared at r159641 (pr38407). This option corresponds to -Wunused-parameter for other FEs. AFAICT these options are handled by the fortran FE and should not propagate to the ME.
[Bug middle-end/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #8 from Richard Biener ---
Yes, consider
struct X { int n; char x[1]; };
which has sizeof(X) == 8 unless you use __attribute__((packed)) (in which case
alignment also gets dropped down to 1).
[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 Richard Biener changed: What|Removed |Added Version|unknown |5.1.0 Target Milestone|--- |5.2 Summary|[5.1 Regression]|[5/6 Regression] |miscompilation due to |miscompilation due to |ipa-ra on MinGW |ipa-ra on MinGW
[Bug target/29693] ICE while compiling gcc-3.4.3 with gcc-4.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693 --- Comment #9 from Ramana Radhakrishnan --- Author: ramana Date: Thu Jun 25 08:18:19 2015 New Revision: 224932 URL: https://gcc.gnu.org/viewcvs?rev=224932&root=gcc&view=rev Log: Fix PR target/29693 2015-06-25 Ramana Radhakrishnan PR target/29693 * config/arm/arm.c (arm_dbx_register_number): Return DWARF_FRAME_REGISTERS by default. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug target/29693] ICE while compiling gcc-3.4.3 with gcc-4.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #10 from Ramana Radhakrishnan --- Hmmm atleast fixed for 6.0 ...
[Bug target/63408] [4.9/5/6 regression] GCC emits incorrect fixed->fp conversion instruction on Cortex-M4 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408 --- Comment #14 from Ramana Radhakrishnan --- Author: ramana Date: Thu Jun 25 08:36:03 2015 New Revision: 224933 URL: https://gcc.gnu.org/viewcvs?rev=224933&root=gcc&view=rev Log: Fix PR target/63408 Backport fix for PR target/63408 from mainline The attached patch fixes PR target/63408 and adds a regression test for the same. The problem is essentially that vfp3_const_double_for_fract_bits() needs to be aware that negative values cannot be used in this context. Tested with a bootstrap and regression test run on armhf. Applied. 2015-06-25 Ramana Radhakrishnan Backport from mainline. 2015-06-24 Ramana Radhakrishnan PR target/63408 * config/arm/arm.c (vfp3_const_double_for_fract_bits): Disable for negative numbers. 2015-06-25 Ramana Radhakrishnan Backport from mainline. 2015-06-24 Ramana Radhakrishnan PR target/63408 * gcc.target/arm/pr63408.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr63408.c - copied unchanged from r224879, trunk/gcc/testsuite/gcc.target/arm/pr63408.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/arm.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66605 --- Comment #12 from Manuel López-Ibáñez --- (In reply to Dominique d'Humieres from comment #11) > > (It would be interesting to know at which GCC version or revision > > the warning started appearing). > > The warning for unused parameters appeared at r126486 (pr31129) and > -Wunused-parameter at r126486. Sorry, perhaps I was not clear. I meant: when did this testcase start triggering a warning (or an ICE, whatever happened first) with -Wunused-parameter? As I said in comment #4, GCC 4.3.1 had this warning and the warning option was enabled for the testcase but the warning did not trigger. When did it start triggering? > AFAICT these options are handled by the fortran FE and should not propagate > to the ME. Wunused-parameter is both a Fortran and a middle-end option. It is unfortunate it has a different meaning. One could argue that it should not be a middle-end option and the warning should be given only by the FEs. My intuition is that if you found a clean way to move the ME warning from cgraphunit.c to somewhere in c-family/ , such a patch is likely to be approved and it will fix this problem also. However, all this has nothing to do with the warning triggering now, since this has been the status quo since at least GCC 4.3.1. The reason it did not warn before is that somehow the Fortran FE marked the TREE_DECL as TREE_NO_WARNING and it doesn't do this anymore.
[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #18 from Marek Polacek --- Backporting a new warning to a released branch isn't viable I'm afraid, it would make upgrading from 5.1 to 5.2 unsafe for some users.
[Bug target/66660] [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Andrey Belevantsev changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-25 CC||abel at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrey Belevantsev --- I will take a look in a week or so when I'll be back in office.
[Bug bootstrap/66638] [6 Regression] profiledbootstrap failure on x86-64 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66638 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-25 Ever confirmed|0 |1 --- Comment #3 from H.J. Lu --- (In reply to amker from comment #2) > It is an assertion failure, only I had difficualty in reproducing the issue. > I got below link error when doing profiledbootstrap with given configuration > options: > > /tmp/cc3NzkDN.ltrans0.ltrans.o: In function `read_md_files': > .build/gcc/../../gcc/gcc/read-md.c:1052: undefined reference to `xmalloc' > .build/gcc/../../gcc/gcc/read-md.c:1053: undefined reference to `htab_create' > .build/gcc/../../gcc/gcc/read-md.c:1054: undefined reference to `xmalloc' > .build/gcc/../../gcc/gcc/read-md.c:1055: undefined reference to `htab_create' > .build/gcc/../../gcc/gcc/read-md.c:1056: undefined reference to `xmalloc' > .build/gcc/../../gcc/gcc/read-md.c:1057: undefined reference to `htab_create' > .build/gcc/../../gcc/gcc/read-md.c:1059: undefined reference to `htab_create' > .build/gcc/../../gcc/gcc/read-md.c:1063: undefined reference to > `unlock_std_streams' > .build/gcc/../../gcc/gcc/read-md.c:1131: undefined reference to > `fopen_unlocked' > /tmp/cc3NzkDN.ltrans0.ltrans.o: In function > `_ZL20handle_toplevel_filePFviPKcE.constprop.1': > .build/gcc/../../gcc/gcc/read-md.c:1003: undefined reference to `lbasename' > .build/gcc/../../gcc/gcc/read-md.c:1007: undefined reference to `xstrndup' > /tmp/cc3NzkDN.ltrans0.ltrans.o: In function `parse_include(char const*)': > .build/gcc/../../gcc/gcc/read-md.c:1019: undefined reference to `xmalloc' > /tmp/cc3NzkDN.ltrans1.ltrans.o: In function `read_name(md_name*)': > .build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find' > .build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find' > .build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find' > .build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find' > .build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find' > > I used ubuntu 12.04 system. Anything wrong? Please try binutils 2.25 and ld.bfd.
[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66605 --- Comment #13 from Dominique d'Humieres --- > As I said in comment #4, GCC 4.3.1 had this warning and the warning option > was enabled for the testcase but the warning did not trigger. When did > it start triggering? I don't see the warning with 4.5.4, but I see it with 4.6.4: [macbook] f90/bug% gfortran-fsf-4.5 /opt/gcc/_clean/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_2.f90 -Wunused-parameter -c [macbook] f90/bug% gfortran-fsf-4.6 /opt/gcc/_clean/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_2.f90 -Wunused-parameter -c /opt/gcc/_clean/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_2.f90:7:0: warning: unused parameter 'dummy' [-Wunused-parameter] Compiling the test gfortran.dg/warn_unused_dummy_argument_2.f90 with -Wunused-parameter gives the ICE with 5.1/6.0. To be more precise, I dont't get the warning for 4.7 with r182107 (2011-12-08), but I get it with r182980 (2012-01-07), back ported to 4.6 between r179116 (2011-09-23) and r182981 (2012-01-07), possibly r182211 and r182213 (pr50923)
[Bug fortran/66633] [5/6 regression] ICE on valid "verify_gimple failed" with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633 Mikael Morin changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #5 from Mikael Morin --- The regressing commit is r211308.
[Bug c++/66656] static constexpr array member: cannot get size via constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66656 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- https://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition
[Bug c++/66662] Request: Change #error directive displaying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- This old patch that implemented control flags to selectively hide the caret info in some warnings may be useful for this: https://gcc.gnu.org/ml/gcc-patches/2012-04/msg01836.html Feel free to take it and get it in shape.
[Bug c++/55922] brace initializing parent cause bogus virtual base constructor calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55922 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-25 Ever confirmed|0 |1 Known to fail||4.9.2, 5.1.0, 6.0
[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530 Bug 65530 depends on bug 65528, which changed state. Bug 65528 Summary: [mpx] internal compiler error: in expand_expr_addr_expr_1, at expr.c:7761 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65528 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug other/65528] [mpx] internal compiler error: in expand_expr_addr_expr_1, at expr.c:7761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65528 Ilya Enkovich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Ilya Enkovich --- It passes for r224900.
[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #39 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #38) > I'm testing the patch now. I'll report back when it's done. Done. No new failures for the top level "make -k check".
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #36 from Kazumoto Kojima --- Author: kkojima Date: Thu Jun 25 10:15:18 2015 New Revision: 224935 URL: https://gcc.gnu.org/viewcvs?rev=224935&root=gcc&view=rev Log: PR target/66563 * [SH] Add a new operand to GOTaddr2picreg so to avoid CSE. Modify caller of gen_GOTaddr2picreg. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sh/sh.c branches/gcc-5-branch/gcc/config/sh/sh.md
[Bug c++/55922] brace initializing parent cause bogus virtual base constructor calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55922
--- Comment #2 from Jonathan Wakely ---
bool called = false;
struct Base {
Base() { if (called) throw 1; called = true; }
};
struct B1 : virtual Base {
B1() { }
};
struct C : B1, virtual Base {
C() :
#ifdef FIX
B1()
#else
B1{}
#endif
{ }
};
int main() {
C c;
}
[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66647 --- Comment #8 from Benny --- Wow, that went really quick! Many thanks! Very impressive.
[Bug middle-end/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #9 from Pádraig Brady --- I'm not understanding completely TBH. Are flexible array members not special? Should the optimizations be restricted on access through the flexible array, because I presume most/all existing allocation code is not considering this alignment/padding issue. I certainly didn't notice any examples when looking into a workaround which I came up with independently. For my reference there are some notes RE GCC's divergence from C99 re padding and flexi arrays at: https://sites.google.com/site/embeddedmonologue/home/c-programming/data-alig
[Bug target/64783] -march=armv8.1-a should be supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64783 --- Comment #3 from mwahab at gcc dot gnu.org --- I've just noticed this has been assigned to me. Support for -march=armv8.1-a has been added to the Aarch64 backend, the ARM backend is still to be done. Author: mwahab Date: Tue Jun 16 13:38:37 2015 New Revision: 224519 URL: https://gcc.gnu.org/viewcvs?rev=224519&root=gcc&view=rev Log: 2015-06-16 Matthew Wahab * config/aarch64/aarch64-arches.def: Add "armv8.1-a". * config/aarch64/aarch64-options-extensions.def: Update "fP", "simd" and "crypto". Add "lse", "pan", "lor" and "rdma". * gcc/config/aarch64/aarch64.h (AARCH64_FL_LSE): New. (AARCH64_FL_PAN): New. (AARCH64_FL_LOR): New. (AARCH64_FL_RDMA): New. (AARCH64_FL_FOR_ARCH8_1): New. * doc/invoke.texi (AArch64 Options): Add "armv8.1-a" to -march. Add "lse", "pan", "lor", "rdma" to feature modifiers. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-arches.def trunk/gcc/config/aarch64/aarch64-option-extensions.def trunk/gcc/config/aarch64/aarch64.h trunk/gcc/doc/invoke.texi
[Bug middle-end/66637] [6 Regression] 481.wrf in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66637 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from H.J. Lu --- Fixed as of r224919.
[Bug c/66663] New: gcc misses optimization emits useless test of (a & 31) with 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
Bug ID: 3
Summary: gcc misses optimization emits useless test of (a & 31)
with 32
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fuz at fuz dot su
Target Milestone: ---
The following code:
unsigned long long foo(unsigned long long x, int a) {
return x << (a & 31);
}
compiled with a recent build of gcc for i386 Linux (with -O3) yields the
following assembly:
foo:
movl12(%esp), %ecx
movl4(%esp), %eax
movl8(%esp), %edx
andl$31, %ecx
shldl %eax, %edx
sall%cl, %eax
testb $32, %cl
je .L2
movl%eax, %edx
xorl%eax, %eax
.L2:
rep ret
.ident "GCC: (GNU) 5.0.0 20150314 (experimental)"
The testb instruction seems redundant as %cl has been masked with $31 a few
instructions before: The jump will never be taken.
[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #40 from John Paul Adrian Glaubitz --- (In reply to Kazumoto Kojima from comment #39) > Done. No new failures for the top level "make -k check". So, chances are gcc-5 would build now?
[Bug c/66663] gcc misses optimization emits useless test of (a & 31) with 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3 --- Comment #1 from Robert Clausecker --- Sorry. I meant to say: The branch will always be taken, not never.
[Bug tree-optimization/66664] New: gcc misses optimization emits subtraction where relocation arithmetic would suffice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
Bug ID: 4
Summary: gcc misses optimization emits subtraction where
relocation arithmetic would suffice
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fuz at fuz dot su
Target Milestone: ---
For the following C code:
int foo(int x) {
extern int bar[];
return bar[x - 1];
}
gcc emits the following code (with -O3) on amd64 Linux:
foo:
subl$1, %edi
movslq %edi, %rdi
movlbar(,%rdi,4), %eax
ret
.ident "GCC: (GNU) 5.0.0 20150314 (experimental)"
I expected gcc to emit the following (as signed underflow is undefined):
foo:
movslq %edi, %rdi
movlbar-4(,%rdi,4), %eax
ret
or even this (as the memory model places global variables in the first 2^32
byte of RAM):
foo:
movlbar-4(,%edi,4), %eax
ret
[Bug tree-optimization/66652] try_transform_to_exit_first_loop_alt generates incorrect loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66652 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 35853 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35853&action=edit demonstrator patch This patch fixes the correctness issue, but it fails to do transform_to_exit_first_loop_alt for unsigned loop counters: ... PASS: gcc.dg/parloops-exit-first-loop-alt-2.c (test for excess errors) PASS: gcc.dg/parloops-exit-first-loop-alt-2.c scan-tree-dump-times parloops "(?n)\\[i" 9 PASS: gcc.dg/parloops-exit-first-loop-alt-3.c (test for excess errors) FAIL: gcc.dg/parloops-exit-first-loop-alt-3.c scan-tree-dump-times parloops "(?n)\\* 4" 3 PASS: gcc.dg/parloops-exit-first-loop-alt-4.c (test for excess errors) PASS: gcc.dg/parloops-exit-first-loop-alt-4.c scan-tree-dump-times parloops "(?n)\\* 4" 3 PASS: gcc.dg/parloops-exit-first-loop-alt-5.c (test for excess errors) PASS: gcc.dg/parloops-exit-first-loop-alt-5.c scan-tree-dump-times parloops "(?n)% 13" 4 PASS: gcc.dg/parloops-exit-first-loop-alt-6.c (test for excess errors) FAIL: gcc.dg/parloops-exit-first-loop-alt-6.c scan-tree-dump-times parloops "(?n)\\[i" 9 PASS: gcc.dg/parloops-exit-first-loop-alt-7.c (test for excess errors) FAIL: gcc.dg/parloops-exit-first-loop-alt-7.c scan-tree-dump-times parloops "(?n)\\[i" 9 PASS: gcc.dg/parloops-exit-first-loop-alt-8.c (test for excess errors) FAIL: gcc.dg/parloops-exit-first-loop-alt-8.c scan-tree-dump-times parloops "(?n)\\[i" 9 PASS: gcc.dg/parloops-exit-first-loop-alt.c (test for excess errors) FAIL: gcc.dg/parloops-exit-first-loop-alt.c scan-tree-dump-times parloops "(?n)\\[i" 9 ...
[Bug rtl-optimization/66665] New: Increment instruction is not propagated into address operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Bug ID: 5
Summary: Increment instruction is not propagated into address
operand
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kyukhin at gcc dot gnu.org
Target Milestone: ---
Hello,
Running this:
make check-gcc RUNTESTFLAGS="CFLAGS='-mregparm=3'
--target_board='unix/-mregparm=3{-m32}' i386.exp=addr-sel-1.c"
If got fail since:
f:
.LFB0:
movsbl a+1(%eax), %edx
incl%eax;; Not propagated ...
movsbl b(%eax), %eax ;; ... to here.
addl%edx, %eax
ret
Increment of %eax is not propagated into load of b.
This kind of propagation is occurred during postreload in `reload_cse_regs',
but increment is promoted to load of a.
[Bug c++/66666] New: ARM compiled code segmentation fault on multiple inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Bug ID: 6
Summary: ARM compiled code segmentation fault on multiple
inheritance
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antonio.poggiali at datalogic dot com
Target Milestone: ---
Created attachment 35854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35854&action=edit
Source files, compiled file, gcc output, etc.
Host system:
Linux MatrixPlatVb-lx-apoggiali 3.13.0-44-generic #73~precise1-Ubuntu SMP Wed
Dec 17 00:39:15 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Target system:
ARM cortex A5 (but same behavior on A9).
Linux sama5d4ek 3.18.0-linux4sam_5.0-alpha1 #1 Wed Jun 24 09:45:58 CEST 2015
armv7l GNU/Linux
Cross-compiler invocation and output:
Invoking: GCC C++ Compiler
arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -O0 -g3 -Wall -Wextra -c
-fmessage-length=0 --sysroot=<...> -march=armv7-a -mfloat-abi=hard
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -MMD -MP
-MF"liste.d" -MT"liste.d" -o "liste.o" "liste.cpp"
Finished building:
liste.cpp
Invoking: GCC C++ Linker
arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ --sysroot=<...>
-march=armv7-a -mfloat-abi=hard -o "liste" liste.o
Finished building target: liste
Input file (liste.cpp):
#include
#include
class SmartObject
{
public:
virtual ~SmartObject(){
}
void method(void) {}
};
class IMyInterface
{
public:
virtual ~IMyInterface(){
}
virtual std::list getList() = 0;
};
class MyObject : public virtual IMyInterface, public SmartObject
{
public:
MyObject()
{
list.push_back(4);
list.push_back(5);
}
virtual std::list getList() {
return list;
}
virtual ~MyObject(){
}
std::list list;
};
int main()
{
IMyInterface * ip = new MyObject();
std::list list_clone = ip->getList();
// On size() I get a segmentation fault
std::cout << list_clone.size() << std::endl;
delete ip;
return 0;
}
Stack at fault:
liste [C/C++ Remote Application]
list [1573] [cores: 0]
Thread [1] 1573 [core: 0] (Suspended : Signal :
SIGSEGV:Segmentation fault)
std::_List_const_iterator::operator++() at
stl_list.h:244 0x9738
std::__distance >() at
stl_iterator_base_funcs.h:82 0x97d4
std::distance >() at
stl_iterator_base_funcs.h:118 0x9430
std::list >::size() at
stl_list.h:887 0x9144
main() at liste.cpp:50 0x8a14
Comment:
The list obtained through ip->getList(); is incorrect: the tail pointer is
malformed. When size() is called the list is scanned to count the number of
elements. As the tail pointer is malformed the scan end condition is not met
and i get a segmentation fault (or an endless loop when optimization in on).
The same code works correctly on host system (x86_64-linux).
Notes:
Declaring "class MyObject : public virtual IMyInterface, public virtual
SmartObject" makes it work.
Also removing ~SmartObject() destructor makes it work.
In attachment source code and compiler outputs.
[Bug c/66658] missing -Wunused-value negating a function result in a comma expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66658
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
I do get warning with cc1 but not with cc1plus on the following
int foo (int, int);
int bar (int a)
{
if (a && !foo (0, 0), 1)
return 1;
return 0;
}
[Bug c++/66617] C++11 {brace} initialisation of virtually inherited derived class = failure to override base virtual function, unless all base ctors have same signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66617 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-25 Ever confirmed|0 |1 --- Comment #6 from Jonathan Wakely --- Probably related to PR55922.
[Bug c++/66644] Rejects C++11 in-class anonymous union members initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66644 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-25 Ever confirmed|0 |1
[Bug c++/66667] New: FAIL: g++.dg/diagnostic/inhibit-warn-2.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7 Bug ID: 7 Summary: FAIL: g++.dg/diagnostic/inhibit-warn-2.C Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: miyuki at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /mnt/gnu/gcc/objdir-test/gcc/testsuite/g++/../../xg++ -B/mnt/ gnu/gcc/objdir-test/gcc/testsuite/g++/../../ /mnt/gnu/gcc/gcc/gcc/testsuite/g++. dg/diagnostic/inhibit-warn-2.C -fno-diagnostics-show-caret -fdiagnostics-color= never -nostdinc++ -I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/incl ude/hppa2.0w-hp-hpux11.11 -I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++- v3/include -I/mnt/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/mnt/gnu/gcc/gcc/libstdc+ +-v3/include/backward -I/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-l ength=0 -std=c++98 -pedantic-errors -Wno-long-long -S -o inhibit-warn-2.s (timeout = 300) spawn /mnt/gnu/gcc/objdir-test/gcc/testsuite/g++/../../xg++ -B/mnt/gnu/gcc/objdi r-test/gcc/testsuite/g++/../../ /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/diagnostic /inhibit-warn-2.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdin c++ -I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp -hpux11.11 -I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/m nt/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/mnt/gnu/gcc/gcc/libstdc++-v3/include/ba ckward -I/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c+ +98 -pedantic-errors -Wno-long-long -S -o inhibit-warn-2.s /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/diagnostic/inhibit-warn-2.C: In function ' void fn1()': /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/diagnostic/inhibit-warn-2.C:29:3: error: ' typename A<(F >::type>::value || B:: value) >::type D::operator=(Expr) [with Expr = int; typename A<(F >::type>::value || B:: value)>::type = int]' is private /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/diagnostic/inhibit-warn-2.C:35:7: error: within this context compiler exited with status 1 output is: /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/diagnostic/inhibit-warn-2.C: In function 'void fn1()': /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/diagnostic/inhibit-warn-2.C:29:3: error: 'typename A<(F >::type>::value || B:: value)>::type D::operator=(Expr) [with Expr = int; typename A<(F >::type>::value || B:: value)>::type = int]' is private /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/diagnostic/inhibit-warn-2.C:35:7: error: within this context FAIL: g++.dg/diagnostic/inhibit-warn-2.C -std=c++98 (test for warnings, line 29) FAIL: g++.dg/diagnostic/inhibit-warn-2.C -std=c++98 (test for errors, line 35) FAIL: g++.dg/diagnostic/inhibit-warn-2.C -std=c++98 (test for excess errors) FAIL: g++.dg/diagnostic/inhibit-warn-2.C -std=c++11 (test for warnings, line 29) FAIL: g++.dg/diagnostic/inhibit-warn-2.C -std=c++11 (test for errors, line 35) FAIL: g++.dg/diagnostic/inhibit-warn-2.C -std=c++11 (test for excess errors) This is with revision 224902.
[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #41 from Kazumoto Kojima --- (In reply to John Paul Adrian Glaubitz from comment #40) > So, chances are gcc-5 would build now? Maybe. Trying it with Oleg's patch is a good idea.
[Bug c++/66067] [6 Regression] tree check ICE: accessed elt 1 of tree_vec with 0 elts in write_template_args, at cp/mangle.c:2574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug debug/66668] New: FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Bug ID: 8 Summary: FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/stacked-qualified-types-3.c -f no-diagnostics-show-caret -fdiagnostics-color=never -std=c11 -gdwarf-5 -dA -S -o stacked-qualified-types-3.s(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/debug/dwarf2/stacked-qualified-types-3.c -fno-diagnostics -show-caret -fdiagnostics-color=never -std=c11 -gdwarf-5 -dA -S -o stacked-quali fied-types-3.s PASS: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c (test for excess errors) FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8 -bash-4.3$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa64-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-6 --build=hppa64-hp-hpux11.11 --enable-threads=posix --with-gmp=/opt/gnu64/gcc/gmp --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran Thread model: posix gcc version 6.0.0 20150624 (experimental) [trunk revision 224902] (GCC)
[Bug rtl-optimization/66669] New: FAIL: gcc.dg/loop-8.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Bug ID: 9 Summary: FAIL: gcc.dg/loop-8.c Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/loop-8.c -fno-diagnostics-show-caret -fdiag nostics-color=never -O1 -fdump-rtl-loop2_invariant -S -o loop-8.s (timeou t = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/loop-8.c -fno-diagnostics-show-caret -fdiagnostics-color= never -O1 -fdump-rtl-loop2_invariant -S -o loop-8.s PASS: gcc.dg/loop-8.c (test for excess errors) FAIL: gcc.dg/loop-8.c scan-rtl-dump-times loop2_invariant "Decided" 1 FAIL: gcc.dg/loop-8.c scan-rtl-dump-not loop2_invariant "without introducing a new temporary register" -bash-4.3$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa64-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-6 --build=hppa64-hp-hpux11.11 --enable-threads=posix --with-gmp=/opt/gnu64/gcc/gmp --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran Thread model: posix gcc version 6.0.0 20150624 (experimental) [trunk revision 224902] (GCC)
[Bug c++/66667] FAIL: g++.dg/diagnostic/inhibit-warn-2.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7 Mikhail Maltsev changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-25 Assignee|unassigned at gcc dot gnu.org |miyuki at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Mikhail Maltsev --- I'm waiting for some advice from maintainers (about the proper way of resolving this): https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01742.html
[Bug fortran/66633] [5/6 regression] ICE on valid "verify_gimple failed" with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #6 from Eric Botcazou --- Very likely a latent issue, in any case the workaround is trivial.
[Bug c++/66670] New: "template argument deduction/substitution failed" with function pointers and multiple parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66670
Bug ID: 66670
Summary: "template argument deduction/substitution failed" with
function pointers and multiple parameter packs
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael at ensslin dot cc
Target Milestone: ---
Take this example:
$ cat t28.cpp
template
struct S {
template
void foo(void (*)(Us..., Ts ...)) {}
};
void f(float, int) {}
int main() {
S().foo(f);
}
$ g++-4.9 -std=c++14 t28.cpp
t28.cpp: In function ‘int main()’:
t28.cpp:10:23: error: no matching function for call to ‘S::foo(void
(&)(float, int))’
S().foo(f);
^
t28.cpp:10:23: note: candidate is:
t28.cpp:4:7: note: template void S::foo(void (*)(Us ..., Ts
...)) [with Us = {Us ...}; Ts = {int}]
void foo(void (*)(Us..., Ts ...)) {}
^
t28.cpp:4:7: note: template argument deduction/substitution failed:
t28.cpp:10:23: note: mismatched types ‘int’ and ‘float’
S().foo(f);
^
$ g++-4.9 --version
g++-4.9 (Debian 4.9.2-22) 4.9.2
I have reproduced the issue with g++-5.1.0 using https://gcc.godbolt.org/.
Note that clang++ has this issue as well, but it works with icc and supposedly
even MSVC.
The issue can be fixed by swapping the order of Us... and Ts... in the function
pointer type, or by replacing the function pointer type by some other type like
std::tuple.
Related: http://stackoverflow.com/questions/31040075
clang++ error, for completeness:
$ clang++-3.7 -std=c++14 t28.cpp
t28.cpp:10:11: error: no matching member function for call to 'foo'
S().foo(f);
~^~
t28.cpp:4:7: note: candidate template ignored: failed template argument
deduction
void foo(void (*)(Us..., Ts ...)) {}
^
1 error generated.
$ clang++-3.7 --version
Debian clang version 3.7.0-svn239806-1+b1 (trunk) (based on LLVM 3.7.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #42 from John Paul Adrian Glaubitz --- (In reply to Kazumoto Kojima from comment #41) > Maybe. Trying it with Oleg's patch is a good idea. Is it applied yet? Otherwise I really will have to look into building gcc-5 from SVN myself.
[Bug middle-end/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #10 from joseph at codesourcery dot com --- On Thu, 25 Jun 2015, P at draigBrady dot com wrote: > I'm not understanding completely TBH. Are flexible array members not special? > Should the optimizations be restricted on access through the flexible array, > because I presume most/all existing allocation code is not considering this > alignment/padding issue. I certainly didn't notice any examples when looking > into a workaround which I came up with independently. For my reference there > are some notes RE GCC's divergence from C99 re padding and flexi arrays at: > https://sites.google.com/site/embeddedmonologue/home/c-programming/data-alig That page doesn't exist - I assume you mean: https://sites.google.com/site/embeddedmonologue/home/c-programming/data-alignment-structure-padding-and-flexible-array-member That page is over ten years out of date - it's quoting the wording in C99 as it was before it was corrected by TC2 (published 2004-11-15). You should look at the post-TC2 wording rather than the old wording with various defects in it.
[Bug c++/66666] ARM compiled code segmentation fault on multiple inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Ramana Radhakrishnan changed: What|Removed |Added Target|Linux sama5d4ek |arm*-*-* |3.18.0-linux4sam_5.0-alpha1 | |#1 Wed Jun 24 09:45:58 CEST | |2015 armv7l GNU/Linux | CC||ramana at gcc dot gnu.org Host|Linux |x86_64-*-* |MatrixPlatVb-lx-apoggiali | |3.13.0-44-generic | |#73~precise1-Ubuntu SMP Wed | |Dec 17 00:39:15 UTC 2014| |x86_64 x86_64 x86_64| |GNU/Linux | --- Comment #1 from Ramana Radhakrishnan --- Obvious "dumb" question given this is a cross-environnment - I'm assuming that you have the same libstdc++ in both places ?
[Bug c++/66671] New: Failure to create a new family of templates for template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66671
Bug ID: 66671
Summary: Failure to create a new family of templates for
template alias
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Whenever you use:
template
using Z = Y;
The template Z is different from Y and should be encoded separately. This can
be seen in the example:
#include
template class>
struct X {
X() { std::cout << "1"; }
};
template
struct Y {};
template
using Z = Y;
template <>
struct X {
X() { std::cout << "2"; }
};
int main() {
X x1;
X x2;
}
(from: http://cppquiz.org/quiz/giveup/117)
With GCC 5.1.1, the above prints "22", whereas it prints "21" with ICC 16,
Clang 3.7 and MSVC 2013. The explanation from the quiz site is given as:
> According to §14.5.7¶1 in the standard, a template alias declaration
> resolve to a new family of types. The specialization cannot be used,
> and the first template delcaration is used instead, printing 1.
Disassembly with -O2 -fno-inline shows that Clang and ICC both call different
template specialisations of template class X:
leaq16(%rsp), %rdi
callq _ZN1XI1YEC2Ev ; X::X()
leaq8(%rsp), %rdi
callq _ZN1XI1ZEC2Ev ; X::X()
PS: should X count as a local type or a global one?
[Bug c++/66672] New: std::is_same wrong result for captured reference value inside a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66672
Bug ID: 66672
Summary: std::is_same wrong result for captured reference value
inside a lambda
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Given the following code:
#include
#include
using namespace std;
int main()
{
int i, &j = i;
[=]
{
cout << is_same::value
<< is_same::value;
}();
}
(trimmed from http://cppquiz.org/quiz/question/127)
With GCC 5.1, the code will print 10, but it should be 01. Clang 3.6, ICC 16
and MSVC 2015 do compile this as expected. The output 10 would be correct if
the extra set of parentheses weren't there.
The explanation given on the quiz website is:
> Since the expression for decltype is a parenthesized lvalue
> expression, §7.1.6.2¶4 has this to say: "The type denoted by
> decltype(e) is (...) T&, where T is the type of e;" As the
> expression occurs inside a const member function, the expression is
> const, and decltype((j)) denotes int const&. See also the example in
> §5.1.2¶18.
[NB: it's paragraph 19 as of N4431]
The example in that paragraph of the standard matches almost exactly the code
above.
The output is correct with a functor:
struct S
{
S(int &i) : j(i) {}
void operator()() const
{
cout << is_same::value
<< is_same::value;
};
int j;// captured by value
};
int main()
{
int i;
S{i}();
}
[Bug c/39121] strange behavior in chained operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 joe.carnuccio at qlogic dot com changed: What|Removed |Added CC||joe.carnuccio at qlogic dot com --- Comment #4 from joe.carnuccio at qlogic dot com --- I have found the following: This works: c ^= d ^= c ^= d (where c and d are not pointers) This fails: *a ^= *b ^= *a ^= *b (where a and b are pointers) When compiling using -Os then the failed case now works.
[Bug c/39121] strange behavior in chained operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 --- Comment #5 from joe.carnuccio at qlogic dot com --- Since using gcc -Os causes the correct execution, then "sequence point" does not have anything to do with it.
[Bug c/39121] strange behavior in chained operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 --- Comment #6 from Andrew Pinski --- (In reply to joe.carnuccio from comment #5) > Since using gcc -Os causes the correct execution, then "sequence point" does > not have anything to do with it. And you are wrong about that. -Os causes what you think is the correct execution but there are multiple interpretations of the code because there are not sequence points there.
[Bug c/66673] New: swapping variables via chained xor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673
Bug ID: 66673
Summary: swapping variables via chained xor fails
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joe.carnuccio at qlogic dot com
Target Milestone: ---
This is the same as 39121 which has been marked RESOLVED INVALID (to which I
strongly disagree):
this produces incorrect executable: *p ^= *q ^= *p ^= *q;
( if gcc option "-Os" is used, then that produces correct executable )
( by contrast, this always produces correct executable: a ^= b ^= a ^= b; )
root@elab305:/home/joe/test/c# cat x.c
#include
int main(int argc, char **argv)
{
int a = 0x32, b = 0x45;
int *p = &a, *q = &b;
*p ^= *q ^= *p ^= *q;
printf("%x %x\n", a, b);
return 0;
}
root@elab305:/home/joe/test/c# make -B x
cc-c -o x.o x.c
cc x.o -o x
root@elab305:/home/joe/test/c# ./x
0 32 <--INCORRECT
root@elab305:/home/joe/test/c# make -B x CFLAGS+='-Os'
cc -Os -c -o x.o x.c
cc x.o -o x
root@elab305:/home/joe/test/c# ./x
45 32 <--CORRECT
root@elab305:/home/joe/test/c#
Notice that when -Os (optimize for space rather than speed) is used, the
executable produces the correct result.
Also, doing the chained xor on the integer variables a and b themselves always
produces the correct result (regardless of optimization).
root@elab305:/home/joe/test/c# gcc --version
gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
. . .
root@elab305:/home/joe/test/c# uname -a
Linux elab305 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64
x86_64 x86_64 GNU/Linux
root@elab305:/home/joe/test/c# cat /etc/issue
Red Hat Enterprise Linux Server release 6.2 (Santiago)
Kernel \r on an \m
[Bug debug/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66653 --- Comment #4 from Aldy Hernandez --- Proposed patch and subsequent discussion: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01751.html
[Bug c/66673] swapping variables via chained xor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek --- And again you're invoking undefined behavior. Use -Wall.
[Bug c/66673] swapping variables via chained xor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673 --- Comment #2 from joe.carnuccio at qlogic dot com --- -Wall produces no warnings... root@elab305:/home/joe/test/c# make -B x -Wall cc-c -o x.o x.c cc x.o -o x root@elab305:/home/joe/test/c# ./x 0 32
[Bug c/66673] swapping variables via chained xor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673 --- Comment #3 from joe.carnuccio at qlogic dot com --- Sorry, I ment this: root@elab305:/home/joe/test/c# make -B x CFLAGS+='-Wall' cc -Wall -c -o x.o x.c cc x.o -o x root@elab305:/home/joe/test/c# ./x 0 32
[Bug c/39121] strange behavior in chained operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 --- Comment #7 from joe.carnuccio at qlogic dot com --- Ok, the sequence points are at each of the assignment operators. The crux of this is that doing the xor chain with dereferenced pointers fails (incorrect execution), whereas doing it with variables works... i.e. *a and *b are being treated differently than a and b; a ^= b ^= a ^= b is supposed to do the following: a = a ^ (b = b ^ (a = a ^ b)) from right-to-left each assignment is done in sequence (and has been verified to work correctly); *a ^= *b ^= *a ^= *b should work the same way, but it does not (unless you compile with -Os).
[Bug c/66673] swapping variables via chained xor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673 --- Comment #4 from joe.carnuccio at qlogic dot com --- if I do a ^= b ^= a ^= b it always work correctly; doing *p ^= *q ^= *p ^= *q fails (unless -Os is used); i.e. dereferenced pointers are being treated differently int a = 0x32, b = 0x45; int *p = &a, *q = &b;
[Bug c/66673] swapping variables via chained xor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673 --- Comment #5 from Markus Trippelsdorf --- https://www.google.com/?#q=nasal%20demons&lang=en
[Bug c/66673] swapping variables via chained xor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673 --- Comment #6 from Marek Polacek --- (In reply to joe.carnuccio from comment #2) > -Wall produces no warnings... Oh, you're using too old GCC. Please try a newer version.
[Bug c/39121] strange behavior in chained operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #8 from Manuel López-Ibáñez --- (In reply to joe.carnuccio from comment #7) > *a ^= *b ^= *a ^= *b should work the same way, but it does not (unless you > compile with -Os). https://gcc.gnu.org/wiki/FAQ#undefinedbut
[Bug c/66673] warning missing for undefined behavior when swapping variables via chained xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673
Manuel López-Ibáñez changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2015-06-25
CC||manu at gcc dot gnu.org
Resolution|INVALID |---
Summary|swapping variables via |warning missing for
|chained xor fails |undefined behavior when
||swapping variables via
||chained xor
Ever confirmed|0 |1
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Marek Polacek from comment #6)
> (In reply to joe.carnuccio from comment #2)
> > -Wall produces no warnings...
>
> Oh, you're using too old GCC. Please try a newer version.
To be fair, GCC 5.1 does not generate a warning either with -Wall -Wextra.
Neither does clang 3.7.
For this testcase:
void swap(int *a, int *b) {
*a ^= *b ^= *a ^= *b;
}
int main() {
int a = 5;
int b = 8;
printf("%d, %d\n", a, b);
a ^= b ^= a ^= b;
__builtin_printf("%d, %d\n", a, b);
swap(&a, &b);
__builtin_printf("%d, %d\n", a, b);
}
Clang warns:
20 : warning: unsequenced modification and access to 'a' [-Wunsequenced]
a ^= b ^= a ^= b;
but gcc is silent.
[Bug c/66673] Wsequence-point warning missing when swapping variables via chained xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic Version|4.4.6 |6.0 Summary|warning missing for |Wsequence-point warning |undefined behavior when |missing when swapping |swapping variables via |variables via chained xor |chained xor | Severity|major |enhancement --- Comment #8 from Manuel López-Ibáñez --- It seems a missing feature to me. There are several open PRs about Wsequence-point but this one does not seem to be one of them.
[Bug c/66673] Wsequence-point warning missing when swapping variables via chained xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673 Manuel López-Ibáñez changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Manuel López-Ibáñez --- Ops, this may have been added recently, it does warn with my GCC 6 build: test.c:2:6: warning: operation on ‘*a’ may be undefined [-Wsequence-point] *a ^= *b ^= *a ^= *b; ^ test.c:9:5: warning: operation on ‘a’ may be undefined [-Wsequence-point] a ^= b ^= a ^= b; ^ Oh, well, then this is INVALID. Sorry for the noise.
[Bug c++/65656] __builtin_constant_p should always be constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656 --- Comment #3 from Ryan Johnson --- (In reply to Jason Merrill from comment #2) > Author: jason > Date: Tue Apr 28 14:43:59 2015 > New Revision: 222531 > > URL: https://gcc.gnu.org/viewcvs?rev=222531&root=gcc&view=rev > Log: > PR c++/65656 > * constexpr.c (cxx_eval_builtin_function_call): Fix > __builtin_constant_p. > > Added: > trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-builtin3.C > Modified: > trunk/gcc/cp/ChangeLog > trunk/gcc/cp/constexpr.c Any reason this bug should not be closed as 'fixed' ?
[Bug c++/66674] New: name lookup failure in lambda construction in a member function of a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66674
Bug ID: 66674
Summary: name lookup failure in lambda construction in a member
function of a template class
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: huili80 at gmail dot com
Target Milestone: ---
The following causes internal compiler error with gcc4.8.2.
struct base
{
void foo(){};
};
template < typename >
struct derived : base
{
void foo()
{
auto l = [this](){base::foo();};
// workaround:
// auto l = [this](){this->base::foo();};
};
};
int main()
{
derived d;
d.foo();
}
[Bug target/65375] aarch64: poor codegen for vld2q_f32 and vst2q_f32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65375 --- Comment #13 from Ramana Radhakrishnan --- Or indeed PR 63277...
[Bug rtl-optimization/63277] ARM - NEON excessive use of vmov for vtbl2 / uint8x8x2 for shuffling data unnecessarily around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63277 Ramana Radhakrishnan changed: What|Removed |Added Blocks||47562 --- Comment #6 from Ramana Radhakrishnan --- Link to meta bug. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47562 [Bug 47562] [meta-bug] keep track of Neon enhancements
[Bug tree-optimization/66675] New: Could improve vector bit_field_ref style optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66675
Bug ID: 66675
Summary: Could improve vector bit_field_ref style
optimizations.
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ramana at gcc dot gnu.org
Target Milestone: ---
This example
#include
int main(int argc, char *argv[])
{
int8x8_t a = {argc, 1, 2, 3, 4, 5, 6, 7};
int8x8_t b = {0, 1, 2, 3, 4, 5, 6, 7};
int8x8_t c = vadd_s8(a, b);
return c[0];
}
or it's variant written in gcc vector speak generate pretty terrible code for
AArch64
main:
adr x1, .LC0
ld1 {v0.8b}, [x1]
ins v0.b[0], w0
adr x0, .LC2
ld1 {v1.8b}, [x0]
add v0.8b, v0.8b, v1.8b
umovw0, v0.b[0]
sxtbw0, w0
ret
.size main, .-main
This could well be folded down to a simple function that returns just argc.
While this is a bit silly to expect in real life, it does show an interesting
example
regards
Ramana
[Bug tree-optimization/66675] Could improve vector bit_field_ref style optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66675 Ramana Radhakrishnan changed: What|Removed |Added Keywords||missed-optimization Target||aarch64*-*-*, arm*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-25 Blocks||47562 Ever confirmed|0 |1 Severity|normal |enhancement Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47562 [Bug 47562] [meta-bug] keep track of Neon Intrinsics enhancements
[Bug tree-optimization/66675] Could improve vector lane folding style operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66675
--- Comment #1 from Ramana Radhakrishnan ---
The GCC vector speak variant is as below.
typedef char v8qi __attribute__ ((vector_size (8)));
int main(int argc, char *argv[])
{
v8qi a = {argc, 1, 2, 3, 4, 5, 6, 7};
v8qi b = {0, 1, 2, 3, 4, 5, 6, 7};
v8qi c = a + b;
return c[0];
}
True on both arm and aarch64 - I haven't checked other targets.
[Bug c++/66674] name lookup failure in lambda construction in a member function of a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66674 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Markus Trippelsdorf --- gcc-4.8 isn't supported anymore. Please use a more recent compiler.
[Bug c/66673] Wsequence-point warning missing when swapping variables via chained xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66673 Markus Trippelsdorf changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug target/47562] [meta-bug] keep track of Neon Intrinsics enhancements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47562 Ramana Radhakrishnan changed: What|Removed |Added Target|arm-linux-gnueabi, arm-eabi |arm-linux-gnueabi, ||arm-eabi, aarch64*-*-* --- Comment #1 from Ramana Radhakrishnan --- It is expected that quite a lot of the improvements required for the intrinsics will be applicable to both the AArch64 and the ARM backends.
[Bug rtl-optimization/65912] x_rtl.x_frame_offset not updated after frame related insn deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65912 Ramana Radhakrishnan changed: What|Removed |Added Keywords||missed-optimization Target||aarch64*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-25 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan --- Confirmed then.
[Bug rtl-optimization/65912] x_rtl.x_frame_offset not updated after frame related insn deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65912 Ramana Radhakrishnan changed: What|Removed |Added Blocks||47562 --- Comment #3 from Ramana Radhakrishnan --- Technically blocks 47562 as this is another intrinsics related issue. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47562 [Bug 47562] [meta-bug] keep track of Neon Intrinsics enhancements
[Bug driver/66657] Feature request - assembly output from lto compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66657 --- Comment #3 from Kenneth Almquist --- (In reply to Andrew Pinski from comment #2) > What are you trying to do with the assembly after the fact? In this particular case, I wanted to look at it for two reasons: 1) To determine which functions were being inlined. 2) To identify errant calls to printf and puts. When compiled to run in background mode, my program should send all messages to the log rather than stdout/stderr, so calls to printf/puts that the compiler doesn't discard as unreachable represent program bugs. Gcc has had the -S option for essentially forever, and I've probably used it more times and for more reasons than I can remember at this point.
[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #43 from Kazumoto Kojima --- (In reply to John Paul Adrian Glaubitz from comment #42) > Is it applied yet? Otherwise I really will have to look into building gcc-5 > from SVN myself. It's not.
[Bug tree-optimization/66675] Could improve vector lane folding style operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66675 --- Comment #2 from Andrew Pinski --- Basically VECTOR_CST + VECTOR_CST is not optimized at all. I bet almost all operations that act on VECTOR_CST are not optimized including and not limited to PLUS, SUB, MULTIPLY, DIVIDE, SHIFT, IOR, XOR, and AND.
[Bug tree-optimization/66675] Could improve vector lane folding style operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66675 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Basically VECTOR_CST + VECTOR_CST is not optimized at all. I bet almost all > operations that act on VECTOR_CST are not optimized including and not > limited to PLUS, SUB, MULTIPLY, DIVIDE, SHIFT, IOR, XOR, and AND. Or rather CONSTRUCTOR + VECTOR_CST. We I suspect having a VECTOR_EXPR instead of a CONSTRUCTOR can help in those cases.
[Bug tree-optimization/66675] Could improve vector lane folding style operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66675 --- Comment #4 from Andrew Pinski --- Note for this optimization to be useful there needs to be a heurstic to find out if folding CONSTRUCTOR + VECTOR_CST is going to be only one or no other add. Or using one element of the whole vector. AKA it might not be profit able to fold CONSTRUCTOR + VECTOR_CST to CONSTRUCTOR with all scalar additions.
[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #44 from Oleg Endo --- Author: olegendo Date: Thu Jun 25 23:12:07 2015 New Revision: 224988 URL: https://gcc.gnu.org/viewcvs?rev=224988&root=gcc&view=rev Log: gcc/ PR target/65979 PR target/66611 * config/sh/sh.md (tstsi_t peephole2): Use insn_invalid_p to check if the replacement insn will work. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug target/66611] SH: ICE on -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66611 --- Comment #3 from Oleg Endo --- Author: olegendo Date: Thu Jun 25 23:12:07 2015 New Revision: 224988 URL: https://gcc.gnu.org/viewcvs?rev=224988&root=gcc&view=rev Log: gcc/ PR target/65979 PR target/66611 * config/sh/sh.md (tstsi_t peephole2): Use insn_invalid_p to check if the replacement insn will work. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug c++/66676] New: pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66676
Bug ID: 66676
Summary: pragma omp simd aligned(x) results in "internal
compiler error: Segmentation fault"
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: schreiberx at gmail dot com
Target Milestone: ---
Created attachment 35855
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35855&action=edit
reproducer of bug
The Compiler segfaults if declaring a function with
#pragma omp declare simd aligned(i_x)
void ODEBenchmark_OpenMP_ver2(double *i_x){}
By specifying the alignment such as via
#pragma omp declare simd aligned(i_x:128)
void ODEBenchmark_OpenMP_ver2(double *i_x){}
compiles the program.
GCC version 5.1.0
Compile attached source code with
g++ -fopenmp ODEBenchmark.cpp
to reproduce bug.
[Bug c++/66676] pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66676 Martin Schreiber changed: What|Removed |Added Severity|normal |major
[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #45 from Oleg Endo --- Kaz, I wanted to backport the patch to GCC 5. It doesn't apply because on trunk gen_rtx_SET doesn't take a machine_mode arg. Since SET rtx is always VOIDmode, it has been removed. In GCC 5 though, SImode is used for gen_rtx_SET (see your comment #20). Why is that SImode? It should be VOIDmode, shouldn't it?
[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #46 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #45) > Kaz, I wanted to backport the patch to GCC 5. It doesn't apply because on > trunk gen_rtx_SET doesn't take a machine_mode arg. Since SET rtx is always > VOIDmode, it has been removed. In GCC 5 though, SImode is used for > gen_rtx_SET (see your comment #20). Why is that SImode? It should be > VOIDmode, shouldn't it? You are right. I should be VOIDmode, though SImode will work for these cases.
