[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- You always need to use the libstdc++ that is bundled with the compiler.
[Bug ada/66437] False Positive warning "Variable is not modified in loop body"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66437 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-06-06 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- 4.7.x is not supported anymore, please try more recent versions. IIRC this was fixed at some point.
[Bug c++/66355] defining a constructor inhibits optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66355 --- Comment #2 from Marc Glisse --- PR 65197 has links to a number of related PRs. The middle-end has no code to handle the case where we detect "late" (i.e. not in the front-end) that the initialization is constant.
[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 --- Comment #2 from Andrew Pinski --- (In reply to Andreas Schwab from comment #1) > You always need to use the libstdc++ that is bundled with the compiler. Actually that is true but that does not make this bug a valid bug. What is mentioned is c++11 abi breaks between 4.9 and 5. So this bug is still invalid but a slightly different reason. From now (5), gcc will no longer break the abi.
[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Do you plan to backport this to gcc-5-branch?
[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 --- Comment #10 from Kai Tietz --- Yeah, thanks for working on that. With extensions shown by Jouni, the patch is preapproved. Jonathan, will you take care?
[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258 --- Comment #6 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #5) > Do you plan to backport this to gcc-5-branch? As I mentioned this is really needed to compile grub so if it is not back ported, you can't compile a full Linux distro using gcc 5 at all.
[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 --- Comment #11 from Jonathan Wakely --- Yes, I'll deal with it.
[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 --- Comment #3 from Jonathan Wakely --- Indeed. Before gcc-5 it was never supported to combine C++11 objects compiled with different major versions. The whole point of calling C++11 support experimental was that we reserved the right to make incompatible changes to the C++11 features, otherwise you'd be forever stuck with the partial C++0x support added around the gcc-4.4 timeframe.
[Bug libstdc++/66262] [REGRESSION] testsuite failure with libstdc++ (gcc-5) and g++-4.9 together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66262 --- Comment #16 from Jonathan Wakely --- PR66438 has a proper analysis of this issue (and it isn't related to PR66145)
[Bug libstdc++/66441] wstring_convert not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66441 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-06 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Leo Carreon from comment #0) > In my opinion, there is a problem with the way wstring_convert behaves. In my opinion there's a problem with the way wstring_convert is designed, but it's also likely I made a mistake implementing it.
[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 --- Comment #4 from Gianfranco --- The problem actually is Debian has gcc-4.9 as default compiler, and the libstdc++ provided in testing is from gcc-5.
[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 James Y Knight changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from James Y Knight --- Sorry, please try again. Andreas Schwab: I did compile it with the libstdc++ that came with the compiler -- and then I upgraded the binary libstdc++.so to the newer one that came with gcc 5. And it broken. Thus the report of breaking binary compat. (It also happens with new compiles in Debian because of what Gianfranco says) Andrew Pinski: The *one and only purpose* of the file libstdc++-v3/src/c++11/compatibility-c++0x.cc is to provide binary compatibility for c++11 binaries compiled against older libstdc++ versions, and now running against a newer one. If libstdc++.so.6, version 5.1, is not supposed to work properly with c++ binaries compiled by the 4.9 compiler, it should not be providing these compatibility symbols at all. Since it does provide them, there is clearly intent to provide compatibility so, it ought to work. Or they should be deleted...
[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Jonathan Wakely --- (In reply to James Y Knight from comment #5) > The *one and only purpose* of the file > libstdc++-v3/src/c++11/compatibility-c++0x.cc is to provide binary > compatibility for c++11 binaries compiled against older libstdc++ versions, > and now running against a newer one. It ensures they will still link. > If libstdc++.so.6, version 5.1, is not supposed to work properly with c++ > binaries compiled by the 4.9 compiler, it should not be providing these > compatibility symbols at all. I would prefer that, but it's not our policy. > Since it does provide them, there is clearly intent to provide compatibility I didn't realise you were the maintainer and knew what's supposed to work. Oh wait, you're not :-)
[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 --- Comment #7 from Jonathan Wakely --- If you can provide a patch that makes it work without any unwanted side effects then I'll certainly look at it, but mixing versions for C++11 code is unsupported, and so I'm not going to spend my time trying to make it work.
[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 --- Comment #8 from Jonathan Wakely --- Created attachment 35708 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35708&action=edit Compare old and new categories This fixes this specific testcase, but not all cases (if you compare error_condition objects created in different translation unit compiled with different GCC versions then whether it works depends on which error_condition is on the left-hand side).
[Bug tree-optimization/66442] New: [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 Bug ID: 66442 Summary: [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: vries at gcc dot gnu.org Blocks: 65443 Target Milestone: --- Target: m68k-*-* $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/autopar/pr46885.c -O -ftree-parallelize-loops=4 -fcompare-debug -fno-tree-dominator-opts -funswitch-loops -S -o pr46885.s xgcc: error: ../gcc/testsuite/gcc.dg/autopar/pr46885.c: -fcompare-debug failure Removing any of the flags causes the failure to disappear. d38409cd8b970f3d3657ca979a3235bfb54ad3ff is the first bad commit commit d38409cd8b970f3d3657ca979a3235bfb54ad3ff Author: vries Date: Fri Jun 5 15:57:34 2015 + git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@224154 138bc75d-0d04-0410-961f-82ee72b054a4 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443 [Bug 65443] Don't peel last iteration from loop in transform_to_exit_first_loop
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |6.0
[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 --- Comment #9 from James Y Knight --- What good is having special code to allow linking compatibility, if the program then can't work anyways? Isn't that anti-useful? > I didn't realise you were the maintainer and knew what's supposed to work. No, of course...I'm only a user > If you can provide a patch I'm not certain, but it seems like probably the old-ABI error_category::default_error_condition(int) ought to just return an error_condition also with the old ABI, instead of the new one? CC'ing debian's gcc maintainer, because the stated lack of desire for compatibility between libstdc++ version 5, and g++ 4.9 seems like it's probably something he wasn't aware of when upgrading.
[Bug libstdc++/66438] libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438 James Y Knight changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #10 from James Y Knight --- Oops, actually cc'ing doko this time (hopefully.)
[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47359 --- Comment #4 from Thomas Koenig --- Author: tkoenig Date: Sat Jun 6 16:12:39 2015 New Revision: 224190 URL: https://gcc.gnu.org/viewcvs?rev=224190&root=gcc&view=rev Log: 2015-06-06 Thomas Koenig PR fortran/47359 * arith.c (eval_intrinsic_op): Set warn flag for gfc_type_convert_binary if -Wconversion or -Wconversion-extra are set. (wprecision_real_real): New function. (wprecision_int_real): New function. (gfc_int2int): If -fno-range-check and -Wconversion are specified and it is a narrowing conversion, warn. (gfc_int2real): If there is a change in value for the conversion, warn. (gfc_int2complex): Likewise. (gfc_real2int): If there is a fractional part to the real number, warn with -Wconversion, otherwise warn with -Wconversion-extra. (gfc_real2real): Emit warning if the constant was changed by conversion with either -Wconversion or -Wconversion-extra. With -Wconversion-extra, warn if no warning was issued earlier. (gfc_real2complex): Likewise. (gfc_complex2int): For -Wconversion or -Wconversion-extra, if there was an imaginary part, warn; otherwise, warn for change in value. Warn with -Wconversion-extra if no other warning was issued. (gfc_complex2real): For -Wconversion or -Wconversion-extra, if there was an imaginary part, warn; otherwise, warn for change in value. Warn with -Wconversion-extra if no other warning was issued. (gfc_complex2complex): For -Wconversion, warn if the value of either the real or the imaginary part was changed. Warn for -Wconversion-extra if no prior warning was issued. * expr.c (gfc_check_assign): Remove check for change in value. * primary.c (match_real_constant): For -Wconversion-extra, check against a number in which the last non-zero digit has been replaced with a zero. If the number compares equal, warn. * intrinsic.c (gfc_convert_type_warn): Do not warn about constant conversions. 2015-06-06 Thomas Koenig PR fortran/47359 * gfortran.dg/array_constructor_type_17.f03: Adjust error message. * gfortran.dg/warn_conversion.f90: Add warning for change in value for assignment. * gfortran.dg/warn_conversion_3.f90: Add warnings. * gfortran.dg/warn_conversion_5.f90: New test. * gfortran.dg/warn_conversion_6.f90: New test. * gfortran.dg/warn_conversion_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/warn_conversion_5.f90 trunk/gcc/testsuite/gfortran.dg/warn_conversion_6.f90 trunk/gcc/testsuite/gfortran.dg/warn_conversion_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/array_constructor_type_17.f03 trunk/gcc/testsuite/gfortran.dg/warn_conversion.f90 trunk/gcc/testsuite/gfortran.dg/warn_conversion_3.f90
[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47359 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Sat Jun 6 16:16:03 2015 New Revision: 224191 URL: https://gcc.gnu.org/viewcvs?rev=224191&root=gcc&view=rev Log: 2015-06-06 Thomas Koenig PR fortran/47359 * ChangeLog: Correct PR number in previous commit. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug fortran/47659] -Wconversion[-extra] should emit warning for constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Thomas Koenig --- With this commit https://gcc.gnu.org/viewcvs?rev=224190&root=gcc&view=rev we should have most cases covered.
[Bug middle-end/39366] Memory Leak in Exception Handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39366 Bill Torpey changed: What|Removed |Added CC||bill.torpey at ullink dot com --- Comment #9 from Bill Torpey --- Looks like this may have been fixed in glibc: https://sourceware.org/bugzilla/show_bug.cgi?id=12650
[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47359 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig --- (In reply to Thomas Koenig from comment #5) > Author: tkoenig > Date: Sat Jun 6 16:16:03 2015 > New Revision: 224191 Of course, this was a commit for PR 47659. One day, I will get the PR numbers right... hopefully.
[Bug c++/66443] New: Virtual inheritance vs. non-default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66443
Bug ID: 66443
Summary: Virtual inheritance vs. non-default constructors
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vpozdyayev at gmail dot com
Target Milestone: ---
This code has become valid in C++14, see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1611 (and #1658).
Current result:
main.cpp: In constructor 'C::C()':
main.cpp:13:15: error: use of deleted function 'B::B()'
...
class A {
public:
A( int ) { }
};
class B: virtual public A {
public:
virtual void do_something() = 0;
};
class C: public B {
public:
C(): A( 1 ) { }
virtual void do_something() { }
};
int main() {
C c;
return 0;
}
[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319 --- Comment #7 from John David Anglin --- Author: danglin Date: Sat Jun 6 18:33:06 2015 New Revision: 224192 URL: https://gcc.gnu.org/viewcvs?rev=224192&root=gcc&view=rev Log: PR bootstrap/66319 * config/pa/pa-hpux10.h (TARGET_OS_CPP_BUILTINS): Rearrange builtin defines. Define _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE for c++. Define _XOPEN_UNIX and _XOPEN_SOURCE_EXTENDED for c++ if unix95 or later. * config/pa/pa-hpux11.h (TARGET_OS_CPP_BUILTINS): Likewise. Define _INCLUDE_STDC_SOURCE_PRE_199901, _INCLUDE_STDC_SOURCE_199901, _INCLUDE_XOPEN_SOURCE_PRE_500, _INCLUDE_XOPEN_SOURCE_520, _INCLUDE_XOPEN_SOURCE_PRE_600 and _INCLUDE_XOPEN_SOURCE_600 for c++ and non iso if unix2003. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa-hpux10.h trunk/gcc/config/pa/pa-hpux11.h
[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319 --- Comment #8 from John David Anglin --- Author: danglin Date: Sat Jun 6 18:35:16 2015 New Revision: 224193 URL: https://gcc.gnu.org/viewcvs?rev=224193&root=gcc&view=rev Log: PR bootstrap/66319 * config/pa/pa-hpux10.h (TARGET_OS_CPP_BUILTINS): Rearrange builtin defines. Define _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE for c++. Define _XOPEN_UNIX and _XOPEN_SOURCE_EXTENDED for c++ if unix95 or later. * config/pa/pa-hpux11.h (TARGET_OS_CPP_BUILTINS): Likewise. Define _INCLUDE_STDC_SOURCE_PRE_199901, _INCLUDE_STDC_SOURCE_199901, _INCLUDE_XOPEN_SOURCE_PRE_500, _INCLUDE_XOPEN_SOURCE_520, _INCLUDE_XOPEN_SOURCE_PRE_600 and _INCLUDE_XOPEN_SOURCE_600 for c++ and non iso if unix2003. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/pa/pa-hpux10.h branches/gcc-5-branch/gcc/config/pa/pa-hpux11.h
[Bug rtl-optimization/66444] New: [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444
Bug ID: 66444
Summary: [5/6 Regression] Miscompilation of Xen since r211078
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org, vries at gcc dot gnu.org
Target Milestone: ---
void foo (unsigned long);
int bar (unsigned long);
unsigned long a, c, d, f, g;
volatile void *b;
int e;
struct S { unsigned long p, q, r; void *v; };
void fn2 (struct S *x);
__attribute__((noinline, noclone)) void *
fn1 (struct S *x)
{
unsigned long y = x->q;
unsigned long z = a;
do
{
if ((x->q + 2 & 1UL << 63 - 10) <= 2)
return (void *) 0;
}
while (y = z != x->q);
return x->v ? x->v : (void *) 0;
}
int
baz (void)
{
foo (f);
struct S *x = (struct S *) 0xe0UL;
x += bar (f);
fn1 (x);
fn2 (x);
return 0;
}
reduced from Xen is miscompiled at -O2 starting with r211078 on x86_64-linux.
Still in *.optimized dump we have:
_6 = bar (f.0_4);
_7 = (long unsigned int) _6;
_8 = _7 * 32;
x_9 = 962072674304B + _8;
fn1 (x_9);
fn2 (x_9);
(note the same value, constant + 32 * result of bar) is passed to both fn1 and
fn2.
But starting with *.reload we get:
movabsq $962072674304, %r8
salq$5, %rax
leaq(%r8,%rax), %rdi
callfn1
movq%r8, %rdi
callfn2
which is wrong, it passes just the constant, without the added 32 * bar (), to
the second function.
[Bug rtl-optimization/66444] [5/6 Regression] Miscompilation of Xen since r211078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66444 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-06 Target Milestone|--- |5.2 Ever confirmed|0 |1
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-06 Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/66445] [5/6 Regression] ICE with lambda in stmt expression in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66445 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-06 Target Milestone|--- |5.2 Ever confirmed|0 |1
[Bug c++/66445] New: [5/6 Regression] ICE with lambda in stmt expression in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66445
Bug ID: 66445
Summary: [5/6 Regression] ICE with lambda in stmt expression in
a template
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
template void foo ()
{
auto a = ({ [=] {}; });
}
ICEs with -std=c++11 as well as -std=c++14 starting with r217748.
The diagnostics is:
rh1228916.ii: In function ‘void fn1()’:
rh1228916.ii:3:24: sorry, unimplemented: unexpected AST of kind type_decl
auto a = ({ [=] {}; });
^
rh1228916.ii:3:24: internal compiler error: in potential_constant_expression_1,
at cp/constexpr.c:4235
[Bug tree-optimization/66442] [6 regression] FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66442
--- Comment #1 from vries at gcc dot gnu.org ---
The problem is here:
...
static bool
try_transform_to_exit_first_loop_alt (struct loop *loop,
reduction_info_table_type
*reduction_list,
tree nit)
{
/* Check whether the latch contains a single statement. */
if (!gimple_seq_singleton_p (bb_seq (loop->latch)))
return true;
...
First of all, the 'return true' should be 'return false'. That fixes the
-fcompare-debug failure, but means that with and without -g, we return false at
a different location in try_transform_to_exit_first_loop_alt.
The gimple_seq_singleton_p returns different results with and without -g, we
need to use a 'gimple_seq_nondebug_singleton_p'.
[Bug c/66348] Simple loop never exits with -O1, exits with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #11 from Sebastiano Vigna ---
Dear Mikhail,
I have several ongoing open-source projects and, believe me, I make exactly the
same recommendation to people reporting bugs. They are perfectly sensible and
certainly the way to go in 99% of the cases.
The problem is that we face what is called a "heisenbug". Any tentative to
observe it or reproduce it fails. Add ubsan: no bug. Add a print in the loop:
no bug. Isolate the behaviour by having a main() calling the faulty function
with the same parameters: no bug.
Reproducing requires running ne (the nice editor) on a machine with at least
256GB of RAM, opening a 30GB file and running a specified macro. I don't think
this is doable. But if anybody is interested in reproducing the bug, I can
provide an account, given ssh credentials, and a directory with all necessary
instructions. Running ne using the given macro reproduces exactly the bug. But
all my tentatives to reduce the size of the source failed miserably.
Heisenbugs are very often (but not always) compiler bugs. In our case, I
finally settled for
// Problematic loop
for(int64_t i = 0; i < b->num_lines - 1 - n; i++) {
if ( i == -1 ) fputc('.', stderr); // ***
ld = (line_desc *)ld->ld_node.prev;
}
I just added the line marked ***. It does nothing--i is never -1. Nothing is
ever printed. But now the code runs correctly when using -O3.
Does this prove that I'm facing a compiler bug? I don't know for certain, but
I'm pretty sure it does, and considering the very short function in which the
bug appears it would be probably easy to check whether this is true or not.
[Bug c/66348] Simple loop never exits with -O1, exits with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #12 from Sebastiano Vigna --- BTW, to further restrict the search I'm trying to replicate the bug with -fsanitize=address, or at least to get to the problematic call under -fsanitize=address, but it'll take a while. I have to recompile the gcc suite, as the current version of libasan does not allocate more than 64GB (in Fedora, libasan is built with gcc).
[Bug debug/66446] New: Incorrect symbol output with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66446
Bug ID: 66446
Summary: Incorrect symbol output with -fno-omit-frame-pointer
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: smokeyjoe4u at hotmail dot com
Target Milestone: ---
Created attachment 35709
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35709&action=edit
Test case in C.
I realize I must be the only person on the planet still using STABs. When the
following test case is compiled, GCC emits the wrong location for stack-based
variables. In this case, the variable LocalList is at ebp-0x20, but GCC emits a
symbol indicating it is at ebp-0x10. If I reduce the code further, then the
stack offsets all change and become consistent with the reported STABs. From my
limited sample size, it appears that when the symbols are wrong, they're always
off by 16. The bug exhibits itself on -O1 through -O3, but not -O0.
I'm using GCC 4.8.2 on Ubuntu, but have also verified the issue on 4.9.2. The
last build not to exhibit the issue was GCC 4.7.4.
I tried debugging this myself but got lost in all the RTL and optimizations. It
appears the RTL hanging off the current_function_decl indicates LocalList at
argp-8, which is then eliminated to hardfp-16. But the RTL used to actually
emit assembly seems to be somewhere entirely different (and is always ebp-32),
and I can't figure out how the two are (or should be) connected.
gcc -O1 -fno-omit-frame-pointer -gstabs+ -m32 -S ./t.c
t.c:
typedef struct _LIST_ENTRY LIST_ENTRY, *PLIST_ENTRY;
struct _LIST_ENTRY {
PLIST_ENTRY Next;
PLIST_ENTRY Previous;
};
typedef struct _MYSTRUCT MYSTRUCT, *PMYSTRUCT;
struct _MYSTRUCT {
unsigned int Member;
};
LIST_ENTRY MyGlobalList;
void
Nonsense (
)
{
PLIST_ENTRY CurrentEntry;
PMYSTRUCT MyStruct;
LIST_ENTRY LocalList;
LocalList.Next = MyGlobalList.Next;
CurrentEntry = LocalList.Next;
while (CurrentEntry != &LocalList) {
MyStruct = (PMYSTRUCT)CurrentEntry;
CurrentEntry = CurrentEntry->Next;
Nonsense(MyStruct->Member);
Nonsense(MyStruct);
}
return;
}
===
Output:
... (snip) ...
Nonsense:
...
leal-32(%ebp), %eax <<< The variable LocalList is at -32(%ebp)
...
.size Nonsense, .-Nonsense
.stabs "LocalList:(0,19)",128,0,23,-16 <<< The stabs being generated
are telling me it's at -16(%ebp).
...
.Letext0:
.ident "GCC: (Ubuntu 4.8.2-19ubuntu1) 4.8.2"
===
specifics (this is just the stock Ubuntu compiler):
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
[Bug c/66447] New: -Werror=maybe-uninitialized indicates trashing of variable across longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66447 Bug ID: 66447 Summary: -Werror=maybe-uninitialized indicates trashing of variable across longjmp Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jbowler at acm dot org Target Milestone: --- Download libpng-1.6.17.tar (this version, not the next one which will have work-round, you may have to look in the archives for this version), e.g.: ftp ftp.simplesystems.org cd pub/png/src/libpng16 get libpng-1.6.17.tar.xz quit Extract, e.g: tar xf libpng-1.6.17.tar.xz cd libpng-1.6.17 Then: mkdir test cd test CFLAGS="-pedantic -ansi -O2 -Wall" cC=gcc-5.1.0 ../configure --enable-werror make pngvalid Expect: successful compilation of pngvalid.c Observe: ../contrib/libtests/pngvalid.c:4038:30: error: 'exception_prev_1' may be used uninitialized in this function The second error will be fixed in later versions. This one seems to be bogus; the variable (actually exception__prev, #defined to eliminate warnings about shadows) is not modified between the setjmp and the longjmp, therefore this is valid, totally conformant ANSI-C90. The "-pendantic -ansi" is unnecessary to show the problem, I just put it in because: a) That is what libpng is. b) ANSI X3.159-1989 4.6.2.1 lines 11-14; I believe the variable must be preserved across setjmp/longjmp. John Bowler
[Bug target/66258] compiling a stdarg function with arch +nofp generates an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66258 --- Comment #7 from jim.wilson at linaro dot org --- On Sat, Jun 6, 2015 at 2:02 AM, pinskia at gcc dot gnu.org wrote: >> Do you plan to backport this to gcc-5-branch? I didn't realize it was broken on the gcc-5 release branch. I only checked mainline. I can check the gcc-5 release branch and backport, but I'm a little out of touch, and not sure what approval I need for the backport. If I can't backport to the FSF gcc-5 release branch for some reason, I can backport to the linaro gcc-5 branch instead. I've also discovered that I got a little bad info on grub. The person who tried -mgeneral-regs-only accidentally compiled linux user space with that option, which is why the build with it failed. Grub itself apparently doesn't use FP. So with correct makefiles, changing grub to use -mgeneral-regs-only instead of +nofp does solve the problem. Since the linux kernel already uses -mgeneral-regs-only, and this option is (presumably) not broken in gcc-5, I believe that grub will be changed to use -mgeneral-regs-only to match the kernel, in which case a build will work with gcc-5. There is still the problem that grub versions before the change was made (this week? last week?) will still fail with gcc-5 unless the patch is backported, or users make local mods to grub to use -mgeneral-regs-only instead of +nofp. Jim
