[Bug c++/87282] Invalid use of 'void', in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87282 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Dup of bug 78173. I should say this was fixed in GCC 11+
[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173 Andrew Pinski changed: What|Removed |Added CC||delrieutheo at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 87282 has been marked as a duplicate of this bug. ***
[Bug c++/87282] Invalid use of 'void', in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87282 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 78173. *** This bug has been marked as a duplicate of bug 78173 ***
[Bug c++/86619] Missed optimization opportunity with array aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619
--- Comment #5 from Andrew Pinski ---
I Noticed clang, ICC nor MSVC either handle this either.
Note GCC is the only one which handles :
int f(std::array & a, std::array & b)
{
a[0] = 1;
b[0] = 1;
return a[0];
}
[Bug c/103531] Propose compiler warning when ceil/ceilf used on integral value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103531 --- Comment #4 from Eyal Rozenberg --- (In reply to Eric Gallager from comment #3) > -Wtraditional-conversion catches this: Well... you're technically right, but: 1. That is a much wider warning. If someone were to turn this on they would get a gazillion warnings which would drown out this one. 2. (Weak point) Few people would consider turning this on given the description. 3. This doesn't work for C++.
[Bug c++/87235] g++ doesn't implement sparse initialisation of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87235 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-03 --- Comment #3 from Andrew Pinski --- :5:1: sorry, unimplemented: non-trivial designated initializers not supported 5 | }; | ^ :5:1: sorry, unimplemented: non-trivial designated initializers not supported
[Bug c++/86598] Incorrect lexing of pp-numbers in C++11 due to hexfloat extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86598
--- Comment #4 from Andrew Pinski ---
Here is a full testcase that still fails:
template struct Units{int operator+(int);};
class Amp{};
Units operator"" _amp(unsigned long long d);
int k = 4_amp+1; // incorrect error: no literal operator "" _amp+1
Note ICC rejects it with:
(7): error: non-identifier character in user-defined literal suffix
int k = 4_amp+1; // incorrect error: no literal operator "" _amp+1
^
[Bug preprocessor/23827] standard C++ should not have hex float preprocessing tokens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23827 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/86743] [c++98] Compilation failure when initializing POD structs containing constant member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86743 Andrew Pinski changed: What|Removed |Added Summary|Compilation failure when|[c++98] Compilation failure |initializing POD structs|when initializing POD |containing constant member |structs containing constant ||member --- Comment #4 from Andrew Pinski --- ICC (EDG) still rejects this for -std=c++98 while clang accepts this. I highly doubt there is anything to be done for C++98/C++03 modes.
[Bug c++/79318] [DR 1726] conversion member function preceded with & is not marked as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79318 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Confirmed. The defect report has been in drafting since 2013. Maybe it was forgotten about. I assume it is supposed to be rejected too.
[Bug c++/72777] broken error message with reference in constexpr arguments in c++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72777 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #2 from Jiang An --- (In reply to bloerwald from comment #1) > Note: compiles fine in c++11 mode of clang 3.8, so not sure if it actually > is forbidden by the standard. In C++11 this program is ill-formed, no diagnostic required. Because the definition of dop satisfies the diagnostic-requiring rules of constexpr functions (C++11 [dcl.constexpr]), but dop can't produce a constant expression as a compound assignment is fobidden in constant evalution (C++11 [expr.const]).
[Bug c++/99931] Unnamed `struct` defined with `using` having internal linkage instead of external, unlike `typedef`, yielding different semantics for two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99931 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-03 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/61457] [C++11/14 only] Inaccurately refusing non-ODR usage of type with no linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61457 Andrew Pinski changed: What|Removed |Added Summary|Inaccurately refusing |[C++11/14 only] |non-ODR usage of type with |Inaccurately refusing |no linkage |non-ODR usage of type with ||no linkage --- Comment #2 from Andrew Pinski --- Hmm, on the trunk this is accepted for C++17+ but rejected for C++11 and C++14.
[Bug c++/60277] Bogus "inline function virtual ..." used but never defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60277 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.3 Resolution|--- |FIXED Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92695 --- Comment #4 from Andrew Pinski --- Fixed in GCC 9.3.0+ and in GCC 10 by r10-5027-g99150b053e1 and r9-8069-ge3edafbca9f3553 (PR 92695). The patch includes exactly a testcase which is similar enough to this one. So closing as fixed.
[Bug c++/60551] __attribute__((unused)) is ignored for 'static' declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60551 Andrew Pinski changed: What|Removed |Added Summary|__attribute__((used)) is|__attribute__((unused)) is |ignored for 'static'|ignored for 'static' |function declarations |declarations --- Comment #2 from Andrew Pinski --- friend has nothing to do with the warning. Even this warns: static void friendly_accessor (void) __attribute__((unused));
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028 --- Comment #6 from Alexandre Oliva --- This will probably avoid the error. valid_insn_p checks the alternatives, and fails for the invalid cmpdi_ccu that we attempt to create. Conceivably, this could be avoided by narrowing down the condition of the cbranch4 expander to reject unfit constants after reload. Alas, there doesn't seem to be any existing opportunity to adjust the canonicalized condition to fit md constraints, e.g. undoing the LEU to LTU transformation so that we could still get a conditional trap for this case: we don't go through the cbranch4 expander there. diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c index 017944f4f79aa..b0052f6c5ced3 100644 --- a/gcc/ifcvt.c +++ b/gcc/ifcvt.c @@ -4726,7 +4726,9 @@ find_cond_trap (basic_block test_bb, edge then_edge, edge else_edge) /* If that results in an invalid insn, back out. */ for (rtx_insn *x = seq; x; x = NEXT_INSN (x)) -if (recog_memoized (x) < 0) +if (reload_completed + ? !valid_insn_p (x) + : recog_memoized (x) < 0) return FALSE; /* Emit the new insns before cond_earliest. */
[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939 --- Comment #6 from Andrew Pinski --- Note I think this paper applies to C++20 too or at least part of it. >From CWG1291: [Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to DR at the February, 2021 meeting.]
[Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701 --- Comment #6 from Andrew Pinski --- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1291 [Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to DR at the February, 2021 meeting.] So there is a defect report in this area after all
[Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
Andrew Pinski changed:
What|Removed |Added
Keywords|accepts-invalid |
--- Comment #5 from Andrew Pinski ---
So I think clang and MSVC have a bug in this area too.
See basic.lookup.classref/7 :
If the id-expression is a conversion-function-id, its conversion-type-id is
first looked up in the class of the object
expression (11.8) and the name, if found, is used. Otherwise it is looked up in
the context of the entire
postfix-expression. In each of these lookups, only names that denote types or
templates whose specializations
are types are considered. [Example:
struct A { };
namespace N {
struct A {
void g() { }
template operator T();
};
}
int main() {
N::A a;
a.operator A(); // calls N::A::operator N::A
}
— end example]
If we take the example, clang and MSVC calls N::A::operator ::A and not what
the standard says.
GCC I think is still wrong in the original testcase I think because B::A does
not represent a type .
In my example in comment #4, GCC and ICC does the correct thing and selects the
correct type.
[Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-12-03
Keywords||accepts-invalid
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski ---
Here is a different testcase which shows we also have an accepts invalid:
class A {};
class B {
typedef int AT;
public:
operator AT () const noexcept { return {}; }
typedef int A;
};
int main() {
B b;
b.operator A();
}
I have not looked up in the standard which A is supposed to be found here (for
b.operator A) is it B::A or ::A?
[Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701 --- Comment #3 from Andrew Pinski --- ICC also rejects this for the same reason as GCC while both MSVC and clang accept it. Maybe there is a defect report about this.
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #5 from Andrew Pinski ---
(In reply to Alexandre Oliva from comment #4)
> Andrew,
>
> asm("":"=g"(tt):"g"(t));
> asm("":"=g"(ii):"g"(i));
>
> Make it "0" for the inputs:
>
> asm("":"=g"(tt):"0"(t));
Oh yes sorry I did make that mistake there, thanks for correcting me.
[Bug rtl-optimization/103028] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #4 from Alexandre Oliva ---
Andrew,
asm("":"=g"(tt):"g"(t));
asm("":"=g"(ii):"g"(i));
Make it "0" for the inputs:
asm("":"=g"(tt):"0"(t));
and AFAICT if you "detach" the immediate constant, you won't get the bug.
The problem occurs because (leu (compare reg imm)...) is turned into (ltu
(compare reg imm+1)...) for the trap_if, and then the immediate no longer fits
in the compare.
[Bug c/103531] Propose compiler warning when ceil/ceilf used on integral value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103531 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Blocks||87403 --- Comment #3 from Eric Gallager --- -Wtraditional-conversion catches this: $ /usr/local/bin/gcc -c -Wall -Wextra -pedantic -Wconversion -Wdouble-promotion -Wtraditional-conversion 103531.c 103531.c: In function 'foo': 103531.c:5:30: warning: passing argument 1 of 'ceil' as floating rather than integer due to prototype [-Wtraditional-conversion] 5 | int covers_half = ceil(x / 2); |~~^~~ 103531.c:5:23: warning: conversion from 'double' to 'int' may change value [-Wfloat-conversion] 5 | int covers_half = ceil(x / 2); | ^~~~ $ Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c++/68699] Wrong location_t due to template instance canonicalization when setting location_t values on expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68699 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-03 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/48850] Bogus overflow in constant expression warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48850
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=87996
Known to work||11.1.0, 9.1.0
Status|REOPENED|RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |9.0
--- Comment #4 from Andrew Pinski ---
GCC 9+ give:
:3:33: error: size '9223372036854775808' of array 'a' exceeds maximum
object size '9223372036854775807'
3 | extern char a[((size_t)-1 >> 1) + 1]; /* { dg-error "too large" } */
| ~~^~~
:5:12: error: size '9223372036854775808' of array 'c' exceeds maximum
object size '9223372036854775807'
5 | extern int c[(((size_t)-1 >> 1) + 1) / sizeof(int)]; /* { dg-error "too
large" } */
|^
Fixed by r9-5932-g28a8cef1e240 (PR 87996).
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #14 from Andrew Pinski ---
clang accepts the reduced testcase in comment #1 but MSVC and ICC both reject
it too.
MSVC:
(18): error C3201: the template parameter list for class template 'Foo'
does not match the template parameter list for template parameter 'TT'
(18): error C2955: 'is_instantiation_of_nontypes::check':
use of class template requires template argument list
(12): note: see declaration of
'is_instantiation_of_nontypes::check'
(18): error C2338: Ouch
ICC:
(11): error: parameter pack "Ts" was referenced but not expanded
template class TT, typename T>
^
(14): error: parameter pack "Ts" was referenced but not expanded
template class TT, Ts... Args>
^
(14): warning #885: constant "Args" is not used in or cannot be deduced
from the template argument list of class template
"is_instantiation_of_nontypes::check> [with Ts=]"
template class TT, Ts... Args>
^
detected during instantiation of class
"is_instantiation_of_nontypes [with Ts=]" at line 18
(18): error: static assertion failed with "Ouch"
static_assert(is_instantiation_of_nontypes::check >::value, "Ouch");
^
GCC rejects it with:
:15:27: error: expansion pattern '' contains no parameter
packs
15 | struct check> : true_type {};
| ^~~
:15:30: error: template argument 2 is invalid
15 | struct check> : true_type {};
| ^~
:18:87: error: static assertion failed: Ouch
18 | static_assert(is_instantiation_of_nontypes::check >::value, "Ouch");
|
^
[Bug rtl-optimization/93027] ICE: in match_reload, at lra-constraints.c:1060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #6 from Alexandre Oliva ---
FWIW, with or without optimization, this testcase allocates inout f and in
to the same register in the .reload dump. If the asm code used %0, expecting
it to be initially 0 as it should, it would fail:
int main (void) {
int f = 0, w, z;
asm volatile(
"movl\t%0, %1"
: "+m"(f), "=g" (z)
: "0a"()
);
if (z)
__builtin_abort ();
return 0;
}
[Bug c++/83756] [9/10/11/12 Regression] gcc ICE in gimplify_expr on boost::call_once (-fms-extensions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83756 Andrew Pinski changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #13 from Andrew Pinski --- *** Bug 85776 has been marked as a duplicate of this bug. ***
[Bug c++/85776] ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85776 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 83756. *** This bug has been marked as a duplicate of bug 83756 ***
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 63217, which changed state. Bug 63217 Summary: template conversion operator returning const reference not used for conversion in some cases https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/61663] [DR 976] Deduction for const T& conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61663 Andrew Pinski changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 63217 has been marked as a duplicate of this bug. ***
[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #10 from Andrew Pinski --- Dup of bug 61663. *** This bug has been marked as a duplicate of bug 61663 ***
[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217 --- Comment #9 from Andrew Pinski --- Other related ones: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#493 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#322 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#913
[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217 Andrew Pinski changed: What|Removed |Added Blocks||94404 Alias||CWG976 --- Comment #8 from Andrew Pinski --- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#976 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 [Bug 94404] [meta-bug] C++ core issues
[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217 --- Comment #7 from Andrew Pinski --- ICC also rejects this for the same reason as GCC. MSVC and clang both accept it though. Could there be a defect report for this?
[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217 Andrew Pinski changed: What|Removed |Added CC||vz at quantitativesystems dot com --- Comment #6 from Andrew Pinski --- *** Bug 79035 has been marked as a duplicate of this bug. ***
[Bug c++/79035] Rejects valid code due to failure to use user const conversion template operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79035 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 63217. *** This bug has been marked as a duplicate of bug 63217 ***
[Bug c++/79035] Rejects valid code due to failure to use user const conversion template operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79035 --- Comment #1 from Andrew Pinski --- ICC also rejects this for the same reason as GCC. MSVC and clang both accept it though.
[Bug target/102376] [aarch64] using target("sve") attribute without a + is not very helpful on what is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102376 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed.
[Bug c++/102647] Wrong caret location for 'attribute directive ignored' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102647 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78425 Last reconfirmed||2021-12-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. Though I think this is almost exact dup of bug 78425.
[Bug tree-optimization/103536] New: Suboptimal codegen for && and || combination.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103536
Bug ID: 103536
Summary: Suboptimal codegen for && and || combination.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: navidr at gcc dot gnu.org
Target Milestone: ---
We do have suboptimal codegen for this pattern:
https://compiler-explorer.com/z/dszaK49WT
bool
src_1 (bool a, bool b)
{
return (a || b) && (a && b);
}
bool
src_2 (bool a, bool b) // no problem here
{
return (a && b) && (a || b);
}
bool
tgt (bool a, bool b) // what we want
{
return (a && b);
}
In the case of src_2, it is the "ethread" pass which will remove the extra
basicblock. But in case of src_1 since the operation is spread over multiple
basicblocks, the match.pd is not able to detect and solve this.
1) In limited situations, it is possible to detect pattern in GENERIC and fix
this:
As proof of concept, I tried with something like this and was able to fix this
in GENERIC:
(for firstAnd (truth_and truth_andif)
(for secondAnd (truth_and truth_andif)
(for firstOr (truth_or truth_orif)
(simplify
(firstAnd (firstOr @0 @1) (secondAnd truth_valued_p@0 truth_valued_p@1))
(truth_and @0 @1)
Because of GENERIC limitation, this is not going to work on something like
this:
bool src_12 (bool a, bool b)
{
int z = a || b;
return z && (a && b);
}
2) A better approach which I haven't looked at, is not to spread this over
multiple basic blocks.
[Bug c++/66901] Segmentation fault in compiler instead of error message for ill-formed program with namespace alias and qualified definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66901
Andrew Pinski changed:
What|Removed |Added
Known to work||8.1.0, 9.1.0
Ever confirmed|0 |1
Known to fail||7.5.0
Keywords||needs-bisection
Last reconfirmed||2021-12-03
Status|RESOLVED|NEW
Resolution|DUPLICATE |---
--- Comment #3 from Andrew Pinski ---
Reopening since this looks unrelated.
It looks like it was fixed in GCC 8+ though:
:5:19: error: declaration of 'struct X::S' in namespace 'X::Y' which
does not enclose 'X::Y::Z'
struct Z::S {};
^
[Bug c++/66878] Segmentation fault when compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66878 Andrew Pinski changed: What|Removed |Added Known to work||11.1.0 Status|RESOLVED|NEW Known to fail||10.3.0 Resolution|DUPLICATE |--- Keywords||ice-on-valid-code, ||needs-bisection --- Comment #5 from Andrew Pinski --- Reopening as this one does not seem like a dup after all. Also this one seems to be fixed in GCC 11+
[Bug c++/66934] Compiler accepting ill-formed program with extern variable declarations and using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934 Andrew Pinski changed: What|Removed |Added Known to work||8.1.0 Last reconfirmed||2021-12-03 Known to fail||7.5.0 Target Milestone|--- |8.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords|rejects-valid |needs-bisection
[Bug c++/95074] Function found via ADL when it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95074 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/71755] friend function may not be defined inside a class using a qualified name but GCC allows that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71755 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/53402] [C++11] non-inline namespace can be wrongly re-opened as inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53402 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79369 Target Milestone|--- |8.0
[Bug c++/79766] inline namespace and ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79766 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/66935] Compiler rejects well-formed program with local extern variable declaration and using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66935 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-03 Status|RESOLVED|NEW Ever confirmed|0 |1 Resolution|DUPLICATE |--- Keywords||rejects-valid --- Comment #2 from Andrew Pinski --- Confirmed, this was not a dup of bug 66934 after all. Though there might be a dup of this bug already.
[Bug c++/66934] Compiler accepting ill-formed program with extern variable declarations and using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934
--- Comment #9 from Andrew Pinski ---
(In reply to Anders Granlund from comment #4)
> I'm pulling in this test case from my related bug report.
>
> int x = 1;
>
> int main() {
> extern int x;
> using ::x;
> }
This is unrelated to the first testcase though.
[Bug c++/66934] Compiler accepting ill-formed program with extern variable declarations and using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66934 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66878, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66888, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66889, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66901, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66935 --- Comment #8 from Andrew Pinski --- (In reply to Anders Granlund from comment #0) > The following program is ill-formed since the two declarations in main are > conflicting. This was fixed in GCC 8+.
[Bug c++/71886] Incorrect error on operator() being an member in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71886
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Andrew Pinski ---
MSVC rejects it at instantiation time:
(14): error C2207: 'Template::()': a member of a class template
cannot acquire a function type
(19): note: see reference to class template instantiation
'Template' being compiled
Or it even has an internal compiler erorr in some cases:
template
struct Template
{
typedef T type;
T operator();
};
Template t;
int main(void)
{
t();
}
Anyways this is invalid as the type of T is dependent and such.
[Bug c++/71841] variadic template can't cast to base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71841 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- No testcase provided in over 5 years and the snipp of code fails to compile even when tried to make into a testcase (comment #2) so closing as invalid.
[Bug c++/70446] g++: internal compiler error: Killed (program cc1plus), probably related to vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70446 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #7 from Andrew Pinski --- We cannot reproduce this bug even in the upstream GCC (ubuntu's gcc has patches in it) and it was only an error recovery issue so closing as works for me.
[Bug c++/61587] Line number of code that triggers "use of deleted function" error is absent from error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61587 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2014-06-24 00:00:00 |2021-12-2
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534
--- Comment #4 from Martin Sebor ---
Yes, the warning does disappear when malloc() and free() are used instead of
operator new and delete. foo() also ends up much better optimized, even at
-O1:
__attribute__((abi_tag ("cxx11")))
struct string foo ()
{
struct string & _7(D);
char * _69;
[local count: 1073741824]:
_69 = __builtin_malloc (17);
__builtin_memcpy (_69, "1234567890123456", 16);
MEM[(char_type &)_69 + 16] = 0;
MEM[(struct basic_string *)_7(D)]._M_dataplus._M_p = _69;
MEM[(struct basic_string *)_7(D)].D.33183._M_allocated_capacity = 16;
MEM[(struct basic_string *)_7(D)]._M_string_length = 16;
return _7(D);
}
The -O1 dump in comment #1 doesn't look right, I may have messed something up.
The same issue happens at -O2 where the dump is as follows:
=== BB 3
Imports: n_5(D)
Exports: _1 n_5(D)
_1 : n_5(D)(I)
n_5(D) int [-INF, -1][1, +INF]
[local count: 536870913]:
_1 = (sizetype) n_5(D);
if (_1 == 1)
goto ; [51.12%]
else
goto ; [48.88%]
_1 : sizetype [1, 2147483647][18446744071562067968, +INF]
3->4 (T) _1 : sizetype [1, 1]
3->4 (T) n_5(D) : int [1, 1]
3->5 (F) _1 : sizetype [2, 2147483647][18446744071562067968, +INF]
3->5 (F) n_5(D) : int [-INF, -1][2, +INF]
=== BB 4
[local count: 274448412]:
MEM[(char *)] = 0;
goto ; [100.00%]
=== BB 5
[local count: 262422500]:
__builtin_memcpy (, , _1);
[Bug middle-end/103530] ICE: in execute, at gimple-harden-conditionals.cc:397 with -O -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103530
--- Comment #2 from Andrew Pinski ---
gcc_checking_assert (TREE_CODE (TREE_TYPE (lhs)) == BOOLEAN_TYPE);
This assert is incorrect because useless_type_conversion_p has the following
code:
/* If both the inner and outer types are integral types, then the
conversion is not necessary if they have the same mode and
signedness and precision, and both or neither are boolean. */
if (INTEGRAL_TYPE_P (inner_type)
&& INTEGRAL_TYPE_P (outer_type))
{
/* Preserve changes in signedness or precision. */
if (TYPE_UNSIGNED (inner_type) != TYPE_UNSIGNED (outer_type)
|| TYPE_PRECISION (inner_type) != TYPE_PRECISION (outer_type))
return false;
/* Preserve conversions to/from BOOLEAN_TYPE if types are not
of precision one. */
if (((TREE_CODE (inner_type) == BOOLEAN_TYPE)
!= (TREE_CODE (outer_type) == BOOLEAN_TYPE))
&& TYPE_PRECISION (outer_type) != 1)
return false;
/* We don't need to preserve changes in the types minimum or
maximum value in general as these do not generate code
unless the types precisions are different. */
return true;
}
Which means if the precision is 1 of the integer type (and boolean is also
prevision of 1), then the cast between BOOLEAN_TYPE and that integer type will
be removed.
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534 --- Comment #3 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #2) > I also noticed that with -std=c++17 (or before), the constructor for > std::string is not inlined fully for both std::string objects which avoids > the false positive. That's because of the explicit instantiation declaration (i.e. extern template) for the std::string instantiation, which is only declared for C++17 and earlier.
[Bug tree-optimization/97711] Failure to optimise "x & 1 ? x - 1 : x" to "x & -2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97711 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/97711] Failure to optimise "x & 1 ? x - 1 : x" to "x & -2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97711 Andrew Pinski changed: What|Removed |Added CC||jengelh at inai dot de --- Comment #6 from Andrew Pinski --- *** Bug 103535 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/103535] [missed optimization] remainder-of-2 with subtract-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103535 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- This is actually an exact dup of bug 97711. *** This bug has been marked as a duplicate of bug 97711 ***
[Bug tree-optimization/103535] [missed optimization] remainder-of-2 with subtract-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103535 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103216 --- Comment #2 from Andrew Pinski --- I have a patch which gets the optimized code (at least being able to generate at the rtl level): _1 = p_3(D) & 1; _7 = _1 != 0; _6 = (unsigned int) _7; _9 = p_3(D) - _6; movl%edi, %eax andl$-2, %eax ret The patch is the one for PR 103216.
[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #12)
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 6ac3460d538..08f94b7a17a 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -3050,6 +3050,23 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
> lhs_base = TREE_OPERAND (lhs_base, 0);
>reg_lhs = (mem_ref_refers_to_non_mem_p (lhs_base)
> || non_mem_decl_p (lhs_base));
> + /* If this expands to a register and the underlying decl is wrapped in
> +a MEM_REF that just serves as an access type change expose the decl
> +if it is of correct size. This avoids a situation as in PR103271
> +if the target does not support a direct move to the registers mode.
> */
> + if (reg_lhs
> + && TREE_CODE (lhs_base) == MEM_REF
> + && TREE_CODE (TREE_OPERAND (lhs_base, 0)) == ADDR_EXPR
> + && DECL_P (TREE_OPERAND (TREE_OPERAND (lhs_base, 0), 0))
> + && integer_zerop (TREE_OPERAND (lhs_base, 1))
> + && tree_fits_uhwi_p (var_size)
> + && tree_int_cst_equal
> + (var_size,
> + DECL_SIZE_UNIT (TREE_OPERAND (TREE_OPERAND (lhs_base, 0),
> 0
> + {
> + lhs = TREE_OPERAND (TREE_OPERAND (lhs_base, 0), 0);
> + var_type = TREE_TYPE (lhs);
> + }
> }
>
>if (!reg_lhs)
>
> solves the issue. There might be a situation where that's not enough though,
> I'm giving the above some testing.
this patch is so specific to target this specific case, I am wondering whether
this is needed if Tim will provide a patch to support MOVTI in riscv backend?
[Bug tree-optimization/103535] [missed optimization] remainder-of-2 with subtract-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103535 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Severity|normal |enhancement Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-02 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine for GCC 13.
[Bug tree-optimization/103535] New: [missed optimization] remainder-of-2 with subtract-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103535
Bug ID: 103535
Summary: [missed optimization] remainder-of-2 with subtract-1
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
gcc version 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
(SUSE Linux) x86_64
== input ==
unsigned int fff(unsigned int p)
{
// equivalent to return p & ~1;
if (p % 2 != 0)
--p;
return p;
}
== Observed output ==
» gcc -O2 -c x.cpp; objdump -Mintel -d x.o
0: 89 fa movedx,edi
2: 89 f8 moveax,edi
4: 83 e2 01andedx,0x1
7: 83 fa 01cmpedx,0x1
a: 83 d0 ffadceax,0x
d: c3 ret
== Expected output ==
0: 89 f8 moveax,edi
2: 83 e0 feandeax,0xfffe
5: c3 ret
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
Martin Sebor changed:
What|Removed |Added
Keywords|missed-optimization |
--- Comment #10 from Martin Sebor ---
Using -O2 doesn't avoid the warning in general. The following C test case
reproduces an equivalent warning at all optimization levels (with GCC 11 it
triggers a -Warray-bounds only). The warning works as designed. If you don't
want these warnings to trigger on these cases we need change the design,
starting with outlining the conditions under which they should trigger. As it
is, they all trigger for every invalid call in the IL, whether it's in the
source code of the original test case, or in the standard library headers (like
in the case of std::string) inlined into user code, or whether it's isolated by
the compiler. Fiddling with optimization levels, disabling them for system
headers, or other heuristics won't prevent them under other conditions.
$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout
-Wno-array-bounds t.c
static inline __attribute__ ((always_inline))
void f (char *d, const char *s, __SIZE_TYPE__ n)
{
if (n == 1)
*d = *s;
else
__builtin_memcpy (d, s, n);
}
static inline __attribute__ ((always_inline))
void ff (char *d, const char *s0, const char *s1)
{
f (d, s0, s1 - s0);
}
void g (void*);
void h (int n)
{
char a[1] = "";
char b[16];
if (n)
ff (b, a, a + n);
g (b);
}
;; Function h (h, funcdef_no=2, decl_uid=1990, cgraph_uid=3, symbol_order=2)
Removing basic block 7
void h (int n)
{
char b[16];
char a[1];
sizetype _1;
[local count: 1073741824]:
a = "";
if (n_5(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_1 = (sizetype) n_5(D);
if (_1 == 1)
goto ; [51.12%]
else
goto ; [48.88%]
[local count: 274448412]:
MEM[(char *)] = 0;
goto ; [100.00%]
[local count: 262422500]:
__builtin_memcpy (, , _1);
[local count: 1073741824]:
g ();
a ={v} {CLOBBER};
b ={v} {CLOBBER};
return;
}
In function ‘f’,
inlined from ‘ff’ at t.c:13:3,
inlined from ‘h’ at t.c:23:5:
t.c:7:5: warning: ‘__builtin_memcpy’ reading 2 or more bytes from a region of
size 1 [-Wstringop-overread]
7 | __builtin_memcpy (d, s, n);
| ^~
t.c: In function ‘h’:
t.c:20:8: note: source object ‘a’ of size 1
20 | char a[1] = "";
|^
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534
Andrew Pinski changed:
What|Removed |Added
Keywords||alias, missed-optimization
--- Comment #2 from Andrew Pinski ---
Note there is one missing optimization:
D.42086._M_string_length = 0;
MEM[(char_type &) + 16] = 0;
MEM[(struct basic_string *)] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)]._M_p = _M_local_buf;
_69 = operator new (17);
[local count: 1003797485]:
D.41925._M_dataplus._M_p = _69;
D.41925.D.33308._M_allocated_capacity = 16;
__builtin_memcpy (_69, "1234567890123456", 16);
D.41925._M_string_length = 16;
MEM[(char_type &)_69 + 16] = 0;
_75 = D.42086._M_string_length;
__size_76 = _75 + 16;
pretmp_56 = D.42086._M_dataplus._M_p;
if (__size_76 > 16)
goto ; [67.00%]
else
goto ; [33.00%]
This might be related to that GCC does not handle the operator new better.
Obvious if that missed optimization is fixed, then the warning will be gone.
I also noticed that with -std=c++17 (or before), the constructor for
std::string is not inlined fully for both std::string objects which avoids the
false positive.
This is another case where it is a "maybe" exceeds maximum object size and we
need to come up with a solution for it.
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 since r8-7594-g078c5aff5ed83e9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #7) > Bummer. Is the regression an ICE or a segfault on execution. > The former is unacceptable. The latter is user error and the > testcase can be removed. I wouldn't be that cavalier. It was a different error message. There is a simple workaround: do not simplify if an arithmetic error occurs. Submitted as: https://gcc.gnu.org/pipermail/fortran/2021-December/057102.html
[Bug tree-optimization/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96188 Martin Sebor changed: What|Removed |Added Known to work||12.0 --- Comment #9 from Martin Sebor --- Today's trunk doesn't reproduce it but the warning is still issued with GCC 12 for a GCC 11 translation unit, so it must be some library change that's made it go away.
[Bug tree-optimization/100366] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366 Martin Sebor changed: What|Removed |Added Known to fail||11.2.0, 12.0 Last reconfirmed|2021-05-02 00:00:00 |2021-12-2 --- Comment #10 from Martin Sebor --- Unchanged in GCC 12.
[Bug target/103470] GNU-stack section not emitted on MIPS hard-float targets with MUSL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103470 Jeffrey A. Law changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-02 CC||law at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk. I'll leave it to someone else to decide on the backport.
[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Last reconfirmed||2021-12-02 Ever confirmed|0 |1 Blocks||88443 CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- The warning is for the memcpy() call in BB 12 with _73 being in the reported excessive range: [local count: 172868773]: _209 = D.41961._M_dataplus._M_p; _103 = _69 + 16; __builtin_memcpy (_103, _209, _73); <<< 27->12 (T) _73 : long unsigned int [18446744073709551600, +INF] The range comes from BB 27: === BB 27 Imports: _73 Exports: _73 _73 long unsigned int [0, 0][18446744073709551600, +INF] __size_74 const long unsigned int [0, 16] [local count: 523844769]: if (_73 != 0) goto ; [33.00%] else goto ; [67.00%] 27->12 (T) _73 : long unsigned int [18446744073709551600, +INF] 27->12 (T) __size_74 : const long unsigned int [0, 15] 27->13 (F) _73 : long unsigned int [0, 0] 27->13 (F) __size_74 : const long unsigned int [16, 16] The magic 16 most likely has to do with the small internal std::string buffer that's 16 bytes big. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug other/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #9 from Jeffrey A. Law --- Should be fixed on the trunk now. I forgot to add the PR marker though.
[Bug c++/81176] decltype(auto) yields reference type for structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81176 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-12-02
[Bug c/103531] Propose compiler warning when ceil/ceilf used on integral value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103531 Eyal Rozenberg changed: What|Removed |Added Summary|Prpose compiler warning |Propose compiler warning |when ceil functions used on |when ceil/ceilf used on |integral value |integral value --- Comment #2 from Eyal Rozenberg --- This also applies to C++, although in C++ you might be doing this in a templated context, e.g. T x = get_x(); auto y = ceil(x); which is fine for floating-point T's and fishy for integral T's.
[Bug c++/103534] New: [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103534
Bug ID: 103534
Summary: [12 regression] Spurious -Wstringop-overflow warning
with std::string concatencation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
With a recent checkout of gcc12 (20211201) on a x86_64-pc-linux-gnu host,
compiling the following source with -O --std=c++20 gives a bogus
-Wstringop-overflow warning:
-- x.cc ---
#include
std::string foo()
{
return std::string("1234567890123456") + std::string("");
}
---
$ g++ -c -O --std=c++20 x.cc
In file included from /usr/local/gcc/include/c++/12.0.0/string:40,
from x.cc:1:
In static member function ‘static constexpr std::char_traits::char_type*
std::char_traits::copy(std::char_traits::char_type*, const
std::char_traits::char_type*, std::size_t)’,
inlined from ‘static constexpr void std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::_S_copy(_CharT*, const _CharT*,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]’ at
/usr/local/gcc/include/c++/12.0.0/bits/basic_string.h:423:21,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Allocator>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_append(const _CharT*, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]’ at
/usr/local/gcc/include/c++/12.0.0/bits/basic_string.tcc:417:19,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::append(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]’ at
/usr/local/gcc/include/c++/12.0.0/bits/basic_string.h:1385:25,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Allocator> std::operator+(std::__cxx11::basic_string<_CharT, _Traits,
_Allocator>&&, std::__cxx11::basic_string<_CharT, _Traits, _Allocator>&&) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at
/usr/local/gcc/include/c++/12.0.0/bits/basic_string.h:3530:23,
inlined from ‘std::string foo()’ at x.cc:5:59:
/usr/local/gcc/include/c++/12.0.0/bits/char_traits.h:426:56: warning: ‘void*
__builtin_memcpy(void*, const void*, long unsigned int)’ specified bound
between 18446744073709551600 and 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
426 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
|
^
$
Perhaps interestingly, the warning goes away if the first string literal
is less than 16 characters long.
[Bug target/55610] cc1 is calling munmap() on part of itself on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55610 --- Comment #11 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:22a982409323feb203401d345488a5a9c18e6733 commit r12-5759-g22a982409323feb203401d345488a5a9c18e6733 Author: Iain Sandoe Date: Sat Nov 13 12:39:09 2021 + Darwin: Rewrite host PCH support [PR 55610]. We need to revise the PCH memory allocation scheme to enable support for PIE on aarch64. The rewrite uses a similar scheme to the one used on Linux. We attempt to identify VM segments for each arch/OS version that are always available to the compiler (note this is not general, it only needs to work for the cc1* exes). If we cannot find the preferred segment we fall back to allowing the kernel to supply one - this is more likely to fail when the PCH read-in occurs (but that is trapped). In doing this we obviate the need to unmap any part of the compiler __DATA segment - thus fixing PR 55610. Signed-off-by: Iain Sandoe gcc/ChangeLog: PR target/55610 * config/host-darwin.c (TRY_EMPTY_VM_SPACE, SAFE_ALLOC_SIZE): New. (darwin_gt_pch_get_address): Rewrite to use nominated memory segments rather than part of the compiler __DATA segment. (darwin_gt_pch_use_address): Likewise.
[Bug c++/100102] [9 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 Patrick Palka changed: What|Removed |Added CC||michaelreneer at gmail dot com --- Comment #28 from Patrick Palka --- *** Bug 103532 has been marked as a duplicate of this bug. ***
[Bug c++/103532] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103532 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Thanks for the bug report. This looks like dup of PR100102, which has been fixed for GCC 10.4, 11.2 and 12. Feel free to reopen this PR if you can reproduce the crash with newer versions of GCC. *** This bug has been marked as a duplicate of bug 100102 ***
[Bug analyzer/103526] -fanalyzer considers memcpy()ed and returned pointer to malloc()ed memory a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103526 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Regression test added to trunk by above commit; marking as resolved.
[Bug analyzer/103526] -fanalyzer considers memcpy()ed and returned pointer to malloc()ed memory a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103526 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:38a0ee2649ef236ea2763bb9cfc42dc917c7d3fd commit r12-5757-g38a0ee2649ef236ea2763bb9cfc42dc917c7d3fd Author: David Malcolm Date: Thu Dec 2 11:48:04 2021 -0500 analyzer: add regression test for leak false +ve [PR103526] gcc/testsuite/ChangeLog: PR analyzer/103526 * gcc.dg/analyzer/pr103526.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/103533] New: Enable "taint" state machine with -fanalyzer without requiring -fanalyzer-checker=taint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533
Bug ID: 103533
Summary: Enable "taint" state machine with -fanalyzer without
requiring -fanalyzer-checker=taint
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
sm.cc: make_checkers currently has:
/* The "taint" checker must be explicitly enabled (as it currently
leads to state explosions that stop the other checkers working). */
if (flag_analyzer_checker)
out.safe_push (make_taint_state_machine (logger));
and all of the various testcases for the "taint" state machine have:
// TODO: remove need for this option:
/* { dg-additional-options "-fanalyzer-checker=taint" } */
and with notes in the docs of the form:
This warning requires both @option{-fanalyzer} and
@option{-fanalyzer-checker=taint} to enable it;
I'm opening this bug to track removing the need for this, so that the the taint
checker can be enabled directly by -fanalyzer.
Currently removing this leads to:
* ICE in alt_get_inherited_state in abs-1.c, data-model-1.c, data-model-19.c,
pr101570.c, pr99771-1.c, zlib-2.c, zlib-3.c, torture/pr93450.c; all of which
seems to be for a UNARY_OP that isn't a NOP_EXPR; replacing that
gcc_unreachable with break, so it returns NULL fixes all of these.
* state explosion and failure in pr93032-mztools.c, with:
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c: In function
‘unzRepair’:
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:252:16: warning:
terminating analysis for this program point: callstring: [] after SN: 52EN:
270-271, EN: 526-527, EN: 782-783, EN: 1038-1039 [-Wanalyzer-too-complex]
252 | entries++;
| ~~~^~
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:252:16: warning:
terminating analysis for this program point: callstring: [] after SN: 52EN:
270-271, EN: 526-527, EN: 782-783, EN: 1038-1039 [-Wanalyzer-too-complex]
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning:
terminating analysis for this program point: callstring: [] before (SN: 68
stmt: 0): _325 = fread (, 1, 8192, fpOutCD_522);EN: 1302-1308, EN: 1329
[-Wanalyzer-too-complex]
299 | while ( (nRead = (int)fread(buffer, 1, sizeof(buffer),
fpOutCD)) > 0) {
| ^
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning:
terminating analysis for this program point: callstring: [] before (SN: 68
stmt: 0): _325 = fread (, 1, 8192, fpOutCD_522);EN: 1302-1308, EN: 1329
[-Wanalyzer-too-complex]
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning:
terminating analysis for this program point: callstring: [] before (SN: 68
stmt: 0): _325 = fread (, 1, 8192, fpOutCD_522);EN: 1302-1308, EN: 1329
[-Wanalyzer-too-complex]
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning:
terminating analysis for this program point: callstring: [] before (SN: 68
stmt: 0): _325 = fread (, 1, 8192, fpOutCD_522);EN: 1302-1308, EN: 1329
[-Wanalyzer-too-complex]
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning:
terminating analysis for this program point: callstring: [] before (SN: 68
stmt: 0): _325 = fread (, 1, 8192, fpOutCD_522);EN: 1302-1308, EN: 1329
[-Wanalyzer-too-complex]
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning:
terminating analysis for this program point: callstring: [] before (SN: 68
stmt: 0): _325 = fread (, 1, 8192, fpOutCD_522);EN: 1302-1308, EN: 1329
[-Wanalyzer-too-complex]
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning:
terminating analysis for this program point: callstring: [] before (SN: 68
stmt: 0): _325 = fread (, 1, 8192, fpOutCD_522);EN: 1302-1308, EN: 1329
[-Wanalyzer-too-complex]
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c: At top level:
../../src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:319:21: warning:
analysis bailed out early (401 'after-snode' enodes; 1506 enodes)
[-Wanalyzer-too-complex]
319 | *nRecovered = entries;
| ^
Interestingly, PR analyzer/103521 reports this as now failing on powerpc64
(without turning on taint detection), although the explosion is in a different
place.
[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090 --- Comment #7 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #6) > The other is to introduce the solver into the predicate analysis pass which > starts to touch on other ideas I've had. Namely that thread discovery and > predicate analysis are closely related. ie, we could be using predicate > analysis to discover more threading opportunities and we could be using the > path solver to prune out infeasible paths for the uninit (and other) passes > by integrating path solving into predicate analysis. What you've done is > the first step in this direction. It looks like compute_control_dep_chain builds a vectors of edges indicating paths from DEF to USE. We may be able to feed a variant of this to the path solver to determine if the path is reachable. That is, without having to search for the path :). Hmm, there may be something here.
[Bug c++/103532] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103532 Bug ID: 103532 Summary: internal compiler error: Segmentation fault Product: gcc Version: og10 (devel/omp/gcc-10) Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michaelreneer at gmail dot com Target Milestone: --- * The exact version of GCC: gcc (Ubuntu 10.3.0-1ubuntu1~18.04~1) 10.3.0 * The system type: Ubuntu * The options given when GCC was configured/built: Not sure * The compiler output (error messages, warnings, etc.): ERROR: /home/kbuilder/.cache/bazel/_bazel_kbuilder/37fb99bea68ee800120d59291ba62264/external/nccl_archive/BUILD.bazel:77:13: C++ compilation of rule '@nccl_archive//:nccl' failed (Exit 1): crosstool_wrapper_driver_is_not_gcc failed: error executing command (cd /home/kbuilder/.cache/bazel/_bazel_kbuilder/37fb99bea68ee800120d59291ba62264/execroot/org_tensorflow_federated && \ exec env - \ LD_LIBRARY_PATH=/usr/local/cuda:/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64: \ PATH=/tmpfs/src/github/federated/venv/bin:/usr/local/cuda/bin:/opt/android-sdk/current/cmdline-tools/tools/bin:/opt/android-sdk/current/bin:/usr/local/go/bin:/usr/local/go/packages/bin:/opt/kubernetes/client/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin \ PWD=/proc/self/cwd \ TF2_BEHAVIOR=1 \ TF_CUDA_VERSION=11 \ TF_CUDNN_VERSION=8 \ external/local_config_cuda/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -MD -MF bazel-out/k8-opt/bin/external/nccl_archive/_objs/nccl/bootstrap.d '-frandom-seed=bazel-out/k8-opt/bin/external/nccl_archive/_objs/nccl/bootstrap.o' -iquote external/nccl_archive -iquote bazel-out/k8-opt/bin/external/nccl_archive -iquote external/local_config_cuda -iquote bazel-out/k8-opt/bin/external/local_config_cuda -Ibazel-out/k8-opt/bin/external/nccl_archive/_virtual_includes/nccl -Ibazel-out/k8-opt/bin/external/nccl_archive/_virtual_includes/include_hdrs -Ibazel-out/k8-opt/bin/external/local_config_cuda/cuda/_virtual_includes/cuda_headers_virtual -Ibazel-out/k8-opt/bin/external/nccl_archive/_virtual_includes/src_hdrs -isystem external/local_config_cuda/cuda -isystem bazel-out/k8-opt/bin/external/local_config_cuda/cuda -isystem external/local_config_cuda/cuda/cuda/include -isystem bazel-out/k8-opt/bin/external/local_config_cuda/cuda/cuda/include -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -fPIE -U_FORTIFY_SOURCE '-D_FORTIFY_SOURCE=1' -fstack-protector -Wall -fno-omit-frame-pointer -no-canonical-prefixes -fno-canonical-system-headers -DNDEBUG -g0 -O2 -ffunction-sections -fdata-sections -Wno-stringop-truncation -Wno-maybe-uninitialized -w -DAUTOLOAD_DYNAMIC_KERNELS '-march=native' -O3 -Wno-ignored-attributes -Wno-missing-field-initializers -Wno-unknown-pragmas '-std=c++14' '-std=c++14' '-D_GLIBCXX_USE_CXX11_ABI=0' -x cuda '-DGOOGLE_CUDA=1' '-Xcuda-fatbinary=--compress-all' '--no-cuda-include-ptx=all' '--cuda-include-ptx=sm_35' '--cuda-gpu-arch=sm_35' '--cuda-include-ptx=sm_52' '--cuda-gpu-arch=sm_52' -c external/nccl_archive/src/bootstrap.cc -o bazel-out/k8-opt/bin/external/nccl_archive/_objs/nccl/bootstrap.o) Execution platform: @local_execution_config_platform//:platform nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' and 'sm_50' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning). nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' and 'sm_50' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning). /usr/include/c++/10/chrono: In substitution of ‘template template using __is_harmonic = std::__bool_constant<(std::ratio<((_Period2::num / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::num, _Period::num)) * (_Period::den / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den, _Period::den))), ((_Period2::den / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den, _Period::den)) * (_Period::num / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::num, _Period::num)))>::den == 1)> [with _Period2 = _Period2; _Rep = _Rep; _Period = _Period]’: /usr/include/c++/10/chrono:473:154: required from here /usr/include/c++/10/chrono:428:27: internal compiler error: Segmentation fault 428 | _S_gcd(intmax_t __m, intmax_t __n) noexcept | ^~ Please submit a full bug report, with preprocessed source if appropriate. * The preprocessed file (*.i*) that triggers the bug: This will be difficult for me to acquire, please let me know if this file will be useful in this case to help debug.
[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271 --- Comment #16 from Jim Wilson --- I have a patch to add movti to the riscv port. I agree that we should be adding this. I just unfortunately had a kitchen accident and had take some time off before I finished it. I noticed that a comment before riscv_split_doubleword_move implies that we did used to have a movti pattern. I wanted to check out the history before re-adding movti to make sure I didn't break anything.
[Bug rtl-optimization/103437] gcc/ira-color.c:2813:5: runtime error: signed integer overflow: 15 * 147462000 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437 --- Comment #8 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:cd47cd4b5eb2dfa7a3190e46a3ae93cc87dbe6b1 commit r12-5756-gcd47cd4b5eb2dfa7a3190e46a3ae93cc87dbe6b1 Author: Vladimir N. Makarov Date: Thu Dec 2 12:31:28 2021 -0500 [PR103437] Make backup code for overflow conditional Switch off long long variant overflow code by preprocessor if the build compiler has __builtin_smul_overflow. gcc/ChangeLog: PR rtl-optimization/103437 * ira-color.c (setup_allocno_priorities): Switch off backup code for overflow if compiler has __builtin_smul_overflow. Use < for comparison with -INT_MAX.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 102467, which changed state. Bug 102467 Summary: Missed SLP discovery for gathers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102467 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/102467] Missed SLP discovery for gathers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102467 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from rsandifo at gcc dot gnu.org --- OK, closing as fixed then :-)
[Bug libstdc++/103400] src/c++98/*_allocator.cc symbols not exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103400 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed by removing these allocators as possible implementations of std::allocator.
[Bug libstdc++/103340] [12 Regression] constexpr std::string is incompatible with --enable-libstdcxx-allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103340 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- Fixed by removing these options.
[Bug middle-end/103364] s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103364 --- Comment #16 from Sarah Julia Kriesch --- Sorry! I thought I have created these links as a logged out user. Here are the public links. PostgreSQL14: https://build.opensuse.org/public/build/openSUSE:Factory:zSystems/standard/s390x/postgresql14/_log Rust1.54: https://build.opensuse.org/public/build/openSUSE:Factory:zSystems/standard/s390x/rust1.54/_log
[Bug libstdc++/103381] [9/10/11 Regression] --enable-libstdcxx-allocator=bitmap doesn't build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103381 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e2e98f524fdb80c16e3395f20fee930fbcad5562 commit r12-5754-ge2e98f524fdb80c16e3395f20fee930fbcad5562 Author: Jonathan Wakely Date: Wed Dec 1 16:30:30 2021 + libstdc++: Remove broken std::allocator base classes [PR103340] The bitmap_allocator, __mt_alloc and __pool_alloc extensions are no longer suitable for use as the base class of std::allocator, because they have not been updated to meet the C++20 requirements. There is a patch attached to PR 103340 which addresses that, but more work would be needed to solve the linking errors that occur when the library is configured to use them. Using --enable-libstdcxx-allocator=bitmap wouldn't even bootstrap for the past few years, and I can't find any gcc-testresults reports using any of these allocators. This patch removes the configure option to use these as the std::allocator base class. The allocators are still in the tree and can be used directly, you just can't configure the library to use one of them as the base class of std::allocator. libstdc++-v3/ChangeLog: PR libstdc++/103340 PR libstdc++/103400 PR libstdc++/103381 * acinclude.m4 (GLIBCXX_ENABLE_ALLOCATOR): Remove mt, bitmap and pool options. * configure: Regenerate. * config/allocator/bitmap_allocator_base.h: Removed. * config/allocator/mt_allocator_base.h: Removed. * config/allocator/pool_allocator_base.h: Removed. * doc/xml/manual/allocator.xml: Update. * doc/xml/manual/configure.xml: Update. * doc/xml/manual/evolution.xml: Document removal. * doc/xml/manual/mt_allocator.xml: Editorial tweaks. * doc/html/manual/*: Regenerate.
[Bug libstdc++/103400] src/c++98/*_allocator.cc symbols not exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103400 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e2e98f524fdb80c16e3395f20fee930fbcad5562 commit r12-5754-ge2e98f524fdb80c16e3395f20fee930fbcad5562 Author: Jonathan Wakely Date: Wed Dec 1 16:30:30 2021 + libstdc++: Remove broken std::allocator base classes [PR103340] The bitmap_allocator, __mt_alloc and __pool_alloc extensions are no longer suitable for use as the base class of std::allocator, because they have not been updated to meet the C++20 requirements. There is a patch attached to PR 103340 which addresses that, but more work would be needed to solve the linking errors that occur when the library is configured to use them. Using --enable-libstdcxx-allocator=bitmap wouldn't even bootstrap for the past few years, and I can't find any gcc-testresults reports using any of these allocators. This patch removes the configure option to use these as the std::allocator base class. The allocators are still in the tree and can be used directly, you just can't configure the library to use one of them as the base class of std::allocator. libstdc++-v3/ChangeLog: PR libstdc++/103340 PR libstdc++/103400 PR libstdc++/103381 * acinclude.m4 (GLIBCXX_ENABLE_ALLOCATOR): Remove mt, bitmap and pool options. * configure: Regenerate. * config/allocator/bitmap_allocator_base.h: Removed. * config/allocator/mt_allocator_base.h: Removed. * config/allocator/pool_allocator_base.h: Removed. * doc/xml/manual/allocator.xml: Update. * doc/xml/manual/configure.xml: Update. * doc/xml/manual/evolution.xml: Document removal. * doc/xml/manual/mt_allocator.xml: Editorial tweaks. * doc/html/manual/*: Regenerate.
[Bug libstdc++/103340] [12 Regression] constexpr std::string is incompatible with --enable-libstdcxx-allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103340 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e2e98f524fdb80c16e3395f20fee930fbcad5562 commit r12-5754-ge2e98f524fdb80c16e3395f20fee930fbcad5562 Author: Jonathan Wakely Date: Wed Dec 1 16:30:30 2021 + libstdc++: Remove broken std::allocator base classes [PR103340] The bitmap_allocator, __mt_alloc and __pool_alloc extensions are no longer suitable for use as the base class of std::allocator, because they have not been updated to meet the C++20 requirements. There is a patch attached to PR 103340 which addresses that, but more work would be needed to solve the linking errors that occur when the library is configured to use them. Using --enable-libstdcxx-allocator=bitmap wouldn't even bootstrap for the past few years, and I can't find any gcc-testresults reports using any of these allocators. This patch removes the configure option to use these as the std::allocator base class. The allocators are still in the tree and can be used directly, you just can't configure the library to use one of them as the base class of std::allocator. libstdc++-v3/ChangeLog: PR libstdc++/103340 PR libstdc++/103400 PR libstdc++/103381 * acinclude.m4 (GLIBCXX_ENABLE_ALLOCATOR): Remove mt, bitmap and pool options. * configure: Regenerate. * config/allocator/bitmap_allocator_base.h: Removed. * config/allocator/mt_allocator_base.h: Removed. * config/allocator/pool_allocator_base.h: Removed. * doc/xml/manual/allocator.xml: Update. * doc/xml/manual/configure.xml: Update. * doc/xml/manual/evolution.xml: Document removal. * doc/xml/manual/mt_allocator.xml: Editorial tweaks. * doc/html/manual/*: Regenerate.
[Bug analyzer/103526] -fanalyzer considers memcpy()ed and returned pointer to malloc()ed memory a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103526 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-12-02 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this bug. It affects gcc 11.2: https://godbolt.org/z/focGvsesh but is fixed in trunk for GCC 12 : https://godbolt.org/z/hc5f7vWPY I've rewritten the pertinent parts of -fanalyzer's internals a fair amount for GCC 12. I'm working on adding the test case to our regression testsuite.
[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271 --- Comment #15 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #11) > > I suppose assigning TImode to a decl but not even being able to move TImode > can be a problem elsewhere... this might be the root issue that we should fix? as mentioned by Jim in comment #5 and #6, adding a MOVTI pattern in riscv will fix other bug in addition to this one. so, should the right fix be in riscv backend?
[Bug rtl-optimization/103437] gcc/ira-color.c:2813:5: runtime error: signed integer overflow: 15 * 147462000 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437 --- Comment #7 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:7d02c8bf75980fa2468f4167a82dd3a619e35cb4 commit r12-5717-g7d02c8bf75980fa2468f4167a82dd3a619e35cb4 Author: Vladimir N. Makarov Date: Thu Dec 2 10:55:59 2021 -0500 [PR103437] Use long long multiplication as backup for overflow processing __builtin_smul_overflow can be unavailable for some C++ compilers. Add long long multiplication as backup for overflow processing. gcc/ChangeLog: PR rtl-optimization/103437 * ira-color.c (setup_allocno_priorities): Use long long multiplication as backup for overflow processing.
[Bug middle-end/103364] s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103364 --- Comment #15 from Andreas Krebbel --- (In reply to Sarah Julia Kriesch from comment #0) ... > Full PostgreSQL log: > https://build.opensuse.org/build/openSUSE:Factory:zSystems/standard/s390x/ > postgresql14/_log > > Full Rust log: > https://build.opensuse.org/build/openSUSE:Factory:zSystems/standard/s390x/ > rust1.54/_log No access
[Bug target/103383] Microblaze bswaphi2 can cause issues with delay slots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103383 --- Comment #7 from Michael Eager --- Do you have a test case which shows the problem?
