[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 #5 from john.harper at vuw dot ac.nz --- True. I reported the bug because in ESw.dEe output format all 3 of w,d,e may be 0, but gfortran then gave the right numerical result in the wrong format with my test programs. (I'm told NAG hasn't yet implemented ES0.0E0 but ifort has got it right.) On Wed, 16 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Wed, 16 Aug 2023 03:39:58 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Wed, 16 Aug 2023 15:40:09 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #4 from Jerry DeLisle --- > The relative text in the standard is: > > 13.7.2.1 General rules > --- snip --- > (6) On output, with I, B, O, Z, D, E, EN, ES, EX, F, and G editing, the > specified value of the field width w may be zero. In such cases, the processor > selects the smallest positive actual field width that does not result in a > field filled with asterisks. The specified value of w shall not be zero on > input. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug tree-optimization/95906] Failure to recognize max pattern with mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > cmp_8 = -_2; > _3 = cmp_8 & a_6(D); > We convert that into: > _2 * a_6(D); > > And then have: > _11 = _2 + -1; > _5 = b_7(D) & _11; > > This could be convert into: > (_11 ^ 1) * b_7(D) Sorry `(_2 ^ 1) * b_7(D)` (the patch was ok).
[Bug tree-optimization/95906] Failure to recognize max pattern with mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
--- Comment #8 from Andrew Pinski ---
cmp_8 = -_2;
_3 = cmp_8 & a_6(D);
We convert that into:
_2 * a_6(D);
And then have:
_11 = _2 + -1;
_5 = b_7(D) & _11;
This could be convert into:
(_11 ^ 1) * b_7(D)
```
(simplify
(bit_and:c (convert? (plus zero_one_valued_p@0 integer_all_onesp)) @1)
(if (INTEGRAL_TYPE_P (type)
&& INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& TREE_CODE (TREE_TYPE (@0)) != BOOLEAN_TYPE
/* Sign extending of the neg or a truncation of the neg
is needed. */
&& (!TYPE_UNSIGNED (TREE_TYPE (@0))
|| TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@0
(mult (convert (bit_xor @0 { build_one_cst (TREE_TYPE (@0)); })) @1))
```
[Bug tree-optimization/111110] (A CMP B) != 0 and (A CMP B) == true patterns produce an extra (A CMP B) rather than reusing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-08-23 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Mine. Will test it in the next few days. I had noticed some extra comparison expressions being made and I wonder if this was the cause ...
[Bug tree-optimization/111110] New: (A CMP B) != 0 and (A CMP B) == true patterns produce an extra (A CMP B) rather than reusing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 Bug ID: 10 Summary: (A CMP B) != 0 and (A CMP B) == true patterns produce an extra (A CMP B) rather than reusing it 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: --- (simplify (ne (cmp@2 @0 @1) integer_zerop) (if (types_match (type, TREE_TYPE (@2))) (cmp @0 @1))) (simplify (eq (cmp@2 @0 @1) integer_truep) (if (types_match (type, TREE_TYPE (@2))) (cmp @0 @1))) Those (cmp @0 @1) results really should just be @2
[Bug tree-optimization/111109] [13/14 Regression] wrong code for some fp comparisons (after r13-4620-g4d9db4bdd458)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=09 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-08-23 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- The fix is to add: if (invert_tree_comparison (cmp, HONOR_NANS (@01)) == icmp) for each of those patterns there. I guess I will do that.
[Bug tree-optimization/111109] [13/14 Regression] wrong code for some fp comparisons (after r13-4620-g4d9db4bdd458)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=09 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3
[Bug tree-optimization/111109] New: [13/14 Regression] wrong code for some fp comparisons (after r13-4620-g4d9db4bdd458)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=09
Bug ID: 09
Summary: [13/14 Regression] wrong code for some fp comparisons
(after r13-4620-g4d9db4bdd458)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
[[gnu::noipa]]
int f(int a, int b, float fa, float fb) {
const bool c = fa < fb;
const bool c1 = fa >= fb;
return (c * a) | (c1 * b);
}
int main(void)
{
float a = __builtin_nan("");
float b = __builtin_nan("");
if (f(-1,-1, a, b) != 0)
__builtin_abort();
}
```
This works at -O0 but fails at -O2.
The reasoning is that after r13-4620-g4d9db4bdd458 we think > and <= are
inverses of each other but they are not.
[Bug tree-optimization/103660] Sub-optimal code with relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103660 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Note I think the patterns added in that revision were incorrect: > + (cond (cmp@0 @01 @02) @3 zerop) > + (cond (icmp@4 @01 @02) @5 zerop)) > > allows for @1 and @2 (which by the way 01 and 02 is; just using base 8 > rather than base 10). for floating point and guess what !(a < b) for floating point is not the same as (a >= b). I will file a bug about that ...
[Bug tree-optimization/103660] Sub-optimal code with relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103660
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Actually:
> ```
> (for (op plus bit_ior bit_xor)
> (simplify
> (op (cond @0 @1 integer_zero_p)
> (cond @2 @3 integer_zero_p))
> (with { bool wascmp; }
>(if (bitwise_inverted_equal_p (@0, @2, wascmp))
> (cond @0 @1 @3)
>)
> )
> )
> )
> ```
> Should fix this.
>
> Well that replaces the pattern that was added in r13-4620-g4d9db4bdd458 and
> extends it to for plus and bit_xor.
Note I think the patterns added in that revision were incorrect:
+ (cond (cmp@0 @01 @02) @3 zerop)
+ (cond (icmp@4 @01 @02) @5 zerop))
allows for @1 and @2 (which by the way 01 and 02 is; just using base 8 rather
than base 10).
[Bug tree-optimization/103660] Sub-optimal code with relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103660
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #2 from Andrew Pinski ---
Actually:
```
(for (op plus bit_ior bit_xor)
(simplify
(op (cond @0 @1 integer_zero_p)
(cond @2 @3 integer_zero_p))
(with { bool wascmp; }
(if (bitwise_inverted_equal_p (@0, @2, wascmp))
(cond @0 @1 @3)
)
)
)
)
```
Should fix this.
Well that replaces the pattern that was added in r13-4620-g4d9db4bdd458 and
extends it to for plus and bit_xor.
[Bug tree-optimization/103536] Suboptimal codegen for && and || combination.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103536
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #3 from Andrew Pinski ---
After r14-1597-g64d90d06d2db , we are just missing:
```
int
src_int (int a, int b)
{
return (a | b) & (a & b);
}
```
into:
```
int
src_int_ (int a, int b)
{
return (a & b);
}
```
Which is detected at the RTL level though.
This is
So mine:
```
(for bitop (bit_and bit_ior)
rbitop (bit_ior bit_and)
/* (x | y) & (x & z) -> (x & z) */
/* (x & y) | (x | z) -> (x | z) */
(simplify
(bitop:c (rbitop:c @0 @1) (bitop:c@3 @0 @2))
@3)
```
[Bug tree-optimization/95906] Failure to recognize max pattern with mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906 Bug 95906 depends on bug 54525, which changed state. Bug 54525 Summary: Recognize (vec_)cond_expr in mask operation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54525 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/54525] Recognize (vec_)cond_expr in mask operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54525 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #4 from Andrew Pinski --- We do recognize f now on the trunk after r14-1654-g7ceed7e3e29c . _9 = (unsigned int) b_2(D); # RANGE [irange] unsigned int [0, 0][+INF, +INF] _10 = -_9; _4 = x_5(D) ^ y_6(D); _3 = _10 & _4; _7 = _3 ^ y_6(D); After that patch _3 is able to convert to: _3 = _4 * _9; And we recongize that _7 to be: gimple_simplified to _7 = b_2(D) ? x_5(D) : y_6(D); Because match has a pattern for `A ^ (A^B)*cmp into cmp ? B : A` (since r13-793-g8fb94fc6097c ).
[Bug tree-optimization/95906] Failure to recognize max pattern with mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906 Andrew Pinski changed: What|Removed |Added Depends on||110949 --- Comment #7 from Andrew Pinski --- _1 = a_5(D) > b_6(D); _2 = (int) _1; _11 = a_5(D) > b_6(D); _3 = _11 ? a_5(D) : 0; _9 = _2 + -1; If we convert _9 to be: _t = a_5(D) <= b_6(D) _9 = - _t Then we would handle it like mentioned in comment #6. So that is PR 110949 . Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110949 [Bug 110949] ((cast)cmp) - 1 should be tranformed into -(cast)cmp` where cmp` is the inverse of cmp
[Bug tree-optimization/95408] Failure to optimize bitwise and with negated conditional using the same operand to conditional with decremented operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95408 --- Comment #2 from Andrew Pinski --- In forwprop1 we have: _2 = x.0_1 <= 121210; _3 = (int) _2; _4 = _3 * x_5(D); _6 = _4 != 0; since _3 is zero_one_valued we could do instead: ``` (for cmp (ne eq ) bitop (bit_and bit_ior) (simplify (cmp (mult zero_one_valued_p@0 @1) integer_zerop@2) (bitop! (convert @0) (ne @1 @2 ``` And we should be able to get it earlier on. Still mine and I will look into the above.
[Bug tree-optimization/95034] Failure to convert xor pattern (made out of or+and) to xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95034
--- Comment #6 from Andrew Pinski ---
So after phiopt2 we end up with:
```
_1 = a_3(D) | b_4(D);
if (_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
_5 = a_3(D) & b_4(D);
_7 = ~_5;
[local count: 1073741824]:
# iftmp.0_2 = PHI <_7(3), 0(2)>
```
Phi-opt does not support more than one statement inside the middle BB so it
does nothing here.
But if we rewrite it such that the 2 statements were not inside the middle BB
by phiopt2, we get the xor as expected.
That is:
```
bool f(bool a, bool b)
{
bool c = a | b;
bool d = a & b;
d = !d;
return c ? d : false;
}
```
Will produce:
```
_8 = a_3(D) ^ b_4(D);
return _8;
```
>From the phiopt2 dump:
```
Folded into the sequence:
_8 = a_3(D) ^ b_4(D);
```
I wonder if we could support more than 1 statement in the middle BBs iff the
resulting simplifications only reference one SSA_NAME of the statements max ...
[Bug tree-optimization/71336] Suboptimal code generated for "(a & 1) ? (CST1 + CST2) : CST1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71336 --- Comment #11 from Andrew Pinski --- (In reply to Andrew Pinski from comment #10) > So it should be possible to extend the match pattern for what was the > two_value_replacement replacement to do this too. > The main thing is instead of difference by 1, the difference of the two > constants should be a power of 2. > We could also extend it such that the (a !=/== CST) part where a has only > one non-zero bit in addition to a having a range over two values. > > That would be better than what I was proposing in comment #6. Actually we already have a pattern for: (zero_one == 0) ? y : z y (zero_one != 0) ? z y : y Just in this case y and z are constant. And the mention of one bit set for a in `a != 0` has been mentioned in one places too ...
[Bug tree-optimization/101650] (len | N) == len is transformed to len & N != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101650
--- Comment #2 from Andrew Pinski ---
So the pattern which we have currently matching (X | Y) == Y does this:
/* (X | Y) == Y becomes (X & ~Y) == 0. */
(simplify
(cmp:c (bit_ior:c @0 @1) @1)
(cmp (bit_and @0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0)); }))
So adding:
/* (Y | CST) == Y becomes (Y & CST) != 0. */
(simplify
(cmp:c (bit_ior @1 INTEGER_CST@0) @1)
(icmp (bit_and @1 @0) { build_zero_cst (TREE_TYPE (@0)); }))
Is needed.
[Bug tree-optimization/111108] New: (a|c) == (a|c) should be convert into (a&~c) == (a&~c) IFF ~c simplifies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=08
Bug ID: 08
Summary: (a|c) == (a|c) should be convert into (a&~c) ==
(a&~c) IFF ~c simplifies
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:
```
#define C 0x1
unsigned g(unsigned X, unsigned Y)
{
return (X | C) == (Y | C);
}
unsigned g1(unsigned X, unsigned Y)
{
return (X & ~C) == (Y & ~C);
}
unsigned g2(unsigned X, unsigned Y)
{
return ((X | C) & ~C) == ((Y | C) & ~C);
}
```
These all functions are the same as (X|C) == (Y|C) is saying the only bits of X
and Y which you want to compare is ~C.
Note I suspect we could also do this for non-constant C but that would normally
produce worse code but maybe we could see if both X & ~C and Y & ~C simplifies
(due to non-zero bits ...).
[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #3 from Hongtao.liu --- in x86 backend expand_vec_perm_1, we always tries vec_merge frist for !one_operand_p, expand_vselect_vconcat is only tried when vec_merge failed which means we'd better to use vec_merge instead of vec_select:vec_concat when available in out backend pattern match. Also for the view of avx512 kmask instructions, use vec_merge will help constant propagation. 20107 /* Try the SSE4.1 blend variable merge instructions. */ 20108 if (expand_vec_perm_blend (d)) 20109return true; 20110 20111 /* Try movss/movsd instructions. */ 20112 if (expand_vec_perm_movs (d)) 20113return true;
[Bug tree-optimization/94884] Failure to recognize that result of or is always superior to operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94884 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Andrew Pinski --- Mine.
[Bug tree-optimization/101590] (len & - N) <= len is not optimized to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101590
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> U | N < U -> false
> U & N <= U -> true
> U & N > U -> false
> U | N >= U -> true
>
> >I don't see an easy way to combine these two patterns though.
> I totally missed that the for loop is a pair for.
>
> (for cmp (lt ge le gt )
> bitop (bit_ior bit_ior bit_and bit_and)
> (simplify
> (cmp (bitop @0 INTEGER_CST@1) @0)
> (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && TREE_UNSIGNED (TREE_TYPE (@0)))
>({ constant_boolean_node (cmp == GE_EXPR || cmp == LE_EXPR, type); })))
@1 here does not even need to be a constant even ...
And that might solve PR 94884 even.
[Bug tree-optimization/101590] (len & - N) <= len is not optimized to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101590
--- Comment #4 from Andrew Pinski ---
U | N < U -> false
U & N <= U -> true
U & N > U -> false
U | N >= U -> true
>I don't see an easy way to combine these two patterns though.
I totally missed that the for loop is a pair for.
(for cmp (lt ge le gt )
bitop (bit_ior bit_ior bit_and bit_and)
(simplify
(cmp (bitop @0 INTEGER_CST@1) @0)
(if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && TREE_UNSIGNED (TREE_TYPE (@0)))
({ constant_boolean_node (cmp == GE_EXPR || cmp == LE_EXPR, type); })))
[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 #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:3242fb533d48abab621618c4f183ca395de3dcd2 commit r14-3391-g3242fb533d48abab621618c4f183ca395de3dcd2 Author: David Malcolm Date: Tue Aug 22 18:36:54 2023 -0400 analyzer: reimplement kf_strlen [PR105899] Reimplement kf_strlen in terms of the new string scanning implementation, sharing strlen's implementation with __analyzer_get_strlen. gcc/analyzer/ChangeLog: PR analyzer/105899 * kf-analyzer.cc (class kf_analyzer_get_strlen): Move to kf.cc. (register_known_analyzer_functions): Use make_kf_strlen. * kf.cc (class kf_strlen::impl_call_pre): Replace with implementation of kf_analyzer_get_strlen from kf-analyzer.cc. Handle "UNKNOWN" return from check_for_null_terminated_string_arg by falling back to a conjured svalue. (make_kf_strlen): New. (register_known_functions): Use make_kf_strlen. * known-function-manager.h (make_kf_strlen): New decl. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/null-terminated-strings-1.c: Update expected results on symbolic values. * gcc.dg/analyzer/strlen-1.c: New test. Signed-off-by: David Malcolm
[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 #4 from Zebediah Figura --- (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. Here is, again, what I am trying to communicate: Currently i686-w64-mingw32-gcc effectly assumes 4-byte stack alignment in some places (when -msse2 is used), and 16-byte alignment in others (when __attribute__((aligned)) is used). I am trying to request that it pick one or the other and stick with it. Now, personally, I think that assuming 4-byte stack alignment makes more *sense*. Otherwise *every* API function needs that extra alignment, which is wasteful when comparatively little code actually uses types aligned to 8 or more bytes. (It obviously makes more sense if you can get the whole API to agree on 16-bytes; then you don't have to manually align anything). But if there's a clear consensus that gcc should assume 16 bytes, and that it's Wine's responsibility to set -mstackrealign, or -mincoming-stack-boundary=2, or something, fine, but I'd like GCC to be consistent about that policy. Otherwise it looks like this behaviour is a bug. That's why I reported this as a bug.
[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 #3 from Andrew Pinski --- https://inbox.sourceware.org/gcc-patches/5969976.Bvae8NF9fS@polaris/
[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 #2 from Zebediah Figura --- (In reply to Andrew Pinski from comment #1) > This on purpose, it is only callbacks (from libc) and main that needs the > realignment here. I don't understand what you mean? It's not just libc and main that needs this. As mentioned, this is *the* 32-bit x86 ABI on Windows. Win32 programs compiled with MSVC don't assume 16-byte alignment (if they do now, they didn't historically, and we do regularly run across programs in Wine that do not keep the stack aligned to 16 bytes). And again, gcc does not, as a blanket statement, assume 16-byte stack alignment for i386. If we think that gcc *should* assume 16-byte stack alignment, then we should also get rid of the existing code in gcc that assumes 4-byte stack alignment. I think this is a bad idea, for the reasons I've been describing, but if that's the decision then let's please at least be consistent and clear about it. I'm sure this is something of a canned response since, as you say, this issue has been reported before (although I couldn't actually find any such reports, just from searching the gcc Bugzilla?). I wouldn't report this as a bug per se if gcc wasn't currently being *inconsistent* about what it assumes the stack alignment is.
[Bug c++/111103] gcc accepts bad type syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=03 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Bell from comment #4) > What is the purpose of the extension? The extension has been there since the C++ front-end was checked into source control years before 1999. I doubt anyone understands the purpose of the extension any more.
[Bug c++/111103] gcc accepts bad type syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=03 --- Comment #4 from Andrew Bell --- What is the purpose of the extension?
[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 #1 from Andrew Pinski --- This on purpose, it is only callbacks (from libc) and main that needs the realignment here. There are other bug reports for a similar thing for mingw even.
[Bug target/111107] New: 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
Bug ID: 07
Summary: i686-w64-mingw32 does not realign stack when
__attribute__((aligned)) or
__attribute__((vector_size)) are used
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Keywords: ABI, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zfigura at codeweavers dot com
Target Milestone: ---
Target: i686-w64-mingw32
Minimal example:
typedef int myint[4] __attribute__((aligned(16)));
extern void g(void *);
void f(void)
{
myint a;
g();
}
The same thing happens if __attribute__((aligned(16))) is applied to the
variable instead of the typedef.
This seems to also prevent __m128 from being aligned correctly (which uses the
"vector_size" attribute rather than "aligned", but I would assume that
"vector_size" implies "aligned").
-mincoming-stack-boundary=2 works as a workaround; so does -mstackrealign.
Neither should be necessary, though.
I've seen some disagreement [1] [2] as to whether the stack alignment for
i686-w64-mingw32 *should* be 16 or 4, but as far as I can tell it really should
be 4. It's explicitly called out in a code comment [3]; it shows up when -msse2
is used [4], and, well, it reflects the actual ABI of programs that exist in
the wild.
We do regularly come across programs in Wine that don't align the stack to a
16-byte boundary before calling win32 functions, and while -mstackrealign and
similar functions exist, they imply that we either waste time and space
unnecessarily aligning *every* function, or we manually align any function that
might use an aligned type, which is in general something that's treated as the
compiler's responsibility.
[1] https://github.com/mingw-w64/mingw-w64/issues/30#issuecomment-1685487779
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273#c5
[3]
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/cygming.h;h=d539f8d0699d69b014e9d3378e78d690ea289f14;hb=HEAD#l34
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273#c6
[Bug c++/111106] [11/12/13/14 Regression] missing ; causes internal compiler error: in dependent_type_p, at cp/pt.cc:27901
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=06 Andrew Pinski changed: What|Removed |Added Priority|P3 |P5
[Bug c++/111106] [11/12/13/14 Regression] missing ; causes internal compiler error: in dependent_type_p, at cp/pt.cc:27901
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=06 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 Summary|missing ; causes internal |[11/12/13/14 Regression] |compiler error: in |missing ; causes internal |dependent_type_p, at|compiler error: in |cp/pt.cc:27901 |dependent_type_p, at ||cp/pt.cc:27901
[Bug c++/111106] missing ; causes internal compiler error: in dependent_type_p, at cp/pt.cc:27901
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=06 --- Comment #2 from Marek Polacek --- (In reply to Marek Polacek from comment #1) > With s/consteval/contexpr/ ICEs since GCC 10. constexpr
[Bug c++/111106] missing ; causes internal compiler error: in dependent_type_p, at cp/pt.cc:27901
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=06 Andrew Pinski changed: What|Removed |Added Keywords||error-recovery, ||ice-checking Target Milestone|11.5|--- Severity|normal |trivial Summary|[11/12/13/14 Regression]|missing ; causes internal |missing ; causes internal |compiler error: in |compiler error: in |dependent_type_p, at |dependent_type_p, at|cp/pt.cc:27901 |cp/pt.cc:27901 |
[Bug c++/111106] [11/12/13/14 Regression] missing ; causes internal compiler error: in dependent_type_p, at cp/pt.cc:27901
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=06 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |11.5 Summary|missing ; causes internal |[11/12/13/14 Regression] |compiler error: in |missing ; causes internal |dependent_type_p, at|compiler error: in |cp/pt.cc:27901 |dependent_type_p, at ||cp/pt.cc:27901 --- Comment #1 from Marek Polacek --- With s/consteval/contexpr/ ICEs since GCC 10.
[Bug c++/111106] New: missing ; causes internal compiler error: in dependent_type_p, at cp/pt.cc:27901
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=06
Bug ID: 06
Summary: missing ; causes internal compiler error: in
dependent_type_p, at cp/pt.cc:27901
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
consteval int id (int i) { return i; }
constexpr int
f (auto i) requires requires { id (i) }
{
return i;
}
void
g ()
{
f (42);
}
$ ./cc1plus -quiet -std=c++23 ice.C
ice.C:4:38: error: expected ‘;’ before ‘}’ token
4 | f (auto i) requires requires { id (i) }
| ^~
| ;
ice.C:4:1: error: constraints on a non-templated function
4 | f (auto i) requires requires { id (i) }
| ^
ice.C:4:39: internal compiler error: in dependent_type_p, at cp/pt.cc:27901
4 | f (auto i) requires requires { id (i) }
| ^
0x10bfe18 dependent_type_p(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:27901
0xe71b20 require_complete_types_for_parms
/home/mpolacek/src/gcc/gcc/cp/decl.cc:14908
0xe7c9eb check_function_type
/home/mpolacek/src/gcc/gcc/cp/decl.cc:17236
0xe7dd74 start_preparsed_function(tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl.cc:17435
0xe8098b start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
/home/mpolacek/src/gcc/gcc/cp/decl.cc:17759
0xff3994 cp_parser_function_definition_from_specifiers_and_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.cc:31935
0xfe06bc cp_parser_init_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.cc:22827
0xfd2054 cp_parser_simple_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.cc:15435
0xfd1bcd cp_parser_block_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.cc:15255
0xfd1816 cp_parser_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.cc:15121
0xfd18f6 cp_parser_toplevel_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.cc:15142
0xfb98ac cp_parser_translation_unit
/home/mpolacek/src/gcc/gcc/cp/parser.cc:5140
0x102d32f c_parse_file()
/home/mpolacek/src/gcc/gcc/cp/parser.cc:49810
0x122af79 c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.cc:1257
[Bug c++/98992] attribute malloc error associating a member deallocator with an allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98992 Andrew Pinski changed: What|Removed |Added CC||thiago at kde dot org --- Comment #2 from Andrew Pinski --- *** Bug 05 has been marked as a duplicate of this bug. ***
[Bug c++/111105] [12/13/14 regression] __attribute__((malloc)) can no longer name a C++ member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=05 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 98992, this never really worked. *** This bug has been marked as a duplicate of bug 98992 ***
[Bug c++/111105] New: [12/13/14 regression] __attribute__((malloc)) can no longer name a C++ member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=05
Bug ID: 05
Summary: [12/13/14 regression] __attribute__((malloc)) can no
longer name a C++ member function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
This compiles with GCC 11:
struct QArrayData
{
static void free(void *);
__attribute__((malloc(QArrayData::free))) static void *allocate();
};
But fails since 12.0.
error: 'malloc' attribute argument 1 does not name a function
See https://conformance.godbolt.org/z/n76jTsahT
[Bug target/111104] Fatal error: can't fill 256 bytes in section .rodata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=04 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Basically the assembler is trying to create an object file which contains 4501954476025838640 (or 4094503TB) in size (and that will fail at runtime when you try to load the generated elf file. There is nothing to be done here as GCC compiles this just fine and the assembler is failing because well the array is huge and not placed in a section which is zero-filed at runtime.
[Bug target/111104] Fatal error: can't fill 256 bytes in section .rodata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=04 --- Comment #1 from Andrew Pinski --- I don't think there is anything GCC can do here. You requested a huge array which is zero-filled and GCC is able to compile it to the produce assembly code which is valid.
[Bug target/43744] SH: Error: pcrel too far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744 --- Comment #19 from Giulio Benetti --- This bug still shows up with gcc 12.3.0. Can you please reopen it? Thank you
[Bug c++/111104] New: Fatal error: can't fill 256 bytes in section .rodata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=04
Bug ID: 04
Summary: Fatal error: can't fill 256 bytes in section .rodata
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adavanian at nvidia dot com
Target Milestone: ---
Created attachment 55777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55777=edit
The preprocessed file that triggers the bug
Compiling the following file results in a fatal error:
$gcc-12 -v
Using built-in specs.
COLLECT_GCC=gcc-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: "..."
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04)
$cat test.cpp
struct A {
int i;
constexpr A() : i(0) {}
};
struct B {
A a[1125488619006459660];
};
extern const B b{};
$gcc-12 test.cpp -o test.bin
/tmp/cc4H9Jsi.s: Assembler messages:
/tmp/cc4H9Jsi.s: Fatal error: can't fill 256 bytes in section .rodata of
/tmp/cc9wAeg1.o: 'file truncated'
/tmp/cc4H9Jsi.s: Fatal error: /tmp/cc9wAeg1.o: file truncated
Additional note: this test case is very similar to
testsuite\g++.dg\cpp0x\constexpr-array.C.
[Bug c++/80516] No error for bad type-specifier-seq in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80516 Andrew Pinski changed: What|Removed |Added CC||andrew.bell.ia at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 03 has been marked as a duplicate of this bug. ***
[Bug c++/111103] gcc accepts bad type syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=03 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Basically a dup of bug 80516 (The extension is not documented but been there for a long time). *** This bug has been marked as a duplicate of bug 80516 ***
[Bug c++/80516] No error for bad type-specifier-seq in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80516 --- Comment #6 from Andrew Pinski --- The error message with -pedantic is now: :7:3: error: 'signed' specified with typedef-name 'using u = unsigned int' [-Wpedantic] 7 | S s; | ^~
[Bug c++/111103] gcc accepts bad type syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=03 --- Comment #2 from Andrew Pinski --- : In function 'long long int f()': :6:13: error: 'long long' specified with typedef-name 'U8' [-Wpedantic] 6 | U8 long long i = 23; | ^~~~
[Bug libstdc++/111102] illegal pointer arithmetic invoked by std::format("L{:65536}",1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=02 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |13.3 Last reconfirmed||2023-08-22
[Bug fortran/25095] Disallowed intrinsic in initialization statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||anlauf at gcc dot gnu.org --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Jürgen Reuter from comment #7) > Indeed, ifort and PGI fortran flag this as an error in the implied DO > expression. Nagfor flags it just as an extension. Actually, current nagfor flags it as: % nagfor pr25095.f90 -f2003 NAG Fortran Compiler Release 7.1(Hanzomon) Build 7101 Extension(F2008): pr25095.f90, line 2: Function reference in DATA-implied-DO [NAG Fortran Compiler normal termination, 1 warning] and is silent for -f2008 or -f2018 . The F2018 (and similarly F2008) text is slightly clearer here: ! C881 (R841) In an array-element or scalar-structure-component that is a ! data-i-do-object, any subscript shall be a constant expression, and any ! primary within that subscript that is a data-i-do-variable shall be a ! DO variable of this data-implied-do or of a containing data-implied-do. and then ! 10.1.12 Constant expression ! ! (5) a reference to an elemental standard intrinsic function, where each ! argument is a constant expression, ! ! (11) a data-i-do-variable within a data-implied-do, ! ! and Note 1 and among the standard intrinsic procedures: ! 16.9.136 MODULO (A, P) So this is more likely an ifort and PGI/Nvidia bug on the one hand, and on the other the question whether we care for a diagnostic for -std=f95 .
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 --- Comment #8 from Mikael Morin --- (In reply to JuzheZhong from comment #7) > Do you have a solution that we can fix RISC-V backend? No, this is not RISC-V specific. > Or you will fix it in Fortran front-end? Yes, the fix will have to be in the fortran front-end, but I haven't found it yet.
[Bug c++/111103] gcc accepts bad type syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=03 --- Comment #1 from Andrew Pinski --- Try with -pedantic-errors. This is an extension iirc.
[Bug c++/111103] New: gcc accepts bad type syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=03
Bug ID: 03
Summary: gcc accepts bad type syntax
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.bell.ia at gmail dot com
Target Milestone: ---
The following code is accepted by gcc 13.2 as confirmed by compiler explorer
(x86_64 or ARM):
typedef long long U8;
long long f()
{
U8 long long i = 23;
return i;
}
[Bug c++/109751] [13/14 Regression] boost iterator_interface fails concept check starting in gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751 --- Comment #24 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:810bcc00156cefce7ad40fc9d8de6e43c3a04450 commit r14-3389-g810bcc00156cefce7ad40fc9d8de6e43c3a04450 Author: Jason Merrill Date: Thu Aug 17 11:36:23 2023 -0400 c++: constrained hidden friends [PR109751] r13-4035 avoided a problem with overloading of constrained hidden friends by checking satisfaction, but checking satisfaction early is inconsistent with the usual late checking and can lead to hard errors, so let's not do that after all. We were wrongly treating the different instantiations of the same friend template as the same function because maybe_substitute_reqs_for was failing to actually substitute in the case of a non-template friend. But we don't actually need to do the substitution anyway, because [temp.friend] says that such a friend can't be the same as any other declaration. After fixing that, instead of a redefinition error we got an ambiguous overload error, fixed by allowing constrained hidden friends to coexist until overload resolution, at which point they probably won't be in the same ADL overload set anyway. And we avoid mangling collisions by following the proposed mangling for these friends as a member function with an extra 'F' before the name. I demangle this by just adding [friend] to the name of the function because it's not feasible to reconstruct the actual scope of the function since the mangling ABI doesn't distinguish between class and namespace scopes. PR c++/109751 gcc/cp/ChangeLog: * cp-tree.h (member_like_constrained_friend_p): Declare. * decl.cc (member_like_constrained_friend_p): New. (function_requirements_equivalent_p): Check it. (duplicate_decls): Check it. (grokfndecl): Check friend template constraints. * mangle.cc (decl_mangling_context): Check it. (write_unqualified_name): Check it. * pt.cc (uses_outer_template_parms_in_constraints): Fix for friends. (tsubst_friend_function): Don't check satisfaction. include/ChangeLog: * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_FRIEND. libiberty/ChangeLog: * cp-demangle.c (d_make_comp): Handle DEMANGLE_COMPONENT_FRIEND. (d_count_templates_scopes): Likewise. (d_print_comp_inner): Likewise. (d_unqualified_name): Handle member-like friend mangling. * testsuite/demangle-expected: Add test. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-friend11.C: Now works. Add template. * g++.dg/cpp2a/concepts-friend15.C: New test.
[Bug c++/70248] constexpr initialization with unspecified equality expression accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70248
Paul Keir changed:
What|Removed |Added
CC||pkeir at outlook dot com
--- Comment #10 from Paul Keir ---
Here is another example which GCC accepts, but Clang correctly rejects:
constexpr bool test()
{
int arr[2]{};
void *p1 = [0];
void *p2 = [1];
return p1 < p2;
}
constexpr bool b = test();
[Bug fortran/49588] DATA statement with vector sections rejected (ICE: TODO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49588 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed more than 12 years after the report. Yay!
[Bug fortran/33056] [Meta-bug] Data - statement related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056 Bug 33056 depends on bug 49588, which changed state. Bug 49588 Summary: DATA statement with vector sections rejected (ICE: TODO) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49588 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/111091] Split view with double quoted string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111091 --- Comment #4 from KL --- I get it. Must be more careful :) Thanks
[Bug libstdc++/111091] Split view with double quoted string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111091 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Patrick Palka --- Thanks for the report. Although the behavior may seem surprising I believe it's working as specified. The string literal "/" when treated as a range includes the null terminator, so we're actually splitting at occurrences of '/' followed by '\0', of which there are none in the input string. The corresponding std::string or std::string_view doesn't include the null terminator and so does the expected thing.
[Bug libstdc++/111102] New: illegal pointer arithmetic invoked by std::format("L{:65536}",1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=02
Bug ID: 02
Summary: illegal pointer arithmetic invoked by
std::format("L{:65536}",1)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at pauldreik dot se
Target Milestone: ---
The following program:
#include
constexpr auto blah = std::format(L"{:65536}", 1);
is problematic when compiled with gcc 13 as well as the current trunk.
It triggers a pointer arithmetic error inside
https://gcc.gnu.org/git/?p=gcc.git;a=blame;f=libstdc%2B%2B-v3/include/std/format;hb=1d9454aba615eadd0d85c93713dd848227345f67#l295
it seems like the width is parsed into a unsigned short, but the return value
is not checked in the case the format string was not a char string (as above,
which is a wide char string).
The following patch fixes the problem:
commit 78ac41590432f4f01036797fd9d661f6ed80cf37 (HEAD -> master)
Author: Paul Dreik
Date: Tue Aug 22 19:16:57 2023 +0200
libstdc++: fix illegal pointer arithmetic in format
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
diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index f3d9ae152f..fe2caa5868 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -285,7 +285,8 @@ namespace __format
for (int __i = 0; __i < __n && (__first + __i) != __last; ++__i)
__buf[__i] = __first[__i];
auto [__v, __ptr] = __format::__parse_integer(__buf, __buf + __n);
- return {__v, __first + (__ptr - __buf)};
+ if (__ptr) [[likely]]
+ return {__v, __first + (__ptr - __buf)};
}
return {0, nullptr};
}
[Bug tree-optimization/95929] Failure to optimize tautological comparisons of comparisons to a single one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929 --- Comment #5 from Andrew Pinski --- /* -bool is always bool, likewise for abs and absu. */ (for op (negate abs absu) (simplify (op @0) (if (INTEGER_TYPE_P (type) && TYPE_PRECISION (type) == 1) (non_lvalue @0
[Bug tree-optimization/95929] Failure to optimize tautological comparisons of comparisons to a single one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Andrew Pinski --- r14-3110-g7fb65f102851 (handling of a?~t:t -> (-(a))^t) basically fixes this. The only thing left is removing of `bool = -bool`: In: _1 = a_5(D) != 0; _2 = b_3(D) != 0; _13 = -_2; _12 = _1 ^ _13;
[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 gccbug at provalid dot com changed: What|Removed |Added CC||gccbug at provalid dot com --- Comment #4 from gccbug at provalid dot com --- I think the ABI might have softened on this point at https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#general-purpose-registers. It says the platform can let x29 be used as a general-purpose callee-saved register in section 6.4.6.
[Bug c++/102613] [C++23] P2246R1 - Character encoding of diagnostic text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102613 --- Comment #2 from Jakub Jelinek --- Looking at what clang++ does, they emit 01.C:1:1: error: static_assert failed "\360\237\230\200" etc. and don't really support -finput-charset=ISO-8859-1 etc. (-finput-charset=utf-8 works).
[Bug c++/102613] [C++23] P2246R1 - Character encoding of diagnostic text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102613 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Is there anything we need to do here? >From what I can see, e.g. for static assertions which is one of the two changed points we reencode the message from -finput-charset= charset if supplied to UTF-8 and then emit the UTF-8 chars to the terminal regardless of locale's charset unobfuscated, so say given: static_assert (false, "��c"); and -finput-charset=ISO-8859-1 00.C:1:16: error: static assertion failed: áæc 1 | static_assert (false, "áæc"); |^ is emitted, while without that -finput-charset= (i.e. when it is invalid UTF-8), we emit 00.C:1:16: error: static assertion failed: ��c 1 | static_assert (false, "��c"); |^ On valid UTF-8 emoji: static_assert (false, ""); we emit 01.C:1:16: error: static assertion failed: 1 | static_assert (false, ""); |^ and with -finput-charset=ISO-8859-1 01.C:1:16: error: static assertion failed: ð 1 | static_assert (false, "ð"); |^ Not really sure what to do for our testsuite for this though, because while we can use -finput-charset= in dg-options, we have no control on what the pseudo terminal encoding actually is.
[Bug rtl-optimization/110093] [12/13/14 Regression][avr] Move frenzy leading to code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093 Georg-Johann Lay changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-08-22 Status|UNCONFIRMED |NEW
[Bug rtl-optimization/110093] [12/13/14 Regression][avr] Move frenzy leading to code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093
--- Comment #2 from Georg-Johann Lay ---
Meanwhile (2023-08-22) the generated code from above got worse once again and
even pops a frame:
long add (long aa, long bb, long cc)
{
if (cc < 0)
return aa - cc;
return aa + bb;
}
> avr-gcc -Os -S -dp
add:
push r4 ; 83 [c=4 l=1] pushqi1/0
push r5 ; 84 [c=4 l=1] pushqi1/0
push r6 ; 85 [c=4 l=1] pushqi1/0
push r7 ; 86 [c=4 l=1] pushqi1/0
push r8 ; 87 [c=4 l=1] pushqi1/0
push r9 ; 88 [c=4 l=1] pushqi1/0
push r10 ; 89 [c=4 l=1] pushqi1/0
push r11 ; 90 [c=4 l=1] pushqi1/0
push r14 ; 91 [c=4 l=1] pushqi1/0
push r15 ; 92 [c=4 l=1] pushqi1/0
push r16 ; 93 [c=4 l=1] pushqi1/0
push r17 ; 94 [c=4 l=1] pushqi1/0
push r28 ; 95 [c=4 l=1] pushqi1/0
push r29 ; 96 [c=4 l=1] pushqi1/0
; SP -= 4 ; 100 [c=4 l=2] *addhi3_sp
rcall .
rcall .
in r28,__SP_L__ ; 126 [c=4 l=2] *movhi/7
in r29,__SP_H__
/* prologue: function */
/* frame size = 4 */
/* stack size = 18 */
.L__stack_usage = 18
mov r8,r22 ; 69 [c=4 l=1] movqi_insn/0
mov r9,r23 ; 70 [c=4 l=1] movqi_insn/0
mov r10,r24 ; 71 [c=4 l=1] movqi_insn/0
mov r11,r25 ; 72 [c=4 l=1] movqi_insn/0
std Y+1,r18 ; 73 [c=4 l=1] movqi_insn/2
std Y+2,r19 ; 74 [c=4 l=1] movqi_insn/2
std Y+3,r20 ; 75 [c=4 l=1] movqi_insn/2
std Y+4,r21 ; 76 [c=4 l=1] movqi_insn/2
mov r4,r14 ; 77 [c=4 l=1] movqi_insn/0
mov r5,r15 ; 78 [c=4 l=1] movqi_insn/0
mov r6,r16 ; 79 [c=4 l=1] movqi_insn/0
mov r7,r17 ; 80 [c=4 l=1] movqi_insn/0
sbrs r7,7; 123 [c=4 l=2] *sbrx_branchhi
rjmp .L2
mov r25,r11 ; 67 [c=4 l=4] *movsi/0
mov r24,r10
mov r23,r9
mov r22,r8
sub r22,r4 ; 68 [c=16 l=4] *subsi3/0
sbc r23,r5
sbc r24,r6
sbc r25,r7
.L1:
/* epilogue start */
; SP += 4 ; 106 [c=4 l=4] *addhi3_sp
pop __tmp_reg__
pop __tmp_reg__
pop __tmp_reg__
pop __tmp_reg__
pop r29 ; 107 [c=4 l=1] popqi
pop r28 ; 108 [c=4 l=1] popqi
pop r17 ; 109 [c=4 l=1] popqi
pop r16 ; 110 [c=4 l=1] popqi
pop r15 ; 111 [c=4 l=1] popqi
pop r14 ; 112 [c=4 l=1] popqi
pop r11 ; 113 [c=4 l=1] popqi
pop r10 ; 114 [c=4 l=1] popqi
pop r9 ; 115 [c=4 l=1] popqi
pop r8 ; 116 [c=4 l=1] popqi
pop r7 ; 117 [c=4 l=1] popqi
pop r6 ; 118 [c=4 l=1] popqi
pop r5 ; 119 [c=4 l=1] popqi
pop r4 ; 120 [c=4 l=1] popqi
ret ; 121 [c=0 l=1] return_from_epilogue
.L2:
ldd r22,Y+1 ; 65 [c=16 l=4] *movsi/2
ldd r23,Y+2
ldd r24,Y+3
ldd r25,Y+4
add r22,r8 ; 66 [c=16 l=4] *addsi3/0
adc r23,r9
adc r24,r10
adc r25,r11
rjmp .L1 ; 124 [c=4 l=1] jump
.ident "GCC: (GNU) 14.0.0 20230822 (experimental)"
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 --- Comment #22 from CVS Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e7a097ea72d3295a1a1680ba05c4fc8242bae7f0 commit r13-7743-ge7a097ea72d3295a1a1680ba05c4fc8242bae7f0 Author: Jakub Jelinek Date: Tue Aug 22 16:13:44 2023 +0200 doc: Remove obsolete sentence about _Float* not being supported in C++ [PR106652] As mentioned in the PR, these types are supported in C++ since GCC 13, so we shouldn't confuse users. 2023-08-22 Jakub Jelinek PR c++/106652 * doc/extend.texi (_Float): Drop obsolete sentence that the types aren't supported in C++. (cherry picked from commit 145da6a8e1ad60f048069012d81e37f84e1585fd)
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 --- Comment #21 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:145da6a8e1ad60f048069012d81e37f84e1585fd commit r14-3385-g145da6a8e1ad60f048069012d81e37f84e1585fd Author: Jakub Jelinek Date: Tue Aug 22 16:13:44 2023 +0200 doc: Remove obsolete sentence about _Float* not being supported in C++ [PR106652] As mentioned in the PR, these types are supported in C++ since GCC 13, so we shouldn't confuse users. 2023-08-22 Jakub Jelinek PR c++/106652 * doc/extend.texi (_Float): Drop obsolete sentence that the types aren't supported in C++.
[Bug rtl-optimization/111101] -finline-small-functions may invert FP arguments breaking FP bit accuracy in case of NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=01 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- 0x7fe5ed65 is a quiet NaN, not signaling (it differs from the input 0x7fa5ed65 sNaN by the leading mantissa bit 0x0040). IEEE-754 does not pin down which of the two payloads should be propagated when both operands are NaNs, and neither do language standards, so for GCC floating-point addition and similar operations are commutative. Observed NaN payloads are not predictable and may change depending on optimization level, choice of x87 vs. SSE instructions, etc. This is not a bug.
[Bug rtl-optimization/111101] New: -finline-small-functions may invert FP arguments breaking FP bit accuracy in case of NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=01 Bug ID: 01 Summary: -finline-small-functions may invert FP arguments breaking FP bit accuracy in case of NaNs Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pavel.morozkin at gmail dot com Target Milestone: --- Notes: 1. This may not be a bug. 2. This may be a duplicate. 3. I don't have MRE. Brief: -finline-small-functions may invert FP arguments breaking FP bit accuracy in case of NaNs Demo: $ gcc t1.c -O1 -std=c11 && ./a r nan 7fe5ed65 r_ref nan 7fe5ed65 $ gcc t1.c -O1 -std=c11 -finline-small-functions && ./a r -nan fffe r_ref nan 7fe5ed65 Description: In my code I add two FP values (represented in "raw hex"): 0x7fa5ed65 (sNaN) with 0xfffe (qNaN). x86_64 instruction addss returns 0x7fe5ed65 (sNaN). However, under -finline-small-functions gcc, I guess, rewrites A+B to B+A, resulting in 0xfffe (qNaN), which breaks FP bit accuracy. I examined generated assembly code: -O1: add(x, y) x => ecx => ebp => xmm0 y => edx => edi => xmm1 addss xmm1, xmm0 (at syntax) -O1 -finline-small-functions: add(x, y) x => ecx => esi => xmm1 y => edx => ebx => xmm0 addss xmm1, xmm0 (at syntax) Here we see that in case of -finline-small-functions x and y are inverted. Notes: 1. Some software may rely on FP bit accuracy in case of NaNs (NaN boxing, etc.). 2. I'm not sure which "Component:" to select: rtl-optimization or tree-optimization.
[Bug debug/111080] [11/12/13/14 Regression] restrict qualifier causes extra debug info to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080 Richard Biener changed: What|Removed |Added Keywords|needs-bisection | Priority|P3 |P2
[Bug gcov-profile/111100] Use extern "C" for __gcov_dump and related functions in gcov.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=00 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-08-22 --- Comment #1 from Richard Biener --- I think so, yes. Confirmed.
[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 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #2 from Uroš Bizjak --- Created attachment 55776 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55776=edit Proposed patch Patch that introduces alternative MOVQ RTX definition.
[Bug middle-end/111054] [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054 --- Comment #2 from Jan Hubicka --- This is a missing check for profile presence (we can not convert undefined probability to sreal). I will fix that.
[Bug sanitizer/111063] [UBSAN] Implement "-inf is outside the range of representable values of type 'unsigned long'" to be on par with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111063 --- Comment #4 from Jakub Jelinek --- Yet, even for C++ both the compiler middle-end and users assume they can do say 0.0 / 0.0 and get a NaN, not UB etc. Even for the conversions, the generated code or library functions just set the resulting integer to minimum or maximum value of the type depending on what is closer to the value. So, I think it is good that -fsanitize=undefined doesn't include -fsanitize=float-divide-by-zero,float-cast-overflow.
[Bug sanitizer/111063] [UBSAN] Implement "-inf is outside the range of representable values of type 'unsigned long'" to be on par with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111063 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- Last reconfirmed||2023-08-22 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- For C++ it's undefined behaviour. Annex F of the C standard doesn't apply to C++. Either the sanitizer should be enabled for C++, or the docs should say that G++ applies the rules of Annex F to floating-point types even where the standard says it's UB.
[Bug c++/111097] mistifying bug triggered by trivial code change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111097 --- Comment #7 from Fabio Cannizzo --- Apologies for my ignorance. Thank you.
[Bug gcov-profile/111100] New: Use extern "C" for __gcov_dump and related functions in gcov.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=00 Bug ID: 00 Summary: Use extern "C" for __gcov_dump and related functions in gcov.h Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: carlosgalvezp at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hi! The documentation of GCOV mentions that users can use __gcov_dump and __gcov_reset. This comes from gcov.h. The problem is that we currently can't use them in C++ code, because they don't have extern "C" declaration. Therefore the names are mangled which leads to linking errors (undefined reference) when using the code. As a workaround, people need to re-create gcov.h on their own to add the extern "C" declaration, or include the header under an extern "C" block, which is not very clean. Would it be possible to add extern "C" to the declarations in gcov.h? Thanks
[Bug c++/111097] mistifying bug triggered by trivial code change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111097 --- Comment #6 from Jonathan Wakely --- (In reply to Fabio Cannizzo from comment #3) > Using -fno-strict-aliasing the issue disappear, however I am not sure if > that is a real fix, or if it is merely circumstantial. When creating the bug report there was a notice at the top of the page: "Before reporting that GCC compiles your code incorrectly, compile it with gcc -Wall -Wextra and see whether this shows anything wrong with your code. Similarly, if compiling with -fno-strict-aliasing -fwrapv makes a difference, your code probably is not correct." That is the case here. > As mentioned, there are many other possible workarounds which also make the > issue disappear. The most curious one being the one below, where p has type > __m128i*, and simply casting it to XV* before the assignment, things stop > working. Yes, code with undefined behaviour is fragile and unpredictable. > Worth noting, this code works correctly with Visual Studio and with clang. Yes. code with undefined behaviour sometimes appears to work correctly with different compilers, or just with different optimizations enabled.
[Bug tree-optimization/93080] insert of an extraction on the same location is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080 --- Comment #9 from Richard Biener --- The testcase in the description is fixed, comment#2 and comment#4 are not.
[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866 Bug 94866 depends on bug 94864, which changed state. Bug 94864 Summary: Failure to combine vunpckhpd+movsd into single vunpckhpd https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/94864] Failure to combine vunpckhpd+movsd into single vunpckhpd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #6 from Richard Biener --- Fixed.
[Bug target/94865] Failure to combine unpckhpd+unpcklpd into blendps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94865 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #4 from Richard Biener --- Fixed.
[Bug rtl-optimization/94864] Failure to combine vunpckhpd+movsd into single vunpckhpd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:27de9aa152141e7f3ee66372647d0f2cd94c4b90 commit r14-3381-g27de9aa152141e7f3ee66372647d0f2cd94c4b90 Author: Richard Biener Date: Wed Jul 12 15:01:47 2023 +0200 tree-optimization/94864 - vector insert of vector extract simplification The PRs ask for optimizing of _1 = BIT_FIELD_REF ; result_4 = BIT_INSERT_EXPR ; to a vector permutation. The following implements this as match.pd pattern, improving code generation on x86_64. On the RTL level we face the issue that backend patterns inconsistently use vec_merge and vec_select of vec_concat to represent permutes. I think using a (supported) permute is almost always better than an extract plus insert, maybe excluding the case we extract element zero and that's aliased to a register that can be used directly for insertion (not sure how to query that). The patch FAILs one case in gcc.target/i386/avx512fp16-vmovsh-1a.c where we now expand from __A_28 = VEC_PERM_EXPR ; instead of _28 = BIT_FIELD_REF ; __A_29 = BIT_INSERT_EXPR ; producing a vpblendw instruction instead of the expected vmovsh. That's either a missed vec_perm_const expansion optimization or even better, an improvement - Zen4 for example has 4 ports to execute vpblendw but only 3 for executing vmovsh and both instructions have the same size. The patch XFAILs the sub-testcase. PR tree-optimization/94864 PR tree-optimization/94865 PR tree-optimization/93080 * match.pd (bit_insert @0 (BIT_FIELD_REF @1 ..) ..): New pattern for vector insertion from vector extraction. * gcc.target/i386/pr94864.c: New testcase. * gcc.target/i386/pr94865.c: Likewise. * gcc.target/i386/avx512fp16-vmovsh-1a.c: XFAIL. * gcc.dg/tree-ssa/forwprop-40.c: Likewise. * gcc.dg/tree-ssa/forwprop-41.c: Likewise.
[Bug tree-optimization/93080] insert of an extraction on the same location is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:27de9aa152141e7f3ee66372647d0f2cd94c4b90 commit r14-3381-g27de9aa152141e7f3ee66372647d0f2cd94c4b90 Author: Richard Biener Date: Wed Jul 12 15:01:47 2023 +0200 tree-optimization/94864 - vector insert of vector extract simplification The PRs ask for optimizing of _1 = BIT_FIELD_REF ; result_4 = BIT_INSERT_EXPR ; to a vector permutation. The following implements this as match.pd pattern, improving code generation on x86_64. On the RTL level we face the issue that backend patterns inconsistently use vec_merge and vec_select of vec_concat to represent permutes. I think using a (supported) permute is almost always better than an extract plus insert, maybe excluding the case we extract element zero and that's aliased to a register that can be used directly for insertion (not sure how to query that). The patch FAILs one case in gcc.target/i386/avx512fp16-vmovsh-1a.c where we now expand from __A_28 = VEC_PERM_EXPR ; instead of _28 = BIT_FIELD_REF ; __A_29 = BIT_INSERT_EXPR ; producing a vpblendw instruction instead of the expected vmovsh. That's either a missed vec_perm_const expansion optimization or even better, an improvement - Zen4 for example has 4 ports to execute vpblendw but only 3 for executing vmovsh and both instructions have the same size. The patch XFAILs the sub-testcase. PR tree-optimization/94864 PR tree-optimization/94865 PR tree-optimization/93080 * match.pd (bit_insert @0 (BIT_FIELD_REF @1 ..) ..): New pattern for vector insertion from vector extraction. * gcc.target/i386/pr94864.c: New testcase. * gcc.target/i386/pr94865.c: Likewise. * gcc.target/i386/avx512fp16-vmovsh-1a.c: XFAIL. * gcc.dg/tree-ssa/forwprop-40.c: Likewise. * gcc.dg/tree-ssa/forwprop-41.c: Likewise.
[Bug target/94865] Failure to combine unpckhpd+unpcklpd into blendps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94865 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:27de9aa152141e7f3ee66372647d0f2cd94c4b90 commit r14-3381-g27de9aa152141e7f3ee66372647d0f2cd94c4b90 Author: Richard Biener Date: Wed Jul 12 15:01:47 2023 +0200 tree-optimization/94864 - vector insert of vector extract simplification The PRs ask for optimizing of _1 = BIT_FIELD_REF ; result_4 = BIT_INSERT_EXPR ; to a vector permutation. The following implements this as match.pd pattern, improving code generation on x86_64. On the RTL level we face the issue that backend patterns inconsistently use vec_merge and vec_select of vec_concat to represent permutes. I think using a (supported) permute is almost always better than an extract plus insert, maybe excluding the case we extract element zero and that's aliased to a register that can be used directly for insertion (not sure how to query that). The patch FAILs one case in gcc.target/i386/avx512fp16-vmovsh-1a.c where we now expand from __A_28 = VEC_PERM_EXPR ; instead of _28 = BIT_FIELD_REF ; __A_29 = BIT_INSERT_EXPR ; producing a vpblendw instruction instead of the expected vmovsh. That's either a missed vec_perm_const expansion optimization or even better, an improvement - Zen4 for example has 4 ports to execute vpblendw but only 3 for executing vmovsh and both instructions have the same size. The patch XFAILs the sub-testcase. PR tree-optimization/94864 PR tree-optimization/94865 PR tree-optimization/93080 * match.pd (bit_insert @0 (BIT_FIELD_REF @1 ..) ..): New pattern for vector insertion from vector extraction. * gcc.target/i386/pr94864.c: New testcase. * gcc.target/i386/pr94865.c: Likewise. * gcc.target/i386/avx512fp16-vmovsh-1a.c: XFAIL. * gcc.dg/tree-ssa/forwprop-40.c: Likewise. * gcc.dg/tree-ssa/forwprop-41.c: Likewise.
[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 #3 from Thomas Koenig --- (In reply to Andrew Pinski from comment #2) > See https://gcc.gnu.org/pipermail/gcc-patches/2016-September/456662.html > > I think this is by design of the ABI ... The workaround mentioned in the thread does not appear to work, -O3 -fomit-frame-pointer -fcall-used-x29 yields cc1: error: cannot use 'x29' as a call-used register
[Bug analyzer/111099] New: -fanalyzer -Os segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111099 Bug ID: 111099 Summary: -fanalyzer -Os segmentation fault Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: alexey.lapshin at espressif dot com Target Milestone: --- Created attachment 55775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55775=edit reproducer.c To reproduce build the attached file with the command: $ gcc -fanalyzer -Os -c reproducer.c Observe issie on gcc 12.2.0 and gcc 13.2.0
[Bug tree-optimization/111098] New: Missed combine .FMA + .COND_NEG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111098
Bug ID: 111098
Summary: Missed combine .FMA + .COND_NEG
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lehua.ding at rivai dot ai
Target Milestone: ---
For code[1], GCC first combine a[i] + b[i] * c to a .FMA (widening_mul pass)
than fold .FMA + neg to .FNMS. But for code[2], it not fold .FMA + .COND_NEG to
.COND_FNMS. See the codes and dump tree on https://godbolt.org/z/WTKrET4sn.
Can we relax the fold condition after fuse mul+add from neg to neg or COND_NEG?
The simple try is as diff[3].
[1]
r[i] = -(a[i] + b[i] * c);
[2]
r[i] = pred[i] != 1 ? -(a[i] + b[i] * c) : c;
[3]
diff --git a/gcc/match.pd b/gcc/match.pd
index 86fdc606a79..a3719f725ab 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -8020,7 +8020,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(simplify
(negate (fmas@3 @0 @1 @2))
(if (single_use (@3))
-(IFN_FNMS @0 @1 @2
+(IFN_FNMS @0 @1 @2)))
+ (simplify
+ (IFN_COND_NEG @0 (fmas@5 @1 @2 @3) @4)
+ (if (single_use (@5))
+(IFN_COND_FNMS @0 @1 @2 @3 @4
(simplify
(IFN_FMS:c (negate @0) @1 @2)
diff --git a/gcc/tree-ssa-math-opts.cc b/gcc/tree-ssa-math-opts.cc
index 712097ac5be..b9f9baba002 100644
--- a/gcc/tree-ssa-math-opts.cc
+++ b/gcc/tree-ssa-math-opts.cc
@@ -3163,8 +3163,10 @@ convert_mult_to_fma_1 (tree mul_result, tree op1, tree
op2)
&& gimple_call_lhs (orig_stmt)
&& TREE_CODE (gimple_call_lhs (orig_stmt)) == SSA_NAME
&& single_imm_use (gimple_call_lhs (orig_stmt), _p, _stmt)
- && is_gimple_assign (neg_stmt)
- && gimple_assign_rhs_code (neg_stmt) == NEGATE_EXPR
+ && ((is_gimple_assign (neg_stmt)
+ && gimple_assign_rhs_code (neg_stmt) == NEGATE_EXPR)
+ || (gimple_call_internal_p (neg_stmt)
+ && gimple_call_internal_fn (neg_stmt) == IFN_COND_NEG))
&& !stmt_could_throw_p (cfun, neg_stmt))
{
gsi = gsi_for_stmt (neg_stmt);
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 --- Comment #7 from JuzheZhong --- (In reply to Mikael Morin from comment #6) > (In reply to Mikael Morin from comment #5) > > Here sym->formal_ns is NULL because the symbol C has not been completely > > setup. > > This makes the following an "obvious" fix: > > diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc > index 8182ef29f43..5afb9f2e2d3 100644 > --- a/gcc/fortran/decl.cc > +++ b/gcc/fortran/decl.cc > @@ -7496,6 +7496,7 @@ gfc_match_function_decl (void) > sym->attr.module_procedure = 1; > >gfc_new_block = sym; > + sym->formal_ns = gfc_current_ns; > >m = gfc_match_formal_arglist (sym, 0, 0); >if (m == MATCH_NO) > @@ -7993,6 +7994,7 @@ gfc_match_subroutine (void) > sym = sym->result; > >gfc_new_block = sym; > + sym->formal_ns = gfc_current_ns; > >/* Check what next non-whitespace character is so we can tell if there > is the required parens if we have a BIND(C). */ > > > However, that patch makes the situation worse by releasing the namespace for > "c" too early, as we access it later in reject_statement (it is the > "current" namespace). Thanks for helping with this issue. Do you have a solution that we can fix RISC-V backend? Or you will fix it in Fortran front-end? Thanks.
[Bug fortran/49588] DATA statement with vector sections rejected (ICE: TODO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49588 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d3b5a1bccc219680dc19281b6fd6cc798bb679eb commit r14-3380-gd3b5a1bccc219680dc19281b6fd6cc798bb679eb Author: Harald Anlauf Date: Mon Aug 21 21:23:57 2023 +0200 Fortran: implement vector sections in DATA statements [PR49588] gcc/fortran/ChangeLog: PR fortran/49588 * data.cc (gfc_advance_section): Derive next index set and next offset into DATA variable also for array references using vector sections. Use auxiliary array to keep track of offsets into indexing vectors. (gfc_get_section_index): Set up initial indices also for DATA variables with array references using vector sections. * data.h (gfc_get_section_index): Adjust prototype. (gfc_advance_section): Likewise. * resolve.cc (check_data_variable): Pass vector offsets. gcc/testsuite/ChangeLog: PR fortran/49588 * gfortran.dg/data_vector_section.f90: New test.
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #17 from Uroš Bizjak --- (In reply to r...@cebitec.uni-bielefeld.de from comment #16) > >> Regtested on i386-pc-solaris2.11; compiles both the reduced and the full > >> testcase with ICE. > > > > *WITH* ICE? > > With*out* ICE. Sorry for being too dumb to type ;-) Oh, thanks. I'll take care of the bug later today/tomorrow.
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #15 from Uroš Bizjak --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #13) >> > --- Comment #11 from Uroš Bizjak --- >> > Created attachment 55772 [details] >> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55772=edit >> > The correct proposed patch >> > >> > Eh, sorry for wrong attachment. This is the correct one. >> >> Regtested on i386-pc-solaris2.11; compiles both the reduced and the full >> testcase with ICE. > > *WITH* ICE? With*out* ICE. Sorry for being too dumb to type ;-)
[Bug fortran/110996] RISC-V vector Fortran: SEGV ICE during parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996 --- Comment #6 from Mikael Morin --- (In reply to Mikael Morin from comment #5) > Here sym->formal_ns is NULL because the symbol C has not been completely > setup. This makes the following an "obvious" fix: diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc index 8182ef29f43..5afb9f2e2d3 100644 --- a/gcc/fortran/decl.cc +++ b/gcc/fortran/decl.cc @@ -7496,6 +7496,7 @@ gfc_match_function_decl (void) sym->attr.module_procedure = 1; gfc_new_block = sym; + sym->formal_ns = gfc_current_ns; m = gfc_match_formal_arglist (sym, 0, 0); if (m == MATCH_NO) @@ -7993,6 +7994,7 @@ gfc_match_subroutine (void) sym = sym->result; gfc_new_block = sym; + sym->formal_ns = gfc_current_ns; /* Check what next non-whitespace character is so we can tell if there is the required parens if we have a BIND(C). */ However, that patch makes the situation worse by releasing the namespace for "c" too early, as we access it later in reject_statement (it is the "current" namespace).
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 --- Comment #15 from Uroš Bizjak --- (In reply to r...@cebitec.uni-bielefeld.de from comment #13) > > --- Comment #11 from Uroš Bizjak --- > > Created attachment 55772 [details] > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55772=edit > > The correct proposed patch > > > > Eh, sorry for wrong attachment. This is the correct one. > > Regtested on i386-pc-solaris2.11; compiles both the reduced and the full > testcase with ICE. *WITH* ICE?
[Bug c++/111097] mistifying bug triggered by trivial code change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111097 --- Comment #5 from Andrew Pinski --- > Worth noting, this code works correctly with Visual Studio and with clang. Gcc is known to be take more into account when it comes to aliasing rules of c and c++. That is exactly what you are running into really.
[Bug c++/111097] mistifying bug triggered by trivial code change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111097 --- Comment #4 from Andrew Pinski --- You can mark XV as may_alias attribute to fix the code too.
[Bug c++/111097] mistifying bug triggered by trivial code change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111097
--- Comment #3 from Fabio Cannizzo ---
Hi Richard
Using -fno-strict-aliasing the issue disappear, however I am not sure if that
is a real fix, or if it is merely circumstantial.
As mentioned, there are many other possible workarounds which also make the
issue disappear. The most curious one being the one below, where p has type
__m128i*, and simply casting it to XV* before the assignment, things stop
working.
Worth noting, this code works correctly with Visual Studio and with clang.
template
static FORCE_INLINE void doLoop(__m128i*& p, __m128i& xC, __m128i& xD,
__m128i bmask)
{
auto pend = p + N;
do {
__m128i tmp = advance1(p[0], p[JB], xC, xD, bmask);
xC = xD;
xD = tmp;
#if 1
struct XV {
__m128i m_v;
XV(__m128i v) : m_v(v) {}
};
((XV *)p)[0] = tmp;
#else
p[0] = tmp;
#endif
++p;
} while (p != pend);
}
