[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88220 --- Comment #18 from Andrew Pinski --- I wonder if this is fixed for GCC 10 by the patch which fixes PR 88220.
[Bug c++/102084] Segfault when lambda is missing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084 --- Comment #1 from Andrew Pinski --- With -fsanitize=undefined I get: /opt/compiler-explorer/gcc-trunk-20210826/include/c++/12.0.0/bits/invoke.h:116:38: runtime error: reference binding to null pointer of type 'const double' /opt/compiler-explorer/gcc-trunk-20210826/include/c++/12.0.0/bits/std_function.h:292:44: runtime error: reference binding to null pointer of type 'const double' /app/example.cpp:24:43: runtime error: load of null pointer of type 'const double'
[Bug c++/102084] Segfault when lambda is missing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
--- Comment #2 from Andrew Pinski ---
So we have in original:
< = (const double &) &TARGET_EXPR (const
double&)::&> (<<< Unknown tree: empty_class_expr >>>,
std::forward(const double&)::&> ((struct
type &) __fn))>;, 0>>;
Note the ,0 there.
The original code:
template
constexpr __can_invoke_as_nonvoid<_Res, _Callable, _Args...>
__invoke_r(_Callable&& __fn, _Args&&... __args)
{
using __result = __invoke_result<_Callable, _Args...>;
using __type = typename __result::type;
using __tag = typename __result::__invoke_type;
return std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
std::forward<_Args>(__args)...);
}
Note I think this is undefined code anyways, you are causing a return of a
reference to a local variable here.
[Bug c++/102084] Segfault when lambda is missing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Andrew Pinski ---
Your code is the same as this code:
template
std::function constant_ref_broken(const T& c) {
return [c]() noexcept -> const T { return c; };
}
So you are returning a non-reference and then have a return of a refence.
Nothing shocking.
If you want to capture the reference of c and return the reference rather than
what points to the refence you need c++14 to do that and this code works and
does what you originally wanted:
template
std::function constant_ref_broken(const T& c) {
return [&c]() noexcept -> decltype(auto) { return c; };
}
[Bug fortran/101997] [9 regression] ICE after r9-8665 at gcc/toplev.c:326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997
--- Comment #4 from anlauf at gcc dot gnu.org ---
I have run the testcase under the debugger and the longest arguments to
sprintf I have found is
"m2345678901234567890123456789012345678901234567890123456789_123.n2345678901234567890123456789012345678901234567890123456789_123"
(gdb) p (int)strlen(derived->ns->proc_name->name)
$45 = 127
which is 2*GFC_MAX_SYMBOL_LEN+1, and I also do not see how dt_name would
overflow. (GFC_MAX_SYMBOL_LEN is 63).
I've tentatively increased the buffers in question and run again under gdb
but did not see that the checked string length in get_unique_hashed_string
or gfc_hash_value would change anything.
Here's the simple modification I tried:
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 1a5bcfae3c0..e794a762d33 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -479,7 +479,7 @@ gfc_class_initializer (gfc_typespec *ts, gfc_expr
*init_expr)
static void
get_unique_type_string (char *string, gfc_symbol *derived)
{
- char dt_name[GFC_MAX_SYMBOL_LEN+1];
+ char dt_name[2*(GFC_MAX_SYMBOL_LEN+1)];
if (derived->attr.unlimited_polymorphic)
strcpy (dt_name, "STAR");
else
@@ -502,7 +502,7 @@ static void
get_unique_hashed_string (char *string, gfc_symbol *derived)
{
/* Provide sufficient space to hold "symbol.symbol_symbol". */
- char tmp[3*GFC_MAX_SYMBOL_LEN+3];
+ char tmp[4*(GFC_MAX_SYMBOL_LEN+1)];
get_unique_type_string (&tmp[0], derived);
size_t len = strnlen (tmp, sizeof (tmp));
gcc_assert (len < sizeof (tmp));
@@ -527,7 +527,7 @@ gfc_hash_value (gfc_symbol *sym)
{
unsigned int hash = 0;
/* Provide sufficient space to hold "symbol.symbol_symbol". */
- char c[3*GFC_MAX_SYMBOL_LEN+3];
+ char c[4*(GFC_MAX_SYMBOL_LEN+1)];
int i, len;
get_unique_type_string (&c[0], sym);
[Bug sanitizer/102085] libsanitizer/asan/asan_errors.cpp:387: declaration and definition do not match ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102085 --- Comment #1 from Andrew Pinski --- It might be useful to submit this upstream too.
[Bug c++/102084] Segfault when lambda is missing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084 --- Comment #4 from Sergio Losilla --- I see, thanks! The second version (constant_ref) which returns the reference to the captured does not trigger the sanitizer, so returning a reference to that is valid?
[Bug c++/102084] Segfault when lambda is missing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084 --- Comment #5 from Andrew Pinski --- (In reply to Sergio Losilla from comment #4) > I see, thanks! The second version (constant_ref) which returns the reference > to the captured does not trigger the sanitizer, so returning a reference to > that is valid? In the second case you are returning a reference to the capatured lamdba struct.
[Bug c++/102084] Segfault when lambda is missing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084 --- Comment #6 from Sergio Losilla --- Thank you for taking the time in explaining it, appreciated :-)
[Bug tree-optimization/102087] New: ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
Bug ID: 102087
Summary: ICE on valid code at -O3 on x86_64-linux-gnu: in
determine_exit_conditions, at
tree-ssa-loop-manip.c:1049
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[540] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210826 (experimental) [master revision
352d5e85a70:96f76144c4d:5a6c626710ad2ac4baa2dba02fac0750177e3305] (GCC)
[541] %
[541] % gcctk -O2 small.c
[542] %
[542] % gcctk -O3 small.c
during GIMPLE pass: unrolljam
small.c: In function ‘main’:
small.c:4:5: internal compiler error: in determine_exit_conditions, at
tree-ssa-loop-manip.c:1049
4 | int main() {
| ^~~~
0xfe4bea determine_exit_conditions
../../gcc-trunk/gcc/tree-ssa-loop-manip.c:1049
0xfe4bea tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.c:1253
0x19ed2eb tree_loop_unroll_and_jam
../../gcc-trunk/gcc/gimple-loop-jam.c:590
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[543] %
[543] % cat small.c
volatile int a[1];
unsigned b;
int c;
int main() {
int d;
for (; b > 1; b++)
for (c = 0; c < 2; c++)
for (d = 0; d < 2; d++)
a[0];
return 0;
}
[Bug c++/81609] incompatible extern C declarations of the same extern function at local scope accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81609 --- Comment #4 from Andrew Pinski --- Seems fixed for GCC 11.
[Bug c++/32042] linkage confused with scope?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32042 Andrew Pinski changed: What|Removed |Added Known to work||11.1.0 --- Comment #2 from Andrew Pinski --- Seems fixed for GCC 11.
[Bug c++/88344] sole attribute specification in a class silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88344 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-26 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/88344] sole attribute specification in a class silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88344
--- Comment #2 from Andrew Pinski ---
The same is true for C2x and C++11 style attributes:
struct B {
[[gnu::always_inline]];
};
The C front-end warns:
:3:3: warning: 'always_inline' attribute ignored [-Wattributes]
3 | [[gnu::always_inline]];
| ^
[Bug c++/89898] invalid function template definition with non-type class argument accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89898
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
>In the following, the invalid function template definition is accepted in
>c++2a mode:
How is this invalid C++20 code? C++20 allows class non-type template
arguments.
X is a valid type now in C++20.
This is defining a template function whos template argument is of type X
E.g this is also valid:
template a> void f () { }
I Know it looks confusing but I don't see anything wrong with this code.
[Bug c++/89898] invalid function template definition with non-type class argument accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89898
--- Comment #2 from Andrew Pinski ---
This is valid C++ 20 too:
struct A { int t; };
template struct X { int d = a.t; };
template a > int f () { return a.d; }
int g(void)
{
return f{1}>();
}
Yes I know it looks off but it is valid now and f<{1}> will return 1.
Note {} and {0} are the same here really.
Even something like this is valid now too:
struct A { int t; };
template struct X { int d = a.t; };
template x > int f () { return x.d; }
int g(void)
{
return f{1}>();
}
[Bug c++/89898] invalid function template definition with non-type class argument accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89898 --- Comment #3 from Andrew Pinski --- This was implemented by r9-3836 which is P0732R2: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf
[Bug middle-end/102088] New: poor uninitialized warning points to an initialized variable, no note to uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102088
Bug ID: 102088
Summary: poor uninitialized warning points to an initialized
variable, no note to uninitialized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The uninitialized warning below is valid, but the quality is poor. The message
refers to an 'x' but the caret is under 'z'. There also is no note pointing to
x's declaration, which compounds the confusion.
$ cat z.c && gcc -O2 -S -Wall z.c
int f (int i, int j)
{
int x, y = j, z;
if (i)
z = x;
else
z = y;
return z;
}
z.c: In function ‘f’:
z.c:9:10: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
9 | return z;
| ^
With the patch in
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578130.html installed GCC
does print a helpful note, but the warning still refers to 'z':
z.c: In function ‘f’:
z.c:9:10: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
9 | return z;
| ^
z.c:3:7: note: ‘x’ was declared here
3 | int x, y = j, z;
| ^
The warning should underline the whole return statement, e.g., like so:
9 | return z;
| ^~~~
but the location of the return statement is the same as that of z. So that
seems like a bug earlier on. The output of -fdump-tree-gimple-lineno shows:
[z.c:9:10] return D.2358;
indicating that this might be a front-end problem. Sure enough, the C front
end in c_finish_return() does this:
case RID_RETURN:
c_parser_consume_token (parser);
if (c_parser_next_token_is (parser, CPP_SEMICOLON))
{
stmt = c_finish_return (loc, NULL_TREE, NULL_TREE);
c_parser_consume_token (parser);
}
else
{
location_t xloc = c_parser_peek_token (parser)->location;
struct c_expr expr = c_parser_expression_conv (parser);
mark_exp_read (expr.value);
stmt = c_finish_return (EXPR_LOC_OR_LOC (expr.value, xloc), <<<
statement location
expr.value, expr.original_type);
goto expect_semicolon;
}
[Bug c++/94405] [temp.names]p4 not fully implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94405 --- Comment #1 from Andrew Pinski --- Only MSVC rejects this code.
[Bug middle-end/102088] poor uninitialized warning points to an initialized variable, no note to uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102088
--- Comment #1 from Martin Sebor ---
The patch below changes the latest warning to the following without any dg.exp
test failures:
z.c: In function ‘f’:
z.c:9:3: warning: ‘x’ may be used uninitialized [-Wmaybe-uninitialized]
9 | return z;
| ^~~~
z.c:3:7: note: declared here, initialized if ‘i == 0’
3 | int x, y = j, z;
| ^
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 356cf2504d4..73c303b1b4f 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -6168,6 +6168,12 @@ c_parser_statement_after_labels (c_parser *parser, bool
*if_p,
mark_exp_read (expr.value);
stmt = c_finish_return (EXPR_LOC_OR_LOC (expr.value, xloc),
expr.value, expr.original_type);
+ if (stmt)
+ {
+ /* Set the statement location to include the operand. */
+ xloc = make_location (loc, loc, xloc);
+ SET_EXPR_LOCATION (stmt, xloc);
+ }
goto expect_semicolon;
}
break;
Though ideally, the warning would point to the uninitialized read, like so:
z.c: In function ‘f’:
z.c:9:3: warning: ‘x’ may be used uninitialized [-Wmaybe-uninitialized]
5 | z = x;
| ^
But that's not in the IL at -O2 when the warning runs.
[Bug middle-end/102088] poor uninitialized warning points to an initialized variable, no note to uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102088 --- Comment #2 from Martin Sebor --- At -O0 the warning looks right although not as nice as what the analyzer prints (but the analyzer doesn't catch it at -O1 or higher): $ gcc -S -Wall -fanalyzer z.c z.c: In function ‘f’: z.c:5:7: warning: ‘x’ may be used uninitialized [-Wmaybe-uninitialized] 5 | z = x; | ~~^~~ z.c:3:7: note: ‘x’ was declared here 3 | int x, y = j, z; | ^ z.c:5:7: warning: use of uninitialized value ‘x’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 5 | z = x; | ~~^~~ ‘f’: events 1-3 | |4 | if (i) | | ^ | | | | | (1) following ‘true’ branch (when ‘i != 0’)... |5 | z = x; | | ~ | | | | | (2) ...to here | | (3) use of uninitialized value ‘x’ here |
[Bug c++/32042] linkage confused with scope?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32042 --- Comment #3 from Andrew Pinski --- Was fixed by r11-3699.
[Bug c++/81609] incompatible extern C declarations of the same extern function at local scope accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81609 --- Comment #5 from Andrew Pinski --- Was fixed by r11-3699.
[Bug c++/69855] Missing diagnostic for overload that only differs by return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855 --- Comment #10 from Andrew Pinski --- (In reply to Nathan Sidwell from comment #9) > Reopening. I think I'm on the path of getting this right ... I think r11-3699 fixed it the right way.
[Bug c++/95484] Friend declaration of conversion function template has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95484 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-08-26 Blocks||65608 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 [Bug 65608] [meta-bug] friend issues
[Bug c++/92193] Poor diagnostics when a constexpr function call follows a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92193 --- Comment #2 from Jonathan Wakely --- This makes the diagnostics for std::vector diabolical. We hit a nice static assertion saying something like: /home/jwakely/gcc/12/include/c++/12.0.0/bits/stl_uninitialized.h:90:56: error: static assertion failed: result type must be constructible from input type And then the compiler just keeps on rollin' ... /home/jwakely/gcc/12/include/c++/12.0.0/bits/stl_construct.h:115:28: error: no matching function for call to 'construct_at(X*&, X&)' ... /home/jwakely/gcc/12/include/c++/12.0.0/bits/stl_construct.h:96:17: error: use of deleted function 'X::X(const X&)' ... /home/jwakely/gcc/12/include/c++/12.0.0/bits/stl_construct.h:119:7: error: use of deleted function 'X::X(const X&)' ... The 23_containers/vector/cons/89164.cc test produces 28 lines of errors in C++17 mode, and 159 lines of errors in C++20 mode, because everything is constexpr.
[Bug c++/101243] Coroutine lambda capture is destroyed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101243
--- Comment #5 from Jonathan Wakely ---
For the attachment in comment 3 trunk now says:
In file included from /home/jwakely/gcc/12/include/c++/12.0.0/functional:59,
from /tmp/pr-1.cc:2:
/home/jwakely/gcc/12/include/c++/12.0.0/bits/std_function.h: In instantiation
of 'std::function<_Res(_ArgTypes ...)>::function(_Functor&&) [with _Functor =
f(f()::_Z1fv.frame*)::; = void; _Res = void;
_ArgTypes = {}]':
/tmp/pr-1.cc:71:13: required from here
/home/jwakely/gcc/12/include/c++/12.0.0/bits/std_function.h:442:69: error:
static assertion failed: std::function target must be copy-constructible
442 |
static_assert(is_copy_constructible<__decay_t<_Functor>>::value,
|
^
/home/jwakely/gcc/12/include/c++/12.0.0/bits/std_function.h:442:69: note:
'std::integral_constant::value' evaluates to false
[Bug c++/91609] friend declaration not honoured
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91609 --- Comment #4 from Andrew Pinski --- Seems fixed in GCC 11+.
[Bug c++/89616] Parameter names can be redeclared in outermost block of a function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89616 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 52953. *** This bug has been marked as a duplicate of bug 52953 ***
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953 Andrew Pinski changed: What|Removed |Added CC||jtcash at ucsd dot edu --- Comment #5 from Andrew Pinski --- *** Bug 89616 has been marked as a duplicate of this bug. ***
[Bug c++/67943] [DR472] Friend declaration applied to base class, leading to allowing access to protected base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67943 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-26 Status|UNCONFIRMED |SUSPENDED Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#472 Suspended as it is still active.
[Bug c++/95407] [DR 1873] G++ allows access to base class members from a friend of a derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95407 --- Comment #2 from Andrew Pinski --- I think PR 67943 is also related. But then DR 472 is also related to that one.
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476 --- Comment #3 from Andrew Pinski --- GCC, clang, ICC, and MSVC all agree they have external linkage.
[Bug c++/79531] bad location when trying to define undeclared method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79531
--- Comment #2 from Andrew Pinski ---
Since GCC 8, we produce:
:8:16: error: 'virtual void derived::method2()' marked 'override', but
does not override
virtual void method2() override;
^~~
:11:6: error: no declaration matches 'void derived::n()'
void derived::n ()
^~~
:11:6: note: no functions named 'void derived::n()'
:6:8: note: 'struct derived' defined here
struct derived : public base {
^~~
Which seems ok, unless I am missing something.
[Bug c++/64519] variadic template as the first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64519 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93140 --- Comment #3 from Andrew Pinski --- By the way this was most likely fixed by the patch which fixed PR 93140.
[Bug c++/83249] C++11 Parameter pack deduced incorrectly in decltype return declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83249 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64519, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93140 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Fixed in GCC 8.4.0 and GCC 9.3.0 and GCC 10+; most likely by the patch which fixes PR 93140.
[Bug c++/89687] Empty pack expansion in `decltype` results in cryptic compiler error (dump_expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89687 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0 Keywords||rejects-valid --- Comment #1 from Andrew Pinski --- Seems fixed for GCC 10+.
[Bug c++/90960] declaring a member function with a computed typedef is confused as a data member definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90960 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/67633] decltype on parenthesized class member access of a prvalue sometimes return wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67633 --- Comment #2 from Andrew Pinski --- GCC, clang and MSVC all argree here but ICC disagrees.
[Bug target/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 --- Comment #3 from Hongtao.liu --- (In reply to H.J. Lu from comment #2) > It is caused by r12-2679. Mine.
[Bug c++/93625] [DR281] inline specifier in a friend function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93625
Andrew Pinski changed:
What|Removed |Added
Summary|inline specifier in a |[DR281] inline specifier in
|friend function declaration |a friend function
||declaration
--- Comment #2 from Andrew Pinski ---
What is interesting is the testcase in comment #0 is accepted by EDG but the
testcase in the defect report is rejected.
And even more interesting is this one:
void f(){}
struct X{
friend inline void f();
};
Only clang rejects it while GCC, EDG and MSVC all accept it.
By the way here is the testcase from the defect report:
struct A {
void f();
};
struct B {
friend inline void A::f();
};
void A::f(){}
[Bug c++/93625] [DR281] inline specifier in a friend function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93625
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=66995
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> What is interesting is the testcase in comment #0 is accepted by EDG but the
> testcase in the defect report is rejected.
>
> And even more interesting is this one:
> void f(){}
>
> struct X{
> friend inline void f();
> };
>
> Only clang rejects it while GCC, EDG and MSVC all accept it.
That is similar to PR 66995.
[Bug c++/66995] [DR317] First declaration as inline after definition of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66995 Andrew Pinski changed: What|Removed |Added Blocks||94404 Summary|First declaration as inline |[DR317] First declaration |after definition of |as inline after definition |function|of function --- Comment #1 from Andrew Pinski --- So this is DR317. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 [Bug 94404] [meta-bug] C++ core issues
[Bug rtl-optimization/43147] SSE shuffle merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147 --- Comment #19 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:0fa4787bf34b173ce6f198e99b6f6dd8a3f98014 commit r12-3177-g0fa4787bf34b173ce6f198e99b6f6dd8a3f98014 Author: liuhongt Date: Fri Dec 11 19:02:43 2020 +0800 Fold more shuffle builtins to VEC_PERM_EXPR. A follow-up to https://gcc.gnu.org/pipermail/gcc-patches/2019-May/521983.html gcc/ PR target/98167 PR target/43147 * config/i386/i386.c (ix86_gimple_fold_builtin): Fold IX86_BUILTIN_SHUFPD512, IX86_BUILTIN_SHUFPS512, IX86_BUILTIN_SHUFPD256ï¼ IX86_BUILTIN_SHUFPSï¼ IX86_BUILTIN_SHUFPS256. (ix86_masked_all_ones): New function. gcc/testsuite/ * gcc.target/i386/avx512f-vshufpd-1.c: Adjust testcase. * gcc.target/i386/avx512f-vshufps-1.c: Adjust testcase. * gcc.target/i386/pr43147.c: New test.
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167 --- Comment #12 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:0fa4787bf34b173ce6f198e99b6f6dd8a3f98014 commit r12-3177-g0fa4787bf34b173ce6f198e99b6f6dd8a3f98014 Author: liuhongt Date: Fri Dec 11 19:02:43 2020 +0800 Fold more shuffle builtins to VEC_PERM_EXPR. A follow-up to https://gcc.gnu.org/pipermail/gcc-patches/2019-May/521983.html gcc/ PR target/98167 PR target/43147 * config/i386/i386.c (ix86_gimple_fold_builtin): Fold IX86_BUILTIN_SHUFPD512, IX86_BUILTIN_SHUFPS512, IX86_BUILTIN_SHUFPD256ï¼ IX86_BUILTIN_SHUFPSï¼ IX86_BUILTIN_SHUFPS256. (ix86_masked_all_ones): New function. gcc/testsuite/ * gcc.target/i386/avx512f-vshufpd-1.c: Adjust testcase. * gcc.target/i386/avx512f-vshufps-1.c: Adjust testcase. * gcc.target/i386/pr43147.c: New test.
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #13 from Hongtao.liu ---
fold shulfps to vec_perm_exp, but still 2 shulfps are generated.
__m128 f (__m128 a, __m128 b)
{
vector(4) float _3;
vector(4) float _5;
vector(4) float _6;
;; basic block 2, loop depth 0
;;pred: ENTRY
_3 = VEC_PERM_EXPR ;
_5 = VEC_PERM_EXPR ;
_6 = _3 * _5;
return _6;
;;succ: EXIT
}
[Bug rtl-optimization/43147] SSE shuffle merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147 --- Comment #20 from Hongtao.liu --- Fixed in GCC12, now gcc generate optimal codes. main: .LFB532: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 movaps .LC0(%rip), %xmm0 callprintv xorl%eax, %eax addq$8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE532: .size main, .-main .section.rodata.cst16,"aM",@progbits,16 .align 16 .LC0: .long 1073741824 .long 1065353216 .long 1082130432 .long 1077936128 .ident "GCC: (GNU) 12.0.0 20210825 (experimental)" .section.note.GNU-stack,"",@progbits
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #14 from Andrew Pinski ---
(In reply to Hongtao.liu from comment #13)
> fold shulfps to vec_perm_exp, but still 2 shulfps are generated.
>
> __m128 f (__m128 a, __m128 b)
> {
> vector(4) float _3;
> vector(4) float _5;
> vector(4) float _6;
>
> ;; basic block 2, loop depth 0
> ;;pred: ENTRY
> _3 = VEC_PERM_EXPR ;
> _5 = VEC_PERM_EXPR ;
> _6 = _3 * _5;
> return _6;
> ;;succ: EXIT
>
> }
So this is a bit more complex as not all targets have a good extract/dup
functionary for scalars. So maybe this should be done as a define_insn for x86.
[Bug target/102068] [AIX] field alignment ignores packed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102068 --- Comment #2 from CVS Commits --- The master branch has been updated by David Edelsohn : https://gcc.gnu.org/g:5faf7120398c9bf290758891a975da1f727d631a commit r12-3178-g5faf7120398c9bf290758891a975da1f727d631a Author: David Edelsohn Date: Thu Aug 26 17:14:18 2021 -0400 aix: packed struct alignment [PR102068] Further fixes to structure alignment when the structure is packed and contains double. This patch checks for packed attribute at the top level. gcc/ChangeLog: PR target/102068 * config/rs6000/rs6000.c (rs6000_adjust_field_align): Use computed alignment if the entire struct has attribute packed.
[Bug fortran/65025] Internal compiler error with preprocessor in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Andrew Pinski --- Dup of bug 55210. *** This bug has been marked as a duplicate of bug 55210 ***
[Bug fortran/55210] cannot use macro #define FOO 'a' in a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55210 Andrew Pinski changed: What|Removed |Added CC||siteg at mathalacarte dot com --- Comment #2 from Andrew Pinski --- *** Bug 65025 has been marked as a duplicate of this bug. ***
[Bug fortran/68968] Internal Compiler error with cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68968 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 55210. *** This bug has been marked as a duplicate of bug 55210 ***
[Bug fortran/55210] cannot use macro #define FOO 'a' in a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55210 --- Comment #3 from Andrew Pinski --- *** Bug 68968 has been marked as a duplicate of this bug. ***
[Bug fortran/91237] ICE in gfortran with preprocessor directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91237 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 55210. *** This bug has been marked as a duplicate of bug 55210 ***
[Bug fortran/55210] cannot use macro #define FOO 'a' in a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55210 Andrew Pinski changed: What|Removed |Added CC||Melven.Roehrig-Zoellner@DLR ||.de --- Comment #4 from Andrew Pinski --- *** Bug 91237 has been marked as a duplicate of this bug. ***
[Bug fortran/87737] ICE tree check: expected ssa_name, have addr_expr in remap_gimple_op_r, at tree-inline.c:923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87737 --- Comment #3 from Andrew Pinski --- GCC 10+ rejects this code with: /app/example.f90:2:9: 2 | program p | 1 Error: Entity 'master.0.f' at (1) has a deferred type parameter and requires either the POINTER or ALLOCATABLE attribute IFC also rejects it: /app/example.f90(18): error #6625: The character lengths of the functions must not be different. [G] entry g() --^ compilation aborted for /app/example.f90 (code 1) flang also rejects it: /app/example.f90:18:7: error: Result of ENTRY is not compatible with result of containing function entry g() ^ /app/example.f90:13:10: Containing subprogram function f() ^ so maybe this is fixed.
[Bug fortran/67623] interaction between cpp and Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67623 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 58334. *** This bug has been marked as a duplicate of bug 58334 ***
[Bug fortran/58334] preprocessor behavior diffs under line continuation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58334 Andrew Pinski changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #4 from Andrew Pinski --- *** Bug 67623 has been marked as a duplicate of this bug. ***
[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662 Bug 28662 depends on bug 67623, which changed state. Bug 67623 Summary: interaction between cpp and Fortran https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67623 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug target/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #4 from Hongtao.liu ---
diff --git a/test.c.032t.ccp1 b/test.c.033t.forwprop1
index 5b18739..c6f0587 100644
--- a/test.c.032t.ccp1
+++ b/test.c.033t.forwprop1
@@ -31,11 +31,12 @@ void EncodedFromDisplay ()
__m256 __trans_tmp_11;
vector(8) float _mm256_mul_ps___A.2_1;
vector(8) float _mm256_mul_ps___B.3_2;
+ vector(8) _5;
vector(8) float _mm256_blendv_ps___M.0_6;
vector(8) float _mm256_blendv_ps___Y.1_7;
vector(8) int _8;
vector(8) _9;
- vector(8) float _10;
+ vector(8) float _12;
:
_mm256_mul_ps___A.2_1 = _mm256_mul_ps___A;
@@ -45,8 +46,9 @@ void EncodedFromDisplay ()
_mm256_blendv_ps___Y.1_7 = _mm256_blendv_ps___Y;
_8 = VIEW_CONVERT_EXPR(_mm256_blendv_ps___M.0_6);
_9 = _8 < { 0, 0, 0, 0, 0, 0, 0, 0 };
- _10 = VEC_COND_EXPR <_9, _mm256_blendv_ps___Y.1_7, __trans_tmp_11_4>;
- IfThenElse___trans_tmp_9 = _10;
+ _5 = _8 >= { 0, 0, 0, 0, 0, 0, 0, 0 };
+ _12 = .COND_MUL (_5, _mm256_mul_ps___A.2_1, _mm256_mul_ps___B.3_2,
_mm256_blendv_ps___Y.1_7);
+ IfThenElse___trans_tmp_9 = _12;
return;
fwprop1 should check if the type of _5 satisfies the predicate of cond_mul.
[Bug target/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Keywords||ice-on-valid-code
--- Comment #5 from Andrew Pinski ---
(In reply to Hongtao.liu from comment #4)
> diff --git a/test.c.032t.ccp1 b/test.c.033t.forwprop1
> index 5b18739..c6f0587 100644
> --- a/test.c.032t.ccp1
> +++ b/test.c.033t.forwprop1
> @@ -31,11 +31,12 @@ void EncodedFromDisplay ()
>__m256 __trans_tmp_11;
>vector(8) float _mm256_mul_ps___A.2_1;
>vector(8) float _mm256_mul_ps___B.3_2;
> + vector(8) _5;
>vector(8) float _mm256_blendv_ps___M.0_6;
>vector(8) float _mm256_blendv_ps___Y.1_7;
>vector(8) int _8;
>vector(8) _9;
> - vector(8) float _10;
> + vector(8) float _12;
>
> :
>_mm256_mul_ps___A.2_1 = _mm256_mul_ps___A;
> @@ -45,8 +46,9 @@ void EncodedFromDisplay ()
>_mm256_blendv_ps___Y.1_7 = _mm256_blendv_ps___Y;
>_8 = VIEW_CONVERT_EXPR(_mm256_blendv_ps___M.0_6);
>_9 = _8 < { 0, 0, 0, 0, 0, 0, 0, 0 };
> - _10 = VEC_COND_EXPR <_9, _mm256_blendv_ps___Y.1_7, __trans_tmp_11_4>;
> - IfThenElse___trans_tmp_9 = _10;
> + _5 = _8 >= { 0, 0, 0, 0, 0, 0, 0, 0 };
> + _12 = .COND_MUL (_5, _mm256_mul_ps___A.2_1, _mm256_mul_ps___B.3_2,
> _mm256_blendv_ps___Y.1_7);
> + IfThenElse___trans_tmp_9 = _12;
>return;
>
> fwprop1 should check if the type of _5 satisfies the predicate of cond_mul.
Actually this seems backwards ... what match pattern is doing this?
[Bug target/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #6 from Andrew Pinski ---
This is the match pattern which does it:
(for uncond_op (UNCOND_BINARY)
cond_op (COND_BINARY)
(simplify
(vec_cond @0 (view_convert? (uncond_op@4 @1 @2)) @3)
(with { tree op_type = TREE_TYPE (@4); }
(if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type)
&& element_precision (type) == element_precision (op_type))
(view_convert (cond_op @0 @1 @2 (view_convert:op_type @3))
(simplify
(vec_cond @0 @1 (view_convert? (uncond_op@4 @2 @3)))
(with { tree op_type = TREE_TYPE (@4); }
(if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type)
&& element_precision (type) == element_precision (op_type))
(view_convert (cond_op (bit_not @0) @2 @3 (view_convert:op_type @1)))
I don't see anything wrong here.
Are we saying the (bit_not @0) part is causing issues?
[Bug target/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 --- Comment #7 from Andrew Pinski --- The operation works elementwise if the operands are vectors. No I think x86's cond_* patterns are not correct.
[Bug target/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 --- Comment #8 from Andrew Pinski --- That is the mask is a vector mode still for these patterns according to the internals doc. Rather than the scalar mode you have: (match_operand: 1 "register_operand")
[Bug target/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 --- Comment #9 from Hongtao.liu --- (In reply to Andrew Pinski from comment #8) > That is the mask is a vector mode still for these patterns according to the > internals doc. > Rather than the scalar mode you have: > (match_operand: 1 "register_operand") No, according to doc, mode of operands[1] is decided by TARGET_VECTORIZE_GET_MASK_MODE. Which means integer mode shoud also be accepted. Operands 0, 2, 3 and 4 all have mode m. Operand 1 is a scalar integer if m is scalar, otherwise it has the mode returned by TARGET_VECTORIZE_GET_MASK_ MODE.
[Bug fortran/67170] PRE can't hoist out a readonly argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67170 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0 Keywords||missed-optimization
[Bug middle-end/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 Andrew Pinski changed: What|Removed |Added Component|target |middle-end --- Comment #10 from Andrew Pinski --- (In reply to Hongtao.liu from comment #9) > (In reply to Andrew Pinski from comment #8) > > That is the mask is a vector mode still for these patterns according to the > > internals doc. > > Rather than the scalar mode you have: > > (match_operand: 1 "register_operand") > > No, according to doc, mode of operands[1] is decided by > TARGET_VECTORIZE_GET_MASK_MODE. Which means integer mode shoud also be > accepted. > > Operands 0, 2, 3 and 4 all have mode m. Operand 1 is a scalar integer if m is > scalar, otherwise it has the mode returned by TARGET_VECTORIZE_GET_MASK_ > MODE. Looks like vectorized_internal_fn_supported_p might need to be extended here or a better function needs to be used to check on cond_* optabs.
[Bug target/102089] New: MIPS: use N64 ABI by default if the triple end with -gnuabi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089 Bug ID: 102089 Summary: MIPS: use N64 ABI by default if the triple end with -gnuabi64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: syq at debian dot org Target Milestone: --- We use mips64el-linux-gnuabi64 as the triplet for mips64el port on Debian since 2013. --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -2553,16 +2553,30 @@ mips*-*-linux*) # Linux MIPS, either endian. target_cpu_default=MASK_SOFT_FLOAT_ABI enable_mips_multilibs="yes" ;; + mipsisa64r6*-*-linux-gnuabi64) + default_mips_abi=64 + default_mips_arch=mips64r6 + enable_mips_multilibs="yes" + ;; mipsisa64r6*-*-linux*) default_mips_abi=n32 default_mips_arch=mips64r6 enable_mips_multilibs="yes" ;; + mipsisa64r2*-*-linux-gnuabi64) + default_mips_abi=64 + default_mips_arch=mips64r2 + enable_mips_multilibs="yes" + ;; mipsisa64r2*-*-linux*) default_mips_abi=n32 default_mips_arch=mips64r2 enable_mips_multilibs="yes" ;; + mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64) + default_mips_abi=64 + enable_mips_multilibs="yes" + ;; mips64*-*-linux* | mipsisa64*-*-linux*) default_mips_abi=n32 enable_mips_multilibs="yes"
[Bug c/102030] Optimization turns null ptr true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102030 --- Comment #4 from Joe Eagar --- I hadn't realized the nonnull attribute is 1-based. That makes sense.
[Bug libstdc++/102090] New: Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090 Bug ID: 102090 Summary: Placement-new is not constexpr Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: friedkeenan at protonmail dot com Target Milestone: --- When calling placement-new in a constant expression, a compiler error occurs saying that `void* operator new(std::size_t, void*)` is not constexpr; see https://godbolt.org/z/8enoG9G57 for a minimal example. As far as I can tell, the fix should just be adding constexpr to the signature.
[Bug target/102089] MIPS: use N64 ABI by default if the triple end with -gnuabi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089 Andrew Pinski changed: What|Removed |Added Target||mips*-*-linux-gnuabi64 --- Comment #1 from Andrew Pinski --- Patches should be sent to gcc-patches@ after reading https://gcc.gnu.org/contribute.html
[Bug target/102089] MIPS: use N64 ABI by default if the triple end with -gnuabi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089 --- Comment #2 from YunQiang Su --- (In reply to Andrew Pinski from comment #1) > Patches should be sent to gcc-patches@ after reading > https://gcc.gnu.org/contribute.html Yes. the patch will be send just now.
[Bug libstdc++/102090] Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090 --- Comment #1 from Andrew Pinski --- I don't think inplacement new is valid for constexpr. See PR 61105 also.
[Bug libstdc++/102090] Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #2 from Andrew Pinski ---
clang produces:
:3:16: error: consteval function never produces a constant expression
[-Winvalid-constexpr]
consteval auto fuck() {
^
:5:23: note: call to placement 'operator new'
const auto data = new(buf) int(1);
^
[Bug libstdc++/102090] Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090 --- Comment #3 from Andrew Pinski --- DR 1312 also mentions something similar with respect to casting to void*.
[Bug libstdc++/102090] Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090 --- Comment #4 from friedkeenan at protonmail dot com --- I think you're correct. That's really strange, but I guess that's what std::construct_at is for? But that also confuses me, how is GCC's implementation of std::construct_at working if placement-new isn't constexpr: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/include/bits/stl_construct.h#L97
[Bug libstdc++/102090] Placement-new is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- I know cppreference is not the standard but from: https://en.cppreference.com/w/cpp/memory/construct_at except that construct_at may be used in evaluation of constant expressions. (In reply to friedkeenan from comment #4) > I think you're correct. That's really strange, but I guess that's what > std::construct_at is for? But that also confuses me, how is GCC's > implementation of std::construct_at working if placement-new isn't > constexpr: > https://github.com/gcc-mirror/gcc/blob/ > 16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/include/bits/ > stl_construct.h#L97 Because it is still broken ...
[Bug target/102089] MIPS: use N64 ABI by default if the triple end with -gnuabi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089 --- Comment #3 from YunQiang Su --- https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578240.html Patch has been sent to gcc-patches.
[Bug libffi/83636] libffi/mips/n32: don't .set mips4 for mips r6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83636 --- Comment #2 from YunQiang Su --- Patch has been sent to: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578243.html
[Bug middle-end/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 --- Comment #11 from Hongtao.liu --- Created attachment 51363 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51363&action=edit Proposed patch I'm testing this patch.
[Bug target/101472] AVX-512 wrong code for consecutive masked scatters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101472 --- Comment #2 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:44a545a6abdd330083c1d12ad70092defbba702a commit r12-3181-g44a545a6abdd330083c1d12ad70092defbba702a Author: konglin1 Date: Mon Aug 9 11:37:52 2021 +0800 i386: Fix wrong optimization for consecutive masked scatters [PR 101472] gcc/ChangeLog: PR target/101472 * config/i386/sse.md: (scattersi): Add mask operand to UNSPEC_VSIBADDR. (scattersi): Likewise. (*avx512f_scattersi): Merge mask operand to set_dest. (*avx512f_scatterdi): Likewise gcc/testsuite/ChangeLog: PR target/101472 * gcc.target/i386/avx512f-pr101472.c: New test. * gcc.target/i386/avx512vl-pr101472.c: New test.
[Bug target/101472] AVX-512 wrong code for consecutive masked scatters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101472 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:b186040b468f6da512b9b123e1d4549f44396993 commit r11-8934-gb186040b468f6da512b9b123e1d4549f44396993 Author: konglin1 Date: Mon Aug 9 11:37:52 2021 +0800 i386: Fix wrong optimization for consecutive masked scatters [PR 101472] gcc/ChangeLog: PR target/101472 * config/i386/sse.md: (scattersi): Add mask operand to UNSPEC_VSIBADDR. (scattersi): Likewise. (*avx512f_scattersi): Merge mask operand to set_dest. (*avx512f_scatterdi): Likewise gcc/testsuite/ChangeLog: PR target/101472 * gcc.target/i386/avx512f-pr101472.c: New test. * gcc.target/i386/avx512vl-pr101472.c: New test.
[Bug target/101472] AVX-512 wrong code for consecutive masked scatters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101472 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:fab014ecf9f7faf3b607a1e0892d0aeabe556661 commit r10-10073-gfab014ecf9f7faf3b607a1e0892d0aeabe556661 Author: konglin1 Date: Mon Aug 9 11:37:52 2021 +0800 i386: Fix wrong optimization for consecutive masked scatters [PR 101472] gcc/ChangeLog: PR target/101472 * config/i386/sse.md: (scattersi): Add mask operand to UNSPEC_VSIBADDR. (scattersi): Likewise. (*avx512f_scattersi): Merge mask operand to set_dest. (*avx512f_scatterdi): Likewise gcc/testsuite/ChangeLog: PR target/101472 * gcc.target/i386/avx512f-pr101472.c: New test. * gcc.target/i386/avx512vl-pr101472.c: New test.
[Bug target/101472] AVX-512 wrong code for consecutive masked scatters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101472 --- Comment #5 from Hongtao.liu --- Fixed in GCC12, backport to GCC11 and GCC10.
[Bug rtl-optimization/48128] Excessive code generated for vectorized loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48128
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.8.0
Status|NEW |RESOLVED
Known to work||4.8.0
Keywords||ra
Resolution|--- |FIXED
--- Comment #5 from Andrew Pinski ---
The problem was this RTL:
(insn 7 2 25 2 (set (reg:V4SI 65 [ MEM[(int[8] *)&baz] ])
(mem/c:V4SI (symbol_ref:SI ("baz") [flags 0x2] ) [2 MEM[(int[8] *)&baz]+0 S16 A256])) /app/example.cpp:19
1080 {*movv4si_internal}
(nil))
(insn 25 7 26 2 (set (reg:SI 72)
(subreg:SI (reg:V4SI 65 [ MEM[(int[8] *)&baz] ]) 0))
/app/example.cpp:19 -1
(nil))
Which was produced by dse.
In GCC 4.8 we produce the same except lra produces:
(insn 25 7 26 2 (set (reg:SI 0 ax [72])
(mem/c:SI (symbol_ref:SI ("baz") [flags 0x2] ) [2 MEM[(int[8] *)&baz]+0 S4 A256])) /app/example.cpp:19 89
{*movsi_internal}
(nil))
So this got fixed with the new reload (LRA) :).
Note -fno-tree-loop-distribute-patterns is needed otherwise you get a memcpy
:).
With -mno-sse, the extra register push was gone in GCC 4.6.0.
GCC 8 also no longer vectorizers the code based on the cost model of pentium3,
you need to add -fno-vect-cost-model.
Starting GCC 9, GCC is able to produce for -msse2 case:
movd%xmm0, %eax
Anyways the original issue is fixed.
With the trunk -O3 -m32 -msse GCC produces:
foo2():
movdqa baz, %xmm7
movd%xmm7, %eax
movaps %xmm7, bar
movdqa baz+16, %xmm7
movaps %xmm7, bar+16
ret
With -O3 -m32 -msse2:
foo2():
movdqa baz, %xmm7
movd%xmm7, %eax
movaps %xmm7, bar
movdqa baz+16, %xmm7
movaps %xmm7, bar+16
ret
The problem is -march=pentium3 causes a loop for the memcpy (tuning).
[Bug rtl-optimization/65056] Missed optimization (x86): Redundant test/compare after arithmetic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65056 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #1 from Andrew Pinski --- GCC 8+ gets rid of the compare for andq and GCC produces: .L11: movq%r8, %rcx andq(%rdi,%rdx,8), %rcx movq%r9, %r8 jne .L10 .L3: subq$1, %rdx cmpq$-1, %rdx jne .L11 This was fixed by r8-3869. GCC 10+ gets rid of the compare for the subq and GCC produces: .L11: andq(%rdi,%rax,8), %rdx movq%rdx, %rcx movq$-1, %rdx jne .L10 .L3: subq$1, %rax jnb .L11 There was a lot of carry improvements for GCC 10 and that fixed that one.
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #15 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #14)
> (In reply to Hongtao.liu from comment #13)
> > fold shulfps to vec_perm_exp, but still 2 shulfps are generated.
> >
> > __m128 f (__m128 a, __m128 b)
> > {
> > vector(4) float _3;
> > vector(4) float _5;
> > vector(4) float _6;
> >
> > ;; basic block 2, loop depth 0
> > ;;pred: ENTRY
> > _3 = VEC_PERM_EXPR ;
> > _5 = VEC_PERM_EXPR ;
> > _6 = _3 * _5;
> > return _6;
> > ;;succ: EXIT
> >
> > }
>
> So this is a bit more complex as not all targets have a good extract/dup
> functionary for scalars. So maybe this should be done as a define_insn for
> x86.
No need for extract/dup, if both perm indexes is the same, it can be c = a * b,
and vec_perm_expr (c, c, index}. it seems a quite general optimization which
could apply to all other operations.
[Bug rtl-optimization/63315] -fcompare-debug bootstrap issue in libjava (fixup_abnormal_edges related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63315 --- Comment #3 from Andrew Pinski --- So I looked and I suspect in the end was the same issue as PR 69838. I have no way to prove this though.
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #16 from Hongtao.liu ---
typedef int v4si __attribute__ ((vector_size(16)));
v4si f(v4si a, v4si b) {
v4si a1 = __builtin_shufflevector (a, a, 2, 3 ,1 ,0);
v4si b1 = __builtin_shufflevector (b, a, 2, 3 ,1 ,0);
return a1 * b1;
}
gcc generate
f:
vpshufd xmm1, xmm1, 30
vpshufd xmm0, xmm0, 30
vpmulld xmm0, xmm0, xmm1
ret
llvm generate
f: # @f
vpmulld xmm0, xmm1, xmm0
vpshufd xmm0, xmm0, 30 # xmm0 = xmm0[2,3,1,0]
ret
[Bug rtl-optimization/43056] __builtin_prefetch causes ICE: in rtl_verify_flow_info, at cfgrtl.c:2205 with -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056 Andrew Pinski changed: What|Removed |Added Known to work||4.8.0 --- Comment #7 from Andrew Pinski --- 4.7: ;;0-->11 simple_return :athlon-vector,athlon-ieu,athlon-ieu ;;0--> 5 prefetch(`x',0,0x3) :nothing 4.8.0: ;;0--> 5prefetch(`x',0,0x3) :nothing ;;0--> 10simple_return :athlon-vector,athlon-ieu,athlon-ieu
[Bug tree-optimization/102072] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072 --- Comment #6 from Jiu Fu Guo --- (In reply to Richard Earnshaw from comment #5) > (In reply to Jiu Fu Guo from comment #4) > > > I did not find arm big-endian yet, I'm trying to reproduce this issue on > > other targets... > > For testing purposes you should be able to build a standard arm-eabi config > and then compile the testcase with -mbig-endian. Thanks a lot! config with --target=arm-none-eabi, I could reproduce the ice for -mcpu=cortex-a9.
[Bug rtl-optimization/43056] __builtin_prefetch causes ICE: in rtl_verify_flow_info, at cfgrtl.c:2205 with -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from Andrew Pinski --- Dup of bug 55153. *** This bug has been marked as a duplicate of bug 55153 ***
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 --- Comment #7 from Andrew Pinski --- *** Bug 43056 has been marked as a duplicate of this bug. ***
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #17 from Andrew Pinski ---
(In reply to Hongtao.liu from comment #16)
> typedef int v4si __attribute__ ((vector_size(16)));
>
> v4si f(v4si a, v4si b) {
> v4si a1 = __builtin_shufflevector (a, a, 2, 3 ,1 ,0);
> v4si b1 = __builtin_shufflevector (b, a, 2, 3 ,1 ,0);
> return a1 * b1;
> }
>
> gcc generate
>
> f:
> vpshufd xmm1, xmm1, 30
> vpshufd xmm0, xmm0, 30
> vpmulld xmm0, xmm0, xmm1
> ret
>
> llvm generate
>
> f: # @f
> vpmulld xmm0, xmm1, xmm0
> vpshufd xmm0, xmm0, 30 # xmm0 = xmm0[2,3,1,0]
> ret
For the above, this is safe for -ftrapping-math as all elements are still used.
It is when elements that are not used it might not be safe ...
[Bug libgcc/81415] termio ioctl returns incorrect value for some bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81415
--- Comment #5 from Andreas Schwab ---
ioctl.c: In function ‘main’:
ioctl.c:21:24: warning: array subscript is above array bounds [-Warray-bounds]
if ((int) sgbuf.c_cc[VSUSP] != 0377) {
~~^~~
[Bug c++/102071] crash when combining -faligned-new=N with array cookie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102071 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Cannot reproduce it with g++ pr102071.C -c -faligned-new=2 g++ --version g++ (GCC) 12.0.0 20210826 (experimental)
[Bug c++/102071] crash when combining -faligned-new=N with array cookie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102071 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-08-26
[Bug target/102069] [12 regression] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on power 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069
--- Comment #1 from Jiu Fu Guo ---
Thanks, Segher!
The test case could be updated. The patch supports calculating the number of
iterations for the special condition(step to min/max), so we may just update to
the case to check if the "number of iterations" is there.
like:
diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c
b/gcc/testsuite/gcc.dg/vect/pr101145_3.c
index 99289afec0b..819e134c6e6 100644
--- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c
+++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c
@@ -10,4 +10,4 @@
#include "pr101145.inc"
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */
+/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2
"vect" } } */
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #10 from Richard Biener --- OPTION_MASK_P8_FUSION is purely optimization and shouldn't prevent inlining, no? As of HTM it would make the testcase a user error - when using -mcpu=power10 it would require building with -mcpu=power8 -mno-htm? Thus INVALID based on HTM, and the OPTION_MASK_P8_FUSION (and other "tuning" things) should be excluded from the compares in the backend, at least for the always-inline case.
