[Bug tree-optimization/105903] Missed optimization for __synth3way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105903 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #11 from Andrew Pinski --- (In reply to Andrew Pinski from comment #10) > (In reply to Andrew Pinski from comment #9) > > Actually this is not optimized all the way in the end. > > For greater3way, we still get: > > _8 = _5 > _6; > > _7 = _5 >= _6; > > _2 = _7 & _8; > > > > This should be optimized to just _5 >= _6 . > > Sorry `_5 > _6` . What is interesting is I tested with the patches I have for PR 106164 which should fix this but does not. If I try it out manually forwprop does catch it so I need to figure out what is going wrong in phiopt4.
[Bug tree-optimization/105903] Missed optimization for __synth3way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105903 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #9) > Actually this is not optimized all the way in the end. > For greater3way, we still get: > _8 = _5 > _6; > _7 = _5 >= _6; > _2 = _7 & _8; > > This should be optimized to just _5 >= _6 . Sorry `_5 > _6` .
[Bug tree-optimization/105903] Missed optimization for __synth3way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105903 Andrew Pinski changed: What|Removed |Added Target Milestone|14.0|--- Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #9 from Andrew Pinski --- Actually this is not optimized all the way in the end. For greater3way, we still get: _8 = _5 > _6; _7 = _5 >= _6; _2 = _7 & _8; This should be optimized to just _5 >= _6 .
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164
--- Comment #9 from Andrew Pinski ---
Created attachment 55658
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55658&action=edit
Secondary patch to add the thing I mentioned
Note this does not handle the constant case since we change `a >= 2` into `a >
1`.
For an example:
```
int f(int a, int b)
{
b =2;
int c = a != b;
int d = a >= b;
return c & d;
}
```
But we do handle now more ...
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Created attachment 55657 [details] > Patch which just needs some testcases > > This simple patch implements what I Mentioned about extending those other > patterns. Note this does implement all of what combine_comparisons implements but implements most of them. It could easily extend for some more. Like `x_2 >= y_3 && x_2 != y_3` could be added to convert to `x_2 > y_3`. I will do that in a different patch.
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164 --- Comment #7 from Andrew Pinski --- Created attachment 55657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55657&action=edit Patch which just needs some testcases This simple patch implements what I Mentioned about extending those other patterns.
[Bug modula2/110125] Variables are reported as uninitialized when only set inside WITH statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:3fd979bf568d91016b797818e6c9c940b6f389bd commit r13-7650-g3fd979bf568d91016b797818e6c9c940b6f389bd Author: Gaius Mulley Date: Sun Jul 30 02:18:57 2023 +0100 PR modula2/110125 variables reported as uninitialized when set inside WITH The modula-2 static analysis incorrectly identifies variables as uninitialized if they are initialized within a WITH statement. This bug fix re-implements the variable static analysis and will detect simple pointer record fields being accessed before being initialized. The static analysis is limited to the first basic block in a procedure. It does not check variant records, arrays or sets. A new option -Wuninit-variable-checking will turn on the new semantic checking (-Wall also enables the new checking). gcc/ChangeLog: PR modula2/110125 * doc/gm2.texi (Semantic checking): Include examples using -Wuninit-variable-checking. gcc/m2/ChangeLog: PR modula2/110125 * Make-lang.in (GM2-COMP-BOOT-DEFS): Add M2SymInit.def. (GM2-COMP-BOOT-MODS): Add M2SymInit.mod. * gm2-compiler/M2BasicBlock.mod: Formatting changes. * gm2-compiler/M2Code.mod: Remove import of VariableAnalysis from M2Quads. Import VariableAnalysis from M2SymInit.mod. * gm2-compiler/M2GCCDeclare.mod (PrintVerboseFromList): Add debugging print for a component. (TypeConstFullyDeclared): Call RememberType for every type. * gm2-compiler/M2GenGCC.mod (CodeReturnValue): Add parameter to GetQuadOtok. (CodeBecomes): Add parameter to GetQuadOtok. (CodeXIndr): Add parameter to GetQuadOtok. * gm2-compiler/M2Optimize.mod (ReduceBranch): Reformat and preserve operand token positions when reducing the branch quadruples. (ReduceGoto): Reformat. (FoldMultipleGoto): Reformat. (KnownReachable): Reformat. * gm2-compiler/M2Options.def (UninitVariableChecking): New variable declared and exported. (SetUninitVariableChecking): New procedure. * gm2-compiler/M2Options.mod (SetWall): Set UninitVariableChecking. (SetUninitVariableChecking): New procedure. * gm2-compiler/M2Quads.def (PutQuadOtok): Exported and declared. (VariableAnalysis): Removed. * gm2-compiler/M2Quads.mod (PutQuadOtok): New procedure. (doVal): Reformatted. (MarkAsWrite): Reformatted. (MarkArrayAsWritten): Reformatted. (doIndrX): Use PutQuadOtok. (MakeRightValue): Use GenQuadOtok. (MakeLeftValue): Use GenQuadOtok. (CheckReadBeforeInitialized): Remove. (IsNeverAltered): Reformat. (DebugLocation): New procedure. (BuildDesignatorPointer): Use GenQuadO to preserve operand token position. (BuildRelOp): Use GenQuadOtok ditto. * gm2-compiler/SymbolTable.def (VarCheckReadInit): New procedure. (VarInitState): New procedure. (PutVarInitialized): New procedure. (PutVarFieldInitialized): New procedure function. (GetVarFieldInitialized): New procedure function. (PrintInitialized): New procedure. * gm2-compiler/SymbolTable.mod (VarCheckReadInit): New procedure. (VarInitState): New procedure. (PutVarInitialized): New procedure. (PutVarFieldInitialized): New procedure function. (GetVarFieldInitialized): New procedure function. (PrintInitialized): New procedure. (LRInitDesc): New type. (SymVar): InitState new field. (MakeVar): Initialize InitState. * gm2-gcc/m2options.h (M2Options_SetUninitVariableChecking): New function declaration. * gm2-lang.cc (gm2_langhook_handle_option): Detect OPT_Wuninit_variable_checking and call SetUninitVariableChecking. * lang.opt: Add Wuninit-variable-checking. * gm2-compiler/M2SymInit.def: New file. * gm2-compiler/M2SymInit.mod: New file. gcc/testsuite/ChangeLog: PR modula2/110125 * gm2/switches/uninit-variable-checking/fail/testinit.mod: New test. * gm2/switches/uninit-variable-checking/fail/testlarge.mod: New test. * gm2/switches/uninit-variable-checking/fail/testlarge2.mod: New test. * gm2/switches/uninit-variable-checking/fail/testrecinit.mod: New test. * gm2/switches/uninit-variable-checking/fail/testrecinit2.mod: New test. * gm2/switches/uninit-variable-checking/fail/testrecinit5.mod
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164 --- Comment #6 from Andrew Pinski --- I think I have a better patch. There are patterns for: Convert (X OP1 CST1) || (X OP2 CST2). externding them easily to support: Convert (X OP1 Y) || (X OP2 Y). is a few lines. Don't even need to call combine_comparisons either. Once I test it I will submit the patch.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #36 from David Edelsohn ---
I don't know enough FORTRAN90 to instruct the compiler to use an external
function as if it were native.
EXTERNAL :: MYFUNC
changes the calling convention.
But if I manually change the assembly code so that "val" calls a C function a
print the values
#include
void
val_0 (int x, int y)
{
printf ("char(0x%x = %d) = %c 0 0 %c (LEN = %d)\n",
x, x, (char) (x>>24), (char) (x), y);
}
it produces the following output (32 bit):
char(0x4100 = 1090519040) = A 0 0 (LEN = 1)
char(0x41 = 65) = 0 0 A (LEN = 1)
char(0x41 = 65) = 0 0 A (LEN = 1)
for
call val ("A")
call val (c)
call val (char(a))
to demonstrate exactly what I see on big endian POWER.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #35 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #34)
> AIX POWER BE output:
>
> $ ./a.out
> val(fortran): 65 A
> val(fortran):0
> val(fortran):0
> val_c: char(65)='A'
> val_c: char(65)='A'
> val_c: char(804399656)='('
Ah, that is helpful. The handling of literals is thus fine and can be taken
as reference.
[Bug modula2/110189] Using an unknown TYPE as argument to VAL gives ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110189 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:8b0bd9ae4e2927f770da352ac64261411e6d652e commit r13-7647-g8b0bd9ae4e2927f770da352ac64261411e6d652e Author: Gaius Mulley Date: Sat Jul 29 22:41:13 2023 +0100 PR modula2/110189 Using an unknown TYPE as argument to VAL gives ICE This patch tidies P3Build.bnf and fixes error format specs in M2Quads.mod when encountering unknown symbols. gcc/m2/ChangeLog: PR modula2/110189 * gm2-compiler/M2Quads.mod (BuildAbsFunction): Replace abort format specifier. (BuildValFunction): Replace abort format specifier. (BuildCastFunction): Replace abort format specifier. (BuildMinFunction): Replace abort format specifier. (BuildMaxFunction): Replace abort format specifier. (BuildTruncFunction): Replace abort format specifier. * gm2-compiler/P3Build.bnf (Pass1): Remove. (Pass2): Remove. (Pass3): Remove. (Expect): Add Pass1. (AsmStatement): Remove Pass3. (AsmOperands): Remove Pass3. (AsmOperandSpec): Remove Pass3. (AsmInputElement): Remove Pass3. (AsmOutputElement): Remove Pass3. (AsmTrashList): Remove Pass3. gcc/testsuite/ChangeLog: PR modula2/110189 * gm2/pim/fail/foovaltype.mod: New test. (cherry picked from commit 8089f26b94f47d9923d3bc0c05aae09363983b2e) Signed-off-by: Gaius Mulley
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #34 from David Edelsohn ---
AIX POWER BE output:
$ ./a.out
val(fortran): 65 A
val(fortran):0
val(fortran):0
val_c: char(65)='A'
val_c: char(65)='A'
val_c: char(804399656)='('
[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #6) > I will backport to 13-branch in a few weeks. Could you please ping me after the backport? I would like to backport the fix for pr110825 and avoid a merge conflict, as the changes are adjacent.
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 Gaius Mulley changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Gaius Mulley --- Many thanks for the bug report and test code! Closing now as the patches have been applied to the gcc-13 branch.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #33 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #32)
> I'm leaning back to big-endian vs little-endian, and not a struct issue. A
> little-endian STRING will start at the lowest address and a big-endian
> STRING will start at the highest address.
OK. I've thought a little and came to the following testcase that might
help to understand what we have right now (a mess). It tests 6 = 3 x 2
variations, namely passing a literal constant, a variable, and a function
result via a temporary to either a fortran subroutine or a C function:
% cat value_10_c.c
#include
void
val_c (char c)
{
printf ("val_c: char(%d)='%c'\n", (int) c, c);
}
% cat value_10_f.f90
program p
implicit none
interface
subroutine val_c (c) bind(c)
use iso_c_binding, only: c_char
character(c_char), value :: c
end subroutine val_c
end interface
integer :: a = 65
character :: c = char(65)
call val ("A")
call val (c)
call val (char(a))
call val_c ("A")
call val_c (c)
call val_c (char(a))
contains
subroutine val (c)
character(kind=1), value :: c
print *, "val(fortran): ", iachar (c), c
end
end
With the Intel compiler on x86 I get what I expect:
val(fortran): 65 A
val(fortran): 65 A
val(fortran): 65 A
val_c: char(65)='A'
val_c: char(65)='A'
val_c: char(65)='A'
With current 14-trunk on x86 I get:
% gfc-14 value_10_f.f90 value_10_c.c && ./a.out
val(fortran): 65 A
val(fortran): 65 A
val(fortran): 65 A
val_c: char(65)='A'
val_c: char(65)='A'
val_c: char(-122)='�'
The last line of output is junk, which is understood by looking at the dump,
as in that case we wrongly pass a reference instead of the value.
The C interface part hasn't been touched by the patches in the current PR
and obviously also needs a fix.
So the next thing is to understand how the C interface works and get it right
and consistent (both for LE and BE), and with that knowledge find out how the
Fortran part might be.
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 --- Comment #16 from CVS Commits --- The releases/gcc-13 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:4fa9afdc9b52cfa9ea16443418de29e0e31b293b commit r13-7646-g4fa9afdc9b52cfa9ea16443418de29e0e31b293b Author: Gaius Mulley Date: Sat Jul 29 21:04:26 2023 +0100 PR modula2/110126 variables are reported as unused when referenced by ASM fix This patch fixes the trash list of the asm statement. It introduces a separate build procedure for trashed elements. gcc/m2/ChangeLog: PR modula2/110126 * gm2-compiler/M2Quads.def (BuildAsmElement): Remove trash parameter. (BuildAsmTrash): New procedure. * gm2-compiler/M2Quads.mod (BuildAsmTrash): New procedure. (BuildAsmElement): Remove trash parameter. * gm2-compiler/P3Build.bnf (AsmTrashList): Rewrite. (cherry picked from commit bf470895905e9152424076d1630a9d2c60de023b) Signed-off-by: Gaius Mulley
[Bug tree-optimization/100864] (a&!b) | b is not opimized to a | b for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2023-July/62 |il/gcc-patches/2023-July/62 |5289.html |5792.html --- Comment #8 from Andrew Pinski --- New patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625792.html
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #32 from David Edelsohn ---
i think that I see part of the difference. The 005t.original dump shows
(intermingled with sources)
! call val ("B","B")
val (&"B"[1]{lb: 1 sz: 1}, "B", 1, 1);
! call val ("A",char(65))
val (&"A"[1]{lb: 1 sz: 1}, "A", 1, 1);
! call val ("A",char(a))
{
character(kind=1) char.6;
char.6 = (character(kind=1)) a;
val (&"A"[1]{lb: 1 sz: 1}, char.6, 1, 1);
}
! call val ("A",mychar(65))
{
static integer(kind=4) C.2654 = 65;
character(kind=1) str.7[1];
mychar ((character(kind=1)[1:1] *) &str.7, 1, &C.2654);
val (&"A"[1]{lb: 1 sz: 1}, str.7[0], 1, 1);
}
! call val ("A",mychar(a))
{
character(kind=1) str.8[1];
mychar ((character(kind=1)[1:1] *) &str.8, 1, &a);
val (&"A"[1]{lb: 1 sz: 1}, str.8[0], 1, 1);
}
char(65) is folded by the FORTRAN front-end to "A", so it is passed in the same
manner that elicits the shift. The rest of the calls pass 65. The string is
left-shifted and the number is right-shifted. GFORTRAN seems to assume that
passing a STRING by value will be padded the same as a number or character,
which isn't accurate.
I'm leaning back to big-endian vs little-endian, and not a struct issue. A
little-endian STRING will start at the lowest address and a big-endian STRING
will start at the highest address.
[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=83028
--- Comment #14 from Andrew Pinski ---
(In reply to Nicolai Josuttis from comment #13)
> Oh, sorry, your are right, the example indeed works.
> BUT: I used in fact a slightly different example
> (sorry, didn't expect that there is a difference):
>
> int main() {
> int i = 0;
> int j = i++ << i++; // OK, NO WARNING
> std::cout << i++ << i++; // still WARNING
> }
>
> see https://wandbox.org/permlink/ioZnOv3oAp5F0BsQ
>
> According to my understanding the warning should especially
> also not come when we pass i++ twice to std::cout
> (to sequence output was a key goal of this fix in C++17).
>
> But may be I am missing something.
That would be PR 83028 .
[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110790 --- Comment #7 from Sergei Trofimovich --- The new change did not break `grep`, `gmp` and `mpfr` on x86_64-linux and i686-linux. Success!
[Bug modula2/109952] Inconsistent HIGH values with 'ARRAY OF CHAR'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109952 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:b555f824d6b6f2ab759f57098a7b4b3b47470c64 commit r13-7645-gb555f824d6b6f2ab759f57098a7b4b3b47470c64 Author: Gaius Mulley Date: Sat Jul 29 17:33:28 2023 +0100 PR modula2/109952 Fix oversight in latest change gcc/ PR modula2/109952 * doc/gm2.texi (Standard procedures): Fix Next link. (cherry picked from commit e8d41e031b9f52601249ec7e4c4215b851cc8ffe) Signed-off-by: Gaius Mulley
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 --- Comment #15 from CVS Commits --- The releases/gcc-13 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:3ad40f65a7c89af2f3cb71c06e327ee33a996bd4 commit r13-7644-g3ad40f65a7c89af2f3cb71c06e327ee33a996bd4 Author: Gaius Mulley Date: Sat Jul 29 17:24:38 2023 +0100 PR modula2/110126 variables are reported as unused when referenced by ASM This patches fixes two problems with the asm statement. gm2 -Wall -c fooasm3.mod generates an incorrect warning and gm2 cannot concatenate strings before an ASM statement. The asm statement now accepts a constant expression (rather than a string) and it updates the variable read/write use lists as appropriate. gcc/m2/ChangeLog: PR modula2/110126 * gm2-compiler/M2GenGCC.mod (BuildTreeFromInterface): Remove tokenno parameter. Use object tok instead of tokenno. (BuildTrashTreeFromInterface): Use object tok instead of GetDeclaredMod. (CodeInline): Remove tokenno from parameter list to BuildTreeFromInterface. * gm2-compiler/M2Quads.def (BuildAsmElement): Exported and defined. * gm2-compiler/M2Quads.mod (BuildOptimizeOff): Reformatted. (BuildInline): Reformatted. (BuildLineNo): Reformatted. (UseLineNote): Reformatted. (BuildAsmElement): New procedure. * gm2-compiler/P0SyntaxCheck.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/P1Build.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/P2Build.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/P3Build.bnf (AsmOperands): Rewrite. (AsmOperandSpec): Rewrite. (AsmOutputList): New rule. (AsmInputList): New rule. (TrashList): Rewrite. * gm2-compiler/PCBuild.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/PHBuild.bnf (AsmOperands): Use ConstExpression instead of string. (AsmElement): Use ConstExpression instead of string. (TrashList): Use ConstExpression instead of string. * gm2-compiler/SymbolTable.def (PutRegInterface): Rewrite interface. (GetRegInterface): Rewrite interface. * gm2-compiler/SymbolTable.mod (SetFirstUsed): New procedure. (PutFirstUsed): New procedure. (PutRegInterface): Rewrite. (GetRegInterface): Rewrite. gcc/testsuite/ChangeLog: PR modula2/110126 * gm2/pim/pass/fooasm3.mod: New test. (cherry picked from commit 990d10ab23360fef8b5eb6937ac10b4f67f46e2d) Signed-off-by: Gaius Mulley
[Bug target/110787] [14 regression] ICE building SYSTEM.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110787 --- Comment #6 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:e68a31549d9827030391d837951be96a5f95f291 commit r14-2866-ge68a31549d9827030391d837951be96a5f95f291 Author: Roger Sayle Date: Sat Jul 29 17:07:58 2023 +0100 [Committed] Use QImode for offsets in zero_extract/sign_extract in i386.md As suggested by Uros, this patch changes the ZERO_EXTRACTs and SIGN_EXTRACTs in i386.md to consistently use QImode for bit offsets (i.e. third and fourth operands), matching the use of QImode for bit counts in shifts and rotates. This iteration also corrects the "ne:QI" vs "eq:QI" mistake in the previous version, which was responsible for PR 110787 and PR 110790 and so was rapidly reverted last weekend. New test cases have been added to check the correct behaviour. 2023-07-29 Roger Sayle gcc/ChangeLog PR target/110790 * config/i386/i386.md (extv): Use QImode for offsets. (extzv): Likewise. (insv): Likewise. (*testqi_ext_3): Likewise. (*btr_2): Likewise. (define_split): Likewise. (*btsq_imm): Likewise. (*btrq_imm): Likewise. (*btcq_imm): Likewise. (define_peephole2 x3): Likewise. (*bt): Likewise (*bt_mask): New define_insn_and_split. (*jcc_bt): Use QImode for offsets. (*jcc_bt_1): Delete obsolete pattern. (*jcc_bt_mask): Use QImode offsets. (*jcc_bt_mask_1): Likewise. (define_split): Likewise. (*bt_setcqi): Likewise. (*bt_setncqi): Likewise. (*bt_setnc): Likewise. (*bt_setncqi_2): Likewise. (*bt_setc_mask): New define_insn_and_split. (bmi2_bzhi_3): Use QImode offsets. (*bmi2_bzhi_3): Likewise. (*bmi2_bzhi_3_1): Likewise. (*bmi2_bzhi_3_1_ccz): Likewise. (@tbm_bextri_): Likewise. gcc/testsuite/ChangeLog PR target/110790 * gcc.target/i386/pr110790-1.c: New test case. * gcc.target/i386/pr110790-2.c: Likewise.
[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110790 --- Comment #6 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:e68a31549d9827030391d837951be96a5f95f291 commit r14-2866-ge68a31549d9827030391d837951be96a5f95f291 Author: Roger Sayle Date: Sat Jul 29 17:07:58 2023 +0100 [Committed] Use QImode for offsets in zero_extract/sign_extract in i386.md As suggested by Uros, this patch changes the ZERO_EXTRACTs and SIGN_EXTRACTs in i386.md to consistently use QImode for bit offsets (i.e. third and fourth operands), matching the use of QImode for bit counts in shifts and rotates. This iteration also corrects the "ne:QI" vs "eq:QI" mistake in the previous version, which was responsible for PR 110787 and PR 110790 and so was rapidly reverted last weekend. New test cases have been added to check the correct behaviour. 2023-07-29 Roger Sayle gcc/ChangeLog PR target/110790 * config/i386/i386.md (extv): Use QImode for offsets. (extzv): Likewise. (insv): Likewise. (*testqi_ext_3): Likewise. (*btr_2): Likewise. (define_split): Likewise. (*btsq_imm): Likewise. (*btrq_imm): Likewise. (*btcq_imm): Likewise. (define_peephole2 x3): Likewise. (*bt): Likewise (*bt_mask): New define_insn_and_split. (*jcc_bt): Use QImode for offsets. (*jcc_bt_1): Delete obsolete pattern. (*jcc_bt_mask): Use QImode offsets. (*jcc_bt_mask_1): Likewise. (define_split): Likewise. (*bt_setcqi): Likewise. (*bt_setncqi): Likewise. (*bt_setnc): Likewise. (*bt_setncqi_2): Likewise. (*bt_setc_mask): New define_insn_and_split. (bmi2_bzhi_3): Use QImode offsets. (*bmi2_bzhi_3): Likewise. (*bmi2_bzhi_3_1): Likewise. (*bmi2_bzhi_3_1_ccz): Likewise. (@tbm_bextri_): Likewise. gcc/testsuite/ChangeLog PR target/110790 * gcc.target/i386/pr110790-1.c: New test case. * gcc.target/i386/pr110790-2.c: Likewise.
[Bug modula2/110019] Reported line numbers ar off-by-1 when preprocessing source files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110019 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:07c1033f003a858f4bfc6bb9e6b7ce67670db974 commit r13-7643-g07c1033f003a858f4bfc6bb9e6b7ce67670db974 Author: Gaius Mulley Date: Sat Jul 29 15:16:08 2023 +0100 PR modula2/110019 Reported line numbers off by 1 when cpp invoked. Fix off by one in m2.flex when the line number is set via cpp. gcc/m2/ChangeLog: PR modula2/110019 * gm2-compiler/SymbolKey.mod (SearchAndDo): Reformatted. (ForeachNodeDo): Reformatted. * gm2-compiler/SymbolTable.mod (AddListify): Join list with "," or "and" if more than one word is in the list. * m2.flex: Remove -1 from atoi(yytext) line number. gcc/testsuite/ChangeLog: PR modula2/110019 * gm2/cpp/fail/cpp-fail.exp: New test. * gm2/cpp/fail/foocpp.mod: New test. (cherry picked from commit 29c82c6ca929e0f5eccfe038dea71177d814c6b7) Signed-off-by: Gaius Mulley
[Bug c++/110845] Function call when it should inline?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110845 --- Comment #4 from KL --- My mistake indeed, You are right everything is OK :+1
[Bug modula2/110003] Wrong source line listed for unused parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110003 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:6ace58a7241d500a9f57521a581d59f7a2f8b9fd commit r13-7641-g6ace58a7241d500a9f57521a581d59f7a2f8b9fd Author: Gaius Mulley Date: Sat Jul 29 13:48:22 2023 +0100 PR modula2/110003 Wrong source line listed for unused parameters Ensure that the parameter token position is recorded for both definition and implementation modules. The shadow variable is created inside BuildFormalParameterSection. The shadow variable needs to have the other definition or implementation module token position set when CheckFormalParameterSection is called. This allows the MetaError family of procedures to request the implementation module token position when reporting unused parameters. gcc/m2/ChangeLog: PR modula2/110003 * gm2-compiler/P2SymBuild.mod (GetParameterShadowVar): Import. (CheckFormalParameterSection): Call PutDeclared for the shadow variable associated with the parameter. (cherry picked from commit 7c0e2159afb3235950d3d8f61ef085cd1ccf0dfc) Signed-off-by: Gaius Mulley
[Bug c++/110850] New: Evaluation order of assignment operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110850
Bug ID: 110850
Summary: Evaluation order of assignment operands
Product: gcc
Version: 13.2.0
URL: https://godbolt.org/z/89TPG4eaK
Status: UNCONFIRMED
Keywords: diagnostic, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugreport0 at proton dot me
Target Milestone: ---
In C++17 in assignment expressions the right-hand side evaluation and its side
effects are sequenced before the left-hand side evaluation and its side
effects, so this snippet
struct Trivial {
int x;
};
int postincrement(int& i) {
std::cout << "postincrement\n";
return i++;
}
int load(int& i) {
std::cout << "load\n";
return i;
}
int main() {
Trivial a[1]{};
int i = 0;
(std::cout << "LHS\n", a[postincrement(i)])
= (std::cout << "RHS\n", Trivial{load(i)});
std::cout << a->x << '\n';
}
should output "RHS load LHS postincrement 0". Instead, it outputs "RHS LHS
postincrement load 1". Around gcc 7.1 evaluation order seems to have been fixed
in many cases, but not for "aggregate assignment" such as with this Trivial
type.
The URL associated with this report demonstrates several variations of this
example, showing in addition discrepancy between compile- and run-time
behaviour and between optimization levels, and inconsistency in warning
messages in cases other than "aggregate assignment".
Bug report #97288 is related, but it assumes implicit lvalue-to-rvalue
conversion to be part of the right operand evaluation, and in later versions
described behaviour disappears, reappears and finally disappears.
[Bug c++/110848] Consider enabling -Wvla by default in C++ modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848 --- Comment #6 from Aaron Ballman --- (In reply to Andrew Pinski from comment #4) > Maybe my issue is this has been a documented extension for 20 years now. Which is totally fair -- we don't usually enable congratulatory diagnostics by default. > -pedantic or -std=c++NN has always rejected it like it should. GCC has other > extensions which folks could use by accident too (like statement > expressions). Why is VLA special here? FWIW, I can't honestly say I've ever seen someone use a statement expression accidentally, though I believe it's possible to do so if you work hard enough at it. That said, I think misuse of accidental VLAs has more opportunity for poor security behavior (specifically around attacker-controllable stack usage) than for statement expressions. Given the security concerns coupled with the ease of accidental usage, I think VLAs *are* different than statement expressions. Some supporting evidence of the confusion in the wild: https://stackoverflow.com/questions/70912167/how-do-i-tell-if-i-am-using-vla-variable-length-array https://stackoverflow.com/questions/39334435/variable-length-array-vla-in-c-compilers https://ddanilov.me/default-non-standard-features/ https://meta.stackoverflow.com/questions/376955/what-should-i-do-when-an-op-uses-variable-length-arrays-vlas-in-c https://cplusplus.com/forum/beginner/284866/ (Granted, there's confusion about *everything* in C and C++.) It's worth noting that -std=c++NN does *not* reject use of VLAs; you have to pass -pedantic or -Wvla to get the diagnostic: https://godbolt.org/z/PGorTYG7r
[Bug ipa/93385] [11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #54 from rguenther at suse dot de --- > Am 29.07.2023 um 11:16 schrieb xry111 at gcc dot gnu.org > : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 > > Xi Ruoyao changed: > > What|Removed |Added > > CC||xry111 at gcc dot gnu.org > > --- Comment #53 from Xi Ruoyao --- > Note that this occasionally causes csmith failure and produces duplicates. > Maybe we should tell the csmith testers not to disable DCE if fuzzing against > GCC 11. I think disabling DCE is only useful on trunk. > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug ipa/93385] [11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #53 from Xi Ruoyao --- Note that this occasionally causes csmith failure and produces duplicates. Maybe we should tell the csmith testers not to disable DCE if fuzzing against GCC 11.
[Bug ipa/93385] [11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #52 from Andrew Pinski --- *** Bug 110818 has been marked as a duplicate of this bug. ***
[Bug ipa/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #18 from Andrew Pinski --- Yes this is a dup of bug 93385. *** This bug has been marked as a duplicate of bug 93385 ***
[Bug ipa/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 Andrew Pinski changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill |a/show_bug.cgi?id=104543|a/show_bug.cgi?id=93385 --- Comment #17 from Andrew Pinski --- Maybe PR 93385.
[Bug ipa/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5
[Bug ipa/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 --- Comment #16 from Andrew Pinski --- (In reply to Andrew Pinski from comment #15) > _4 = *i_3(D); > > That is the problem. > cmpl%edx, 0 > is a comparing %edx to the memory location 0 ... == IPA-SRA decisions == Evaluating analysis results for f/3 Will remove return value. Will remove parameter 0 Created adjustments: m_always_copy_start: 1 Will SKIP return. Created new node f.isra/7
[Bug ipa/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords||wrong-code Component|middle-end |ipa --- Comment #15 from Andrew Pinski --- _4 = *i_3(D); That is the problem. cmpl%edx, 0 is a comparing %edx to the memory location 0 ...
[Bug middle-end/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 --- Comment #14 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #12) > Created attachment 55656 [details] > Assembly code > > The only difference between GCC 9 and GCC 10 is: > #cmpl%edx, 0 > > GCC 10 has this line uncommented. > > So I almost think this is a bug in the binutils ... Hmm, but isn't "cmpl %edx, 0" accessing address 0? Constant 0 should be "$0". I don't think it's correct...
[Bug middle-end/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 --- Comment #13 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #11) > (In reply to Xi Ruoyao from comment #9) > > https://godbolt.org/z/5vr1oPExb > > > > Looks like .LC0 is not aligned but GCC 11 attempts to use movdqa to load it. > > But it is aligned ... > Maybe there is a binutils fix for merging of .rodata.cst sections Alright, godbolt does not print .align directives by default...
[Bug middle-end/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 --- Comment #12 from Andrew Pinski --- Created attachment 55656 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55656&action=edit Assembly code The only difference between GCC 9 and GCC 10 is: #cmpl%edx, 0 GCC 10 has this line uncommented. So I almost think this is a bug in the binutils ...
[Bug c++/110845] Function call when it should inline?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110845 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Xi Ruoyao --- (In reply to KL from comment #2) > Changed main to foo: > same behavior It's because you don't have a return statement in foo, causing an undefined behavior. And GCC considers undefined behaviors highly improbable to be executed, so the same logic (not to inline too much into "cold" code paths) still applies. If you add the return statement they are inlined: https://godbolt.org/z/Ko9r4fn3d
[Bug middle-end/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 --- Comment #11 from Andrew Pinski --- (In reply to Xi Ruoyao from comment #9) > https://godbolt.org/z/5vr1oPExb > > Looks like .LC0 is not aligned but GCC 11 attempts to use movdqa to load it. But it is aligned ... Maybe there is a binutils fix for merging of .rodata.cst sections
[Bug middle-end/110818] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818 Xi Ruoyao changed: What|Removed |Added Summary|Segmentation fault with |[11 Regression] |'-O3 -fno-dce -fno-ipa-cp |Segmentation fault with |-fno-tree-dce |'-O3 -fno-dce -fno-ipa-cp |-fno-tree-sink' |-fno-tree-dce ||-fno-tree-sink' Known to work||9.1.0 Keywords|needs-reduction | Known to fail||10.5.0 --- Comment #10 from Xi Ruoyao --- And "struct a e()" should be "struct a e(short unused)". But after this fix it still crashes. It's a regression started in GCC 10, but GCC 10 branch is closed anyway.
[Bug middle-end/110818] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818
--- Comment #9 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #8)
> (In reply to CTC from comment #7)
> > No errors or warnings raised and 0 alarms generated by the analysis when
> > analyzed by frama-c.
>
> Still undefined reduced testcase (with `-Wextra -Wall`):
> : At top level:
> :16:6: warning: return type of 'main' is not 'int' [-Wmain]
>16 | void main() { f(&c); }
> | ^~~~
>
> Once I change the return type to int, the reduced testcase always passes.
No it doesn't:
https://godbolt.org/z/5vr1oPExb
Looks like .LC0 is not aligned but GCC 11 attempts to use movdqa to load it.
[Bug tree-optimization/110819] Missed optimization: when vector's size is 0 but vector::reserve has been called.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110819 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- (In reply to AK from comment #2) > > When compiled with clang, libstdc++'s std::vector uses > > __builtin_operator_new which always has the -fassume-sane-operator-new > > semantics, and so can be optimized. > > yes clang optimizes with libstdc++ as well. what can be done in gcc for it > to detect that the new+delete pair can be optimized away? Basically we'll need __builtin_operator_new. See all the "see also" links.
[Bug middle-end/110818] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110818
--- Comment #8 from Andrew Pinski ---
(In reply to CTC from comment #7)
> No errors or warnings raised and 0 alarms generated by the analysis when
> analyzed by frama-c.
Still undefined reduced testcase (with `-Wextra -Wall`):
: At top level:
:16:6: warning: return type of 'main' is not 'int' [-Wmain]
16 | void main() { f(&c); }
| ^~~~
Once I change the return type to int, the reduced testcase always passes.
[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315 --- Comment #9 from Gleb Fotengauer-Malinovskiy --- (In reply to Andrew Macleod from comment #7) > Created attachment 55591 [details] > potental patch > > I've attached Aldy's patch for PR109695 which he had backported to GCC13 > back in May. > This does resolve the issue.. Assuming we want to apply it GCC13. The > original variant has been in trunk for a while now. Im running this thru a > bootstrap/regression run now. > > I don't know if there is anything further you want to try it with? We have applied this patch in the ALT Sisyphus gcc13 package and have not encountered any regressions so far (we do daily test rebuilds of the entire repository for x86_64 arch). Additionally, we were able to rebuild the glaxnimate package with gcc13.
