[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #8 from Jürgen Reuter --- Hi Erik, your patch works beyond the point where the problem occurs first, but then the sanitizer still fails bootstrapping: In file included from /usr/include/sys/sysctl.h:83, from ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:70: /usr/local/packages/gcc_9.0/_build/gcc/include-fixed/sys/ucred.h:106:2: error: '_Atomic' does not name a type 106 | _Atomic u_long cr_ref; /* reference count */ | ^~~ In file included from ../../../../libsanitizer/sanitizer_common/sanitizer_flags.h:15, from ../../../../libsanitizer/sanitizer_common/sanitizer_common.h:17, from ../../../../libsanitizer/sanitizer_common/sanitizer_mac.h:14, from ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:14: ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc: In member function 'void __sanitizer::BlockingMutex::CheckLocked()': ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:406:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] 406 | CHECK_NE(*(OSSpinLock*)&opaque_storage_, 0); | ^ ../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:292:46: note: in definition of macro 'CHECK_IMPL' 292 | __sanitizer::u64 v1 = (__sanitizer::u64)(c1); \ | ^~ ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:406:3: note: in expansion of macro 'CHECK_NE' 406 | CHECK_NE(*(OSSpinLock*)&opaque_storage_, 0); | ^~~~ ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc: In function 'void* __sanitizer::internal_start_thread(void (*)(void*), void*)': ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:578:47: warning: cast between incompatible function types from 'void (*)(void*)' to 'void* (*)(void*)' [-Wcast-function-type] 578 | pthread_create(&th, 0, (void*(*)(void *arg))func, arg); | ^~~~ make[4]: *** [sanitizer_mac.lo] Error 1
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #9 from Jürgen Reuter --- Trying to continue that fix I get loads and loads of other error in the libsanitizer :(
[Bug target/83531] Build broken on macOS 10.13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531 --- Comment #8 from Iain Sandoe --- (In reply to Erik Schnetter from comment #7) > I don't think that people didn't notice. I rather think that they gave up > building the sanitizer. See also > https://github.com/spack/spack/tree/develop/var/spack/repos/builtin/packages/ > gcc and > https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/ > gcc/darwin/headers-10.13-fix.patch , which includes this fix automatically > when GCC is built via Spack. see comment #3 For the record, I build the sanitisers on all systems > Darwin10/macOS 10.6 (where it's no longer supported upstream and is now pretty broken). However, I don't build all the older systems that often - but (for example) - see https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg00055.html So .. I agree that we have test issues with headers [ comment #4 ] (and those need resolving in a general way, not piecemeal) - but AFAICT bootstrap is not broken on current 10.13. [maybe someone is using a different version of the SDK from me? if so, please be specific about the version of Xcode and the SDK in use, thanks.]
[Bug c++/89869] -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-03-29 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, lemme take a look.
[Bug c++/61259] Spurious "ISO C++ forbids zero-size array" warning with -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61259 ilja.honkonen at fmi dot fi changed: What|Removed |Added CC||ilja.honkonen at fmi dot fi --- Comment #3 from ilja.honkonen at fmi dot fi --- Still seeing this with gcc 8.3.1.
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #10 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #9) > Trying to continue that fix I get loads and loads of other error in the > libsanitizer :( I'm not sure that there's a valid "fix includes" replacement for _Atomic (sure, you can get the code to compile - but it won't be doing what was intended). In the short-term, I'd suggest picking up the previous version of Xcode command line tools [e.g.10.1] (from developer.apple.com) and using the SDK from that? While this gets fixed. you can point to a specific SDK for configure with something like: .../configure --with-sysroot=/path/to/SDK . CC="gcc --sysroot=/path/to/SDK" CXX="g++ --sysroot=/path/to/SDK" (or CC="clang.. CXX="clang++).
[Bug middle-end/89725] ICE in get_fnname_from_decl, at varasm.c:1723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
--- Comment #8 from Richard Biener ---
(In reply to bin cheng from comment #7)
> I am testing below simple fix, it bypass access functions doesn't belong to
> analyzing loop_nest:
>
> diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
> index e536b463e96..410d44f43e8 100644
> --- a/gcc/tree-data-ref.c
> +++ b/gcc/tree-data-ref.c
> @@ -4272,6 +4272,7 @@ build_classic_dist_vector_1 (struct
> data_dependence_relation *ddr,
> {
>unsigned i;
>lambda_vector init_v = lambda_vector_new (DDR_NB_LOOPS (ddr));
> + struct loop *loop = DDR_LOOP_NEST (ddr)[0];
>
>for (i = 0; i < DDR_NUM_SUBSCRIPTS (ddr); i++)
> {
> @@ -4302,6 +4303,15 @@ build_classic_dist_vector_1 (struct
> data_dependence_relation *ddr,
> return false;
> }
>
> + /* When data references are collected in a loop while data
> +dependences are analyzed in loop nest nested in the loop, we
> +would have more number of access functions than number of
> +loops. Skip access functions of loops not in the loop nest.
> +
> +See PR89725 for more information. */
> + if (flow_loop_nested_p (get_loop (cfun, var_a), loop))
> + continue;
> +
> dist = int_cst_value (SUB_DISTANCE (subscript));
> index = index_in_loop_nest (var_a, DDR_LOOP_NEST (ddr));
> *index_carry = MIN (index, *index_carry);
>
> Plus the assert in index_in_loop_nest.
I wondered about chrecs like { 1, +, { 0 +, 1 }_1 }_2 (inner loop step
or initial value evolves wrt outer loop). We'd not catch that here.
Also if the above is possible then why not simply strip those
subscripts when we build the DDR? That way the few other cases
we do index_in_loop_nest also are "fixed".
Meanwhile testing of my patch finished but shows an ICE for
FAIL: gfortran.dg/vect/pr81303.f -O scan-tree-dump-times linterchange "is
in
terchanged" 1
FAIL: gfortran.dg/vect/pr81303.f -O (internal compiler error)
FAIL: gfortran.dg/vect/pr81303.f -O (test for excess errors)
#1 0x00a61759 in vec::operator[] (
this=0x3119f50 = {...}, ix=3)
at /space/rguenther/src/gcc-sccvn/gcc/vec.h:845
845 gcc_checking_assert (ix < m_vecpfx.m_num);
(gdb)
#3 0x01f2723a in should_interchange_loops (i_idx=3, o_idx=2,
datarefs=..., i_stmt_cost=41, o_stmt_cost=5, innermost_loops_p=true,
dump_info_p=true)
at /space/rguenther/src/gcc-sccvn/gcc/gimple-loop-interchange.cc:1460
1460 tree iloop_stride = (*stride)[i_idx], oloop_stride =
(*stride)[o_idx];
where the interchange code would need further changes for my change of the
loop-nest for DDRs.
That said, can we strip subscripts for outer loops in
initialize_data_dependence_relation when we compute them?
OTOH the cases where we can ignore the subscript are not so clear
given that the outer loop behavior can very well compute
non-aliasing. So selectively pruning just the unwanted distance
vectors looks safe.
But what about similar code in add_multivariate_self_dist or
add_other_self_distances?
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #11 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #10) > In the short-term, I'd suggest picking up the previous version of Xcode > command line tools [e.g.10.1] (from developer.apple.com) and using the SDK > from that? While this gets fixed. with "while this gets fixed" you mean waiting for an update from the Apple side (like an XCode 10.2.1 update or so), or a 'proper' fix from the gcc side? And if it is a fix from the Apple side, how will I know that an update contains the desired fix?
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #12 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #11) > (In reply to Iain Sandoe from comment #10) > > > In the short-term, I'd suggest picking up the previous version of Xcode > > command line tools [e.g.10.1] (from developer.apple.com) and using the SDK > > from that? While this gets fixed. > > with "while this gets fixed" you mean waiting for an update from the Apple > side (like an XCode 10.2.1 update or so),\ Yes. > or a 'proper' fix from the gcc side? Well, this doesn't seem to be a GCC bug - but if someone can propose a work-around, that's fine (I just have doubts that a fix includes will be enough). > And if it is a fix from the Apple side, how will I know that an update > contains the desired fix? We will only be able to figure that out by testing it - of course, if you file a radar about it - then presumably that would be updated when it's fixed.
[Bug c++/89858] crash with libmpfr.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89858 --- Comment #8 from Hans Buchmann --- Created attachment 46054 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46054&action=edit /proc/cpuinfo Sincerely Hans Buchmann
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #13 from Jürgen Reuter --- I see. For the moment, I will be downgrading to XCode 10.1 with its command line tools, but I really hope that either you or them will be able to fix it. If you were following the progress from Apple, maybe you could also note in this PR in case the issue is fixed by Apple?
[Bug c/89872] [7/8/9 Regression] GCC does not generate read access to volatile compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89872 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |7.5 Summary|GCC does not generate read |[7/8/9 Regression] GCC does |access to volatile compound |not generate read access to |literal |volatile compound literal --- Comment #1 from Jakub Jelinek --- At least with -O0 this regressed with r188665.
[Bug c/89872] [7/8/9 Regression] GCC does not generate read access to volatile compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89872 --- Comment #2 from Jakub Jelinek --- Created attachment 46055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46055&action=edit gcc9-pr89872.patch Untested fix.
[Bug c++/89882] New: [8/9 Regression] Extra caret marker when issuing diagnostics for the "'friend' used outside of class" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89882 Bug ID: 89882 Summary: [8/9 Regression] Extra caret marker when issuing diagnostics for the "'friend' used outside of class" error Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc 9 and 8 emit what I believe is a superfluous marker when issuing a diagnostic for the following invalid code: friend void foo (); % g++-9.0.0-alpha20190324 -fsyntax-only ehvo8syg.cc ehvo8syg.cc:1:1: error: 'friend' used outside of class 1 | friend void | ^~ | -- Or is the second line of dashes meant to give a cue that the marked substring have to be simply removed? If so, it is seemingly inconsistent, as there's no such lines for other invalid specifiers in the following example: friend virtual void foo () override; % g++-9.0.0-alpha20190324 -fsyntax-only ehvo8syg.cc ehvo8syg.cc:1:1: error: 'friend' used outside of class 1 | friend virtual void | ^~ | -- ehvo8syg.cc:1:8: error: 'virtual' outside class declaration 1 | friend virtual void |^~~ ehvo8syg.cc:2:8: error: virt-specifiers in 'foo' not allowed outside a class definition 2 | foo () override; |^~~~
[Bug c++/89871] Wall + designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89871 Richard Biener changed: What|Removed |Added Keywords||diagnostic, ||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-29 CC||dmalcolm at gcc dot gnu.org Known to work||9.0 Ever confirmed|0 |1 Known to fail||8.1.0, 8.2.0, 8.3.0 --- Comment #2 from Richard Biener --- Note GCC 7 doesn't have support for non-trivial designated initializers so not a regression. Not sure if the fix is a real fix.
[Bug c/89872] [7/8/9 Regression] GCC does not generate read access to volatile compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89872 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug c++/89876] [8/9 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89876 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.4
[Bug c++/89875] [7/8/9 Regression] invalid typeof reference to a member of an incomplete struct accepted at function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89875 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.5
[Bug sanitizer/89869] -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869
Martin Liška changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org,
||dvyukov at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||kcc at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Component|c++ |sanitizer
--- Comment #2 from Martin Liška ---
Slightly reduced test-case:
$ cat pr89869.cc
struct Object
{
Object* next = 0;
virtual ~Object() {}
};
void unlinkChild(Object* child, Object *nul)
{
( child->next ? nul: child) = child->next;
}
int main( int argc, char** argv)
{
Object a;
unlinkChild(&a, 0);
return 0;
}
UBSAN generates following original dump:
;; Function void unlinkChild(Object*, Object*) (null)
<, (long unsigned int) SAVE_EXPR
->_vptr.Object, 11320505648503524435, &_ZTI6Object, 3B);, SAVE_EXPR
;)->next != 0B)
{
(void) (nul = (.UBSAN_VPTR (SAVE_EXPR , (long unsigned int)
SAVE_EXPR ->_vptr.Object, 11320505648503524435, &_ZTI6Object, 3B);,
SAVE_EXPR ;)->next);
}
else
{
(void) (child = (.UBSAN_VPTR (SAVE_EXPR , (long unsigned int)
SAVE_EXPR ->_vptr.Object, 11320505648503524435, &_ZTI6Object, 3B);,
SAVE_EXPR ;)->next);
} >;
which looks fine to me. However gimplification generates:
unlinkChild (struct Object * child, struct Object * nul)
{
struct Object * child.0;
struct Object * child.1;
child.0 = child;
_1 = child.0->_vptr.Object;
_2 = (long unsigned int) _1;
.UBSAN_VPTR (child.0, _2, 11320505648503524435, &_ZTI6Object, 3B);
_3 = child.0->next;
if (_3 != 0B) goto ; else goto ;
:
child.1 = child;
_4 = child.1->_vptr.Object;
_5 = (long unsigned int) _4;
.UBSAN_VPTR (child.1, _5, 11320505648503524435, &_ZTI6Object, 3B);
nul = child.1->next;
goto ;
:
_6 = child.1->_vptr.Object;
_7 = (long unsigned int) _6;
.UBSAN_VPTR (child.1, _7, 11320505648503524435, &_ZTI6Object, 3B);
child = child.1->next;
:
}
which is wrong because child.1 is used in uninitialized. Richi is it a
gimplification bug?
Or is the generic wrongly generated?
[Bug sanitizer/89869] -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869 Martin Liška changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Status|ASSIGNED|NEW Known to fail||7.4.0, 8.3.0, 9.0
[Bug sanitizer/89869] -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869 --- Comment #3 from Jakub Jelinek --- If there is a SAVE_EXPR used in both arms of the conditional and not used before that, then it is a bug in the generic code.
[Bug c++/89858] crash with libmpfr.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89858 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Richard Biener --- So you compiled gmp for a different CPU. IIRC it auto-detects that based on the host you compile on unless you use --enable-fat. Please refer to the GMP installation instructions for details. Not a GCC bug.
[Bug c++/89882] [8/9 Regression] Extra caret marker when issuing diagnostics for the "'friend' used outside of class" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89882 Richard Biener changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org Target Milestone|--- |8.4
[Bug c++/89858] crash with libmpfr.so.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89858 --- Comment #10 from Hans Buchmann --- Thank you. Hans Buchmann
[Bug c++/89883] New: Excessive candidates for ambiguous overload in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89883
Bug ID: 89883
Summary: Excessive candidates for ambiguous overload in error
message
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
This code:
#include
enum Foo
{
Bar
};
std::ostream operator<<( std::ostream& os, Foo );
std::ostream operator<<( std::ostream& os, Foo const& );
void func( std::ostream& os )
{
os << Bar;
}
Generates around 70 lines of error message.
But in this case there are really only 2 conflicting overloads. One for 'Foo'
and one for 'Foo const&'. They both match better than any other overload.
Can GCC output just the two more matching overloads in this case?
[Bug lto/89884] g++.dg/lto/pr89335 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89884 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug lto/89884] New: g++.dg/lto/pr89335 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89884 Bug ID: 89884 Summary: g++.dg/lto/pr89335 FAILs Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.* The new g++.dg/lto/pr89335 test FAILs on Solaris with the vendor ld, both 32 and 64-bit sparc and x86: +FAIL: g++.dg/lto/pr89335 cp_lto_pr89335_0.o assemble, -O2 -flto -Wsuggest-final-methods /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/pr89335_0.C:9:7: warning: Declaring virtual destructor of 'struct List' final would enable devirtualization of 1 call [-Wsuggest-final-methods] The failure can also be reproduced on Linux/x86_64 with -fno-use-linker-plugin.
[Bug sanitizer/89869] -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869
--- Comment #4 from Jakub Jelinek ---
The problem is that for the COND_EXPR as lvalue, cp_build_modify_expr does:
/* Handle (a ? b : c) used as an "lvalue". */
case COND_EXPR:
{
/* Produce (a ? (b = rhs) : (c = rhs))
except that the RHS goes through a save-expr
so the code to compute it is only emitted once. */
It uses stabilize_expr on the rhs, but this is before ubsan instrumentation, so
there is nothing to stabilize.
And then we emit:
cond = build_conditional_expr
(input_location, TREE_OPERAND (lhs, 0),
cp_build_modify_expr (loc, TREE_OPERAND (lhs, 1),
modifycode, rhs, complain),
cp_build_modify_expr (loc, TREE_OPERAND (lhs, 2),
modifycode, rhs, complain),
complain);
so rhs is a tree shared in two COND_EXPR branches.
And then we later instrument this and wrap in a SAVE_EXPR for VPTR
instrumentation.
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #24 from Richard Biener --- IIRC we used to say sth like "unable to find a register to spill" for -fschedule-insns introduced issues. Even the ICE with max. number of LRA passes is nicer than compiling indefinitely. So I wonder if we can at least avoid endless work in IRA/LRA and maybe even give a sensible hint to the user (try disabling -fschedule-insns).
[Bug lto/87525] [7/8/9 Regression] infinite loop generated for fread() if enabling -flto and -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #26 from Richard Biener --- I think we "fixed" multiple instances of the underlying issue(s) and Honza promised a "real" fix for the extern inline issue. Don't we throw away extern inline bodies after early inlining now?
[Bug sanitizer/89869] -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869 --- Comment #5 from Jakub Jelinek --- Created attachment 46056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46056&action=edit gcc9-pr89869.patch Untested fix.
[Bug c++/89871] Wall + designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89871 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- In any case we want the testcase into the testsuite on the trunk.
[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400 Jakub Jelinek changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Could somebody from ARM have a look at this? I'm afraid above is as far as I can go without deep knowledge of the arch.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #28 from Richard Biener ---
I am considering the following as a fix for the GIMPLE issue, does that
look acceptable? I think a binary flag as suggested by Jakub results
in somewhat unpredictable behavior with regard to inlining I'd not
appreciate given inlining a function with hard-reg vars would suddenly
make asms in the caller subject to virtual operands... (not sure if we'd
not even ICE on that situation at the moment). Similar situation occurs
if inlining an asm with hardreg clobbers from a function w/o local reg
vars into a function with local reg vars -- that function could even
be pure/const but would have to be treated not so.
So - mine for the GIMPLE part.
Any comments?
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 270012)
+++ gcc/gimple.c(working copy)
@@ -2727,11 +2738,16 @@ gimple_asm_clobbers_memory_p (const gasm
{
unsigned i;
+ /* While strictly speaking only a "memory" clobber denotes clobbering
+ memory in GIMPLE we also treat local hard-register variables as
+ memory so simply treat all clobbers as memory. The only exception
+ is the special clobber "cc". */
for (i = 0; i < gimple_asm_nclobbers (stmt); i++)
{
tree op = gimple_asm_clobber_op (stmt, i);
- if (strcmp (TREE_STRING_POINTER (TREE_VALUE (op)), "memory") == 0)
- return true;
+ if (strcmp (TREE_STRING_POINTER (TREE_VALUE (op)), "cc") == 0)
+ continue;
+ return true;
}
/* Non-empty basic ASM implicitly clobbers memory. */
[Bug driver/89861] g++-8: error: unrecognized command line option ‘-fsanitize’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89861 Martin Liška changed: What|Removed |Added Keywords||patch Known to fail||7.4.0, 8.3.0, 9.0 --- Comment #2 from Martin Liška --- I've just sent a patch to ML: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01401.html
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #29 from Jakub Jelinek ---
(In reply to Richard Biener from comment #28)
> Any comments?
> --- gcc/gimple.c(revision 270012)
> +++ gcc/gimple.c(working copy)
> @@ -2727,11 +2738,16 @@ gimple_asm_clobbers_memory_p (const gasm
> {
>unsigned i;
>
> + /* While strictly speaking only a "memory" clobber denotes clobbering
> + memory in GIMPLE we also treat local hard-register variables as
> + memory so simply treat all clobbers as memory. The only exception
> + is the special clobber "cc". */
>for (i = 0; i < gimple_asm_nclobbers (stmt); i++)
> {
>tree op = gimple_asm_clobber_op (stmt, i);
> - if (strcmp (TREE_STRING_POINTER (TREE_VALUE (op)), "memory") == 0)
> - return true;
> + if (strcmp (TREE_STRING_POINTER (TREE_VALUE (op)), "cc") == 0)
> + continue;
> + return true;
> }
>
>/* Non-empty basic ASM implicitly clobbers memory. */
This will affect not just tree-ssa-operands.c, where it is ok I guess, as it
will just mean a vdef and the alias oracle then can figure out if something
aliases or not, but also ipa-pure-const.c and sanopt. Do we want to say that
functions with register clobbers are no longer pure/const and for sanopt
consider them to be potential spots to free memory?
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #14 from Jürgen Reuter --- Unfortunately, the downgrade to XCode 10.1 didn't work, I still get the buggy/problematic headers. That is really annoying, because now I am stuck with my development.
[Bug c++/89882] [8/9 Regression] Extra caret marker when issuing diagnostics for the "'friend' used outside of class" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89882 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-29 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r250282.
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #15 from Jürgen Reuter --- Sorry for the spam, now I got it, there was something old (i.e. new) lingering around still. Now, back to XCode 10.1 and command line tools from October 2018 with a different include/sys. Started compilation/bootstrapping of gcc again, hopefully it is working now.
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 --- Comment #25 from Uroš Bizjak --- (In reply to Richard Biener from comment #24) > IIRC we used to say sth like "unable to find a register to spill" for > -fschedule-insns introduced issues. Even the ICE with max. number of > LRA passes is nicer than compiling indefinitely. > > So I wonder if we can at least avoid endless work in IRA/LRA and > maybe even give a sensible hint to the user (try disabling -fschedule-insns). The patch in Comment #20 is the correct solution, as explained in Comment #19.
[Bug c++/89882] [8/9 Regression] Extra caret marker when issuing diagnostics for the "'friend' used outside of class" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89882 Jakub Jelinek changed: What|Removed |Added CC||reichelt at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Though, reading that change, it seems that it was exactly what was added by that patch and nothing else, a fix-it hint that the keyword should be removed. So, is the PR about not being to understand it is a fix-it remove hint (which is obvious if you e.g. use -fdiagnostics-generate-patch or -fdiagnostics-parseable-fixits), something else?
[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89134 --- Comment #12 from joey.ye.cc at gmail dot com --- Feng, Have you made any progress on these problems? If advice is still needed, I would suggest you share more details about these problems, and people like Bin and Richi and Richard Sandiford may provide you some advice. Thanks, Joey On Sat, Feb 2, 2019 at 4:23 AM fxue at os dot amperecomputing.com wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89134 > > --- Comment #11 from Feng Xue --- > Actually, I am working on adding optimizations to enable this opportunity, > which can be discomposed to two sub-problems: breaking-loop transformation > mentioned above, and empty-loop elimination. I have worked out several > patches, > but for the second thing, since it seems to be more aggressive than gcc > currently implemented, I need advices and feedbacks from the community.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #30 from rguenther at suse dot de ---
On Fri, 29 Mar 2019, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
>
> --- Comment #29 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #28)
> > Any comments?
>
> > --- gcc/gimple.c(revision 270012)
> > +++ gcc/gimple.c(working copy)
> > @@ -2727,11 +2738,16 @@ gimple_asm_clobbers_memory_p (const gasm
> > {
> >unsigned i;
> >
> > + /* While strictly speaking only a "memory" clobber denotes clobbering
> > + memory in GIMPLE we also treat local hard-register variables as
> > + memory so simply treat all clobbers as memory. The only exception
> > + is the special clobber "cc". */
> >for (i = 0; i < gimple_asm_nclobbers (stmt); i++)
> > {
> >tree op = gimple_asm_clobber_op (stmt, i);
> > - if (strcmp (TREE_STRING_POINTER (TREE_VALUE (op)), "memory") == 0)
> > - return true;
> > + if (strcmp (TREE_STRING_POINTER (TREE_VALUE (op)), "cc") == 0)
> > + continue;
> > + return true;
> > }
> >
> >/* Non-empty basic ASM implicitly clobbers memory. */
>
> This will affect not just tree-ssa-operands.c, where it is ok I guess, as it
> will just mean a vdef and the alias oracle then can figure out if something
> aliases or not, but also ipa-pure-const.c and sanopt. Do we want to say that
> functions with register clobbers are no longer pure/const and for sanopt
> consider them to be potential spots to free memory?
For ipa-pure-const definitely - the calls need to be barriers for
local reg sets. For sanopt a memory clobber isn't a very good
indication for a spot to free memory anyways...
Btw, getting back optimization for cases with hardreg clobbers would
need to be put into the alias oracle then.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/89292] [9 regression] test case gcc.target/powerpc/rs6000-fpint.c fails after r268705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89292 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- . *** This bug has been marked as a duplicate of bug 89271 ***
[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271 Richard Biener changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #17 from Richard Biener --- *** Bug 89292 has been marked as a duplicate of this bug. ***
[Bug c++/89722] [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89722 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 --- Comment #26 from Jakub Jelinek --- Author: jakub Date: Fri Mar 29 11:42:51 2019 New Revision: 270013 URL: https://gcc.gnu.org/viewcvs?rev=270013&root=gcc&view=rev Log: PR rtl-optimization/87485 * function.c (expand_function_end): Move stack_protect_epilogue before loading of return value into hard register(s). * gcc.dg/pr87485.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr87485.c Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/89851] [9 Regression] std::variant comparison operators violate [variant.relops]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89851 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/89868] -fsanitize=address inhibits C++ unhandled exception core dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89868
--- Comment #6 from Jonny Grant ---
(In reply to Andrew Pinski from comment #5)
> Actually it comes from the shell.
>
> e.g. from bash:
> if ((WIFSTOPPED (show->status) == 0) &&
> (WIFCONTINUED (show->status) == 0) &&
> WIFCORED (show->status))
> fprintf (stream, _("(core dumped) "));
>
> As WIFCORED is set on status.
>
> WIFCORED is really a define for WCOREDUMP.
>
> http://man7.org/linux/man-pages/man2/waitpid.2.html
>
> So basically the kernel does not communicate why a core is not dumped to the
> waiting (parent) process.
Hi Andrew
Thank you for tracking that down. It is a shame, there isn't a WCORETOOLARGE,
or WUNABLETOCOREDUMP etc.. I wonder really how big the core must be to be
unable to save
Could I ask, if you run the test case with Asan, do you see the same behaviour?
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #17 from Richard Biener --- Should get rid of that FAIL in any way.
[Bug middle-end/89725] ICE in get_fnname_from_decl, at varasm.c:1723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
--- Comment #9 from bin cheng ---
(In reply to Richard Biener from comment #8)
> (In reply to bin cheng from comment #7)
> > I am testing below simple fix, it bypass access functions doesn't belong to
> > analyzing loop_nest:
> >
> > diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
> > index e536b463e96..410d44f43e8 100644
> > --- a/gcc/tree-data-ref.c
> > +++ b/gcc/tree-data-ref.c
> > @@ -4272,6 +4272,7 @@ build_classic_dist_vector_1 (struct
> > data_dependence_relation *ddr,
> > {
> >unsigned i;
> >lambda_vector init_v = lambda_vector_new (DDR_NB_LOOPS (ddr));
> > + struct loop *loop = DDR_LOOP_NEST (ddr)[0];
> >
> >for (i = 0; i < DDR_NUM_SUBSCRIPTS (ddr); i++)
> > {
> > @@ -4302,6 +4303,15 @@ build_classic_dist_vector_1 (struct
> > data_dependence_relation *ddr,
> > return false;
> > }
> >
> > + /* When data references are collected in a loop while data
> > +dependences are analyzed in loop nest nested in the loop, we
> > +would have more number of access functions than number of
> > +loops. Skip access functions of loops not in the loop nest.
> > +
> > +See PR89725 for more information. */
> > + if (flow_loop_nested_p (get_loop (cfun, var_a), loop))
> > + continue;
> > +
> > dist = int_cst_value (SUB_DISTANCE (subscript));
> > index = index_in_loop_nest (var_a, DDR_LOOP_NEST (ddr));
> > *index_carry = MIN (index, *index_carry);
> >
> > Plus the assert in index_in_loop_nest.
>
> I wondered about chrecs like { 1, +, { 0 +, 1 }_1 }_2 (inner loop step
> or initial value evolves wrt outer loop). We'd not catch that here.
>
> Also if the above is possible then why not simply strip those
> subscripts when we build the DDR? That way the few other cases
> we do index_in_loop_nest also are "fixed".
>
> Meanwhile testing of my patch finished but shows an ICE for
>
> FAIL: gfortran.dg/vect/pr81303.f -O scan-tree-dump-times linterchange
> "is in
> terchanged" 1
> FAIL: gfortran.dg/vect/pr81303.f -O (internal compiler error)
> FAIL: gfortran.dg/vect/pr81303.f -O (test for excess errors)
>
> #1 0x00a61759 in vec::operator[] (
> this=0x3119f50 = {...}, ix=3)
> at /space/rguenther/src/gcc-sccvn/gcc/vec.h:845
> 845 gcc_checking_assert (ix < m_vecpfx.m_num);
> (gdb)
> #3 0x01f2723a in should_interchange_loops (i_idx=3, o_idx=2,
> datarefs=..., i_stmt_cost=41, o_stmt_cost=5, innermost_loops_p=true,
> dump_info_p=true)
> at /space/rguenther/src/gcc-sccvn/gcc/gimple-loop-interchange.cc:1460
> 1460 tree iloop_stride = (*stride)[i_idx], oloop_stride =
> (*stride)[o_idx];
>
> where the interchange code would need further changes for my change of the
> loop-nest for DDRs.
>
> That said, can we strip subscripts for outer loops in
> initialize_data_dependence_relation when we compute them?
> OTOH the cases where we can ignore the subscript are not so clear
> given that the outer loop behavior can very well compute
Agree there may be more opportunities to disambiguate dependence with more
SCEVed access function of outer loop.
> non-aliasing. So selectively pruning just the unwanted distance
> vectors looks safe.
As you mentioned, multivariate needs to be handled with outer loop SCEV handled
as some kind of invariant. This is necessary no matter we bypass it in dist
vector construction or DDR initialization/computation. As you suggested, we
can't undo it yet...
>
> But what about similar code in add_multivariate_self_dist or
> add_other_self_distances?
[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89134 --- Comment #13 from Jiangning Liu --- Feng already sent out the 1st patch at https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00541.html . But the 2nd one is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89713 .
[Bug rtl-optimization/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
--- Comment #18 from Jakub Jelinek ---
The test adjustment so that it only checks what the PR85683 change really meant
to check for would be:
2019-03-29 Jakub Jelinek
PR rtl-optimization/89865
* gcc.target/i386/pr49095.c: Include in scan-assembler-times patterns
the first argument register, so that occassional spills/fills are
ignored.
--- gcc/testsuite/gcc.target/i386/pr49095.c.jj 2018-10-08 15:18:22.074105125
+0200
+++ gcc/testsuite/gcc.target/i386/pr49095.c 2019-03-29 13:11:54.941597147
+0100
@@ -73,5 +73,5 @@ G (long)
/* { dg-final { scan-assembler-not "test\[lq\]" } } */
/* The {f,h}{char,short,int,long}xor functions aren't optimized into
a RMW instruction, so need load, modify and store. FIXME eventually. */
-/* { dg-final { scan-assembler-times "\\), %" 57 { target { ia32 } } } } */
-/* { dg-final { scan-assembler-times "\\), %" 45 { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler-times "\\(%eax\\), %" 12 { target { ia32 } } }
} */
+/* { dg-final { scan-assembler-times "\\(%\[re\]di\\), %" 8 { target { ! ia32
} } } } */
Now, for ia32 we've regressed even there, as we emit those 8 RMWs for
{f,h}{char,short,int,long}xor,
like for m64, but also 4 RMWs for f{char,short,int,long}minus.
Will look at thos next.
[Bug bootstrap/50229] [7/8/9 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 Richard Biener changed: What|Removed |Added Target Milestone|7.4 |7.5
[Bug target/81800] [8/9 regression] on aarch64 ilp32 lrint should not be inlined as two instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800 Richard Biener changed: What|Removed |Added Target Milestone|8.0 |8.4
[Bug c++/84707] [8 Regression] internal compiler error: Segmentation fault (tree_check()/duplicate_decls())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84707 Richard Biener changed: What|Removed |Added Keywords|ice-on-valid-code |rejects-valid Priority|P1 |P2 Status|REOPENED|RESOLVED Known to work||7.4.0, 8.3.0, 9.0 Resolution|--- |FIXED Target Milestone|8.0 |8.3 Known to fail||8.1.0, 8.2.0 --- Comment #14 from Richard Biener --- GCC 8.3 accepts it w/o error.
[Bug middle-end/89725] [8/9 Regression] ICE in get_fnname_from_decl, at varasm.c:1723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.4 Summary|ICE in |[8/9 Regression] ICE in |get_fnname_from_decl, at|get_fnname_from_decl, at |varasm.c:1723 |varasm.c:1723 --- Comment #10 from Richard Biener --- Interchange is new in GCC 8 so a regression for the memory corruption there.
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 Giuliano Belinassi changed: What|Removed |Added CC||giuliano.belinassi at usp dot br --- Comment #7 from Giuliano Belinassi --- It seems that the issue is the backtracking required by the NFA, as it enters in a deep recursion when calling _M_dfs in _M_main_dispatch (regex_executor.tcc). Maybe moving the DFS stack from the recursion stack to the heap and use an iterative DFS could fix this, but converting the NFA to DFA may be a better choice, as it removes the backtracking requirement when iterating with the string.
[Bug driver/89885] New: --help=warning prints wrongly default values for options set via e.g. -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89885
Bug ID: 89885
Summary: --help=warning prints wrongly default values for
options set via e.g. -Wall or -Wextra
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
One example:
$ gcc --help=warning -Wall -Wextra -Q | grep Wcatch-v
-Wcatch-value
-Wcatch-value=<0,3> 0
So it claims the value is 0. But:
$ gcc -Wall -Wextra -Werror
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/warn/Wcatch-value-1.C
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/warn/Wcatch-value-1.C: In
function ‘void foo()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/warn/Wcatch-value-1.C:13:10:
error: catching polymorphic type ‘struct B’ by value [-Werror=catch-value=]
13 | catch (B){} // { dg-warning "catching polymorphic type" }
| ^
Issues is that option common_handle_option_auto is called from:
#0 common_handle_option_auto (opts=0x246be40 ,
opts_set=0x246aea0 , decoded=0x7fffd5e0, lang_mask=32,
kind=0, loc=0, handlers=0x7fffd810, dc=0x246cf00
) at options.c:16459
#1 0x018466a4 in common_handle_option (opts=0x246be40
, opts_set=0x246aea0 ,
decoded=0x7fffd5e0, lang_mask=32, kind=0, loc=0, handlers=0x7fffd810,
dc=0x246cf00 , target_option_override_hook=
0x124b510 ) at
/home/marxin/Programming/gcc/gcc/opts.c:2807
#2 0x0184c5ef in handle_option (opts=0x246be40 ,
opts_set=0x246aea0 , decoded=0x7fffd5e0, lang_mask=32,
kind=0, loc=0, handlers=0x7fffd810, generated_p=true, dc=0x246cf00
)
at /home/marxin/Programming/gcc/gcc/opts-common.c:1104
#3 0x0184c69f in handle_generated_option (opts=0x246be40
, opts_set=0x246aea0 , opt_index=594,
arg=0x0, value=0, lang_mask=32, kind=0, loc=0, handlers=0x7fffd810,
generated_p=true, dc=0x246cf00 )
at /home/marxin/Programming/gcc/gcc/opts-common.c:1130
But --help options are directly printed in:
#0 print_filtered_help (include_flags=131072, exclude_flags=0, any_flags=0,
columns=272, opts=0x21d70c0 , lang_mask=16) at
/home/marxin/Programming/gcc/gcc/opts.c:1303
#1 0x0162173e in print_specific_help (include_flags=131072,
exclude_flags=0, any_flags=0, opts=0x21d70c0 , lang_mask=16) at
/home/marxin/Programming/gcc/gcc/opts.c:1683
#2 0x01622af5 in common_handle_option (opts=0x21d70c0
, opts_set=0x21d6120 , decoded=0x21ef780,
lang_mask=16, kind=0, loc=0, handlers=0x7fffd820, dc=0x21d8180
, target_option_override_hook=
0x1032fc0 ) at
/home/marxin/Programming/gcc/gcc/opts.c:2244
Correct behavior would be to print --help late after all is set. Ideally in
finish_options.
[Bug driver/89885] --help=warning prints wrongly default values for options set via e.g. -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89885 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-03-29 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug c++/89876] [8/9 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89876 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-03-29 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- I have a fix for the ICE.
[Bug c++/89871] Wall + designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89871 --- Comment #4 from Marek Polacek --- I'll add the test to trunk.
[Bug c/89886] New: the local array data will be laid in different section by different optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89886 Bug ID: 89886 Summary: the local array data will be laid in different section by different optimization level Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zhongyunde at huawei dot com Target Milestone: --- Created attachment 46057 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46057&action=edit simple testcase file the simple testcase dd.c, compiled with the following command: pekpcsi2:~ # /opt/buildtools/gcc-7.3.0/bin/gcc dd.c -O2 -o O2.s -S pekpcsi2:~ # /opt/buildtools/gcc-7.3.0/bin/gcc dd.c -O0 -o O0.s -S we'll see that the aucSubFrmType.1820 in assemble O2.s is laid in section rodata, while in assemble O0.s is laid in section data.
[Bug c/89887] New: the local array data will be laid in different section by different optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89887 Bug ID: 89887 Summary: the local array data will be laid in different section by different optimization level Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zhongyunde at huawei dot com Target Milestone: --- file the simple testcase dd.c, compiled with the following command: pekpcsi2:~ # /opt/buildtools/gcc-7.3.0/bin/gcc dd.c -O2 -o O2.s -S pekpcsi2:~ # /opt/buildtools/gcc-7.3.0/bin/gcc dd.c -O0 -o O0.s -S we'll see that the aucSubFrmType.1820 in assemble O2.s is laid in section rodata, while in assemble O0.s is laid in section data.
[Bug c/89887] the local array data will be laid in different section by different optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89887
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #1 from vfdff ---
Created attachment 46058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46058&action=edit
picture shows the bug
// simple test case
typedef unsigned char UINT8;
typedef unsigned short UINT16;
typedef unsigned int UINT32;
typedef signed char INT8;
typedef signed short INT16;
typedef signed int INT32;
typedef float FLOAT;
typedef double DOUBLE;
typedef char CHAR;
typedef unsigned char UCHAR;
typedef unsigned int BOOL;
typedef unsigned long long UINT64;
typedef signed long long INT64;
typedef int INT;
typedef enum
{
LBB_EN_UP_DOWN_CONFIG0 = 0,
LBB_EN_UP_DOWN_CONFIG1 = 1,
LBB_EN_UP_DOWN_CONFIG2 = 2,
LBB_EN_UP_DOWN_CONFIG3 = 3,
LBB_EN_UP_DOWN_CONFIG4 = 4,
LBB_EN_UP_DOWN_CONFIG5 = 5,
LBB_EN_UP_DOWN_CONFIG6 = 6,
LBB_EN_UP_DOWN_CONFIG_BUTT
}LBB_EN_UP_DOWN_CONFIG;
UINT32 test (UINT32 uwUpDownConfig, UINT32 uwSubFrmNum)
{
static UINT8 aucSubFrmType[LBB_EN_UP_DOWN_CONFIG_BUTT][(10)] =
{
{0, 1, 2, 2, 2, 0, 1, 2, 2, 2},
{0, 1, 2, 2, 0, 0, 1, 2, 2, 0},
{0, 1, 2, 0, 0, 0, 1, 2, 0, 0},
{0, 1, 2, 2, 2, 0, 0, 0, 0, 0},
{0, 1, 2, 2, 0, 0, 0, 0, 0, 0},
{0, 1, 2, 0, 0, 0, 0, 0, 0, 0},
{0, 1, 2, 2, 2, 0, 1, 2, 2, 0}
};
return aucSubFrmType[uwUpDownConfig][uwSubFrmNum];
}
[Bug c/89887] the local array data will be laid in different section by different optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89887 --- Comment #2 from vfdff --- Add option -fno-toplevel-reorder for O2, then aucSubFrmType.1820 will also be placed in section data. /opt/buildtools/gcc-7.3.0/bin/gcc dd.c -O2 -S -fno-toplevel-reorder
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #16 from Erik Schnetter --- The proper way to fix this via fixinclude is to replace declarations such as _Atomic u_long with _Atomic(u_long) which is still legal in C. In C++, one can then add #include #ifndef _Atomic #define _Atomic(T) std::atomic< T > #endif to create proper C++ code.
[Bug c++/89882] [8/9 Regression] Extra caret marker when issuing diagnostics for the "'friend' used outside of class" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89882 --- Comment #3 from David Malcolm --- As Jakub notes, it's a deletion fix-it hint. It's suggesting the deletion of the same range as that of the primary location of the diagnostic, so arguably there's some redundancy there. I wonder if there's a better way to present this information, but I don't have any ideas at the moment.
[Bug fortran/77504] [7/8/9 Regression] "is used uninitialized" with allocatable string and array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4
[Bug target/83033] aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033 Andrea Corallo changed: What|Removed |Added CC||andrea.corallo at arm dot com --- Comment #1 from Andrea Corallo --- Path proposed https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01402.html
[Bug target/83033] aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033 --- Comment #2 from Andrea Corallo --- Patch proposed https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01402.html
[Bug rtl-optimization/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865 --- Comment #19 from Jakub Jelinek --- Created attachment 46059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46059&action=edit gcc9-pr89865.patch Peepholes (on top of the above testcase patch) that fix up f*minus on ia32.
[Bug c++/89871] Wall + designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89871 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Fri Mar 29 15:24:00 2019 New Revision: 270019 URL: https://gcc.gnu.org/viewcvs?rev=270019&root=gcc&view=rev Log: PR c++/89871 * g++.dg/cpp2a/desig14.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/desig14.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/89887] the local array data will be laid in different section by different optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89887 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-03-29 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Yes the optimization level does change the fact that array can be found not be touched and moved to the read only section. This is not a bug. I dont see a problem that this would cause. Can you explain why you think this is wrong?
[Bug rtl-optimization/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865 --- Comment #20 from Vladimir Makarov --- I'll be working on this.
[Bug target/83033] aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033 Eric Gallager changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-29 Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- taking the patch as confirmation
[Bug c++/89882] [8/9 Regression] Extra caret marker when issuing diagnostics for the "'friend' used outside of class" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89882 --- Comment #4 from Arseny Solokha --- (In reply to Jakub Jelinek from comment #2) > So, is the PR about not being to understand it is a fix-it remove hint > (which is obvious if you e.g. use -fdiagnostics-generate-patch or > -fdiagnostics-parseable-fixits), something else? The second line of dashes have admittedly confused me at first. I've got a suspicion that it actually may be a remove hint, but then adding equally superfluous virtual or override specifiers yielded no such hint, which made me confident that there's some bug in there anyway, either in emitting those mysterious dashes when they're not needed or not emitting them when they should be printed. It turned out that those dashes are really a remove hint, and the change since gcc 7 was intentional, so I'd just close the PR as INVALID. Sorry, I'd rather stay aside from the UX issues and their discussion, and I won't insist that the current diagnostic is hard to understand. I also don't have any suggestions for improvement here beside the one to mark both the offending keyword and an adjacent one (either left- or rightward) and propose to replace them w/ only that adjacent - which is also far from ideal. Or maybe the line number column could be somehow abused, like: 1 | friend void (---) → | ^~ which is arguably not any clear than the original.
[Bug c/89888] New: When switch controlling expression is promoted from type narrower than int, GCC does not diagnose identical cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89888
Bug ID: 89888
Summary: When switch controlling expression is promoted from
type narrower than int, GCC does not diagnose
identical cases
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
Consider the C function:
long long X;
void f(unsigned char x)
{
switch(x) {
case -1: X=-1; break;
case 0x: X=0x; break;
}
}
The controlling expression of the switch, x, has type unsigned char and is
promoted to int before its type being used as reference for the constants -1
and 0x. This is according to C11 6.8.4.2:5
(https://port70.net/~nsz/c/c11/n1570.html#6.8.4.2p5 )
GCC 8.3 emits very good warnings about each of the constants being, after
conversion, outside the range of an unsigned int and thus unreachable:
: In function 'f':
:6:5: warning: case label value is less than minimum value for type
case -1: X=-1; break;
^~~~
:7:5: warning: case label value is less than minimum value for type
case 0x: X=0x; break;
^~~~
(Compiler Explorer link: https://gcc.godbolt.org/z/gvnvoa )
However, GCC does not warn about the labels being identical after conversion. I
feel silly reporting this, because it only happens for discarded labels that
were unreachable, and there isn't any ambiguity about the meaning of the
program. Still, the C11 clause 6.8.4.2:3 about identical switch case labels
(after conversion) (https://port70.net/~nsz/c/c11/n1570.html#6.8.4.2p3 ) is
under a “Constraints” heading, so depending how much GCC cares about adhering
to the letter of the standard, it may want to diagnose this situation.
Clang diagnoses this situation and emits an “error”:
:7:10: error: duplicate case value '-1'
Clang also emits two misleading warnings about the constants -1 and 0x.
The wording of these warnings is so misleading that it can be considered a
Clang bug, which has been reported in the appropriate place.
[Bug c++/89882] [8/9 Regression] Extra caret marker when issuing diagnostics for the "'friend' used outside of class" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89882 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jakub Jelinek --- Ok then.
[Bug c/89888] When switch controlling expression is promoted from type narrower than int, GCC does not diagnose identical cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89888 --- Comment #1 from Pascal Cuoq --- errata: “outside the range of an unsigned char”
[Bug target/89838] [ARC] ICE building glibc testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89838
--- Comment #1 from Claudiu Zissulescu ---
It is confirmed also in gcc mainline branch:
tst-tls1.c: In function ‘check_s’:
tst-tls1.c:65:1: error: unrecognizable insn:
(insn 36 35 37 6 (set (reg/f:SI 163)
(plus:SI (plus:SI (reg:SI 25 r25)
(reg:SI 164))
(const_int 512 [0x200]))) "tst-tls1.c":64:3 -1
(expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI ("s") [flags 0x22]
)
(const_int 512 [0x200])))
(nil)))
during RTL pass: vregs
[Bug c++/89889] New: worse code compared to clang with alloca()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89889 Bug ID: 89889 Summary: worse code compared to clang with alloca() Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: john.boyer at tutanota dot com Target Milestone: --- Example: https://godbolt.org/z/MLZAA6. Why is the push/lea/leave necessary? Shouldn't modifying the stack pointer be enough?
[Bug fortran/89890] New: Memory leak from a function returning a subtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89890 Bug ID: 89890 Summary: Memory leak from a function returning a subtype Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: andrew at fluidgravity dot co.uk Target Milestone: --- I get a memory leak from the code below. The leak does not occur with either the Intel or PGI Fortran compilers. The leak goes away if I change the return type of function 'new' to "CLASS(subtype), ALLOCATABLE". > gfortran-8 --version GNU Fortran (SUSE Linux) 8.2.1 20180831 [gcc-8-branch revision 264010] Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > gfortran-8 -g -O0 -std=f2008 code.f90 > valgrind --tool=memcheck --leak-check=yes --show-leak-kinds=definite ./a.out ==25304== Memcheck, a memory error detector ==25304== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==25304== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==25304== Command: ./a.out ==25304== ==25304== ==25304== HEAP SUMMARY: ==25304== in use at exit: 12 bytes in 2 blocks ==25304== total heap usage: 27 allocs, 25 frees, 13,553 bytes allocated ==25304== ==25304== 12 (8 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 2 ==25304==at 0x4C2E01F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==25304==by 0x400CAB: __m_MOD_new (code.f90:14) ==25304==by 0x400DA0: MAIN__ (code.f90:28) ==25304==by 0x400F10: main (code.f90:25) ==25304== ==25304== LEAK SUMMARY: ==25304==definitely lost: 8 bytes in 1 blocks ==25304==indirectly lost: 4 bytes in 1 blocks ==25304== possibly lost: 0 bytes in 0 blocks ==25304==still reachable: 0 bytes in 0 blocks ==25304== suppressed: 0 bytes in 0 blocks ==25304== ==25304== For counts of detected and suppressed errors, rerun with: -v ==25304== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) code.f90: MODULE m IMPLICIT NONE TYPE, ABSTRACT, PUBLIC :: base END TYPE TYPE, EXTENDS(base), PUBLIC :: subtype INTEGER, ALLOCATABLE :: x CONTAINS FINAL :: subtype_final END TYPE CONTAINS FUNCTION new(this) INTEGER :: this CLASS(base), ALLOCATABLE :: new ALLOCATE(subtype::new) SELECT TYPE ( new ) CLASS IS ( subtype ) ALLOCATE(new%x, SOURCE=this) END SELECT END SUBROUTINE subtype_final(this) TYPE(subtype) :: this IF ( ALLOCATED(this%x) ) DEALLOCATE(this%x) END END USE m IMPLICIT NONE CLASS(base), ALLOCATABLE :: w ALLOCATE(w, SOURCE=new(0)) DEALLOCATE(w) END
[Bug middle-end/89889] worse code compared to clang with alloca()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89889 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c++ |middle-end --- Comment #1 from Andrew Pinski --- This is because LLVM promotes the alloca to an array that is "statically" allocated on the stack. I would say this is a bad micro-benchmark really.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984 --- Comment #31 from Segher Boessenkool --- If an asm makes a function non-pure, that asm should be volatile in the first place? Or are there any cases where that is not true?
[Bug c++/89881] Incorrect warning "-Wunneeded-internal-declaration"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89881 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Eric Gallager --- -Wunneeded-internal-declaration is a clang flag, not a gcc one
[Bug c++/89881] Incorrect warning "-Wunneeded-internal-declaration"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89881 --- Comment #2 from Lukas Mosimann --- Yes you're right. But also GCC reports a warning, saying that the function is only declared, but not defined. This might be exactly what we want, if the function is only used at compile time, as a kind of type mapping. So I'm not sure, but in my opinion, if a function is declared, but not defined, and it is used in a decltype - that is totally ok and no warning should be omitted at all.
[Bug c++/89876] [8/9 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89876 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Fri Mar 29 18:40:31 2019 New Revision: 270021 URL: https://gcc.gnu.org/viewcvs?rev=270021&root=gcc&view=rev Log: PR c++/89876 - ICE with deprecated conversion. * call.c (convert_like_real): Only give warnings with tf_warning. * g++.dg/warn/conv5.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/conv5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89876] [8 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89876 Marek Polacek changed: What|Removed |Added Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |convert_like_real on|convert_like_real on |decltype expression |decltype expression |involving string conversion |involving string conversion |to char*|to char* --- Comment #5 from Marek Polacek --- Fixed on trunk so far.
[Bug c/89872] [7/8/9 Regression] GCC does not generate read access to volatile compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89872 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Mar 29 19:32:20 2019 New Revision: 270023 URL: https://gcc.gnu.org/viewcvs?rev=270023&root=gcc&view=rev Log: PR c/89872 * gimplify.c (gimplify_compound_literal_expr): Don't optimize a non-addressable complit into its initializer if it is volatile. * gcc.dg/tree-ssa/pr89872.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr89872.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c/89872] [7/8 Regression] GCC does not generate read access to volatile compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89872 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] GCC does |[7/8 Regression] GCC does |not generate read access to |not generate read access to |volatile compound literal |volatile compound literal --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug sanitizer/89869] -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Mar 29 20:10:19 2019 New Revision: 270024 URL: https://gcc.gnu.org/viewcvs?rev=270024&root=gcc&view=rev Log: PR sanitizer/89869 * typeck.c: Include gimplify.h. (cp_build_modify_expr) : Unshare rhs before using it for second time. Formatting fixes. * g++.dg/ubsan/vptr-14.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/vptr-14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/89869] -fsanitize=undefined miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Known to fail|9.0 | --- Comment #7 from Jakub Jelinek --- Fixed for 9.1+ so far.
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 --- Comment #8 from Jonathan Wakely --- I started working on a patch to replace the recursion with iteration, but didn't get it working yet.
[Bug rtl-optimization/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865 --- Comment #21 from Jakub Jelinek --- Author: jakub Date: Fri Mar 29 20:51:15 2019 New Revision: 270025 URL: https://gcc.gnu.org/viewcvs?rev=270025&root=gcc&view=rev Log: PR rtl-optimization/89865 * gcc.target/i386/pr49095.c: Include in scan-assembler-times patterns the first argument register, so that occassional spills/fills are ignored. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr49095.c
[Bug driver/89861] g++-8: error: unrecognized command line option ‘-fsanitize’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89861 --- Comment #3 from Jonny Grant --- Excellent, amazing turnaround time Martin!
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #17 from Jürgen Reuter --- (In reply to Erik Schnetter from comment #16) > The proper way to fix this via fixinclude is to replace declarations such as > > _Atomic u_long > > with > > _Atomic(u_long) > > which is still legal in C. In C++, one can then add > > #include > #ifndef _Atomic > #define _Atomic(T) std::atomic< T > > #endif > > to create proper C++ code. It would be really great if you could provide a proper fix for gcc.
