[Bug c++/107267] ice in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 --- Comment #5 from David Binderman --- (In reply to David Binderman from comment #4) > Trying a git bisect with git hash 93b3ab6c0c6a44df. Seems good. Trying eb491ea5c10955c6.
[Bug c++/107267] ice in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 --- Comment #6 from David Binderman --- (In reply to David Binderman from comment #5) > (In reply to David Binderman from comment #4) > > Trying a git bisect with git hash 93b3ab6c0c6a44df. > > Seems good. Trying eb491ea5c10955c6. Seems good. Trying b9ad850e86b863c2.
[Bug c++/107267] ice in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107267 David Binderman changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #7 from David Binderman --- Advice of Jason sought.
[Bug c/107277] New: Spurious -Wformat-overflow when combined with __builtin_expect()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107277
Bug ID: 107277
Summary: Spurious -Wformat-overflow when combined with
__builtin_expect()
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tomerv at gmail dot com
Target Milestone: ---
Incorrect format-overflow warning/error:
error: '%d' directive writing between 1 and 11 bytes into a region of size 10
[-Werror=format-overflow=]
note: directive argument in the range [-2147483648, 5]
On this code:
__attribute((__noreturn__)) void do_panic();
int get_number();
#define unlikely(x) __builtin_expect((x),0)
int foo()
{
char buff[10]={0};
int index = get_number();
if (unlikely(index < 0)) { // <-- index cannot be negative
do_panic();
}
if (6 <= index) {
index = 0;
}
int n = sprintf(buff, "%d", index);
if (unlikely(n < 0)) {
do_panic();
}
return n;
}
Removing "unlikely" from the first condition fixes the issue.
Also - and this is a missing warning, which is the reverse problem - removing
the whole "if (6 <= index)" block removes the warning, but only with the
"unlikely" present.
https://godbolt.org/z/9esTTTbGq
[Bug c++/107278] New: fails to correctly parse template default function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278
Bug ID: 107278
Summary: fails to correctly parse template default function
declarations.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ky4ct at arrl dot net
Target Milestone: ---
Created attachment 53709
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53709&action=edit
minimal source code to reproduce the error.
This is specific to the -std=C++20 and -std=C++2b switches. The following
compiles fine by default and under C++ 11 and 14.
kd5eax@KY4CT UCRT64 ~
$ cat test.cpp
template
class foo
{
foo(foo const&) = delete;
foo(foo const&&) = default;
};
int main()
{
return 0;
};
kd5eax@KY4CT UCRT64 ~
$ g++ -std=c++20 test.cpp
test.cpp:4:22: error: expected ')' before 'const'
4 | foo(foo const&) = delete;
| ~ ^~
| )
test.cpp:5:22: error: expected ')' before 'const'
5 | foo(foo const&&) = default;
| ~ ^~
| )
kd5eax@KY4CT UCRT64 ~
$ g++ -v
Using built-in specs.
COLLECT_GCC=E:\msys64\ucrt64\bin\g++.exe
COLLECT_LTO_WRAPPER=E:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-12.2.0/configure --prefix=/ucrt64
--with-local-prefix=/ucrt64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/ucrt64/include --libexecdir=/ucrt64/lib
--enable-bootstrap --enable-checking=release --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/ucrt64
--with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64
--with-pkgversion='Rev1, Built by MSYS2 project'
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++
--with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Rev1, Built by MSYS2 project)
[Bug c++/107278] fails to correctly parse template default function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #1 from Andrew Pinski --- Iirc there was a defect report against the c++ standard here and you should just foo instead of foo
[Bug c++/107278] fails to correctly parse template default function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278
--- Comment #2 from Jonathan ---
(In reply to Andrew Pinski from comment #1)
> Iirc there was a defect report against the c++ standard here and you should
> just foo instead of foo
kd5eax@KY4CT CLANG64 ~
$ cat test.cpp
template
class foo
{
foo(foo const&) = delete;
foo(foo const&&) = default;
};
int main()
{
return 0;
};
kd5eax@KY4CT CLANG64 ~
$ clang++ -std=c++20 test.cpp
kd5eax@KY4CT CLANG64 ~
$
[Bug c++/107278] fails to correctly parse template default function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278
--- Comment #3 from Jonathan ---
(In reply to Andrew Pinski from comment #1)
> Iirc there was a defect report against the c++ standard here and you should
> just foo instead of foo
kd5eax@KY4CT CLANG64 ~
$ cat test.cpp
template
class foo
{
foo(foo const&) = delete;
foo(foo const&&) = default;
};
int main()
{
return 0;
};
kd5eax@KY4CT CLANG64 ~
$ clang++ -std=c++20 test.cpp
kd5eax@KY4CT CLANG64 ~
$
kd5eax@KY4CT UCRT64 ~
$ g++ -std=c++2b test.cpp
test.cpp:4:22: error: expected ')' before 'const'
4 | foo(foo const&) = delete;
| ~ ^~
| )
test.cpp:5:22: error: expected ')' before 'const'
5 | foo(foo const&&) = default;
| ~ ^~
| )
kd5eax@KY4CT UCRT64 ~
$ g++ test.cpp
kd5eax@KY4CT UCRT64 ~
$
(In reply to Andrew Pinski from comment #1)
> Iirc there was a defect report against the c++ standard here and you should
> just foo instead of foo
If that is the case, can you please link the defect report against the
standard?
[Bug c++/107278] fails to correctly parse template default function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #4 from Andrew Pinski --- Clang might not implement the defect report after all ...
[Bug c++/107278] fails to correctly parse template default function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #5 from Jonathan --- (In reply to Andrew Pinski from comment #4) > Clang might not implement the defect report after all ... This is why I asked for a link to it so I could understand this issue at its core; at any rate, thanks for looking into this.
[Bug c++/103593] [11/12 Regression] Naming the constructor of a template class without using the injected-class-name causes parse error with C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103593 Andrew Pinski changed: What|Removed |Added CC||ky4ct at arrl dot net --- Comment #6 from Andrew Pinski --- *** Bug 107278 has been marked as a duplicate of this bug. ***
[Bug c++/107278] fails to correctly parse template default function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup of bug 103593. CWG2237 is the defect report #. *** This bug has been marked as a duplicate of bug 103593 ***
[Bug c++/107278] fails to correctly parse template default function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > Dup of bug 103593. > > CWG2237 is the defect report #. >From that defect report: ``` (Note that this resolution is a change for C++20, NOT a defect report against C++17 and earlier versions.) ``` Which means it was not exactly a defect against previous versions of the standard. It also means clang does not implement this part of the C++20 standard as it was published ...
[Bug c++/107278] fails to correctly parse template default function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107278
Jonathan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #8 from Jonathan ---
Proposed resolution (November, 2017)
Change 11.4.5 [class.ctor] paragraph 1 as follows:
...and the id-expression has one of the following forms:
in a member-declaration that belongs to the member-specification of
a class or class template but is not a friend declaration (11.8.4
[class.friend]), the id-expression is the injected-class-name ( Clause 11
[class]) of the immediately-enclosing class; entity or
in a member-declaration that belongs to the member-specification of
a class template but is not a friend declaration, the id-expression is a
class-name that names the current instantiation (13.8.3.2 [temp.dep.type]) of
the immediately-enclosing class template; or
in a declaration at namespace scope or in a friend declaration, the
id-expression is a qualified-id that names a constructor (6.5.5.2
[class.qual]).
Change 11.4.7 [class.dtor] paragraph 1 as follows:
...and the id-expression has one of the following forms:
in a member-declaration that belongs to the member-specification of
a class or class template but is not a friend declaration (11.8.4
[class.friend]), the id-expression is ~class-name and the class-name is the
injected-class-name (Clause 11 [class]) of the immediately-enclosing class;
entity or
in a member-declaration that belongs to the member-specification of
a class template but is not a friend declaration, the id-expression is
~class-name and the class-name names the current instantiation (13.8.3.2
[temp.dep.type]) of the immediately-enclosing class template; or
in a declaration at namespace scope or in a friend declaration, the
id-expression is nested-name-specifier ~class-name and the class-name names the
same class as the nested-name-specifier.
Add the following as a new paragraph in C.2 [diff.cpp17]:
C.5.x Clause 15: Special member functions [diff.cpp17.special]
Affected subclauses: 11.4.5 [class.ctor], 11.4.7 [class.dtor]
Change: A simple-template-id is no longer valid as the declarator-id of
a constructor or destructor.
Rationale: Remove potentially error-prone option for redundancy.
Effect on original feature: Valid C++ 2017 code may fail to compile.
template
struct A {
A(); // error: simple-template-id not allowed for constructor
A(int); // OK, injected-class-name used
~A(); // error: simple-template-id not allowed for destructor
};
(Note that this resolution is a change for C++20, NOT a defect report against
C++17 and earlier versions.)
[Bug c++/107279] New: __builtin_complex is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107279
Bug ID: 107279
Summary: __builtin_complex is not supported
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
I noticed this while trying to create a testcase for another issue.
And it is not documented that __builtin_complex is only support for the C
front-end (I know because I touched the documentation last).
testcase:
```
void f(void)
{
_Complex float a = __builtin_complex (1.0f, 2.0f);
}
```
[Bug c++/107279] __builtin_complex is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107279 --- Comment #1 from Andrew Pinski --- Link to the current documentation: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Complex.html#index-_005f_005fbuiltin_005fcomplex
[Bug c++/107279] __builtin_complex is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107279 --- Comment #2 from Andrew Pinski --- I don't care which way this gets fixed. That is the documentation could be changed or we support this in the C++ front-end.
[Bug tree-optimization/107206] Bogus -Wuninitialized in std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107206
--- Comment #6 from rguenther at suse dot de ---
> Am 14.10.2022 um 18:53 schrieb jamborm at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107206
>
> --- Comment #5 from Martin Jambor ---
> I believe this is fallout from the fix to PR 92706 where we started
> propagating accesses across assignments also from LHS to RHS and
> because everything is totally flow-insensitive, we have an access
> representing:
>
> MEM[(union _StorageD.10576 *)&D.11678]._M_valueD.10616 = 1;
>
> which gets propagated across:
>
> zD.11527.yD.11476.oD.11384 = D.11678;
>
> but this then triggers the LHS->RHS propagation across:
>
> MEM[(struct YD.10174 *)&zD.11527].oD.11384 = MEM[(const struct YD.10174
> &)&D.11546].oD.11384;
>
> So another reason to re-invent SRA from scratch.
Yes
> Apart from that, I
> don't have a good solution except for adding another flag to mark
> accesses that are result of LHS->RHS propagation and ignore them if
> their base did not get totally scalarized because in the PR they were
> added basically to prevent bad total scalarization. But of course it
> is rather another band-aid than a real fix, but it seems to work for
> this case:
>
> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
> index 1a3e12f18cc..6cbeddfc548 100644
> --- a/gcc/tree-sra.cc
> +++ b/gcc/tree-sra.cc
> @@ -260,6 +260,9 @@ struct access
>
> /* Should TREE_NO_WARNING of a replacement be set? */
> unsigned grp_no_warning : 1;
> +
> + /* Result of propagation accross link from LHS to RHS. */
> + unsigned grp_result_of_prop_from_lhs : 1;
> };
>
> typedef struct access *access_p;
> @@ -2532,6 +2535,9 @@ analyze_access_subtree (struct access *root, struct
> access *parent,
> if (allow_replacements && expr_with_var_bounded_array_refs_p (root->expr))
> allow_replacements = false;
>
> + if (!totally && root->grp_result_of_prop_from_lhs)
> +allow_replacements = false;
> +
> for (child = root->first_child; child; child = child->next_sibling)
> {
> hole |= covered_to < child->offset;
> @@ -2959,6 +2965,7 @@ propagate_subaccesses_from_lhs (struct access *lacc,
> struct access *racc)
> struct access *new_acc
>= create_artificial_child_access (racc, lchild, norm_offset,
> true, false);
> + new_acc->grp_result_of_prop_from_lhs = 1;
> propagate_subaccesses_from_lhs (lchild, new_acc);
>}
> else
LGTM
[Bug fortran/107272] ICE in gfc_compare_string and others (related to pr107217)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107272 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Last reconfirmed||2022-10-16 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Keywords||accepts-invalid, ||ice-on-invalid-code --- Comment #1 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058340.html
[Bug c++/107280] New: ICE: tree check: expected constructor, have view_convert_expr in cxx_eval_store_expression, at cp/constexpr.cc:5928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107280
Bug ID: 107280
Summary: ICE: tree check: expected constructor, have
view_convert_expr in cxx_eval_store_expression, at
cp/constexpr.cc:5928
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
Created attachment 53710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53710&action=edit
output from -freport-bug
Ran into this today, while trying to do some basic string manipulation:
$ cat ~/ice.cpp
struct string
{
char str[8] = " ";
const char* data() { return str; }
};
template
consteval string test()
{
string str { };
char* p = str.str;
auto append = [&p](const char* s)
{
while (*s != '\0') *p++ = *s++;
++p;
};
if (a) append("abc");
if (b) append("xyz");
return str;
}
auto f() { return test(); }
$ g++ -std=c++20 ~/ice.cpp
/home/jw/ice.cpp: In function 'auto f()':
/home/jw/ice.cpp:24:34: in 'constexpr' expansion of 'test()'
/home/jw/ice.cpp:19:16: in 'constexpr' expansion of 'append.test()::(((const char*)"abc"))'
/home/jw/ice.cpp:24:34: internal compiler error: tree check: expected
constructor, have view_convert_expr in cxx_eval_store_expres
sion, at cp/constexpr.cc:5928
24 | auto f() { return test(); }
| ~~~^~
...
[Bug target/101697] [11/12/13 regression] ICE compiling uClibc-ng for h8300-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697 --- Comment #6 from Jeffrey A. Law --- So this issue has come up again in the context of LRA conversion which happens to trip over the same bug, but with a different testcase. At the core of this problem is reload and LRA will both generate invalid RTL when performing register eliminations. Specifically, they will create an autoinc addressing mode where the incremented/decremented register is used elsewhere in the same insn as a source operand. Such RTL has been considered invalid as long as I can remember. The H8 backend does try to prevent this behavior by checking for this scenario and rejecting such insns in the insn condition. But in both the reload and LRA cases, they make substitutions in the original insn without validating the resulting insn (which would have failed). Even if they did try to validate the resulting insn, neither has a code generation strategy to deal with a failed substitution during register eliminations. Paul K. indicated how the pdp11 port handles these cases with constraints. Using constraints alone was insufficient to fix this problem, but using constraints in conjunction with the existing insn condition checks does seem to fix this problem. I'm currently upstreaming the various bits to make that happen.
[Bug c++/107281] New: comparisations with u/int64_t constants not generate vector-result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107281 Bug ID: 107281 Summary: comparisations with u/int64_t constants not generate vector-result Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: g.peterh...@t-online.de Target Milestone: --- If no 64-bit vector comparisons are available no vectorized results are produced for the cases <=, >=, <, and >. The cases == and != works. The comparisons themselves are then carried out individually, but the result is combined with unpcklqdq. It would be better if this works with all comparisons so that can better (auto)vectorized. It might be possible to further optimize this so that no scalar comparisons are necessary - especially for the frequent case constant=0. https://godbolt.org/z/cj8n9TenK thx Gero
[Bug target/107281] comparisations with u/int64_t constants not generate vector-result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107281 --- Comment #1 from Andrew Pinski --- Created attachment 53711 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53711&action=edit testcase
[Bug target/107281] comparisations with u/int64_t constants not generate vector-result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107281 --- Comment #2 from Uroš Bizjak --- Try to compile the testcase with -msse4.2.
[Bug c++/107282] New: ICE on valid code template + overloaded + visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107282 Bug ID: 107282 Summary: ICE on valid code template + overloaded + visit Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boris_oncev at hotmail dot com Target Milestone: --- ICE on >=C++17 on all supported versions https://godbolt.org/z/5exMcrhYz
[Bug c++/107283] New: conversions u/int64_t to float64/32_t are not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107283 Bug ID: 107283 Summary: conversions u/int64_t to float64/32_t are not vectorized Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: g.peterh...@t-online.de Target Milestone: --- The conversions u/int64_t to float64/32_t are not vectorisized if no HW-support (eg AVX512) available. But we can do that manually https://stackoverflow.com/questions/41144668/how-to-efficiently-perform-double-int64-conversions-with-sse-avx In the case u/int64_t -> float32_t i first convert to float64_t and then to float32_t. There might be a better way to implement this. With HW-support the standard implementation is of course faster. https://godbolt.org/z/WTa663PrK thx Gero
[Bug tree-optimization/107283] conversions u/int64_t to float64/32_t are not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107283 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement Component|c++ |tree-optimization --- Comment #1 from Andrew Pinski --- I suspect there is a dup of this bug already.
[Bug tree-optimization/107283] conversions u/int64_t to float64/32_t are not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107283 --- Comment #2 from g.peterh...@t-online.de --- That will be right. I had reported something similar many years ago - but it was not fixed. thx Gero
[Bug middle-end/107284] New: Option properties Mask infrastructure can be extended with wide_int_bitmask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107284 Bug ID: 107284 Summary: Option properties Mask infrastructure can be extended with wide_int_bitmask Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com Target Milestone: --- For x86, as more and more ISAs are introduced, we're almost running out of ix86_isa_flags2, a ix86_isa_flags3 needs to be introduced, that caused maintainance difficulty since there're depenedence between bits in different isa_flag(and several values used as same purpose for isa bit mask), it would be nice if we can introduce wide_int_bit_mask in the opth-gen.awk/opts-functions.awk ..etc, extend wide_int_bit_mask to 256 bits, and overload bit set/shift in wide_int_bitmask.h. So the backend can be released from maintain those "overloads" for mask bits.
[Bug tree-optimization/107273] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107273 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #4 from Hongtao.liu --- Looks like the same issue as PR107172 since below change can also pass all the testcase in the PR. diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md index 8e847520491..be815341af5 100644 --- a/gcc/config/i386/i386.md +++ b/gcc/config/i386/i386.md @@ -21335,7 +21335,7 @@ (define_insn "*x86_movcc_0_m1_neg" (define_expand "x86_movcc_0_m1_neg" [(parallel [(set (match_operand:SWI48 0 "register_operand") - (neg:SWI48 (ltu:SWI48 (reg:CCC FLAGS_REG) (const_int 0 + (neg:SWI48 (ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0 (clobber (reg:CC FLAGS_REG))])]) (define_split
[Bug tree-optimization/107269] wrong code at -O1 and above with "-fno-tree-ccp" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107269 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #3 from Hongtao.liu --- Looks like the same issue as PR107172 since below change can also pass all the testcase in the PR. diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md index 8e847520491..be815341af5 100644 --- a/gcc/config/i386/i386.md +++ b/gcc/config/i386/i386.md @@ -21335,7 +21335,7 @@ (define_insn "*x86_movcc_0_m1_neg" (define_expand "x86_movcc_0_m1_neg" [(parallel [(set (match_operand:SWI48 0 "register_operand") - (neg:SWI48 (ltu:SWI48 (reg:CCC FLAGS_REG) (const_int 0 + (neg:SWI48 (ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0 (clobber (reg:CC FLAGS_REG))])]) (define_split
[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #34 from Hongtao.liu --- There's 2 similar issues in PR107273 and PR107269.
[Bug testsuite/107240] [13 Regression] FAIL: gcc.dg/vect/vect-bitfield-write-2.c since r13-3219-g25413fdb2ac249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #6 from Kewen Lin ---
The reason why it fails on power7 is that power7 misses the vector/vector shift
support for V2DImode (type vector(2) long unsigned int), the support querying
is for the gimple statement:
patt_25 = 5 << 28;
It's expected since vsld is supported till ISA 2.07 (power8) (Note that we have
vslb/vslh/vslw since ISA 2.03).
But you might have noticed that both shifted value and shifting count are
constants for this particular test case, so it doesn't need the actual
vector/vector shift target support here. One tiny enhancement as below can make
us not need to special case this for Power port.
diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
index 0cc315d3126..01d043a3d18 100644
--- a/gcc/tree-vect-patterns.cc
+++ b/gcc/tree-vect-patterns.cc
@@ -2115,9 +2115,10 @@ vect_recog_bit_insert_pattern (vec_info *vinfo,
stmt_vec_info stmt_info,
tree shifted = value;
if (shift_n)
{
+ tree shifted_value = fold_build2 (LSHIFT_EXPR, container_type, value,
shift);
pattern_stmt
= gimple_build_assign (vect_recog_temp_ssa_var (container_type),
- LSHIFT_EXPR, value, shift);
+ shifted_value);
append_pattern_def_seq (vinfo, stmt_info, pattern_stmt);
shifted = gimple_get_lhs (pattern_stmt);
}
[Bug testsuite/107240] [13 Regression] FAIL: gcc.dg/vect/vect-bitfield-write-2.c since r13-3219-g25413fdb2ac249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #7 from Kewen Lin ---
Well, it does helps vect-bitfield-write-{2,3}.c, but it doesn't help
vect-bitfield-write-{2,3,4}.c since they do require vector/vector shift
supports.
I guess it might be a good idea to add the vect_long_long effective target
requirement for these relevant test cases. For now, I don't see we make it
effective for powerpc*-*-*, if no objections I'm going to test
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index fdd88e6a516..29d7b4ebd15 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -7059,7 +7059,9 @@ proc check_effective_target_vect_long_long { } {
|| ([istarget mips*-*-*]
&& [et-is-effective-target mips_msa])
|| ([istarget s390*-*-*]
- && [check_effective_target_s390_vx]) }}]
+ && [check_effective_target_s390_vx])
+ || ([istarget powerpc*-*-*]
+ && [check_effective_target_has_arch_pwr8]) }}]
}
Although it's not that accurate, as we can have V2DI vector load/store and some
operations like bitwise on power7, it's only for testing and the missing scope
is very limited.
[Bug c/107285] New: Incorrect code generation when we use __builtin_constant_p built-in function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107285
Bug ID: 107285
Summary: Incorrect code generation when we use
__builtin_constant_p built-in function.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alex.curiou at gmail dot com
Target Milestone: ---
All versions of GCC are affected (I've checked versions from 5 till 12.2).
The minimized example of code:
~~~
#define test(val1) \
__builtin_constant_p(val1) ? (val1 + 10) : (val1 * 20);
unsigned int bar(unsigned int value1) {
return test(value1);
}
int main(void) {
unsigned int a = bar(3);
return a;
}
~~~
The __builtin_constant_p considers the val1 value to be NOT known to be
constant at compile time. So the generated code is
val1 * 20
But optimizer considers that the value is WELL known and can WELL be
calculated.
So, the return value of func bar is calculated at compile time and the call to
the bar func is dropped away.
And the final return value is WRONG:
val1 + 10
As a result we have different return values with -O2 and -Og optimization
flags, 13 and 60 accordingly.
Here is the compiler output for version 12.2:
-O2 will return 13
https://godbolt.org/z/Y1Thdcfch
~~~
bar:
lea eax, [rdi+rdi*4]
sal eax, 2
ret
main:
mov eax, 13
ret
~~~
-Og will return 60
https://godbolt.org/z/sbcer78rP
~~~
bar:
lea eax, [rdi+rdi*4]
sal eax, 2
ret
main:
mov edi, 3
callbar
ret
~~~
