[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337 --- Comment #2 from emsr at gcc dot gnu.org --- It looks like try blocks in constexpr is in. p1002r1. This may be enough to do some constexpr library bits.
[Bug preprocessor/53404] warning column reported on comment in warning during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #6 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug c++/69777] Give a warning when virtual function is devirtualized into a __cxa_pure_virtual call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69777 Eric Gallager changed: What|Removed |Added Blocks||87403 --- Comment #6 from Eric Gallager --- this would be a new warning, so making it block the relevant meta-bug Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c/65403] -Wno-error= is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #9 from Eric Gallager --- (In reply to Alex Henrie from comment #8) > Why weren't Manuel's patches accepted? He probably forgot to ping them and then people just forgot about them, I'm guessing
[Bug c/89051] -Wno-error= does not work for warning groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53075, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66505 --- Comment #9 from Eric Gallager --- For the stuff about -Wpedantic see bug 53075 and bug 66505
[Bug c/89549] [7/8/9 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81334 --- Comment #3 from Eric Gallager --- related to bug 81334 perhaps?
[Bug middle-end/4210] should not warning with dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 Eric Gallager changed: What|Removed |Added CC||joseph at codesourcery dot com --- Comment #29 from Eric Gallager --- (In reply to Paul Eggert from comment #25) > I'd like this bug to be changed from SUSPENDED to CONFIRMED, given that it's > continuing to be a problem (e.g., bug#79479). > > Also, I'd like to suggest what I hope is a simple fix. In 2006 Joseph wrote > "skip_evaluation can't be set for if (0) because you can jump into if (0), > whereas jumps into statement expressions are not permitted". So, how about > if we merely set skip_evaluation for "if (0)" when the then-part lacks > labels? This should be an easy test, as it shouldn't require parsing the > whole function body. The test might still generate false alarms for code > containing gotos, but in practice such gotos are rare, so the proposed > change should be a significant improvement even if it's not perfect. Joseph, what do you think about this solution?
[Bug go/89406] Go testing leaves many temporary directories in /tmp around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406 --- Comment #13 from Ian Lance Taylor --- I increased the timeouts and fixed another case. Let me know what it looks like now. Thanks.
[Bug go/89406] Go testing leaves many temporary directories in /tmp around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406 --- Comment #12 from ian at gcc dot gnu.org --- Author: ian Date: Sat Mar 2 00:50:30 2019 New Revision: 269338 URL: https://gcc.gnu.org/viewcvs?rev=269338=gcc=rev Log: PR go/89406 go/internal/gccgoimporter: remove temporary directories in test Backport of https://golang.org/cl/164862. Updates https://gcc.gnu.org/PR89406 Reviewed-on: https://go-review.googlesource.com/c/164863 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/go/internal/gccgoimporter/importer_test.go
[Bug debug/89530] Wrong debug informations for C array generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530 --- Comment #7 from dcci --- (In reply to Jakub Jelinek from comment #6) > (In reply to dcci from comment #5) > > (In reply to Jakub Jelinek from comment #4) > > > Also, we usually bisect which gcc revision introduced a problem and from > > > that change we can often see what goes wrong quickly. Both Red Hat and > > > SUSE > > > have terrabytes of built gcc revisions to make such bisection faster. > > > > I see. Is this data available for the masses? > > No, it is behind VPNs etc. One can do a git-bisect or write his own script > of course, the bisect seeds we have are just for those who do this several > times a day and don't want to wait until stuff builds again and again. I guess I'll just look at the dump, then.
[Bug c++/89550] [8/9 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-02 CC||msebor at gcc dot gnu.org Blocks||56456 Summary|Spurious array-bounds |[8/9 Regression] Spurious |warning when using |array-bounds warning when |__PRETTY_FUNCTION__ as a|using __PRETTY_FUNCTION__ |string_view.|as a string_view Ever confirmed|0 |1 Known to fail||8.3.0, 9.0 --- Comment #1 from Martin Sebor --- Confirmed with the attached translation unit and GCC 9. Bisection points to r264869: 2018-10-05 Richard Biener PR tree-optimization/63155 * tree-ssa-ccp.c (ccp_propagate::visit_phi): Avoid excess vertical space in dumpfiles. * tree-ssa-propagate.h (ssa_propagation_engine::process_ssa_edge_worklist): Remove. * tree-ssa-propagate.c (cfg_blocks_back): New global. (ssa_edge_worklist_back): Likewise. (curr_order): Likewise. (cfg_blocks_get): Remove abstraction. (cfg_blocks_add): Likewise. (cfg_blocks_empty_p): Likewise. (add_ssa_edge): Add to current or next worklist based on RPO index. (add_control_edge): Likewise. (ssa_propagation_engine::process_ssa_edge_worklist): Fold into ... (ssa_propagation_engine::ssa_propagate): ... here. Unify iteration from CFG and SSA edge worklist so we process everything in RPO order, prioritizing forward progress over iteration. (ssa_prop_init): Allocate new worklists, do not dump immediate uses. (ssa_prop_fini): Free new worklists. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug libstdc++/89416] [9 regression] std::vector::push_back no longer builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely --- Should be.
[Bug rtl-optimization/87716] [9 Regression] FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87716 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #4 from Vladimir Makarov --- I don't think it can be easily fixed. We have the following code in IRA (here - means a removed insn, pref means preferred hard reg for destination pseudo, hard reg in () means assigned hard reg, copy and constrain mean preference of two pseudo to have the same hard reg): -28: r109(di)=di; REG_DEAD di;pref di -29: r110(si)=si; REG_DEAD si;pref si -30: r111(dx)=dx; REG_DEAD dx;pref dx -31: r112(xmm0)=xmm0; REG_DEAD xmm0;pref xmm0 5: r100(xmm3)=r112(xmm0); REG_DEAD r112 ->copy(100,112) -32: r113(xmm1)=xmm1; REG_DEAD xmm1;pref xmm1 -6: r101(xmm1)=r113(xmm1); REG_DEAD r113 ->copy(101,113) 10: r103(xmm2)=[r109(di)]; REG_DEAD r109 11: r102(xmm2)=trunc(zero_extend(r103(xmm2))+zero_extend([r110(si)])+const_vector 0>>0x1);REG_DEAD r110,r103->constrain(102,103) 14: r104(xmm0)=vec_select(vec_concat(r102(xmm2),r101(xmm1)),parallel) 16: r105(xmm2)=vec_select(vec_concat(r102(xmm2),r101(xmm3)),parallel); REG_DEAD r102, r101->constrain(102,105) 19: r106(xmm0)=trunc(zero_extend(r104(xmm0))*zero_extend(r100(xmm3)) 0>>0x10); REG_DEAD r104->constrain(106,104) 21: r107(xmm2)=trunc(zero_extend(r105(xmm2))*zero_extend(r100(xmm3)) 0>>0x10); REG_DEAD r105, r100->constrain(107,105)(107,100) 23: r108(xmm0)=vec_concat(us_truncate(r106(xmm0)),us_truncate(r107(xmm2))); REG_DEAD r107, r106->constrain(108,106) 25: [r111(dx)]=r108(xmm0); REG_DEAD r111, r108 We form threads of pseudos to have the same hard reg: Threads: 1. freq 9000: a2r107(2000) a5r105(2000) a8r102(3000) a10r103(2000) 2. freq 6000: a1r108(2000) a3r106(2000) a6r104(2000) 3. freq 5000: a4r100(3000) a13r112(2000); pref xmm0 4. freq 5000: a7r101(3000) a12r113(2000); pref xmm1 Then coloring algorithm prefers pushing pseudos to coloring stack by threads when the other priorities the same. In this case we assign by threads basically: r102 -- assign reg 22(xmm2) r107 -- assign reg 22(xmm2) r105 -- assign reg 22(xmm2) r103 -- assign reg 22(xmm2) r108 -- assign reg 20(xmm0) r106 -- assign reg 20(xmm0) r104 -- assign reg 20(xmm0) r100 -- assign reg 23(xmm3) r112 -- assign reg 20(xmm0) r101 -- assign reg 21(xmm1) r113 -- assign reg 21(xmm1) r111 -- assign reg 1(dx) r110 -- assign reg 4(si) r109 -- assign reg 5(di) We assign xmm2 (first sse reg after xmm0 and xmm1) to pseudos in the 1st thread becuase threads 3 and 4 prefer xmm0 and xmm1. In LRA: As insn 14 requres p104 and p102 be in the same hard reg we generate an additional insn: r114(xmm0) = r102(xmm2) We could get the desired allocation if we start assignments with pseudos from threads with less priority (in order to assign xmm3 to pseudos from the first thread). But it would worsen performance in common case. RA is all about heuristic solution. In some case they work, in some cases they don't. We should see the whole pictures. Actually in this case RA removes 5 copies out of 6 and satisfies 5 out 6 2-op contraints without additional movement. Probably an additional RA subpass which swaps pseudo-register assignments in order to improve allocation could help. But right now I don't see how effectively to implement this and is it really worth to do.
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 Joseph S. Myers changed: What|Removed |Added CC||andres_takach at mentor dot com --- Comment #25 from Joseph S. Myers --- *** Bug 89540 has been marked as a duplicate of this bug. ***
[Bug libquadmath/89540] roundq(x) returning value with non-zero fractional part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540 Joseph S. Myers changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Joseph S. Myers --- So duplicate. *** This bug has been marked as a duplicate of bug 65757 ***
[Bug c++/89554] New: Incorrect location of warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89554
Bug ID: 89554
Summary: Incorrect location of warning
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Found when building LLVM trunk with GCC 9 trunk (built today) compiler.
https://clang.llvm.org/doxygen/LiteralSupport_8cpp_source.html
const char *End = saw_exponent ? ExponentBegin : SuffixBegin;
for (const char *Ptr = DigitsBegin; Ptr < End; ++Ptr) {
if (*Ptr == '.') {
FoundDecimal = true;
continue;
/home/xbolva00/LLVM/llvm-project/clang/lib/Lex/LiteralSupport.cpp:1127:43:
warning: ‘ExponentBegin’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
1127 | for (const char *Ptr = DigitsBegin; Ptr < End; ++Ptr) {
^
I would expect carret to be here: saw_exponent ? ExponentBegin : SuffixBegin;
^
As side note: there are so many "-Wmaybe-uninitialized" warnings. You should
check them whether real issues or no (they spam build warning log very much) -
don't think so.
You should consider removing '-Wmaybe-uninitialized" from standard "-Wall
-Wextra".
[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77583
--- Comment #6 from Steve Kargl ---
On Fri, Mar 01, 2019 at 09:58:43PM +, anlauf at gcc dot gnu.org wrote:
> (In reply to kargl from comment #4)
> > (In reply to Manuel López-Ibáñez from comment #2)
> > > check_conflict is sometimes called with name = NULL and that is passed to
> > > %qs causing a crash.
> >
> > Index: symbol.c
> > ===
> > --- symbol.c(revision 240140)
> > +++ symbol.c(working copy)
> > @@ -473,8 +473,8 @@ check_conflict (symbol_attribute *attr,
> > }
> > }
> >
> > - if (attr->dummy && ((attr->function || attr->subroutine) &&
> > - gfc_current_state () == COMP_CONTAINS))
> > + if (name && attr->dummy && ((attr->function || attr->subroutine)
> > + && gfc_current_state () == COMP_CONTAINS))
> > gfc_error_now ("internal procedure %qs at %L conflicts with "
> >"DUMMY argument", name, where);
>
> The additional check on 'name' basically applies on current trunk and
> fixes the ICE.
>
> Are you still pursuing this?
>
Given that 2.7 years have past, I'll offer "no".
Feel free to run with the patch.
[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77583
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> (In reply to Manuel López-Ibáñez from comment #2)
> > check_conflict is sometimes called with name = NULL and that is passed to
> > %qs causing a crash.
>
> Index: symbol.c
> ===
> --- symbol.c (revision 240140)
> +++ symbol.c (working copy)
> @@ -473,8 +473,8 @@ check_conflict (symbol_attribute *attr,
> }
> }
>
> - if (attr->dummy && ((attr->function || attr->subroutine) &&
> - gfc_current_state () == COMP_CONTAINS))
> + if (name && attr->dummy && ((attr->function || attr->subroutine)
> + && gfc_current_state () == COMP_CONTAINS))
> gfc_error_now ("internal procedure %qs at %L conflicts with "
> "DUMMY argument", name, where);
The additional check on 'name' basically applies on current trunk and
fixes the ICE.
Are you still pursuing this?
[Bug c/89549] [7/8/9 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 --- Comment #2 from David Malcolm --- Can you attach the testcase please, rather than pasting it as a comment. I can't reproduce the note from the example, but whitespace is significant here, and I'm not sure roundtripping through a BZ comment has preserved it. Thanks. That said, it looks like it's giving up, due to a line wider than > LINE_MAP_MAX_COLUMN_NUMBER; the note doesn't seem to consider that case (rather the case of running out of location_t values).
[Bug c++/88820] [7/8/9 Regression] ICE in in C++2a mode for code which is able to be compiled in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88820
--- Comment #7 from Marek Polacek ---
A little bit more simplified:
template struct S;
template struct W {
template static int foo();
bool b = foo();
};
[Bug fortran/67894] bounds of assumed-rank dummy argument not equal to actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67894 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #9 from anlauf at gcc dot gnu.org --- For an analysis of how the code shall behave, see PR89365, especially Reinhold's quote of F2018 (PR89365 comment #3). IMHO this PR is invalid.
[Bug fortran/84868] [7/8/9 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #3) > Works also if len_trim is replaced by len. > > I wonder if this is related to PR86249. Sorry, off-by-one, that should have been PR86248. Also the date given in comment #0 points to rev. 243478 or nearby.
[Bug c++/89421] [9 Regression] ICE in retrieve_specialization, at cp/pt.c:1245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 from Marek Polacek ---
We have
1235 /* Lambda functions in templates aren't instantiated normally, but
through
1236 tsubst_lambda_expr. */
1237 if (lambda_fn_in_template_p (tmpl))
1238 return NULL_TREE;
but since r266056 we allow lambdas in a template-parameter-list:
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2988,12 +2988,6 @@ begin_class_definition (tree t)
if (error_operand_p (t) || error_operand_p (TYPE_MAIN_DECL (t)))
return error_mark_node;
- if (processing_template_parmlist)
-{
- error ("definition of %q#T inside template parameter list", t);
- return error_mark_node;
-}
-
/* According to the C++ ABI, decimal classes defined in ISO/IEC TR 24733
are passed the same as decimal scalar types. */
if (TREE_CODE (t) == RECORD_TYPE
Jason, should we also return NULL_TREE for lambdas inside template parameter
list (in retrieve_specialization)?
[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596 --- Comment #8 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #7) > The above testcase reproduced, reduced to following, started with r266385. > Note, this testcase ICEd in gcc 7.x and earlier too, got fixed with r258504 > (started with r225484). So, this testcase is effectively [7/9 Regression]. I looked at this. It is a typical problem for x86/x86-64 for some cases when the 1st insn scheduling is used. LRA in some cases can do hard register live range splitting to avoid such problems. The older reload even did not try to do thus. Sometimes LRA tries hard to do the range splitting which results in 'Maximum number of LRA assignment passes is achieved' failure. Unfortunately, the current hard reg live range splitting is not a panacea. I don't know how to make it working in for all cases. I believe the only sane solution for now is to switch off the 1st insn scheduler for problematic targets *even if user specifies -fschedule-insns*. It would stop permanent supply of the same problem especially by automatic test generators.
[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497 --- Comment #22 from Jakub Jelinek --- Author: jakub Date: Fri Mar 1 19:06:36 2019 New Revision: 269332 URL: https://gcc.gnu.org/viewcvs?rev=269332=gcc=rev Log: PR middle-end/89497 * g++.dg/tree-prof/devirt.C: Adjust also the ilp32 scan-tree-dump-times from dom3 to tracer pass. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-prof/devirt.C
[Bug libstdc++/89452] basic_stringbuf::seekoff and basic_stringbuf::seekpos implementations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89452
--- Comment #6 from Baykov Nikita ---
There is one more issue.
ISO/IEC 14882:2017(E) and N4800 specify that seekpos(sp, which) and
seekoff(off_type(sp), ios_base::beg, which) should be equivalent, but it seems
that they are not equivalent in libstdc++ implementation for GCC.
The following code works fine for me:
stringbuf sb("abcdefgh", ios_base::in);
assert (sb.pubseekoff(3, ios_base::beg, ios_base::in|ios_base::out) == -1);
The following code fails:
stringbuf sb("abcdefgh", ios_base::in);
assert (sb.pubseekpos(3, ios_base::in|ios_base::out) == -1);
[Bug libstdc++/89416] [9 regression] std::vector::push_back no longer builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416 --- Comment #9 from Jakub Jelinek --- So fixed now for real?
[Bug c++/89421] [9 Regression] ICE in retrieve_specialization, at cp/pt.c:1245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug c++/89553] New: "static const double x = 2" is treated equivalent to "static constexpr double x = 2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89553
Bug ID: 89553
Summary: "static const double x = 2" is treated equivalent to
"static constexpr double x = 2"
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tadeus.prastowo at unitn dot it
Target Milestone: ---
For the following example, requesting a strict compliance to C++17 using
"-std=c++17 -pedantic-errors", Clang rejects but GCC accepts
(https://www.godbolt.org/z/RDRdE5):
template
struct X {
static constexpr double value = *x * 2;
};
static const double x = 2;
static_assert(X<>::value > 2);
According to the discussion at the C++ standard discussion forum (see
https://groups.google.com/a/isocpp.org/d/topic/std-discussion/i9eAYNDCr8U), GCC
behavior is wrong because C++17 standard (the draft available at
http://www.open-std.org/JTC1/SC22/WG21/docs/standards.html) says that "static
const double x = 2" cannot be treated as being equivalent to "static constexpr
double x = 2" due to the use of lvalue-to-rvalue conversion that hits the
following stipulation in [expr.const]p2,2.7,2.7.1 (page 139 of the draft):
-- 8< -
An expression e is a core constant expression unless the evaluation of e,
following the rules of the abstract machine (4.6), would evaluate one of the
following expressions:
— an lvalue-to-rvalue conversion (7.1) unless it is applied to
— a non-volatile glvalue of integral or enumeration type that refers to a
complete non-volatile const object with a preceding initialization, initialized
with a constant expression
-- 8< -
Specifically, "static const double x = 2" is not "a non-volatile glvalue of
integral or enumeration type that refers to a complete non-volatile const
object with a preceding initialization, initialized with a constant expression"
due to the type "double".
[Bug libquadmath/89459] Incorrect rounding for fma in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459 --- Comment #5 from Andres Takach --- Works in 8.3.0. Needed to use lib64 to link, otherwise was picking up earlier version of the library that had the bug. Version 6.2.0 (as first reported) does have the bug.
[Bug libquadmath/89540] roundq(x) returning value with non-zero fractional part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540 --- Comment #4 from Andres Takach --- Works in 8.3.0.
[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #6 from Jakub Jelinek ---
And in the *.sra dump, I really don't see any way how it could be two:
MEM[(struct &) clique 22 base 1] ={v} {CLOBBER};
...
n1D.7146 ={v} {CLOBBER};
...
MEM[(struct &) clique 27 base 1] ={v} {CLOBBER};
SR.161_6 = SR.150_36;
MEM[(struct tupleD.6437 *) + 8B] = SR.161_6;
n1$tail$head$payload_91 = MEM[(struct tupleD.6437 *) + 4B];
...
n1D.7698 ={v} {CLOBBER};
and no other stmts referencing n1. So, we have the whole var undefined, then
we store an int at offset 8 bytes into it and read an int from offset 4 into
it.
That is uninitialized load which as #c5 tried to prove wasn't there before
late_intra_sra.
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #11 from Piotr Kubaj --- Hm, sorry, I copied the Entering directive from a line before. Nevertheless, setting -O1 helps with GCC 7 and 8. But building GCC 9 still fails (I'm testing the newest snapshot). I tried both -O0 and -O1. The exact set of env variables I set is: CXXFLAGS_FOR_TARGET="-O0" CFLAGS_FOR_TARGET="-O0" BOOT_CFLAGS="-O0" rm -f include-fixed/README cp /usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190224/gcc/../fixincludes/README-fixinc include-fixed/README chmod a+r include-fixed/README echo timestamp > stmp-int-hdrs /usr/local/poudriere/ports/default/lang/gcc9-devel/work/.build/./gcc/xgcc -B/usr/local/poudriere/ports/default/lang/gcc9-devel/work/.build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190224/gcc/testsuite/selftests cc1: internal compiler error: Segmentation fault
[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979 --- Comment #14 from Dominique d'Humieres --- The patch in comment 13 fixes the ICE for pr69102.c. Testing will start soon. Thanks for the work!
[Bug c++/89538] [7.3.0] GCC miscompiling LLVM because of wrong vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538 --- Comment #3 from Taewook Oh --- Here's the compiler command and the preprocessed source. command: https://gist.github.com/taewookoh/45e710594497b887e2ac54168c86c17f source: https://gist.github.com/taewookoh/00f38b4a2f617e78b30d33c8103a7703 Thanks!
[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #5 from Jakub Jelinek ---
You mean -fno-strict-aliasing? I guess many options change the behavior that
it doesn't trigger anymore.
In the #c3 dump, I really don't see how aliasing could matter though, all are
MEM_REFs with addresses of particular automatic vars, there are no pointers
involved.
I've instrumented the compiler a little bit:
--- gcc/gimple-pretty-print.c.jj2019-01-01 12:37:15.700998856 +0100
+++ gcc/gimple-pretty-print.c 2019-03-01 17:44:46.673862737 +0100
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.
#include "stringpool.h"
#include "attribs.h"
#include "asan.h"
+#include "tree-dfa.h"
#define INDENT(SPACE) \
do { int i; for (i = 0; i < SPACE; i++) pp_space (buffer); } while (0)
@@ -575,6 +576,7 @@ dump_ternary_rhs (pretty_printer *buffer
}
}
+volatile bool assign_extra;
/* Dump the gimple assignment GS. BUFFER, SPC and FLAGS are as in
pp_gimple_stmt_1. */
@@ -634,6 +636,35 @@ dump_gimple_assign (pretty_printer *buff
gcc_unreachable ();
if (!(flags & TDF_RHS_ONLY))
pp_semicolon (buffer);
+
+ if (assign_extra && gimple_num_ops (gs) == 2)
+ {
+ bool any = false;
+ for (int i = 0; i < 2; i++)
+ {
+ tree op = gimple_op (gs, i);
+ if (handled_component_p (op)
+ || TREE_CODE (op) == MEM_REF
+ || TREE_CODE (op) == TARGET_MEM_REF
+ || DECL_P (op))
+ {
+ poly_int64 off, size, max_size;
+ bool dummy;
+ get_ref_base_and_extent (op, , , _size, );
+ if (!any)
+ {
+ pp_string (buffer, "//");
+ any = true;
+ }
+ pp_string (buffer, i ? " rhs1 " : " lhs ");
+ pp_wide_integer (buffer, off);
+ pp_space (buffer);
+ pp_wide_integer (buffer, size);
+ pp_space (buffer);
+ pp_wide_integer (buffer, max_size);
+ }
+ }
+ }
}
}
and at the start of late_intra_sra after set assign_extra = 1 debug_bb_n (2)
looks like below.
Extra comments added where the value 2 propagates through:
[local count: 1073741824]:
MEM[(struct &)] ={v} {CLOBBER};// lhs 0 32 32
MEM[(struct &) + 4] ={v} {CLOBBER};// lhs 32 32 32
MEM[(struct &) + 8] ={v} {CLOBBER};// lhs 64 96 96
MEM[(struct &) + 8] ={v} {CLOBBER};// lhs 64 32 32
MEM[(struct &) + 12] ={v} {CLOBBER};// lhs 96 32 32
MEM[(struct &) + 16] ={v} {CLOBBER};// lhs 128 16 16
MEM[(struct &)] ={v} {CLOBBER};// lhs 0 128 128
D.9933 ={v} {CLOBBER};// lhs 0 96 96
MEM[(struct &)] ={v} {CLOBBER};// lhs 0 128 128
D.9940 ={v} {CLOBBER};// lhs 0 96 96
D.9941 ={v} {CLOBBER};// lhs 0 96 96
D.9942 ={v} {CLOBBER};// lhs 0 64 64
D.9936 ={v} {CLOBBER};// lhs 0 128 128
MEM[(struct &)] ={v} {CLOBBER};// lhs 0 128 128
D.9937 ={v} {CLOBBER};// lhs 0 128 128
n1 ={v} {CLOBBER};// lhs 0 128 128
MEM[(struct &)] ={v} {CLOBBER};// lhs 0 32 32
MEM[(struct &) + 4] ={v} {CLOBBER};// lhs 32 32 32
MEM[(struct &) + 8] ={v} {CLOBBER};// lhs 64 96 96
MEM[(struct &) + 8] ={v} {CLOBBER};// lhs 64 32 32
MEM[(struct &) + 12] ={v} {CLOBBER};// lhs 96 32 32
MEM[(struct &) + 16] ={v} {CLOBBER};// lhs 128 16 16
MEM[(struct tuple &) + 4].head.payload = 2;// lhs 32 32 32
// MEM[+4] == 2
MEM[(struct tuple &) + 8].head.payload = 3;// lhs 64 32 32
D.9957.head = MEM[(const struct type_n &) + 4];// lhs 0 32 32 rhs1 32
32 32
// MEM[+0] == 2
MEM[(struct &)] ={v} {CLOBBER};// lhs 0 96 96
MEM[(struct tuple *)].head = MEM[(const struct type_n &)];// lhs
0 32 32 rhs1 0 32 32
// MEM[+0] == 2
D.9957 ={v} {CLOBBER};// lhs 0 64 64
MEM[(struct tuple *) + 4B] = 4;// lhs 32 32 32
D.9960 = D.9959;// lhs 0 96 96 rhs1 0 96 96
// MEM[+0] == 2
MEM[(struct &)] ={v} {CLOBBER};// lhs 0 128 128
D.9953.head = MEM[(const struct type_n &) + 8];// lhs 0 32 32 rhs1 64
32 32
D.9953.tail = MEM[(const struct tuple &)];// lhs 32 96 96 rhs1 0 96 96
// MEM[+4] == 2
D.9960 ={v} {CLOBBER};// lhs 0 96 96
D.9959 ={v} {CLOBBER};// lhs 0 96 96
D.9952 = D.9953;// lhs 0 128 128 rhs1 0 128 128
// MEM[+4] == 2
MEM[(struct &)] ={v} {CLOBBER};// lhs 0 160 160
MEM[(struct tuple *)].tail = MEM[(const struct tuple &)];// lhs
32 128 128 rhs1 0 128 128
// MEM[+8] == 2
D.9952 ={v} {CLOBBER};// lhs 0 128 128
D.9953 ={v} {CLOBBER};// lhs 0 128 128
D.9954 ={v} {CLOBBER};// lhs 0 64 64
D.9947 = MEM[(const struct tuple &) + 8];// lhs 0 96 96 rhs1 64 96 96
// MEM[+0] == 2
MEM[(struct tuple *)].tail = MEM[(const struct tuple &)];// lhs
32 96 96 rhs1 0 96 96
// MEM[+4] == 2
SR.150_36 = MEM[(const struct tuple &) + 4];// rhs1 32 32 32
D.9947 ={v} {CLOBBER};// lhs 0 96 96
MEM[(struct &)] ={v} {CLOBBER};// lhs 0 96 96
D.9949.head = MEM[(const struct type_n &) + 4];// lhs 0 32 32 rhs1 32 32
32
// MEM[+0] == 2
[Bug c++/44859] missed warning: returning reference to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44859 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||4.9.4 Resolution|--- |FIXED Known to fail||4.5.3 --- Comment #2 from Martin Sebor --- Since 4.9, GCC warns on all functions in the test case in comment #0. Fixed by r208970.
[Bug c++/89548] reinterpret_cast treats xvalue as prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89548 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- So fixed, but only for GCC 9...
[Bug c++/89548] reinterpret_cast treats xvalue as prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89548 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Fixed by r260622.
[Bug c/65403] -Wno-error= is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403 --- Comment #8 from Alex Henrie --- Why weren't Manuel's patches accepted?
[Bug debug/89530] Wrong debug informations for C array generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530 --- Comment #6 from Jakub Jelinek --- (In reply to dcci from comment #5) > (In reply to Jakub Jelinek from comment #4) > > Also, we usually bisect which gcc revision introduced a problem and from > > that change we can often see what goes wrong quickly. Both Red Hat and SUSE > > have terrabytes of built gcc revisions to make such bisection faster. > > I see. Is this data available for the masses? No, it is behind VPNs etc. One can do a git-bisect or write his own script of course, the bisect seeds we have are just for those who do this several times a day and don't want to wait until stuff builds again and again.
[Bug c++/89552] odr namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89552 Azat changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Azat --- misclick, sorry
[Bug rtl-optimization/85899] [8/9 Regression] ICE in find_fallthru_edge_from, at haifa-sched.c:8059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899 --- Comment #5 from Alexander Monakov --- Author: amonakov Date: Fri Mar 1 16:18:04 2019 New Revision: 269319 URL: https://gcc.gnu.org/viewcvs?rev=269319=gcc=rev Log: haifa-sched: handle fallthru edge to EXIT block (PR 85899) PR rtl-optimization/85899 * haifa-sched.c (find_fallthru_edge_from): Relax assert to account for fallthru edges leading to the exit block. * gcc.dg/pr85899.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr85899.c Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546 --- Comment #4 from Martin Jambor --- (In reply to Jakub Jelinek from comment #3) > ...But in the sra pass dump that possibility is gone: I am still double checking because it is easy to make a mistake but I have seen a (potential) path in the sra dump, just not in the optimized dump. Also, I believe the testcase passes with -fstrict-aliasing (can you please check?), which would hint at some problems with aliasing... (of course, those might be created by SRA too).
[Bug rtl-optimization/85899] [8 Regression] ICE in find_fallthru_edge_from, at haifa-sched.c:8059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-01 Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |find_fallthru_edge_from, at |find_fallthru_edge_from, at |haifa-sched.c:8059 |haifa-sched.c:8059 Ever confirmed|0 |1
[Bug c++/89552] New: odr namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89552 Bug ID: 89552 Summary: odr namespace Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a3at.mail at gmail dot com Target Milestone: ---
[Bug debug/89530] Wrong debug informations for C array generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530 --- Comment #5 from dcci --- (In reply to Jakub Jelinek from comment #4) > Also, we usually bisect which gcc revision introduced a problem and from > that change we can often see what goes wrong quickly. Both Red Hat and SUSE > have terrabytes of built gcc revisions to make such bisection faster. I see. Is this data available for the masses?
[Bug middle-end/89551] New: [9 regression] Test case gcc.dg/uninit-pred-8_b.c fails after r269302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89551 Bug ID: 89551 Summary: [9 regression] Test case gcc.dg/uninit-pred-8_b.c fails after r269302 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- New failures (update from 269300 to 269304): FAIL: gcc.dg/uninit-pred-8_b.c bogus warning (test for bogus messages, line 20) FAIL: gcc.dg/uninit-pred-8_b.c bogus warning (test for bogus messages, line 39) FAIL: gcc.dg/uninit-pred-8_b.c warning (test for warnings, line 42) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-8_b.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -Wuninitialized -O2 -S -o uninit-pred-8_b.s /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-8_b.c: In function 'foo': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-8_b.c:20:7: warning: 'v' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-8_b.c: In function 'foo_2': /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/uninit-pred-8_b.c:39:7: warning: 'v' may be used uninitialized in this function [-Wmaybe-uninitialized] FAIL: gcc.dg/uninit-pred-8_b.c bogus warning (test for bogus messages, line 20) PASS: gcc.dg/uninit-pred-8_b.c bogus warning (test for bogus messages, line 23) FAIL: gcc.dg/uninit-pred-8_b.c bogus warning (test for bogus messages, line 39) FAIL: gcc.dg/uninit-pred-8_b.c warning (test for warnings, line 42) PASS: gcc.dg/uninit-pred-8_b.c (test for excess errors) testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes2 # of unexpected failures3
[Bug debug/89530] Wrong debug informations for C array generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530 --- Comment #4 from Jakub Jelinek --- Also, we usually bisect which gcc revision introduced a problem and from that change we can often see what goes wrong quickly. Both Red Hat and SUSE have terrabytes of built gcc revisions to make such bisection faster.
[Bug debug/89530] Wrong debug informations for C array generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
--- Comment #3 from Jakub Jelinek ---
In GCC people don't disable passes usually, but just use -fdump-tree-all and/or
-da and look at the dumps where it broke. We do have
-fdisable--{,=range-list} options to disable individual passes if
needed, or various -fno-tree-* or -fno-rtl-* etc. options, but it can give
surprising result if you disable too many and just using binary search in the
pass dumps is much better (start looking at -fdump-tree-optimized dump if it is
a GIMPLE or RTL issue, depending on that look at some pass in the middle of the
either range, etc.
[Bug libstdc++/89452] basic_stringbuf::seekoff and basic_stringbuf::seekpos implementations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89452 --- Comment #5 from Baykov Nikita --- I apologize for my careless mistake. I have some other questions that I would like to clarify. Hope it will be right to do it here. 1. You mentioned that pptr() was no longer required to be null pointer in this case. I have checked https://cplusplus.github.io/LWG/issue2995. The issue has WP status, but what is not clear to me whether the change affects only C++20 and further versions of the standard, or all of the versions, including C++17, C++14, C++11, etc. The explanation in https://cplusplus.github.io/LWG/lwg-active.html#IssueStatus looks ambigous to me and I do not really understand the difference between DR, WP and C++1x statuses. 2. Table 112 in N4800 describes how the positioning depends on function arguments 'which' and 'way'. I am not sure if conditions in the first two rows of the table are specified correctly. Maybe, they should be replaced with '(which & (ios_base::in|ios_base::out)) == ios_base::in' and '(which & (ios_base::in|ios_base::out)) == ios_base::out'? For now, the result doesn't seem to depend on 'way'. If 'which == ios_base::in|ios_base::out && way == ios_base::cur', the conditions of the third row are not satisfied. However, the conditions of the first two rows are satisfied, thus both input and output sequences should be positioned, despite the fact that 'way == ios_base::cur'. 3. Your previous replies don't explain why the opening mode of the buffer should be checked in addition to requirements of the standard.
[Bug libstdc++/89452] basic_stringbuf::seekoff and basic_stringbuf::seekpos implementations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89452 --- Comment #4 from Baykov Nikita --- I apologize for my careless mistake. I have some other questions that I would like to clarify. Hope it will be right to do it here. 1. You mentioned that pptr() was no longer required to be null pointer in this case. I have checked https://cplusplus.github.io/LWG/issue2995. The issue has WP status, but what is not clear to me whether the change affects only C++20 and further versions of the standard, or all of the versions, including C++17, C++14, C++11, etc. The explanation in https://cplusplus.github.io/LWG/lwg-active.html#IssueStatus looks ambigous to me and I do not really understand the difference between DR, WP and C++1x statuses. 2. Table 112 in N4800 describes how the positioning depends on function arguments 'which' and 'way'. I am not sure if conditions in the first two rows of the table are specified correctly. Maybe, they should be replaced with '(which & (ios_base::in|ios_base::out)) == ios_base::in' and '(which & (ios_base::in|ios_base::out)) == ios_base::out'? For now, the result doesn't seem to depend on 'way'. If 'which == ios_base::in|ios_base::out && way == ios_base::cur', the conditions of the third row are not satisfied. However, the conditions of the first two rows are satisfied, thus both input and output sequences should be positioned, despite the fact that 'way == ios_base::cur'. 3. Your previous replies don't explain why the opening mode of the buffer should be checked in addition to requirements of the standard.
[Bug c++/89537] missing location for error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed.
[Bug c++/89532] [9 Regression] internal compiler error: in type_has_nontrivial_copy_init, at cp/tree.c:4024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/89537] missing location for error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Fri Mar 1 15:57:46 2019 New Revision: 269318 URL: https://gcc.gnu.org/viewcvs?rev=269318=gcc=rev Log: PR c++/89537 - missing location for error with non-static member fn. * call.c (resolve_args): Use EXPR_LOCATION. * typeck.c (build_class_member_access_expr): Use input_location. * g++.dg/diagnostic/member-fn-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/diagnostic/member-fn-1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89532] [9 Regression] internal compiler error: in type_has_nontrivial_copy_init, at cp/tree.c:4024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Fri Mar 1 15:55:56 2019 New Revision: 269317 URL: https://gcc.gnu.org/viewcvs?rev=269317=gcc=rev Log: PR c++/89532 - ICE with incomplete type in decltype. * semantics.c (finish_compound_literal): Return error_mark_node if digest_init_flags returns error_mark_node. * g++.dg/cpp2a/nontype-class14.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/89542] Error reported on incorrect line number when using GCC to compile .S files using #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542 --- Comment #4 from puffydaemon at gmail dot com --- Okay, I am going to try with clang... El vie., 1 mar. 2019 a las 10:37, rguenth at gcc dot gnu.org (< gcc-bugzi...@gcc.gnu.org>) escribió: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542 > > --- Comment #3 from Richard Biener --- > Also note that GCC 4.2.1 is no longer maintained. > > -- > You are receiving this mail because: > You reported the bug.
[Bug debug/89530] Wrong debug informations for C array generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530 --- Comment #2 from dcci --- Thanks Jakub. We're trying to report more of these but it's hard to filter out duplicates. A possible way we thought was that of stopping at some point in the pipeline (so running a subset of the optimizations), to identify where this broke. (something like https://llvm.org/docs/OptBisect.html). Is there any easy way of doing this in GCC? I skimmed through the docs and haven't found any.
[Bug c/89051] -Wno-error= does not work for warning groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051 --- Comment #8 from Martin Sebor --- The test passes without the -Wno-error=pedantic so it looks like it's not necessary. I must have thought it was for some reason. But to make sure I understand you correctly: do you mean that -Wpedantic -Wno-error=pedantic suppresses the pedantic warnings? (I would expect that to retain the pedantic warnings and not make them errors even if -Werror were on the command line; unless -Wno-error=pedantic were followed by -Werror=pedantic.)
[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
--- Comment #16 from Daniel Borkmann ---
(In reply to Martin Liška from comment #15)
> (In reply to Daniel Borkmann from comment #12)
> > I've been looking into this issue quite recently and improved the benchmark
> > tool a bit along the way. There need to be multiple considerations wrt to
> > traversing the switch cases, the case is here is doing round robin, but
> > additional distributions / tests could be added. Pushed here just in case:
> > https://github.com/borkmann/microbenchmark
>
> Thanks a lot for the benchmark.
>
> > Numbers I'm getting are stable:
> >
> > * Xeon E3-1240, packet.net c1.small.x86 instance:
> >
> > # make prep
> > [...]
> > # make
> > gcc -g -I. -O2 -c -o test.o test.c
> > gcc -g -I. -O2 -mindirect-branch=thunk --param=case-values-threshold=20
> > -c -o switch-no-table.o switch-no-table.c
> > gcc -g -I. -O2 -mindirect-branch=thunk -c -o switch.o switch.c
> > gcc -g -I. -O2 -c -o switch-no-retpol.o switch-no-retpol.c
> > gcc -o test test.o switch-no-table.o switch.o switch-no-retpol.o
> > taskset 1 ./test
> > no retpoline : 6098325270
> > no jump table: 6298192058 (no retpoline: 103.28%)
> > jump table : 22081802856 (no retpoline: 362.10%, no jump table:
> > 350.61%)
> > # make
> > taskset 1 ./test
> > no retpoline : 6098439816
> > no jump table: 6298242270 (no retpoline: 103.28%)
> > jump table : 22107872854 (no retpoline: 362.52%, no jump table:
> > 351.02%)
> > # make
> > taskset 1 ./test
> > no retpoline : 6098187038
> > no jump table: 6298308128 (no retpoline: 103.28%)
> > jump table : 22071053524 (no retpoline: 361.93%, no jump table:
> > 350.43%)
> >
> > * Xeon Gold 5120, packet.net m2.xlarge.x86 instance:
> >
> > # make prep
> > [...]
> > # make
> > gcc -g -I. -O2 -c -o test.o test.c
> > gcc -g -I. -O2 -mindirect-branch=thunk --param=case-values-threshold=20
> > -c -o switch-no-table.o switch-no-table.c
> > gcc -g -I. -O2 -mindirect-branch=thunk -c -o switch.o switch.c
> > gcc -g -I. -O2 -c -o switch-no-retpol.o switch-no-retpol.c
> > gcc -o test test.o switch-no-table.o switch.o switch-no-retpol.o
> > taskset 1 ./test
> > no retpoline : 5450356814
> > no jump table: 5620673036 (no retpoline: 103.12%)
> > jump table : 21448285314 (no retpoline: 393.52%, no jump table:
> > 381.60%)
> > # make
> > taskset 1 ./test
> > no retpoline : 5450356100
> > no jump table: 5620678302 (no retpoline: 103.12%)
> > jump table : 21448119720 (no retpoline: 393.52%, no jump table:
> > 381.59%)
> > # make
> > taskset 1 ./test
> > no retpoline : 5450331258
> > no jump table: 5620839740 (no retpoline: 103.13%)
> > jump table : 21446922902 (no retpoline: 393.50%, no jump table:
> > 381.56%)
>
> I can confirm the numbers. I've got:
> model name: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
>
> taskset 1 ./test
> no retpoline : 4311969467
> no jump table: 5146081372 (no retpoline: 119.34%)
> jump table : 18845846887 (no retpoline: 437.06%, no jump table:
> 366.22%)
Ok, great, thanks for testing on your side as well!
> > I've also looked into clang for their -mretpoline flag, and they generally
> > turn off jump table generation in this case. For gcc, the s390 folks
> > implemented a target override for the default case-values-threshold to raise
> > it to 20.
>
> Note that GCC has similar parameter:
>
> --param case-values-threshold
>The smallest number of different values for which it is best
> to use a jump-table instead of a tree of conditional branches. If the value
> is 0, use the default for the machine. The default is 0.
Yeah, I know, I've used it above for the test case (see the gcc cmdline parts).
> For 20 branches, I've got even worse numbers:
> https://github.com/marxin/microbenchmark-1/tree/retpoline-table
>
> taskset 1 ./test
> no retpoline : 5096377521
> no jump table: 5169400990 (no retpoline: 101.43%)
> jump table : 28830137876 (no retpoline: 565.70%, no jump table:
> 557.71%)
>
> So are you suggesting to disable jump tables with retpolines at all?
I leave that up to you guys, but I would at min probably implement something
like s390 folks did for gcc, commit db7a90aa0de5 ("S/390: Disable prediction of
indirect branches"), see s390_case_values_threshold() which does:
+unsigned int
+s390_case_values_threshold (void)
+{
+ /* Disabling branch prediction for indirect jumps makes jump tables
+ much more expensive. */
+ if (TARGET_INDIRECT_BRANCH_NOBP_JUMP)
+return 20;
+
+ return default_case_values_threshold ();
+}
> For x86 something similar could be done. Anyway, H.J. Lu asked me
> > to reopen this issue (but seems like I cannot make this change from my
> > account).
>
> Yep, I would need an account ending with @gcc.org to change a bug.
[Bug c++/89550] New: Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550
Bug ID: 89550
Summary: Spurious array-bounds warning when using
__PRETTY_FUNCTION__ as a string_view.
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron at bestateless dot com
Target Milestone: ---
Created attachment 45870
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45870=edit
Preprocessed source.
Compiler Information:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)
Example:
#include
void foo() {
std::string_view s(__PRETTY_FUNCTION__);
s.remove_prefix(s.find_last_of(' '));
std::string().find(s.data());
}
Command Line:
g++ -std=c++17 -Warray-bounds -Werror -O2 -c test.cpp -o test.o
Does not fail for optimization levels -O0, -O1, or -O3. Only fails for -O2.
Expected:
Compiles successfully.
From experiments on https://godbolt.org/ this code compiles on 7.1, 7.2, 7.3,
7.4, 8.1, 8.2, and trunk. It fails to compile on 8.2.1 and 8.3.0.
Actual:
test.cpp: In function ‘void foo()’:
test.cpp:3:6: warning: offset ‘-1’ outside bounds of constant string
[-Warray-bounds]
void foo() {
^~~
Details:
This does not fail if the line with "remove_prefix" is commented out. In this
case __PRETTY_FUNCTION__ does contain a space, so it should not get npos from
the "find_last_of" call. Also does not fail if the call to "find" is
commented
out. It is the combination of both lines that causes the warning.
I can get this to fail in the same way on -O3 if I wrap the function in a
namespace name that is six characters in length or more. If it is five
characters or less then it does compile on -O3.
This example succeeds with "g++ -std=c++17 -Warray-bounds -Werror -O3":
#include
namespace n
{
void foo() {
std::string_view s(__PRETTY_FUNCTION__);
s.remove_prefix(s.find_last_of(' '));
std::string().find(s.data());
}
}
This example fails with "g++ -std=c++17 -Warray-bounds -Werror -O3" (note the
namespace name is longer by one character):
#include
namespace nn
{
void foo() {
std::string_view s(__PRETTY_FUNCTION__);
s.remove_prefix(s.find_last_of(' '));
std::string().find(s.data());
}
}
[Bug c/89549] [7/8/9 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 Martin Liška changed: What|Removed |Added Last reconfirmed||2019-3-1 Known to work||6.4.0 Summary|-Wmisleading-indentation is |[7/8/9 Regression] |disabled from this point|-Wmisleading-indentation is |onwards, since |disabled from this point |column-tracking was |onwards, since |disabled due to the size of |column-tracking was |the code/headers|disabled due to the size of ||the code/headers Known to fail||7.4.0, 8.3.0, 9.0 --- Comment #1 from Martin Liška --- Started with r244292, thus GCC 7 regression.
[Bug c/89549] New: -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
Bug ID: 89549
Summary: -Wmisleading-indentation is disabled from this point
onwards, since column-tracking was disabled due to the
size of the code/headers
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Seen on a test-case that is not having many lines, but one line is very wide:
$ cat mi.ii
class String {
public: bool
operator==(char *) const; bool operator!=(char *) ;
String() ; String(char *); };
class StringName { public:
StringName(char *); };
template class List {public: void push_back( a ) ;
};
class Variant { public: enum b { NIL} ; };
enum c { PROPERTY_HINT_NONE};
enum { PROPERTY_USAGE_CATEGORY
};
struct PropertyInfo { PropertyInfo(Variant::b ,
String , c , String , int ) ; };
class Object { protected:static String _get_category() ;
void _set() ; bool _get( StringName , Variant ) const ; void
_get_property_list(List *) const ; void _notification();
static void _get_valid_parents_static(List *)
; bool _is_gpl_reversed() const
;
};
class ClassDB { public: template void
_add_class() ; static void get_property_list(StringName ,
List *, bool , const Object * );
};
class d : public Object { protected: static void _bind_methods(); };
class AudioStreamPlayback : public d {public:
static String get_class_static() ; bool is_class( String ) const ; bool
is_class_ptr(void *) const ; static void *_get_bind_methods() ; static void
initialize_class() ; bool (Object::*_get_get() const)(const StringName &,
Variant &) const ; bool _getv( StringName , Variant ) const ; bool
(Object::*_get_set() )(const StringName &, const Variant &) ; bool _setv(
StringName , Variant ) ; void (Object::*_get_get_property_list()
const)(List * ) const ; void
_get_property_listv(List *, bool ) const ;};
String get_category_static_category ;
class AudioStreamPlaybackRandomPitch : public AudioStreamPlayback {
private: mutable StringName _class_name; friend class ClassDB; public:
static inline void *get_class_ptr_static() { static int ptr; return }
static inline String get_class_static() { return
String("AudioStreamPlaybackRandomPitch"); } static inline String
get_parent_class_static() { return AudioStreamPlayback::get_class_static(); }
static void get_inheritance_list_static(List *p_inheritance_list) {
AudioStreamPlayback:get_inheritance_list_static(p_inheritance_list);
p_inheritance_list->push_back(String("AudioStreamPlaybackRandomPitch")); }
static String get_category_static() { if (_get_category !=
AudioStreamPlayback::_get_category) { if (get_category_static_category != "")
get_category_static_category = ""; get_category_static_category =
_get_category(); } return get_category_static_category; } static String
inherits_static() { return String("AudioStreamPlayback"); } virtual bool
is_class(const String p_class) const { return (p_class ==
("AudioStreamPlaybackRandomPitch")) ? true :
AudioStreamPlayback::is_class(p_class); } virtual bool is_class_ptr(void
*p_ptr) const { return (p_ptr == get_class_ptr_static) ? true :
AudioStreamPlayback::is_class_ptr(p_ptr); } static void
get_valid_parents_static(List *p_parents) { if
(AudioStreamPlaybackRandomPitch::_get_valid_parents_static !=
AudioStreamPlayback::_get_valid_parents_static) {
AudioStreamPlaybackRandomPitch:_get_valid_parents_static(p_parents); }
AudioStreamPlayback:get_valid_parents_static(p_parents); } protected: inline
static void (*_get_bind_methods())() { return
AudioStreamPlaybackRandomPitch::_bind_methods; } public: static void
initialize_class() { static bool initialized = false; if (initialized) return
AudioStreamPlayback::initialize_class();
ClassDB::_add_class; if
(AudioStreamPlaybackRandomPitch::_get_bind_methods !=
AudioStreamPlayback::_get_bind_methods())
[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 Martin Liška changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Comment #15 from Martin Liška --- (In reply to Daniel Borkmann from comment #12) > I've been looking into this issue quite recently and improved the benchmark > tool a bit along the way. There need to be multiple considerations wrt to > traversing the switch cases, the case is here is doing round robin, but > additional distributions / tests could be added. Pushed here just in case: > https://github.com/borkmann/microbenchmark Thanks a lot for the benchmark. > > Numbers I'm getting are stable: > > * Xeon E3-1240, packet.net c1.small.x86 instance: > > # make prep > [...] > # make > gcc -g -I. -O2 -c -o test.o test.c > gcc -g -I. -O2 -mindirect-branch=thunk --param=case-values-threshold=20 > -c -o switch-no-table.o switch-no-table.c > gcc -g -I. -O2 -mindirect-branch=thunk -c -o switch.o switch.c > gcc -g -I. -O2 -c -o switch-no-retpol.o switch-no-retpol.c > gcc -o test test.o switch-no-table.o switch.o switch-no-retpol.o > taskset 1 ./test > no retpoline : 6098325270 > no jump table: 6298192058 (no retpoline: 103.28%) > jump table : 22081802856 (no retpoline: 362.10%, no jump table: > 350.61%) > # make > taskset 1 ./test > no retpoline : 6098439816 > no jump table: 6298242270 (no retpoline: 103.28%) > jump table : 22107872854 (no retpoline: 362.52%, no jump table: > 351.02%) > # make > taskset 1 ./test > no retpoline : 6098187038 > no jump table: 6298308128 (no retpoline: 103.28%) > jump table : 22071053524 (no retpoline: 361.93%, no jump table: > 350.43%) > > * Xeon Gold 5120, packet.net m2.xlarge.x86 instance: > > # make prep > [...] > # make > gcc -g -I. -O2 -c -o test.o test.c > gcc -g -I. -O2 -mindirect-branch=thunk --param=case-values-threshold=20 > -c -o switch-no-table.o switch-no-table.c > gcc -g -I. -O2 -mindirect-branch=thunk -c -o switch.o switch.c > gcc -g -I. -O2 -c -o switch-no-retpol.o switch-no-retpol.c > gcc -o test test.o switch-no-table.o switch.o switch-no-retpol.o > taskset 1 ./test > no retpoline : 5450356814 > no jump table: 5620673036 (no retpoline: 103.12%) > jump table : 21448285314 (no retpoline: 393.52%, no jump table: > 381.60%) > # make > taskset 1 ./test > no retpoline : 5450356100 > no jump table: 5620678302 (no retpoline: 103.12%) > jump table : 21448119720 (no retpoline: 393.52%, no jump table: > 381.59%) > # make > taskset 1 ./test > no retpoline : 5450331258 > no jump table: 5620839740 (no retpoline: 103.13%) > jump table : 21446922902 (no retpoline: 393.50%, no jump table: > 381.56%) I can confirm the numbers. I've got: model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz taskset 1 ./test no retpoline : 4311969467 no jump table: 5146081372 (no retpoline: 119.34%) jump table : 18845846887 (no retpoline: 437.06%, no jump table: 366.22%) > > I've also looked into clang for their -mretpoline flag, and they generally > turn off jump table generation in this case. For gcc, the s390 folks > implemented a target override for the default case-values-threshold to raise > it to 20. Note that GCC has similar parameter: --param case-values-threshold The smallest number of different values for which it is best to use a jump-table instead of a tree of conditional branches. If the value is 0, use the default for the machine. The default is 0. For 20 branches, I've got even worse numbers: https://github.com/marxin/microbenchmark-1/tree/retpoline-table taskset 1 ./test no retpoline : 5096377521 no jump table: 5169400990 (no retpoline: 101.43%) jump table : 28830137876 (no retpoline: 565.70%, no jump table: 557.71%) So are you suggesting to disable jump tables with retpolines at all? For x86 something similar could be done. Anyway, H.J. Lu asked me > to reopen this issue (but seems like I cannot make this change from my > account). Yep, I would need an account ending with @gcc.org to change a bug.
[Bug tree-optimization/35362] Splitting up a switch table into smaller ones (where there a huge gaps between the clusters)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35362 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- I can confirm it's implemented. One get following clusters for the 2 tests: grep clusters pr36362.c.171t.switchlower1 ;; GIMPLE switch case clusters: JT:0-20 JT:110-220 JT:310-324 grep clusters pr36362-2.c.171t.switchlower1 ;; GIMPLE switch case clusters: JT:0-20 JT:110-220 JT:310-324 1318 1320-1324 Which looks good to me.
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #12 from Michael Matz --- (In reply to H.J. Lu from comment #11) > (In reply to Michael Matz from comment #10) > > Ah, I missed that. Yeah, I'd like to be co-owner. > > Please send me your gitlab account name. Err, right, that probably helps ;-) It's 'susematz'
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #11 from H.J. Lu --- (In reply to Michael Matz from comment #10) > Ah, I missed that. Yeah, I'd like to be co-owner. Please send me your gitlab account name.
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #10 from Michael Matz --- Ah, I missed that. Yeah, I'd like to be co-owner.
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #9 from H.J. Lu --- (In reply to Michael Matz from comment #7) > What about this variant of the second part? > Hi Michael, I moved x86 psABI repo to https://gitlab.com/x86-psABIs Would you like to be co-owners?
[Bug bootstrap/89539] [9 Regression] gcc fails to build/bootstrap on MACOSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89539 --- Comment #6 from Jürgen Reuter --- Yep, fixed, thanks for the overnight reaction^^. (and next time I think I have the guts to mark it as 'bootstrap' right from the beginning)
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 H.J. Lu changed: What|Removed |Added Attachment #45868|0 |1 is obsolete|| --- Comment #8 from H.J. Lu --- Created attachment 45869 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45869=edit An psABI patch
[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #13 from Andrey Belevantsev ---
So now I understand, finally. We move up an sp decrement and are supposed to
check that sp is available on the paths that are not touched by the move. There
are several successors of the move target block so the checking code is special
(and was the same there since day 1 of sel-sched). The code checks, for each
successor block, the expressions that are present in the merged availability
set at the end of target block but are not present in the successor block set.
Such expressions are marked as having unavailable target registers.
In this case for one successor block there happens to be another fence, and
that fence set has the copy of the sp decrement instruction. So it is not
detected as being unavailable. What _should_ have happened is that the
successor block with another fence should have been marked as ineligible
successor (we don't move along that path), so the av set against which we're
checking has to be NULL. The fix is just to have that properly accounted for.
The patch is below, and I wouldn't be surprised if it fixes more PRs than this
one.
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 315f2c0c0ab..2053694b196 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -2820,10 +2820,12 @@ compute_av_set_at_bb_end (insn_t insn, ilist_t p, int
ws)
FOR_EACH_VEC_ELT (sinfo->succs_ok, is, succ)
{
basic_block succ_bb = BLOCK_FOR_INSN (succ);
+ av_set_t av_succ = (is_ineligible_successor (succ, p)
+ ? NULL
+ : BB_AV_SET (succ_bb));
gcc_assert (BB_LV_SET_VALID_P (succ_bb));
-mark_unavailable_targets (av1, BB_AV_SET (succ_bb),
- BB_LV_SET (succ_bb));
+mark_unavailable_targets (av1, av_succ, BB_LV_SET (succ_bb));
}
/* Finally, check liveness restrictions on paths leaving the region. */
[Bug c/89051] -Wno-error= does not work for warning groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051
--- Comment #7 from Martin Liška ---
@Martin:
I've noticed that these tests has a suspicious construct:
gcc/testsuite/g++.dg/ext/flexary16.C:// { dg-options "-Wpedantic
-Wno-error=pedantic" }
gcc/testsuite/g++.dg/ext/flexary18.C:// { dg-additional-options "-Wpedantic
-Wno-error=pedantic" }
gcc/testsuite/g++.dg/ext/flexary19.C:// { dg-additional-options "-Wpedantic
-Wno-error=pedantic" }
gcc/testsuite/g++.dg/ext/flexary7.C:// { dg-options "-Wpedantic
-Wno-error=pedantic" }
gcc/testsuite/g++.dg/ext/flexary9.C:// { dg-options "-Wpedantic
-Wno-error=pedantic" }
gcc/testsuite/g++.dg/ubsan/object-size-1.C:// { dg-options "-Wpedantic
-Wno-error=pedantic -fsanitize=undefined -fpermissive" }
Note that with my patch the warning (Wpedantic) is disabled. Is it intentional
to mix the -Wpedantic and -Wno-error=pedantic?
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #7 from Michael Matz ---
What about this variant of the second part?
diff --git a/x86-64-ABI/low-level-sys-info.tex
b/x86-64-ABI/low-level-sys-info.tex
index 66270b9..93b5e95 100644
--- a/x86-64-ABI/low-level-sys-info.tex
+++ b/x86-64-ABI/low-level-sys-info.tex
@@ -517,7 +517,9 @@ Once arguments are classified, the registers get assigned
(in
left-to-right order) for passing as follows:
\begin{enumerate}
-\item If the class is MEMORY, pass the argument on the stack.
+\item If the class is MEMORY, pass the argument on the stack at an
+ address respecting the arguments alignment (which might be more
+ than its natural alignement).
\item If the class is INTEGER, the next available register of the
sequence \RDI, \RSI, \RDX, \RCX, \reg{r8} and \reg{r9} is
[Bug c++/89513] constexpr functions with function try block shouldn't be accepted at least with -pedantic in -std=c++{11,14,17} modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89513 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Should be fixed now.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 89513, which changed state.
Bug 89513 Summary: constexpr functions with function try block shouldn't be
accepted at least with -pedantic in -std=c++{11,14,17} modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89513
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
[Bug c++/89513] constexpr functions with function try block shouldn't be accepted at least with -pedantic in -std=c++{11,14,17} modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89513 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Mar 1 14:20:03 2019 New Revision: 269314 URL: https://gcc.gnu.org/viewcvs?rev=269314=gcc=rev Log: Implement P1002R1, Try-catch blocks in constexpr functions PR c++/89513 * parser.c (cp_parser_ctor_initializer_opt_and_function_body): Diagnose constexpr ctor or function with function-try-block with pedwarn for c++17 and earlier. Formatting fix. (cp_parser_try_block): Use pedwarn instead of error and only for c++17 and earlier when try block appears in constexpr function. * constexpr.c (build_constexpr_constructor_member_initializers): Handle TRY_BLOCK here instead of erroring on it. * g++.dg/cpp2a/constexpr-try1.C: New test. * g++.dg/cpp2a/constexpr-try2.C: New test. * g++.dg/cpp2a/constexpr-try3.C: New test. * g++.dg/cpp2a/constexpr-try4.C: New test. * g++.dg/cpp2a/constexpr-try5.C: New test. * g++.dg/cpp0x/constexpr-ctor10.C: Don't expect error for C++2a. Added: trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-try1.C trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-try2.C trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-try3.C trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-try4.C trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-try5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor10.C
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 H.J. Lu changed: What|Removed |Added Attachment #45866|0 |1 is obsolete|| --- Comment #6 from H.J. Lu --- Created attachment 45868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45868=edit A new psABI patch
[Bug tree-optimization/89491] Inline jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491
--- Comment #5 from Dávid Bolvanský ---
Let's take the original example with small modification:
int square(int x) { return x*x; }
int add(int x) { return x + x; }
typedef int (*p)(int);
static const p arr[4] = {square, add};
int test(int x) {
int res = arr[x](1);
return res;
}
Nothing is expanded/inlined. ICC can do it for "two items in arr" case.
[Bug target/89517] [8/9 Regression] AArch64's configure option --with-arch can silently lead to incorrectly configured compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89517 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tamar Christina --- Fixed both in trunk and GCC-8
[Bug target/89517] [8/9 Regression] AArch64's configure option --with-arch can silently lead to incorrectly configured compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89517 --- Comment #2 from Tamar Christina --- Author: tnfchris Date: Fri Mar 1 14:07:38 2019 New Revision: 269313 URL: https://gcc.gnu.org/viewcvs?rev=269313=gcc=rev Log: AArch64: Make every option in options.def one line (GCC-8). Due to config.gcc all the options need to be on one line because of the grep lines which would select only the first line of the option. This causes it not to select the right bits on options that are spread over multiple lines when the --with-arch configure option is used. The issue happens silently and you just get a compiler with an incorrect set of default flags. This solution just collapses everything back to one line as they were in GCC7. Unfortunately this does make some lines quite long. gcc/ChangeLog: PR target/89517 * config/aarch64/aarch64-option-extensions.def (fp, simd, crypto, fp16): Collapse line. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/aarch64/aarch64-option-extensions.def
[Bug middle-end/89544] Argument marshalling incorrectly assumes stack slots are naturally aligned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89544 --- Comment #4 from Richard Earnshaw --- An alternative way of fixing this might be if the backend could somehow control DECL_ARG_TYPE for the parameter, to set it to a variant without the additional alignment.
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #5 from H.J. Lu --- (In reply to Richard Biener from comment #3) > It probably implements what we do but changing 32 to 1024*1024 shows that we > (possibly up to MAX_OFILE_ALIGNMENT) align parameters to arbitrarily high X86 backend can align stack up to MAX_OFILE_ALIGNMENT. > values. Maybe we should cap that to some value (but make sure to not run > into issues like PR89544). > > The footnote could cite an example using _Alignas. We don't need a limit in psABI. But GCC can set a reasonable limit like MAX_OFILE_ALIGNMENT.
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #4 from H.J. Lu ---
(In reply to Michael Matz from comment #2)
> I think we should say something about the addresses of stack slots
> individual overaligned arguments as well (i.e. that the slot itself will
> also be aligned
> accordingly), not just for the overall effect.
How about
diff --git a/low-level-sys-info.tex b/low-level-sys-info.tex
index a1778fa..a1cf2e4 100644
--- a/low-level-sys-info.tex
+++ b/low-level-sys-info.tex
@@ -519,7 +519,7 @@ Once arguments are classified, the registers get assigned
(in
left-to-right order) for passing as follows:
\begin{enumerate}
-\item If the class is MEMORY, pass the argument on the stack.
+\item If the class is MEMORY, align and pass the argument on the stack.
\item If the class is INTEGER, the next available register of the
sequence \RDI, \RSI, \RDX, \RCX, \reg{r8} and \reg{r9} is
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #3 from Richard Biener --- It probably implements what we do but changing 32 to 1024*1024 shows that we (possibly up to MAX_OFILE_ALIGNMENT) align parameters to arbitrarily high values. Maybe we should cap that to some value (but make sure to not run into issues like PR89544). The footnote could cite an example using _Alignas.
[Bug c/89547] pthread_mutex_lock and pthread_cond_wait do not behave properly when compiler with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89547 --- Comment #2 from maqsood3525 at live dot com --- Hi , pardon me for the my tardinees , i should have mentioned the gcc version that is gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0 the -flto output is attached. Thanks Haroon From: rguenth at gcc dot gnu.org Sent: Friday, March 1, 2019 1:32 PM To: maqsood3...@live.com Subject: [Bug c/89547] pthread_mutex_lock and pthread_cond_wait do not behave properly when compiler with -flto https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89547 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-03-01 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- It works just fine for me - can you please cut the output of the -flto compile command when you append -v? -- You are receiving this mail because: You reported the bug.
[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979 --- Comment #12 from Andrey Belevantsev --- (In reply to Jakub Jelinek from comment #11) > Any progress on this? I know what happens but am not fully sure as of why. The sp register should not be available for the problematic move, so I'm figuring out why we got this wrong.
[Bug libstdc++/58142] _pthread_tsd_cleanup called before destructors are called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52268 --- Comment #11 from Eric Gallager --- (In reply to Iain Sandoe from comment #4) > (In reply to Jonathan Wakely from comment #3) > > I think it's still open because nobody has looked at it again recently, not > > because of any conscious decision. > > > > I'm changing the component to libstdc++ as the runtime library is > > responsible for the cleanup. > > > > Iain, what do you think? If comment 2 is right, then GCC 7.1 and later will > > use __cxa_thread_atexit from libc and the destruction order will be correct. > > I don't know when Darwin libc acquired that function, maybe it's in all > > supported versions of Darwin but we just didn't use it until the PR 78968 > > change. > > A quick look says that __cxa_thread_atexit exists in libc from Darwin13, > macOS 10.9 / Mavericks onwards. > > So it's not present in the system mentioned in the OP and Comment #1. > .. it will not be present in Darwin9 and 10 which I still build and test > for, but it's present in all versions "supported" by the vendor. > > We have previously worked around such issues by having a version-specific > CRT, but not sure if that's applicable in this case. > > NOTE 1: Darwin uses GCC's emulatedTLS, and I have some concerns that there > might be C++ issues with initialisers (and, thus possibly DTORs) anyway (see > 84497). and also bug 52268 > > NOTE 2: (I don't think it's relevant, but just for completeness) Darwin's > linker doesn't support ctor/dtor priorities.
[Bug target/89517] [8/9 Regression] AArch64's configure option --with-arch can silently lead to incorrectly configured compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89517 --- Comment #1 from Tamar Christina --- Author: tnfchris Date: Fri Mar 1 13:34:14 2019 New Revision: 269309 URL: https://gcc.gnu.org/viewcvs?rev=269309=gcc=rev Log: AArch64: Make every option in options.def one line Due to config.gcc all the options need to be on one line because of the grep lines which would select only the first line of the option. This causes it not to select the right bits on options that are spread over multiple lines when the --with-arch configure option is used. The issue happens silently and you just get a compiler with an incorrect set of default flags. This solution just collapses everything back to one line as they were in GCC7. Unfortunately this does make some lines quite long. I do have an alternate patch which used the pre-processors to first flatten the file in config.gcc. I will send that one out for GCC 10. gcc/ChangeLog: PR target/89517 * config/aarch64/aarch64-option-extensions.def (fp, simd, crypto, fp16, rdma, dotprod, sha2, sha3, sm4, fp16fml, sve): Collapse line. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-option-extensions.def
[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target||arm Priority|P3 |P2
[Bug c/89547] pthread_mutex_lock and pthread_cond_wait do not behave properly when compiler with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89547 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-03-01 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- It works just fine for me - can you please cut the output of the -flto compile command when you append -v?
[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #3 from Jakub Jelinek ---
The gimple dumps aren't exactly readable with so many different tuple/type etc.
types, where it is unclear what exact offset is something being stored at.
That said, in cplxlower1 I still see a possibility to get there the desired
value of 2:
MEM[(struct tupleD.7416 &) + 4].headD.7482.payloadD.6716 = 2;
...
D.9878.headD.7889 = MEM[(const struct type_nD.6356 &) + 4];
MEM[(struct &)] ={v} {CLOBBER};
D.9880.headD.7099 = MEM[(const struct type_nD.6356 &)];
D.9878 ={v} {CLOBBER};
MEM[(struct tupleD.6387 *) + 4B] = 4;
D.9881 = D.9880;
MEM[(struct &)] ={v} {CLOBBER};
D.9874.headD.7096 = MEM[(const struct type_nD.6355 &) + 8];
D.9874.tailD.7097 = D.9881;
D.9881 ={v} {CLOBBER};
D.9880 ={v} {CLOBBER};
D.9873 = D.9874;
MEM[(struct &)] ={v} {CLOBBER};
D.9865.tailD.7802 = D.9873;
D.9873 ={v} {CLOBBER};
D.9874 ={v} {CLOBBER};
D.9875 ={v} {CLOBBER};
D.9868 = MEM[(const struct tupleD.6387 &) + 8];
D.9869.tailD.8063 = D.9868;
SR.34_37 = MEM[(struct tupleD.6387 *) + 4B];
D.9868 ={v} {CLOBBER};
MEM[(struct &)] ={v} {CLOBBER};
D.9870.headD.7099 = MEM[(const struct type_nD.6356 &) + 4];
MEM[(struct &)] ={v} {CLOBBER};
MEM[(struct tupleD.6387 *) + 4B] = SR.34_37;
n1D.7646.tailD.7097 = D.9870;
D.9870 ={v} {CLOBBER};
D.9869 ={v} {CLOBBER};
D.9865 ={v} {CLOBBER};
_2 = n1D.7646.tailD.7097.headD.7099.payloadD.6716;
if (_2 != 2)
But in the sra pass dump that possibility is gone:
MEM[(struct &)] ={v} {CLOBBER};
SR.41_6 = SR.34_37;
MEM[(struct tupleD.6387 *) + 8B] = SR.41_6;
n1$tail$head$payload_90 = MEM[(struct tupleD.6387 *) + 4B];
...
_2 = n1$tail$head$payload_90;
if (_2 != 2)
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #2 from Michael Matz --- I think we should say something about the addresses of stack slots individual overaligned arguments as well (i.e. that the slot itself will also be aligned accordingly), not just for the overall effect.
[Bug c++/87234] GCC should warn if template parameter redefines default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87234 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-01 Ever confirmed|0 |1
[Bug target/89545] ABI clarification for over-aligned type stack passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545 --- Comment #1 from H.J. Lu --- Created attachment 45866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45866=edit An psABI patch How about this?
[Bug c++/89548] New: reinterpret_cast treats xvalue as prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89548
Bug ID: 89548
Summary: reinterpret_cast treats xvalue as prvalue
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ndkrempel at gmail dot com
Target Milestone: ---
The following program fails to compile (with -std= any of c++11, c++14, c++17,
c++2a):
int main() {
reinterpret_cast(static_cast(0));
}
The error reported is:
gcc-xvalue-bug.cc: In function ‘int main()’:
gcc-xvalue-bug.cc:8:48: error: invalid cast of an rvalue expression of type
‘int’ to type ‘int&&’
reinterpret_cast(static_cast(0));
I.e. reinterpret_cast is treating its argument as a prvalue of type "int"
rather than an xvalue of type "int&&". Testing indicates that the return value
from the static_cast is of the correct type and value category, so the problem
lies with the reinterpret_cast.
The static_cast expression could also be replaced with a function returning
"int&&" and the same problem occurs.
The same problem also occurs when less trivial conversions are requested, for
example "reinterpret_cast(static_cast(0))".
For comparison, clang does not give an error, and that is consistent with my
reading of the standards.
[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #2 from Jakub Jelinek ---
When get_tail is esra optimized the old way, main is:
int n1$tail$head$payload;
struct type D.9885;
struct tuple D.9880;
struct type D.9879;
struct type D.9878;
struct type D.9875;
[local count: 1073741825]:
MEM[(struct tuple *)] = 3;
MEM[(struct tuple *) + 4B] = 2;
MEM[(struct tuple *) + 8B] = 4;
D.9875.tail = D.9885;
D.9885 ={v} {CLOBBER};
D.9878 = MEM[(const struct tuple &) + 8];
D.9879.tail = D.9878;
D.9878 ={v} {CLOBBER};
D.9880.head = MEM[(const struct type_n &) + 4];
n1$tail$head$payload_32 = MEM[(struct tuple *)];
D.9880 ={v} {CLOBBER};
D.9879 ={v} {CLOBBER};
D.9875 ={v} {CLOBBER};
if (n1$tail$head$payload_32 != 2)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1072883002]:
return 0;
and the testcase works. If it is esra optimized the new way, I get:
int n1$tail$head$payload;
struct type n1;
[local count: 1073741825]:
MEM[(struct &)] ={v} {CLOBBER};
n1$tail$head$payload_90 = MEM[(struct tuple *) + 4B];
if (n1$tail$head$payload_90 != 2)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1072883002]:
n1 ={v} {CLOBBER};
return 0;
which is undefined, so unless the testcase is UB (but passes e.g. on
x86_64-linux too, valgrind is quiet on it, -fsanitize=address,undefined too),
something went wrong during GIMPLE optimizations.
[Bug tree-optimization/89541] [9 Regression] ICE in VN_INFO(tree_node*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89541 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug target/84072] [meta-bug] -mindirect-branch=thunk issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84072 Bug 84072 depends on bug 86952, which changed state. Bug 86952 Summary: Avoid jump table for switch statement with -mindirect-branch=thunk https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |---
[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 --- Comment #13 from H.J. Lu --- Reopened with new info.
