[Bug tree-optimization/111136] ICE in RISC-V test case since r14-3441-ga1558e9ad85693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
--- Comment #1 from JuzheZhong ---
Hi, Richi.
It faild at RISC-V scatter store cases:
When trying to generate gimple build:
...
.MASK_LEN_SCATTER_STORE (vectp_y.28_130, { 0, 2, 4, ... }, 1, vect__25.27_127,
mask__26.20_117, _135, 0);
...
ICE at:
/* Stores can't yet have gaps. */
gcc_assert (slp_node || vls_type == VLS_LOAD || gap == 0);
in vectorizable_store.
Since slp_node is null and vls_type == VLS_STORE and gap == 1
Then assertion failed.
I change it into:
gcc_assert (slp_node || vls_type == VLS_LOAD || vls_type == VLS_STORE
|| gap == 0);
It passed.
I am not sure it's the correct fix since I saw a comment here:
/* Stores can't yet have gaps. */
Means that we should not have scatter store here?
Re: Compiler bug with bitfields
On 2023-08-25 03:06, libreknight wrote:
> Greetings.
>
> I have come across erroneous behavior whilst comparing optimizations
> performed by different compilers. Said behavior persists through
> different versions of GCC and flags. The output from GCC is incorrect
> and diverges from all compilers.
>
> In order to reproduce aforementioned behavior, compile with any flags of
> your liking the following code:
>
> #include
> #include
>
> typedef struct
> {
> unsigned char value:1;
> } boolean;
>
> int
> main (void)
> {
> boolean var;
>
> var.value = 0;
>
> printf ("%d %d\n", --var.value, --var.value);
>
> return EXIT_SUCCESS;
> }
>
> The outcome disparates from the expected by producing the opposite
> result.
>
> GCC:
> 0 1
>
> clang, tcc, icc, icx, msvc, compcert:
> 1 0
>
> Inasmuch as the potential consequences of faulty logic allows for
> undefined behavior, security vulnerabilities emerges. Nevertheless,
> acknowledging the atypicality of causal application, I evaluate the
> significance of low-medium priority.
>
> Thanks in advance.
My apologies, further testing has confirmed this has nothing to do with
bitfields. I could replicate this experiment with "normal" variables and
the outcome from gcc compiled binaries still differs. From what it
seems, it is a already known undefined behavior practice
(https://stackoverflow.com/questions/4706404/post-pre-increments-in-printf).
Sorry for any inconvenience.
Re: Compiler bug with bitfields
On Thu, Aug 24, 2023 at 8:06 PM libreknight via Gcc-bugs
wrote:
>
> Greetings.
>
> I have come across erroneous behavior whilst comparing optimizations
> performed by different compilers. Said behavior persists through
> different versions of GCC and flags. The output from GCC is incorrect
> and diverges from all compilers.
>
> In order to reproduce aforementioned behavior, compile with any flags of
> your liking the following code:
>
> #include
> #include
>
> typedef struct
> {
> unsigned char value:1;
> } boolean;
>
> int
> main (void)
> {
> boolean var;
>
> var.value = 0;
>
> printf ("%d %d\n", --var.value, --var.value);
GCC does produce a warning:
: In function 'main':
:16:35: warning: operation on 'var.value' may be undefined
[-Wsequence-point]
16 | printf ("%d %d\n", --var.value, --var.value);
| ^~~
Anyways the order of evaluation is not specified in the C standard
when it comes to function arguments; left to right or right to left is
both valid.
Thanks,
Andrew Pinski
>
> return EXIT_SUCCESS;
> }
>
> The outcome disparates from the expected by producing the opposite
> result.
>
> GCC:
> 0 1
>
> clang, tcc, icc, icx, msvc, compcert:
> 1 0
>
> Inasmuch as the potential consequences of faulty logic allows for
> undefined behavior, security vulnerabilities emerges. Nevertheless,
> acknowledging the atypicality of causal application, I evaluate the
> significance of low-medium priority.
>
> Thanks in advance.
Compiler bug with bitfields
Greetings.
I have come across erroneous behavior whilst comparing optimizations
performed by different compilers. Said behavior persists through
different versions of GCC and flags. The output from GCC is incorrect
and diverges from all compilers.
In order to reproduce aforementioned behavior, compile with any flags of
your liking the following code:
#include
#include
typedef struct
{
unsigned char value:1;
} boolean;
int
main (void)
{
boolean var;
var.value = 0;
printf ("%d %d\n", --var.value, --var.value);
return EXIT_SUCCESS;
}
The outcome disparates from the expected by producing the opposite
result.
GCC:
0 1
clang, tcc, icc, icx, msvc, compcert:
1 0
Inasmuch as the potential consequences of faulty logic allows for
undefined behavior, security vulnerabilities emerges. Nevertheless,
acknowledging the atypicality of causal application, I evaluate the
significance of low-medium priority.
Thanks in advance.
[Bug middle-end/111149] bool0 != bool1 should be expanded as bool0 ^ bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |middle-end Summary|bool0 != bool1 should be|bool0 != bool1 should be |convert into bool0 ^ bool1 |expanded as bool0 ^ bool1 --- Comment #1 from Andrew Pinski --- So this is an expansion issue rather than a GIMPLE issue.
[Bug tree-optimization/111149] bool0 != bool1 should be convert into bool0 ^ bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-08-25
[Bug tree-optimization/111149] New: bool0 != bool1 should be convert into bool0 ^ bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49
Bug ID: 49
Summary: bool0 != bool1 should be convert into bool0 ^ bool1
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
_Bool k(_Bool a, _Bool b)
{
return a != b;
}
```
This should be changed into:
```
_Bool k0(_Bool a, _Bool b)
{
return a ^ b;
}
```
Note clange handles this.
The main problem with this is with respect to having it inside GIMPLE_COND ...
[Bug tree-optimization/111148] Missing boolean optimizations due to comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-25 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/111148] New: Missing boolean optimizations due to comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48
Bug ID: 48
Summary: Missing boolean optimizations due to comparisons
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
```
_Bool f(int a, int b)
{
_Bool X = a==1, Y = b == 2;
return (X & !Y) | (!X & Y); // X ^ Y
}
_Bool f0(int X, int Y)
{
_Bool a = X==1, b = Y == 2;
return (!a & b) ^ a; // a | b
}
_Bool f1(int a, int b)
{
_Bool x = a==1, y = b == 2;
return (!x & y) | !(x | y); // !x
}
_Bool f2(int a, int b)
{
_Bool x = a==1, y = b == 2;
return (x | y) ^ (x | !y); // !x
}
_Bool f3(int a, int b)
{
_Bool x = a==1, y = b == 2;
return (x | !y) & (!x | y); // (x==y) or x ^ y ^1
}
_Bool f4(int a, int b)
{
_Bool x = a==1, y = b == 2;
return (!x | y) ^ (x | !y); // x ^ y
}
_Bool f5(int a, int b)
{
_Bool X = a == b;
_Bool Y = !X;
return X == Y; // 0
}
_Bool f6(int a, int b)
{
_Bool X = a == b;
_Bool Y = !X;
return X != Y; // 1
}
```
These all patterns should move over to using bitwise_inverted_equal_p .
[Bug tree-optimization/111147] bitwise_inverted_equal_p can be used in the `(x | y) & (~x ^ y)` pattern to catch more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-25 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug tree-optimization/111147] New: bitwise_inverted_equal_p can be used in the `(x | y) & (~x ^ y)` pattern to catch more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47
Bug ID: 47
Summary: bitwise_inverted_equal_p can be used in the `(x | y) &
(~x ^ y)` pattern to catch more
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int g(int x, int y)
{
return (x | y) & (~x ^ y); // x & y
}
int g0(int x, int y)
{
return (~x | y) & (x ^ y); // ~x & y
}
```
g is correctly optimized to `x & y` but g0 is not optimized to `~x & y` even
though it could be.
If this pattern used bitwise_inverted_equal_p it could be.
Note this could also be used to catch comparisons too.
Filing this not to lose this idea.
[Bug tree-optimization/111146] Some patterns in match.pd are no longer needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-08-25
[Bug tree-optimization/111146] New: Some patterns in match.pd are no longer needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46
Bug ID: 46
Summary: Some patterns in match.pd are no longer needed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
The following patterns now are no longer needed:
```
/* (x | y) & ~x -> y & ~x */
/* (x & y) | ~x -> y | ~x */
(for bitop (bit_and bit_ior)
rbitop (bit_ior bit_and)
(simplify
(bitop:c (rbitop:c @0 @1) (bit_not@2 @0))
(bitop @1 @2)))
```
Because they are covered by:
```
/* (~x | y) & x -> x & y */
/* (~x & y) | x -> x | y */
(simplify
(bitop:c (rbitop:c @2 @1) @0)
(with { bool wascmp; }
(if (bitwise_inverted_equal_p (@0, @2, wascmp)
&& (!wascmp || element_precision (type) == 1))
(bitop @0 @1)
```
Just recording this so I can test and remove it soon.
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #10 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #9) > (In reply to Jan Hubicka from comment #8) > > patch posted > > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628231.html > > Yay! I stand ready to revert my ugly cover-up. > I'll even give the posted patch a spin for cris-elf! JFTR, as mentioned in a reply to the patch, unfortunately it regresses four tests: gcc.sum gcc.c-torture/execute/pr95731.c gcc.sum gcc.dg/pr46309-2.c gcc.sum gcc.dg/torture/pr63464.c gcc.sum gcc.dg/tree-ssa/pr95731.c
[Bug libfortran/109662] bad namelist input but gfortran accepted it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #22 from Jerry DeLisle --- Closing.
[Bug target/111127] [13/14 regression] Wrong code for avx512ne2ps2bf16_maskz intrinsics since gcc13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27 Hongyu Wang changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hongyu Wang --- Fixed on trunk and gcc13.
[Bug target/111127] [13/14 regression] Wrong code for avx512ne2ps2bf16_maskz intrinsics since gcc13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27 --- Comment #2 from CVS Commits --- The releases/gcc-13 branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:bb791011b39813bc7b6fdd0d9831247ace199615 commit r13-7758-gbb791011b39813bc7b6fdd0d9831247ace199615 Author: Hongyu Wang Date: Thu Aug 24 14:41:42 2023 +0800 Fix avx512ne2ps2bf16 wrong code [PR 27] Correct the parameter order for avx512ne2ps2bf16_maskz expander gcc/ChangeLog: PR target/27 * config/i386/sse.md (avx512f_cvtne2ps2bf16__maskz): Adjust paramter order. gcc/testsuite/ChangeLog: PR target/27 * gcc.target/i386/pr27.c: New test. (cherry picked from commit e62fe74e5af913079ba296c74759cd74c0759e8e)
[Bug target/111127] [13/14 regression] Wrong code for avx512ne2ps2bf16_maskz intrinsics since gcc13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27 --- Comment #1 from CVS Commits --- The master branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:e62fe74e5af913079ba296c74759cd74c0759e8e commit r14-3473-ge62fe74e5af913079ba296c74759cd74c0759e8e Author: Hongyu Wang Date: Thu Aug 24 14:41:42 2023 +0800 Fix avx512ne2ps2bf16 wrong code [PR 27] Correct the parameter order for avx512ne2ps2bf16_maskz expander gcc/ChangeLog: PR target/27 * config/i386/sse.md (avx512f_cvtne2ps2bf16__maskz): Adjust paramter order. gcc/testsuite/ChangeLog: PR target/27 * gcc.target/i386/pr27.c: New test.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #6 from Jerry DeLisle --- (In reply to john.harper from comment #5) Thanks John, I had a moment to look at this. I know where to do the implementation but I have not decided how yet.
[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19
--- Comment #3 from Hongtao.liu ---
> I see, we can add an alternative like "noavx2,avx2" to generate
> vmaskmovps/pd when avx2 is not available for integer.
It's better to change assmeble output as
27423 if (TARGET_AVX2)
27424return "vmaskmov\t{%1, %2, %0|%0, %2,
%1}";
27425 else
27426return "vmaskmov\t{%1, %2, %0|%0, %2, %1}";
No need to add alternative.
[Bug rtl-optimization/110823] [missed optimization] >50% speedup for x86-64 ASCII processing a la GNU diffutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110823 --- Comment #5 from Paul Eggert --- Also see bug 43 for a related performance issue, which is perhaps more important given the current state of bleeding-edge GNU diffutils.
[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #2 from Hongtao.liu --- (In reply to Richard Biener from comment #0) > We have > > (define_expand "maskload" > [(set (match_operand:V48_AVX2 0 "register_operand") > (unspec:V48_AVX2 > [(match_operand: 2 "register_operand") >(match_operand:V48_AVX2 1 "memory_operand")] > UNSPEC_MASKMOV))] > "TARGET_AVX") > > and > > (define_mode_iterator V48_AVX2 > [V4SF V2DF >V8SF V4DF >(V4SI "TARGET_AVX2") (V2DI "TARGET_AVX2") >(V8SI "TARGET_AVX2") (V4DI "TARGET_AVX2")]) > > so for example maskloadv4siv4si is disabled with just -mavx while the actual > instruction can operate just fine on SImode sized data by pretending its > SFmode. > > check_effective_target_vect_masked_load is conditional on AVX, not AVX2. > > With just AVX we can still use SSE2 vectorization for integer operations > using > masked loads/stores from AVX. I see, we can add an alternative like "noavx2,avx2" to generate vmaskmovps/pd when avx2 is not available for integer.
[Bug tree-optimization/80770] suboptimal code negating a 1-bit _Bool field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80770 --- Comment #3 from Andrew Pinski --- For aarch64 we get this from combine: ``` Trying 8, 10 -> 12: 8: r92:SI=r96:QI#0&0x1 10: r93:SI=r92:SI^0x1 REG_DEAD r92:SI 12: zero_extract(r99:QI#0,0x1,0)=r93:SI REG_DEAD r93:SI Failed to match this instruction: (set (zero_extract:SI (subreg:SI (reg:QI 99 [ s_4(D)->b1D.4388 ]) 0) (const_int 1 [0x1]) (const_int 0 [0])) (not:SI (subreg:SI (reg:QI 96 [ *s_4(D) ]) 0))) ``` But I don't understand why it does not try to see we could get this: (set (reg:SI 93) (not:SI (subreg:SI (reg:QI 96 [ *s_4(D) ]) 0))) (set (zero_extract:SI (subreg:SI (reg:QI 99 [ s_4(D)->b1D.4388 ]) 0) (const_int 1 [0x1]) (const_int 0 [0])) (reg:SI 93))
[Bug analyzer/111144] RFE: could -fanalyzer warn about assertions that have side effects?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105369 CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- see also (part of) bug 105369
[Bug c/105369] Improved diagnostics for code from statement expressions documentation [C component]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105369 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=6906 --- Comment #5 from Eric Gallager --- oh wait it looks like the "assertion with side effects" part is actually bug 6906; I'm keeping this bug open for the remaining parts, though
[Bug tree-optimization/106677] Abstraction overhead with std::views::join
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106677 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-24 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > On the trunk we now get: > _25 = SR.116_117 == 0; > _27 = (unsigned char) _25; > _32 = _27 | SR.116_117; > > Rather than: > _119 = MAX_EXPR <1, SR.115_117>; > > But we should instead just get: > SR.116_117 | 1 > > Though that should still be transformed into 1 (will fix that seperately). > > I have a quick patch which fixes that, we need to move `a ? zero_one_value : > zero_one_value` part of match.pd below the min/max detection. The two patches for that. https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628405.html https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628404.html I have not looked into the rest but otherwise confirmed.
[Bug analyzer/111144] RFE: could -fanalyzer warn about assertions that have side effects?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44 --- Comment #2 from David Malcolm --- See also bug 6906 and bug 57612
[Bug fortran/35095] DATA with implied-do: Improve bounds checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35095 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||anlauf at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2023-August/059711.html
[Bug libstdc++/111145] New: istream::operator>>(streambuf*) does not set gcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45
Bug ID: 45
Summary: istream::operator>>(streambuf*) does not set gcount
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at computerquip dot com
Target Milestone: ---
Example code: https://godbolt.org/z/cW9Pe1c85
```
#include
#include
int main()
{
std::ostringstream oss;
std::istringstream iss("test");
iss >> oss.rdbuf();
std::cout << "gcount is " << iss.gcount() << "\n";
}
```
Here I'm expecting `iss.gcount()` to return 4 as `iss >> oss.rdbuf();`, as far
as I can tell, fits under the conditions that should set the value accessed by
gcount().
As per the godbolt link, it instead returns 0.
[Bug bootstrap/111141] Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41
--- Comment #2 from Andrew Pinski ---
I think we should improve the toplevel configure to error out if including
errno.h fails.
So instead of:
```
echo "int main () { return 0; }" > conftest.c
```
We should do:
```
echo "#include " > conftest.c
echo "int main () { return 0; }" >> conftest.c
```
I don't have a way to test this but this should at least cause the failure to
happen earlier during configure rather than later on.
[Bug analyzer/111144] RFE: could -fanalyzer warn about assertions that have side effects?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44 --- Comment #1 from David Malcolm --- See e.g.: https://wiki.sei.cmu.edu/confluence/display/c/PRE31-C.+Avoid+side+effects+in+arguments+to+unsafe+macros https://stackoverflow.com/questions/10593492/catching-assert-with-side-effects cppcheck: https://cppcheck.sourceforge.io/devinfo/doxyoutput/checkassert_8cpp_source.html Java: https://wiki.sei.cmu.edu/confluence/display/java/EXP06-J.+Expressions+used+in+assertions+must+not+produce+side+effects https://pvs-studio.com/en/docs/warnings/v6055/
[Bug analyzer/111144] New: RFE: could -fanalyzer warn about assertions that have side effects?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44 Bug ID: 44 Summary: RFE: could -fanalyzer warn about assertions that have side effects? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- >From IRC: dmalcolm__: I wonder if there's any way that the analyzer could find suspicious asserts (asserts w/ side effects) We already have -Wanalyzer-tainted-assertion (as of gcc 13), which has some logic for identifying assertion-failure routines, and control flow leading to them, though the latter part is specific to taint-handling. Presumably we'd need to identify: (a) code that's executed as part of the conditional of an assertion (b) code that has a "side effect".
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #6 from Zebediah Figura --- (In reply to Zebediah Figura from comment #4) > (In reply to Andrew Pinski from comment #3) > > https://inbox.sourceware.org/gcc-patches/5969976.Bvae8NF9fS@polaris/ > > Again, I'm not sure what you're trying to communicate here. I'm aware that > -mstackrealign exists (and its attribute equivalent). We *do* use that in > Wine. Ah, I'm sorry, I think I see what you're trying to say—that it was an intentional choice to add -mstackrealign if -msse2 is used, so it's hard to call this a "bug" per se. (In reply to Richard Biener from comment #5) > I'd say that > > config/i386/cygming.h:#define STACK_REALIGN_DEFAULT TARGET_SSE > > is a non-working "fix". The appropriate default would be > -mincoming-stack-boundary=2. MIN_STACK_BOUNDARY should already be 4, so > that leaves PREFERRED_STACK_BOUNDARY_DEFAULT is the way to go here. I also > see > > /* It should be MIN_STACK_BOUNDARY. But we set it to 128 bits for >both 32bit and 64bit, to support codes that need 128 bit stack >alignment for SSE instructions, but can't realign the stack. */ > #define PREFERRED_STACK_BOUNDARY_DEFAULT \ > (TARGET_IAMCU ? MIN_STACK_BOUNDARY : 128) > > which suggests there might be problems with SSE anyway. > > So does the following work? But I would agree with this, yeah. If we're going to manually align for SSE then we should also manually align for types that need to be manually aligned. Which means that we should just have -mincoming-stack-boundary=2 everywhere. In theory that patch works, although I'll have to put together a gcc build to be sure. I do have one question, though... from reading the documentation, I have a hard time understanding the difference, or intended difference, between -mincoming-stack-boundary and -mpreferred-stack-boundary. Could you by chance try to clarify?
[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Uroš Bizjak --- Implemented for gcc-14.
[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866 --- Comment #9 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:6dd73f0f00f454a05552b008a1d56560bd3f1d4a commit r14-3471-g6dd73f0f00f454a05552b008a1d56560bd3f1d4a Author: Uros Bizjak Date: Thu Aug 24 22:23:52 2023 +0200 i386: Optimize pinsrq of 0 with index 1 into movq [PR94866] Add new pattern involving vec_merge RTX that is produced by combine from the combination of sse4_1_pinsrq and *movdi_internal: 7: r86:DI=0 8: r85:V2DI=vec_merge(vec_duplicate(r86:DI),r87:V2DI,0x2) REG_DEAD r87:V2DI REG_DEAD r86:DI Successfully matched this instruction: (set (reg:V2DI 85 [ a ]) (vec_merge:V2DI (reg:V2DI 87) (const_vector:V2DI [ (const_int 0 [0]) repeated x2 ]) (const_int 1 [0x1]))) PR target/94866 gcc/ChangeLog: * config/i386/sse.md (*sse2_movq128__1): New insn pattern. gcc/testsuite/ChangeLog: * g++.target/i386/pr94866.C: New test.
[Bug rtl-optimization/111143] [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #3 from Andrew Pinski ---
_22 = *iter_57;
if (_22 >= 0)
goto ; [90.00%]
else
goto ; [10.00%]
[local count: 860067200]:
_76 = (long long unsigned int) _22;
_15 = sum_31 + _76;
goto ; [100.00%]
...
[local count: 955630226]:
# prephitmp_42 = PHI <1(4), 1(5), len_29(6)>
# prephitmp_35 = PHI <_15(4), sum_31(5), _34(6)>
mbs ={v} {CLOBBER(eol)};
ch ={v} {CLOBBER(eol)};
iter_21 = iter_57 + prephitmp_42;
[Bug tree-optimization/111142] [14 regression] ICE in get_group_load_store_type, at tree-vect-stmts.cc:2121 (AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|tree-optimization Keywords||ice-on-valid-code Target Milestone|--- |14.0
[Bug bootstrap/111141] Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41 --- Comment #1 from Jonathan Wakely --- Looks like you don't have the 32-bit headers installed. See https://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h
[Bug c++/111140] wrong error message; not able deduct initializer list type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40 --- Comment #3 from Jonathan Wakely --- But I don't know why -fno-deduce-init-list only affects the diagnostic for one of the function templates.
[Bug rtl-optimization/111143] [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43 --- Comment #2 from Paul Eggert --- Created attachment 55790 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55790=edit asm code that's 38% faster on my platform
[Bug rtl-optimization/111143] [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43 --- Comment #1 from Paul Eggert --- Created attachment 55789 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55789=edit asm code generated by gcc -O2 -S
[Bug c++/111140] wrong error message; not able deduct initializer list type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40 --- Comment #2 from Jonathan Wakely --- I think r0-112851-g15694fdd6d84db changed the diagnostic by making -fno-deduce-init-list the default.
[Bug rtl-optimization/111143] New: [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43 Bug ID: 43 Summary: [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- Created attachment 55788 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55788=edit source code illustrating the performance problem This bug report may be related to bug 110823 (also found for diffutils) but the symptoms differ somewhat so I am reporting it separately. I observed it with GCC 13.1.1 20230614 (Red Hat 13.1.1-4) on x86-64. While tuning GNU diffutils I noticed that its loops to process mostly-ASCII text were not compiled well by GCC on x86-64. For a stripped-down example of the problem, compile the attached program with: gcc -O2 -S code-mcel.c The result is in the attached file code-mcel.s. Its loop kernel assuming ASCII text (starting on line 44) looks like this: .L6: movsbq (%rbx), %rax testb %al, %al js .L4 addq%rax, %r12 movl$1, %eax .L5: addq%rax, %rbx cmpq%r13, %rbx jb .L6 The "movl $1, %eax" immediately followed by "addq %rax, %rbx" is poorly scheduled; the resulting dependency makes the code run quite a bit slower than it should. Replacing it with "addq $1, %rbx" and readjusting the surrounding code accordingly, as is done in the attached file code-mcel-opt.s, causes the benchmark to run 38% faster on my laptop's Intel i5-1335U. It seems that code that GCC knows is unlikely (because of __builtin_expect) is causing the kernel, which GCC knows is likely, to be poorly optimized.
[Bug rtl-optimization/111142] [14 regression] ICE in get_group_load_store_type, at tree-vect-stmts.cc:2121 (AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42
--- Comment #1 from Manuel Lauss ---
This is fairly new, something after 4aa14ec7d5b25722e4d02c29c8c1e22dcc5a4915
("MATCH: [PR09] Fix bit_ior(cond,cond) when comparisons are fp") may have
caused this, since I was able to build mesa just 12 hours ago.
[Bug rtl-optimization/111142] New: [14 regression] ICE in get_group_load_store_type, at tree-vect-stmts.cc:2121 (AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42 Bug ID: 42 Summary: [14 regression] ICE in get_group_load_store_type, at tree-vect-stmts.cc:2121 (AVX512) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: manuel.lauss at googlemail dot com Target Milestone: --- Created attachment 55787 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55787=edit compressed unreduced testcase gcc version 14.0.0 20230824 (experimental) 721f7e2c4e5eed645593258624dd91e6c39f3bd2 g++ -m32 -O2 -march=znver4 -c gcc-14-mesa-aco-ice.ii during GIMPLE pass: vect ../mesa-/src/amd/compiler/aco_insert_waitcnt.cpp: In function 'void aco::insert_wait_states(Program*)': ../mesa-/src/amd/compiler/aco_insert_waitcnt.cpp:1042:1: internal compiler error: in get_group_load_store_type, at tree-vect-stmts.cc:2121 can only trigger with "-march=znver4", does not trigger with avx2 only or -O1 or lower. Fails with the same error for x64-64, but the testcase is preprocessed for 32bit targets. Thank you! Manuel
[Bug bootstrap/111141] New: Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41 Bug ID: 41 Summary: Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: etienne_lorrain at yahoo dot fr Target Milestone: --- On Ubuntu 22.04.3 LTS,Compiling gcc-13.2.0 by: wget https://ftp.gnu.org/gnu/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz tar xf gcc-13.2.0.tar.xz cd gcc-13.2.0/ ./contrib/download_prerequisites cd .. mkdir gcc_build cd gcc_build ../../gcc-13.2.0/configure --enable-languages=c,c++,fortran time make -j 32 Fails with: In file included from /usr/include/bits/errno.h:26, from /usr/include/errno.h:28, from ../../../../gcc-13.2.0/libgcc/../gcc/tsystem.h:93, from ../../../../gcc-13.2.0/libgcc/generic-morestack.c:32: /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory 1 | #include | ^ compilation terminated. make[5]: *** [../../../../gcc-13.2.0/libgcc/shared-object.mk:14: generic-morestack.o] Error 1 make[5]: Leaving directory '/home/etienne/aaa/gcc_build/x86_64-pc-linux-gnu/32/libgcc' make[4]: *** [Makefile:1214: multi-do] Error 1 make[4]: Leaving directory '/home/etienne/aaa/gcc_build/x86_64-pc-linux-gnu/libgcc' make[3]: *** [Makefile:127: all-multi] Error 2 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/home/etienne/aaa/gcc_build/x86_64-pc-linux-gnu/libgcc' make[2]: *** [Makefile:24671: all-stage1-target-libgcc] Error 2 make[2]: Leaving directory '/home/etienne/aaa/gcc_build' make[1]: *** [Makefile:30190: stage1-bubble] Error 2 make[1]: Leaving directory '/home/etienne/aaa/gcc_build' make: *** [Makefile:1088: all] Error 2 real1m7.737s user8m1.657s sys 1m2.220s Host compiler being: $ /usr/bin/gcc --version gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 We do have on host a file: /usr/include/asm-generic/errno.h At some point the "-generic" part was modified by default creating a link "asm -> asm-target", but I am not sure now that 64 bits compiler been able to compile 32 bits, the -generic has or not changed meaning... In short I am not sure that is a GCC bug or a Ubuntu bug...
[Bug c++/111132] [11/12/13/14 Regression] Function redeclaration in local scope breaks constant expression evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32 Patrick Palka changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Patrick Palka --- The error started with with r9-6136-g43574e4ff2afd4
[Bug c++/111140] wrong error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2023-08-24 00:00:00 |
--- Comment #1 from Andrew Pinski ---
Note you don't need to use C++20 features to get the bad error message.
Testcase:
```
#include
template
static void S__f (T...) { }
struct S
{
template
static void f (T ...) { }
};
int main ()
{
S__f (1, { });
S::f (1, { });
}
```
The error message changed between GCC 4.6 and GCC 4.7 though.
GCC 4.6 produced:
```
: In function 'int main()':
:13:15: error: no matching function for call to 'S__f(int,
)'
:13:15: note: candidate is:
:3:13: note: template void S__f(T ...)
:14:15: error: no matching function for call to 'S::f(int,
)'
:14:15: note: candidate is:
:8:15: note: template static void S::f(T ...)
```
While GCC 4.7 produces the error message we know today:
```
: In function 'int main()':
:13:15: error: too many arguments to function 'void S__f(T ...) [with T
= {}]'
:3:13: note: declared here
:14:15: error: no matching function for call to 'S::f(int,
)'
:14:15: note: candidate is:
:8:15: note: static void S::f(T ...) [with T = {}]
:8:15: note: candidate expects 0 arguments, 2 provided
```
[Bug c++/111140] wrong error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-24 Ever confirmed|0 |1
[Bug c++/111140] New: wrong error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
Bug ID: 40
Summary: wrong error message
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat test.cpp
static void S__f (auto ...) { }
struct S
{
static void f (auto ...) { }
};
int main ()
{
S__f (1, { });
S::f (1, { });
}
% g++ -std=c++20 test.cpp
test.cpp: In function 'int main()':
test.cpp:10:8: error: too many arguments to function 'void S__f(auto:1 ...)
[with auto:1 = {}]'
10 | S__f (1, { });
| ~^~~~
test.cpp:1:13: note: declared here
1 | static void S__f (auto ...) { }
| ^~~~
test.cpp:11:8: error: no matching function for call to 'S::f(int,
)'
11 | S::f (1, { });
| ~^~~~
test.cpp:5:15: note: candidate: 'static void S::f(auto:2 ...) [with auto:2 =
{}]'
5 | static void f (auto ...) { }
| ^
test.cpp:5:15: note: candidate expects 0 arguments, 2 provided
These error messages are just misleading. The functions accept any number of
arguments. The actual problem is that no type can be deduced for "{ }". (Of
course, it's easy to see here, but in more complex situations with multiple
overloads, it makes it really hard to understand what the problem is.)
Also strange: S__f and S::f are practically the same, yet the error message is
differently worded (though the meaning is very close).
[Bug c++/111132] [11/12/13/14 Regression] Function redeclaration in local scope breaks constant expression evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32 Andrew Pinski changed: What|Removed |Added Known to work||8.5.0 Known to fail||9.1.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||needs-bisection Summary|Function redeclaration in |[11/12/13/14 Regression] |local scope breaks constant |Function redeclaration in |expression evaluation |local scope breaks constant ||expression evaluation Last reconfirmed||2023-08-24 --- Comment #1 from Andrew Pinski --- Confirmed. This used to mostly worked in GCC 8.5.0 and before. In GCC 8.5.0 and before GCC would produce a bogus warning but the static_assert would worked. :7:20: warning: inline function 'constexpr bool bar()' used but never defined constexpr bool bar(void); ^~~
[Bug tree-optimization/111137] [11/12/13/14 Regression] Wrong code at -O2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail||11.1.0
Summary|[12/13/14 Regression] Wrong |[11/12/13/14 Regression]
|code at -O2/3 since |Wrong code at -O2/3
|r12-1000-g6924b5e6bd3 |
Known to work||10.5.0
Last reconfirmed||2023-08-24
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Reduced a little further:
```
int b[3][8];
short d;
volatile int t = 1;
int main() {
int g = t;
for (int e = 1; e >= 0; e--) {
d = 1;
for (; d >= 0; d--) {
b[0][d * 2 + 1] = 0;
b[g - 1 + d][0] ^= 1;
b[0][d * 2 + 2] = 0;
b[g - 1 + d][1] ^= 1;
}
}
if (b[0][1] != 1)
__builtin_abort();
}
```
Note this fails with GCC 11.1.0 with `-O2 -ftree-vectorize` but passes with
`-O3` .
[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #11 from Paul Thomas --- (In reply to G. Steinmetz from comment #5) > A simplification might be : > > > $ cat z1.f90 > program p >type t > integer, allocatable :: a >end type >type t2 > type(t) :: b >end type >type t3 > type(t2) :: c >end type > contains >function g(x) > class(t2) :: x > type(t) :: g(2) >end >function f(x) > class(t3) :: x > type(t) :: f(2) > f = g(x%c) >end > end > > > $ gfortran-10-20191215 -c z1.f90 > gimplification failed: >
[Bug target/111139] RISC-V: improve scalar constants cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-08-24 Ever confirmed|0 |1 CC||palmer at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from palmer at gcc dot gnu.org --- I think maybe Jeff said he was going to look at this? IMO even just a refactoring here would be great, like Vineet is pointing out it's become a bit of a mess. Also: Edwin is refactoring the rest of the types.
[Bug target/111139] New: RISC-V: improve scalar constants cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
Bug ID: 39
Summary: RISC-V: improve scalar constants cost model
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vineetg at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com, kito.cheng at gmail dot com,
palmer at dabbelt dot com
Target Milestone: ---
The current const cost determination in riscv_rtx_costs () and its children
such as riscv_const_insns () needs improvements.
1. There's some likely inaccuracies with various heuristics.
2. Those heuristics are distributed in a bunch of places and better be
consolidated.
3. We need to make const cost cpu/uarch tunable as hardware widgets like macro
fusions could ammortize multi-insn const costs.
Some of the heuristics to cleanup/revisit:
1a. riscv_rtx_cost() returns 1 insn even if riscv_const_insns () returns > 1.
case CONST:
if ((cost = riscv_const_insns (x)) > 0)
{
if (cost == 1 && outer_code == SET)
*total = COSTS_N_INSNS (1);
else if (outer_code == SET || GET_MODE (x) == VOIDmode)
*total = COSTS_N_INSNS (1);
}
1b. riscv_const_insns () caps the const cost to 4 even if it higher with intent
to force const pool. RV backend in general no longer favors const pools for
large constants since 2e886eef7f2b5a ("RISC-V: Produce better code with complex
constants [PR95632] [PR106602]"). This heuristic needs to be revisited.
1c. riscv_split_integer_cost () adds 2 to initial cost computed.
[Bug tree-optimization/111137] [12/13/14 Regression] Wrong code at -O2/3 since r12-1000-g6924b5e6bd3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37 Andrew Pinski changed: What|Removed |Added Summary|Wrong code at -O2/3 since |[12/13/14 Regression] Wrong |r12-1000-g6924b5e6bd3 |code at -O2/3 since ||r12-1000-g6924b5e6bd3 Target Milestone|--- |12.4 Component|c |tree-optimization
[Bug libstdc++/111138] New: views::zip_transform is underconstrained for empty range pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
Bug ID: 38
Summary: views::zip_transform is underconstrained for empty
range pack
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
int main() {
std::views::zip_transform(0); // hard error in libstdc++
}
https://godbolt.org/z/PYWovhdT4
[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 Manuel López-Ibáñez changed: What|Removed |Added Keywords||patch --- Comment #15 from Manuel López-Ibáñez --- (In reply to Peter Frost from comment #14) > FYI, this is the first time I've worked on the GCC codebase, so I have no > idea if this follow best practices etc. But it seems to work if anyone > wanted to try it out In a nutshell: 1. You need to add some tests that show everything works as expected. 2. You need to run the testsuite 3. You need to submit the patch to gcc-patches. More details: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
[Bug c/111137] New: Wrong code at -O2/3 since r12-1000-g6924b5e6bd3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
Bug ID: 37
Summary: Wrong code at -O2/3 since r12-1000-g6924b5e6bd3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
gcc at -O2/3 produces the wrong code.
Bisected to r12-1000-g6924b5e6bd3
Compiler explorer: https://godbolt.org/z/9fo5dxxhf
$ cat a.c
int printf(const char *, ...);
char a;
int b[3][8];
int c, e = 1, f, g;
short d;
int main() {
for (; e >= 0; e--) {
d = 1;
for (; d >= 0; d--) {
c = 0;
for (; c <= 1; c++) {
b[0][d * 2 + c + 1] = 0;
g = a <= '7';
b[g - 1 + d][c] ^= 1;
}
}
}
printf("%d\n", b[0][1]);
}
$
$ gcc -O0 a.c && ./a.out
1
$ gcc -O2 a.c && ./a.out
0
$
[Bug middle-end/110973] 9% 444.namd regression between g:c2a447d840476dbd (2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09 20:17)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110973 Martin Jambor changed: What|Removed |Added CC||fkastl at suse dot cz, ||jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor --- There was also a 7.7% regression on zen3 with generic march (these measurements are without LTO): https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=466.120.0
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25 --- Comment #8 from Thiago Jung Bauermann --- Confirmed. All the failures I reported are fixed in trunk. Thank you!
[Bug libstdc++/111129] std::regex incorrectly matches quantifiers with plus appended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29
Jonathan Wakely changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #2 from Jonathan Wakely ---
This changed with r0-127716-g053eb1f31ede72
* include/bits/regex_compiler.h (_Comipler<>::_M_quantifier()):
Fix parse error of multiple consecutive quantifiers like "a**".
* include/bits/regex_compiler.tcc (_Comipler<>::_M_quantifier()):
Likewise.
* testsuite/28_regex/basic_regex/multiple_quantifiers.cc: New.
That added the following tests:
regex re1("a++");
regex re2("(a+)+");
The second one is fine, but the first is invalid. The "a**" case mentioned in
the commit message is invalid too.
I don't know why Tim wanted to accept the first one. ECMAscript and POSIX don't
accept it. My GNU grep does, but I think that's just a bug in glibc's regcomp:
https://sourceware.org/bugzilla/show_bug.cgi?id=20095
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 --- Comment #9 from CVS Commits --- The master branch has been updated by Jose E. Marchesi : https://gcc.gnu.org/g:721f7e2c4e5eed645593258624dd91e6c39f3bd2 commit r14-3470-g721f7e2c4e5eed645593258624dd91e6c39f3bd2 Author: Jose E. Marchesi Date: Thu Aug 24 17:10:52 2023 +0200 Fix tests for PR 106537. This patch fixes the tests for PR 106537 (support for -W[no]-compare-distinct-pointer-types) which were expecting the warning when checking for equality/inequality of void pointers with non-function pointers. gcc/testsuite/ChangeLog: PR c/106537 * gcc.c-torture/compile/pr106537-1.c: Comparing void pointers to non-function pointers is legit. * gcc.c-torture/compile/pr106537-2.c: Likewise.
[Bug middle-end/111134] Sections for static data declared in functions with section attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34 --- Comment #2 from Manuel Hohmann --- (In reply to Andrew Pinski from comment #1) I see. I did not think about the possibility of inlining functions. Could you elaborate how this would affect the proposed goal? Naively I would assume that the code gets inlined, but would still reference the same variables / constants / string literals in their respective .data / .rodata sections, and so one could rename those sections nevertheless.
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #9 from Hans-Peter Nilsson --- (In reply to Jan Hubicka from comment #8) > patch posted > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628231.html Yay! I stand ready to revert my ugly cover-up. I'll even give the posted patch a spin for cris-elf!
[Bug tree-optimization/111136] New: ICE in RISC-V test case since r14-3441-ga1558e9ad85693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
Bug ID: 36
Summary: ICE in RISC-V test case since r14-3441-ga1558e9ad85693
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at gcc dot gnu.org
Target Milestone: ---
Target: riscv
The following RISC-V test case ICEs since r14-3441-ga1558e9ad85693
(mask_gather_load-11.c)
#define uint8_t unsigned char
void
foo (uint8_t *restrict y, uint8_t *restrict x,
uint8_t *index,
uint8_t *cond)
{
for (int i = 0; i < 100; ++i)
{
if (cond[i * 2])
y[i * 2] = x[index[i * 2]] + 1;
if (cond[i * 2 + 1])
y[i * 2 + 1] = x[index[i * 2 + 1]] + 2;
}
}
I compiled with
build/gcc/cc1 -march=rv64gcv -mabi=lp64 -O3
--param=riscv-autovec-preference=scalable mask_gather_load-11.c
mask_gather_load-11.c: In function 'foo':
mask_gather_load-11.c:9:1: internal compiler error: in
get_group_load_store_type, at tree-vect-stmts.cc:2121
9 | foo (uint8_t *restrict y, uint8_t *restrict x,
| ^~~
0x9e2fad get_group_load_store_type
../../gcc/tree-vect-stmts.cc:2121
0x9e2fad get_load_store_type
../../gcc/tree-vect-stmts.cc:2451
0x1ff7221 vectorizable_store
../../gcc/tree-vect-stmts.cc:8309
[...]
[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096 --- Comment #8 from Richard Earnshaw --- (In reply to Thomas Koenig from comment #7) > Would it make sense to document this somewhere? Or did I just miss it? :-) Possibly, but I've no idea where. It's too target-specific to put under the generic documentation for -fomit-frame-pointer and I don't think there's a section in the manual that really documents the target-specific behaviours of generic options.
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #11 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:bbdc0e0d0042ae16aa4d09ceb52c71e746d9139d commit r14-3469-gbbdc0e0d0042ae16aa4d09ceb52c71e746d9139d Author: David Malcolm Date: Thu Aug 24 10:24:40 2023 -0400 analyzer: implement kf_strcat [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * call-details.cc (call_details::check_for_null_terminated_string_arg): Split into overloads, one taking just an arg_idx, the other a new "include_terminator" param. * call-details.h: Likewise. * kf.cc (class kf_strcat): New. (kf_strcpy::impl_call_pre): Update for change to check_for_null_terminated_string_arg. (register_known_functions): Register kf_strcat. * region-model.cc (region_model::check_for_null_terminated_string_arg): Split into overloads, one taking just an arg_idx, the other a new "include_terminator" param. When returning an svalue, handle "include_terminator" being false by subtracting one. * region-model.h (region_model::check_for_null_terminated_string_arg): Split into overloads, one taking just an arg_idx, the other a new "include_terminator" param. gcc/ChangeLog: PR analyzer/105899 * doc/invoke.texi (Static Analyzer Options): Add "strcat" to the list of functions known to the analyzer. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/strcat-1.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #9 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:46cb27e56f36f23cb277f8a5beae05235af05768 commit r14-3467-g46cb27e56f36f23cb277f8a5beae05235af05768 Author: David Malcolm Date: Thu Aug 24 10:24:40 2023 -0400 analyzer: handle INIT_VAL(ELEMENT_REG(STRING_REG), CONSTANT_SVAL) [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model-manager.cc (region_model_manager::get_or_create_initial_value): Simplify INIT_VAL(ELEMENT_REG(STRING_REG), CONSTANT_SVAL) to CONSTANT_SVAL(STRING[N]). Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #10 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:2bad0eeb5573e52c4b7b51546ecffcb17f46eda3 commit r14-3468-g2bad0eeb5573e52c4b7b51546ecffcb17f46eda3 Author: David Malcolm Date: Thu Aug 24 10:24:40 2023 -0400 analyzer: handle strlen(BITS_WITHIN) [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model.cc (fragment::has_null_terminator): Handle SK_BITS_WITHIN. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #8 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:d99d73c77d1e9cca5938134b4e6e068945cf50b1 commit r14-3466-gd99d73c77d1e9cca5938134b4e6e068945cf50b1 Author: David Malcolm Date: Thu Aug 24 10:24:39 2023 -0400 analyzer: handle strlen(INIT_VAL(STRING_REG)) [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model.cc (fragment::has_null_terminator): Move STRING_CST handling to fragment::string_cst_has_null_terminator; also use it to handle INIT_VAL(STRING_REG). (fragment::string_cst_has_null_terminator): New, from above. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/strcpy-3.c (test_2): New. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #7 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:603bdf906af6d42ce0dabee86efc1e0aec0f1900 commit r14-3464-g603bdf906af6d42ce0dabee86efc1e0aec0f1900 Author: David Malcolm Date: Thu Aug 24 10:24:38 2023 -0400 analyzer: eliminate region_model::get_string_size [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model.cc (region_model::get_string_size): Delete both. * region-model.h (region_model::get_string_size): Delete both decls. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:0ae07a7203dd24f90e49d025046e61ef90a9fd18 commit r14-3463-g0ae07a7203dd24f90e49d025046e61ef90a9fd18 Author: David Malcolm Date: Thu Aug 24 10:24:38 2023 -0400 analyzer: reimplement kf_strcpy [PR105899] This patch reimplements the analyzer's implementation of strcpy using the region_model::scan_for_null_terminator infrastructure, so that e.g. it can complain about out-of-bounds reads/writes, unterminated strings, etc. gcc/analyzer/ChangeLog: PR analyzer/105899 * kf.cc (kf_strcpy::impl_call_pre): Reimplement using check_for_null_terminated_string_arg. * region-model.cc (region_model::get_store_bytes): Shortcut reading all of a string_region. (region_model::scan_for_null_terminator): Use get_store_value for the bytes rather than "unknown" when returning an unknown length. (region_model::write_bytes): New. * region-model.h (region_model::write_bytes): New decl. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/out-of-bounds-diagram-16.c: New test. * gcc.dg/analyzer/strcpy-1.c: Add test coverage. * gcc.dg/analyzer/strcpy-3.c: Likewise. * gcc.dg/analyzer/strcpy-4.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5ef89c5c2f52a2c47fd26845d1f73e20b9081fc9 commit r14-3462-g5ef89c5c2f52a2c47fd26845d1f73e20b9081fc9 Author: David Malcolm Date: Thu Aug 24 10:24:38 2023 -0400 analyzer: handle symbolic bindings in scan_for_null_terminator [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model.cc (iterable_cluster::iterable_cluster): Add symbolic binding keys to m_symbolic_bindings. (iterable_cluster::has_symbolic_bindings_p): New. (iterable_cluster::m_symbolic_bindings): New field. (region_model::scan_for_null_terminator): Treat clusters with symbolic bindings as having unknown strlen. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/sprintf-1.c: Include "analyzer-decls.h". (test_strlen_1): New. Signed-off-by: David Malcolm
[Bug libstdc++/88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- All done on trunk (but still considered experimental for now)
[Bug fortran/111135] New: Add ECF_MALLOC for BUILT_IN_GOMP_ALLOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35 Bug ID: 35 Summary: Add ECF_MALLOC for BUILT_IN_GOMP_ALLOC Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The Fortran side is all in gcc/fortran/f95-lang.cc It seems as if ECF_MALLOC should be added to ATTR_ALLOC_WARN_UNUSED_RESULT_SIZE_2_NOTHROW_LIST to match both builtin-attrs.def; that macro is used for: BUILT_IN_ALIGNED_ALLOC BUILT_IN_GOMP_ALLOC (I find the builtin-attrs.def file not very readable.) I do note that f95-lang.cc has: DECL_IS_MALLOC (builtin_decl_explicit (BUILT_IN_CALLOC)) = 1; while builtins.def uses ATTR_MALLOC_WARN_UNUSED_RESULT_SIZE_1_2_NOTHROW_LEAF_LIST for it. Thus, setting DECL_IS_MALLOC for GOMP_ALLOC explicitly would work as well (ALIGNED_ALLOC is not (yet) used in the Fortran FE.) BTW: The ECF_MALLOC causes DECL_IS_MALLOC to be set via tree.cc's set_call_expr_flags.
[Bug libstdc++/110339] Implement C++26 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 Bug 110339 depends on bug 110354, which changed state. Bug 110354 Summary: [C++26] P2587R3 to_string or not to_string https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110354 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/110354] [C++26] P2587R3 to_string or not to_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110354 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Implemented in r14-3299-gaeed687f4e08f1
[Bug libstdc++/110357] [C++26] P2592R3 Hashing support for std::chrono value classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110357 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-08-24 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug middle-end/111134] Sections for static data declared in functions with section attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- I doubt this will be implemented. The whole "data" associated with a function is not exactly true as these functions could be inlined somewhere else. So unless you have a checker (which the linux kernel kinda does but it has so many exceptions in its rules), you are not going to able to do what you want.
[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 Peter Frost changed: What|Removed |Added CC||mail at pfrost dot me --- Comment #14 from Peter Frost --- Created attachment 55786 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55786=edit Proposed patch I had a quick go at implementing this as I also wanted this warning. This implements a `-Wmissing-field-initializers=2` warning for uninitialized designated initializers FYI, this is the first time I've worked on the GCC codebase, so I have no idea if this follow best practices etc. But it seems to work if anyone wanted to try it out Thanks, Peter
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 Bug 44209 depends on bug 106537, which changed state. Bug 106537 Summary: GCC doesn't support -W[no-]compare-distinct-pointer-types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 Jose E. Marchesi changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Last reconfirmed||2023-08-24 Resolution|FIXED |--- --- Comment #8 from Jose E. Marchesi --- I am on it.
[Bug rtl-optimization/110034] The first popped allcono doesn't take precedence over later popped in ira coloring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034 --- Comment #4 from Vladimir Makarov --- Thank you for providing the test case. To be honest I don't see why assigning to hr3 to r134 is better. Currently we have the following assignments: hr9->r134; hr3->r173; hr3->r124 and the related preferences: cp11:a18(r134)<->a29(r173)@125:shuffle pref3:a29(r173)<-hr3@2000 pref4:a0(r124)<-hr3@125 This removes cost 2000 (pref3) and cost 125 (pref4) and adds cost 125 (cp11). The profit is 2000 If we started with r173, we would have the following assignments: hr3->r173; hr3->r134; ->r124 This would remove cost 2000 (pref3) and cost 125 (cp11) and add cost 125 (pref). The profit would be the same 2000. Choice of heuristics is very time consuming. I spent a lot of time to try and benchmark numerous ones. I clearly remember that introduction of pseudo threads for colorable busket gave visible performance improvement. Currently we assign pseudos from a thread with the biggest frequency first (r173 and r134) and a pseudo (r134) with the biggest frequency first from the same thread. I think it is logical. Also it is always possible to find a test (not this case) where heuristics give some undesirable results. RA is NP-complete task even in the simplest formulation. We can not get the optimal solution for reasonable time. Still I am open to change any heuristic if somebody can show that it improves performance for some credible benchmark (I prefer SPEC2007) on major GCC targets.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #7 from David Edelsohn --- The new testcases in the testsuite for this PR are failing. Is anyone working on these new failures? Is this being tracked in this PR or a new PR for the failures?
[Bug middle-end/111134] New: Sections for static data declared in functions with section attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34
Bug ID: 34
Summary: Sections for static data declared in functions with
section attribute
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: manuelhohmann at online dot de
Target Milestone: ---
Using the section attribute, functions can be placed in specific sections.
However, this only places the code in the named section. However, static
variables, static constants and string literals are not affected by this.
Example:
void __attribute__ ((section ".my.text")) testfunc(void)
{
static char data[] = {0, 1, 2, 3};
static const char rodata[] = {4, 5, 6, 7};
puts("test");
}
This will place data in .data, rodata in .rodata and "test" in .rodata.strM.N
(where M and N is related to alignment). The function code itself is in
.my.text.
For the two arrays, one can change the section:
void __attribute__ ((section ".my.text")) testfunc(void)
{
static char __attribute__ ((section ".my.data")) data[] = {0, 1, 2, 3};
static const char __attribute__ ((section ".my.rodata")) rodata[] = {4, 5,
6, 7};
puts("test");
}
This will place them in .my.data and .my.rodata, respectively. However, there
does not seem to be a possibility to do this with string literals. One could
define them as constant char arrays as a workaround. Also there does not seem
to be a possibility to change the section of all static data items in a
function at once.
Would it be possible to allow such functionality e.g. by introducing function
attributes such as
data_section
rodata_section
string_section
which change the names of the sections, but otherwise retain their attributes
(such as mergeable, string for the string literals)? Or / and e.g. a function
attribute along the lines of
__attribute__ ((section_prefix ".my"))
that will prefix all section names (.text, .data, .rodata, .rodata.strM.N) with
the given string for the function and its associated data?
---
Rationale / example use: For certain environments, such as embedded code or
operating system kernels, a boot loader will load a single executable into
memory, containing both initialization and permanent code. Placing
initialization code into a separate section allows to free the occupied memory
once initialization is completed and the code is no longer used. It would be
helpful if along with a function's code also all of its associated data could
be assigned a custom section.
[Bug c/111130] ice & tree check fail in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- duplicate of PR28?
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #6 from Richard Biener --- middle-end part are fixed, so with optimization we should diagnose this more consistently now. Leaving open for -O0 and the C++ FE issue.
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:abf915193fbf725bb359e6936e10dcc282eb94cc commit r14-3460-gabf915193fbf725bb359e6936e10dcc282eb94cc Author: Richard Biener Date: Thu Aug 24 09:32:54 2023 +0200 tree-optimization/23 - indirect clobbers thrown away too early The testcase in the PR shows that late uninit diagnostic relies on indirect clobbers in CTORs but we throw those away in the fab pass which is too early. The reasoning was they were supposed to keep SSA names live but that's no longer the case since DCE doesn't treat them as keeping SSA uses live. The following instead removes them before out-of-SSA coalescing which is the thing that's still affected by them. PR tree-optimization/23 * tree-ssa-ccp.cc (pass_fold_builtins::execute): Do not remove indirect clobbers here ... * tree-outof-ssa.cc (rewrite_out_of_ssa): ... but here. (remove_indirect_clobbers): New function. * g++.dg/warn/Wuninitialized-pr23-1.C: New testcase.
[Bug tree-optimization/111133] New: SLP of scatters not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33
Bug ID: 33
Summary: SLP of scatters not implemented
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
There is no scatter support for (single-lane) SLP. For example
#define N 16
void __attribute__((noipa))
f (float *restrict y, float *restrict x, int *restrict indices)
{
for (int i = 0; i < N; ++i)
{
x[indices[i * 2]] = y[i * 2] + 1;
x[indices[i * 2 + 1]] = y[i * 2 + 1] + 2;
}
}
doesn't vectorize. Note this is also due to
t.c:6:21: note: === vect_analyze_data_ref_dependences ===
t.c:8:25: missed: possible alias involving gather/scatter between *_10 and
*_20
t.c:6:21: missed: bad data dependence.
but with SLP scatters guarantee left-to-right commit so that shouldn't
be an issue there and also shows why SLP is even required for this
to vectorize.
[Bug target/97807] ICE in output_move_double, at config/arm/arm.c:19689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97807 --- Comment #4 from Richard Earnshaw --- I can reproduce this, but only with -mfloat-abi=soft.
[Bug c++/111132] New: Function redeclaration in local scope breaks constant expression evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32
Bug ID: 32
Summary: Function redeclaration in local scope breaks constant
expression evaluation
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program
constexpr bool bar(void) {
return true;
}
constexpr bool foo() {
constexpr bool bar(void);
return bar();
}
static_assert( foo() );
is accepted in Clang, but not in GCC, which prints
error: non-constant condition for static assertion
10 | static_assert( foo() );
|~~~^~
:10:19: in 'constexpr' expansion of 'foo()'
:7:15: error: 'constexpr bool bar()' used before its definition
7 | return bar();
|~~~^~
Online demo: https://godbolt.org/z/3PvoEx61x
[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19 --- Comment #1 from Richard Biener --- See https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577577.html for the attempt to move x86 to the internal-fn representation
[Bug libstdc++/111102] illegal pointer arithmetic invoked by std::format("L{:65536}",1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=02 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7564fe98657ad5ede34bd08f5279778fa8698865 commit r14-3458-g7564fe98657ad5ede34bd08f5279778fa8698865 Author: Paul Dreik Date: Thu Aug 24 11:43:43 2023 +0100 libstdc++: Add test for illegal pointer arithmetic in format [PR02] libstdc++-v3/ChangeLog: PR libstdc++/02 * testsuite/std/format/string.cc: Check wide character format strings with out-of-range widths.
[Bug libstdc++/111102] illegal pointer arithmetic invoked by std::format("L{:65536}",1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=02 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:dd4bdb9eea436bf06f175d8dbfc2190377455be4 commit r14-3457-gdd4bdb9eea436bf06f175d8dbfc2190377455be4 Author: Paul Dreik Date: Thu Aug 24 11:43:43 2023 +0100 libstdc++: fix illegal pointer arithmetic in format [PR02] When parsing a format string, the width is parsed into an unsigned short but the result is not checked in the case the format string is not a char string (such as a wide string). In case the parse fails, a null pointer is returned which is used for pointer arithmetic which is undefined behaviour. Signed-off-by: Paul Dreik libstdc++-v3/ChangeLog: PR libstdc++/02 * include/std/format (__format::__parse_integer): Check for non-null pointer.
[Bug libstdc++/110944] std::variant & optional GDB representation is too verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110944 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed on trunk, thanks for the suggestion.
[Bug libstdc++/110944] std::variant & optional GDB representation is too verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110944 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:701ce3c723623af13597c05df09a049c57c52fc0 commit r14-3451-g701ce3c723623af13597c05df09a049c57c52fc0 Author: Jonathan Wakely Date: Tue Aug 22 14:26:51 2023 +0100 libstdc++: Declutter std::optional and std:variant pretty printers [PR110944] As the PR says, including the template arguments in the GDB output of these class templates can result in very long names, especially for std::variant. You can use 'whatis' or other GDB commands to get details of the type, we don't need to include it in the value. We could consider including the type if it's not too long, but I think consistency is better (and we already omit the template arguments for std::vector and other class templates). libstdc++-v3/ChangeLog: PR libstdc++/110944 * python/libstdcxx/v6/printers.py (StdExpOptionalPrinter): Do not show template arguments. (StdVariantPrinter): Likewise. * testsuite/libstdc++-prettyprinters/compat.cc: Adjust expected output. * testsuite/libstdc++-prettyprinters/cxx17.cc: Likewise. * testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
[Bug tree-optimization/111131] New: SLP of gathers incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31 Bug ID: 31 Summary: SLP of gathers incomplete Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- SLP of gathers relies on vect_recog_gather_scatter_pattern but for example x86 still uses the decl based target hook. There's also open-coded gather/scatter support which isn't handled by SLP either. The "correct" way is probably to use vect_check_gather_scatter at SLP build time. This can for example be seen when trying to vectorize gcc.dg/vect/tsvc/vect-tsvc-vag.c with single-lane SLP, but gcc.dg/vect/vect-gather-*.c also FAIL without vect_gather_load_ifn.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #8 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #6) > (In reply to Jonathan Wakely from comment #5) > > I agree with your WIP patch. The requirements for data() and size() to be > > constant expressions are in p11 (11.2) which only apply if the static > > assertions fails. > > In other words, I think the paper is clear and clang is wrong here. > > Although arguably what clang does is more useful. I'm not sure why you'd > want to use a non-constexpr size() or data() that only compiles as long as > the static assertion passes. It means you won't find out that your > user-generated message can't actually be printed until you run on a target > where the assertion fails. Sure, if the standard is changed such that size() and data() must be constexpr, it would be nice to check it. Without full evaluation one can't guarantee it will be a constant expression and there could be tons of other reasons why it isn't constant expression (say it returns some class and conversion operator isn't constexpr, or it throws, or has asm and many other reasons). For the M.data () not being a constant expression, it depends on the exact wording as well. Either the standard could drop the requirement that it is a core constant expression altogether, then e.g. nothing will require that (M.data (), 0) is constant expression when M.size () is 0. Or it could say that (M.data (), 0) is an integer constant expression, then one can verify that, and then quietly try if M.data () is a constant expression; if it is, it can grab the message from it using say GCC's c_getstr if it works. If it isn't, it would need to evaluate it character by character. BTW, there is a third difference between my latest patch and clang++ implementation. They reject static_assert (false, "foo"_myd); which I have in the testcase. IMHO "foo"_myd doesn't match the syntactic requirements of unevaluated-string as the https://eel.is/c++draft/dcl.pre#10 wording says, because unevaluated-string non-terminal is string-literal with some extra rules, while user-defined-literal is some other non-terminal. And as I've tried to show in the testcase, a constexpr operator "" can return something on which .size () / .data () can be called and can satisfy the requirements.
[Bug libstdc++/111129] std::regex incorrectly matches quantifiers with plus appended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-24 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. There is no such extension in libstdc++, this is just a bug.
