[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #17 from Tom Stellard --- It looks like the issue is that the function classify_object_over_fdes() expects there to be a zero-length fde at the end of the fde array. It doesn't find one so it runs over the end of the array and segfaults. I don't know if this assumption is wrong or if LLVM should be emitting a zero-length fde at the end of the array.
[Bug analyzer/109120] New: False positive -Wanalyzer-malloc-leak with failed iconv_open()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
Bug ID: 109120
Summary: False positive -Wanalyzer-malloc-leak with failed
iconv_open()
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: urs at akk dot org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Created attachment 54660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54660=edit
minimal test case
gcc build from git @ a9835599fdb56f33da23e4514a9e21d8c2d51d71
with
configure --program-suffix=-13 --enable-languages=c,lto --enable-lto
--disable-multilib --enable-default-pie
make -j 12 BOOT_CFLAGS='-pipe -O0 -w' bootstrap
on
x86_64-pc-linux-gnu (AMD Ryzen 7 PRO 6850U); Debian GNU/Linux 12 (bookworm);
Kernel 6.1.0-4-amd64; GLIBC 2.36-8
gcc-13 -v -save-temps -freport-bug -g -std=c11 -O0 -fanalyzer -c iconv.c -o
iconv
results in
iconv.c: In function ‘t’:
iconv.c:11:5: warning: leak of ‘cd’ [CWE-401] [-Wanalyzer-malloc-leak]
11 | return;
| ^~
‘t’: events 1-2
|
|8 | if ((cd = iconv_open("From", "To")) != (iconv_t) (-1)) {
| |~ ^~~~
| || |
| || (1) allocated here
| |(2) following ‘false’ branch (when ‘cd ==
18446744073709551615’)...
|
‘t’: event 3
|
|cc1:
| (3): ...to here
|
‘t’: event 4
|
| 11 | return;
| | ^~
| | |
| | (4) ‘cd’ leaks here; was allocated at (1)
|
[Bug middle-end/96564] [11/12/13 Regression] New maybe use of uninitialized variable warning since r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564 --- Comment #10 from Andrew Pinski --- Note I don't think you really need exact aliasing information to optimize this though. See PR 109119 for an example where you just need to know on the path where PRE adds the load, the two addresses are equal due to the condition.
[Bug tree-optimization/109119] New: missing loading fre with branch comparing two pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109119
Bug ID: 109119
Summary: missing loading fre with branch comparing two pointers
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
void fun (unsigned *x, unsigned *b) {
asm volatile(""::"r"(*x));
unsigned *a = b;//malloc (*x);
if (a == 0)
return;
if (a != x)// (A)
*a = *x;
*x = *a;
}
```
GCC currently produces:
[local count: 1073741824]:
_1 = *x_6(D);
__asm__ __volatile__("" : : "r" _1);
if (b_7(D) == 0B)
goto ; [18.09%]
else
goto ; [81.91%]
[local count: 879501929]:
if (x_6(D) != b_7(D))
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 263850576]:
pretmp_10 = *b_7(D);
goto ; [100.00%]
[local count: 615651353]:
*b_7(D) = _1;
[local count: 879501929]:
# prephitmp_11 = PHI
*x_6(D) = prephitmp_11;
But pretmp_10 should be the same as _1 as at that point b_7 == x_6.
Note I noticed this while looking into PR 96564.
[Bug target/109117] "__builtin_ia32_vaesdec_v16qi" compiled only with option -mvaes report ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109117 lin1.hu at intel dot com changed: What|Removed |Added Attachment #54659|No need AVX512VL for|0001-i386-Add-missing-OPTIO description|256bit, so I modify the |N_MASK_ISA_AVX512VL-in-i386 |original patch. |-bu.patch --- Comment #3 from lin1.hu at intel dot com --- Comment on attachment 54659 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54659 0001-i386-Add-missing-OPTION_MASK_ISA_AVX512VL-in-i386-bu.patch No need AVX512VL for 256bit, so I modify the original patch.
[Bug target/109117] "__builtin_ia32_vaesdec_v16qi" compiled only with option -mvaes report ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109117 --- Comment #2 from lin1.hu at intel dot com --- Created attachment 54659 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54659=edit No need AVX512VL for 256bit, so I modify the original patch.
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #6 from Hans-Peter Nilsson --- (In reply to David Malcolm from comment #4) > DejaGnu version 1.6.1 > Expect version5.45.4 > Tcl version 8.6 Close enough to say that's probably *not* it, also see below... > What does the generated > testsuite/gcc/diagnostic-format-sarif-file-4.c.sarif > file look like? I'm attaching mine for reference. Besides file-paths and version strings, it's the same; attached for reference. Perhaps your language environment is different? I always build with "LC_ALL=C". (everybody speaks the C language - it must be right! ;) Indeed, if I run the test-suite prefixing the "make" invocation with 'env "LC_ALL=en_US.UTF-8"' or 'env "LC_ALL=C.UTF-8"' the test passes, so I think we found the cause; an assumption that the environment speaks UTF-8. My environment is ISO-8859-1, and I guess similarly the reporter's and John Anglin's tester environments. I'm also guessing you'll see the reflection; the error I see, if you run the test-suite prefixing your make invocation with 'env "LC_ALL=C" "LANG=C"'. It unfortunately makes no difference to add "setenv LC_ALL C" to dg.exp (it's already set via gcc-dg.exp), so this needs some other tweak to force the environment to the preferred setting for the test.
[Bug middle-end/109118] New: [13 Regression] gcc.dg/mla_1.c failed on target w/o __Uint32x4_t support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109118
Bug ID: 109118
Summary: [13 Regression] gcc.dg/mla_1.c failed on target w/o
__Uint32x4_t support
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: haochen.jiang at intel dot com
Target Milestone: ---
For target w/o __Uint32x4_t support, like i386, when run through the testsuite,
we will get error like this:
error: unknown type name '__Uint32x4_t'; did you mean '__uint128_t'
We can reproduce by:
make check RUNTESTFLAGS="dg.exp=gcc.dg/mla_1.c --target_board='unix{-m64\
-march=cascadelake,-m32\ -march=cascadelake,-m32,-m64}'"
It should be a simple fix. But I am not sure whether the testcase aims to test
on middle-end or aarch64 target specific.
If we want to test on middle-end, we might not use the type __Uint32x4_t in
testcase.
If it is a just aarch64 specific test, I suppose we can move the target
aarch64*-*-* to dg-do compile to skip for other backend.
Christina, what is your opinion?
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #5 from Hans-Peter Nilsson --- Created attachment 54658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54658=edit mine, from native build/test of yesterday (see file for exact version).
[Bug target/109117] "__builtin_ia32_vaesdec_v16qi" compiled only with option -mvaes report ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109117 --- Comment #1 from lin1.hu at intel dot com --- Created attachment 54657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54657=edit Untested fix.
[Bug target/109117] New: "__builtin_ia32_vaesdec_v16qi" compiled only with option -mvaes report ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109117
Bug ID: 109117
Summary: "__builtin_ia32_vaesdec_v16qi" compiled only with
option -mvaes report ICE.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lin1.hu at intel dot com
Target Milestone: ---
When the compiler compiles "__builtin_ia32_vaesdec_v16qi" with option
-mvaes,-no-avx512vl, it reports ICE.
The detail can refer to https://godbolt.org/z/fEGavbGWz.
Test-case:
typedef char __v16qi __attribute__ ((__vector_size__(16)));
typedef long long __m128i __attribute__((__vector_size__(16),
__aligned__(16)));
volatile __v16qi x, y;
volatile __m128i res;
void
foo (void)
{
res = (__m128i) __builtin_ia32_vaesdec_v16qi (x, y);
}
[Bug libfortran/109099] Assignment in NAMELIST input does not fill in row-column order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109099 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- Well I got curious here as I implemented many of the namelist features and have not seen too many namelist related bugs. This is with the example in the original post. $ gfc -std=f2003 pr109099.f90 $ ./a.out At line 9 of file pr109099.f90 Fortran runtime error: Cannot match namelist object name 234 My thinking is auto-filling anything is a legacy extension. Now if one comments out the READ and sees how gfortran writes the namelist: $ gfc -std=f2003 pr109099.f90 $ ./a.out X= 12*999, / My own thought is that it is always good to check things this way to see if the "form" of the namelist input is good. Modifying your program: program testit integer, allocatable :: x(:,:); namelist / group / x character(len=80) :: input(3) allocate( x(3,4),source=999) x = reshape ([999, 999, 999, 999, 999, 999, 1, 2, 3, 4, 999, 999], [3, 4]) print *, shape(x), size(x) input=[& " ",& " x(2,3)=1,2,3,4,",& "/ "] !read( input, nml=group) write(*,group) end program testit Assuming I have your intent right in the reshape. $ ./a.out 3 4 12 X= 6*999,1 ,2 ,3 ,4 , 2*999, / and then doing the following shows a safer way to do these things: program testit integer, allocatable :: x(:,:); namelist / group / x character(len=20) :: input(3) allocate( x(3,4),source=999) input=["",& " X= 6*999,1,2,3,4,",& " 2*999,/ "] read( input, nml=group) write(*,group) end program testit $ gfc -std=f2003 pr109099.f90 $ ./a.out X= 6*999,1 ,2 ,3 ,4 , 2*999, /
[Bug target/109093] [13 regression] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
H.J. Lu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #10 from H.J. Lu ---
We have
static bool
ix86_can_eliminate (const int from, const int to)
{
if (stack_realign_fp)
return ((from == ARG_POINTER_REGNUM
&& to == HARD_FRAME_POINTER_REGNUM)
|| (from == FRAME_POINTER_REGNUM
&& to == STACK_POINTER_REGNUM));
else
return to == STACK_POINTER_REGNUM ? !frame_pointer_needed : true;
}
Before IRA, stack_realign_fp is set to true by AVX piecewise move and store.
LRA replaces frame pointer with stack pointer:
insn 259 261 297 4 (set (reg/f:DI 2 cx [144])
(plus:DI (reg/f:DI 7 sp)
(const_int -32 [0xffe0]))) 241 {*leadi}
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 19 frame)
(const_int -32 [0xffe0]))
(nil)))
In ix86_finalize_stack_frame_flags, stack_realign_fp is set to false. Since
the stack realignment skipped, local variable is no longer properly aligned.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #25 from James McKelvey --- I just tried the latest snapshot and it works great, no need to specify --disable-multilib.
[Bug tree-optimization/109115] [13 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in upper_bound, at value-range.h:950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109115 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #5 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #3) > I think it returns false if it is has a type which isn't representable with > the particular range. > Which isn't the case here. > The type is representable, just the range is undefined_p (). Correct. If the range is undefined, then you cannot ask for the upper bounds because there is not one.
[Bug target/109116] vector_pair register allocation bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109116 --- Comment #2 from Chip Kerchner --- This could be a bigger issue with register allocation after the disassemble of an opaque object like vector_pair or MMA.
[Bug modula2/109103] Missing function internal_error_at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109103 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Gaius Mulley --- Many thanks for the bug report - now fixed.
[Bug modula2/109103] Missing function internal_error_at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109103 --- Comment #2 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:370298f493020eeff48bc2e56463c1097ed67b1d commit r13-6649-g370298f493020eeff48bc2e56463c1097ed67b1d Author: Gaius Mulley Date: Mon Mar 13 23:03:24 2023 + PR 109103 Modula2 Missing function internal_error_at m2expr.cc should call to internal_error_at, but that function does not exist yet. For symmetry with the other error reporting functions, it should be added. This patch provides this function and also corrects obvious bool/int parameter mismatches in m2options.h and m2expr.h. gcc/m2/ChangeLog: PR modula2/109103 * gm2-compiler/M2ALU.def (PushString): New parameter issueError. * gm2-compiler/M2ALU.mod (PushString): New parameter issueError. * gm2-compiler/SymbolTable.mod (PushString): New parameter issueError. * gm2-gcc/m2decl.cc (m2decl_DetermineSizeOfConstant): Pass location to interpret_m2_integer. (m2decl_BuildConstLiteralNumber): New parameter issueError. * gm2-gcc/m2expr.cc (m2expr_IsTrue): Replace int with bool. (m2expr_IsFalse): Replace int with bool. (m2expr_AreConstantsEqual): Replace int with bool. (m2expr_BuildBinaryForeachWordDo): Call m2linemap_internal_error_at. (append_digit): Ditto. (m2expr_interpret_integer): Add location parameter. (append_m2_digit): Call m2linemap_internal_error_at. (m2expr_interpret_m2_integer): Add location parameter. (m2expr_GetSizeOf): Replace sizeof with SIZE in error message. * gm2-gcc/m2expr.h (m2expr_AreRealOrComplexConstantsEqual): Replace int with bool. (m2expr_AreConstantsEqual): Ditto. (m2expr_IsFalse): Ditto. (m2expr_IsTrue): Ditto. (m2expr_interpret_integer): Add location parameter. (m2expr_interpret_m2_integer): Add location parameter. * gm2-gcc/m2linemap.cc (mformat_value): New function. (expand_format): New function. (expand_message): New function. (gm2_internal_error_at): New function. (m2linemap_internal_error_at): New function. * gm2-gcc/m2linemap.h (m2linemap_internal_error_at): New function. * gm2-gcc/m2options.h (M2Options_SetISO): Replace int with bool. (M2Options_SetPIM): Ditto. (M2Options_SetPIM2): Ditto. (M2Options_SetPIM3): Ditto. (M2Options_SetPIM4): Ditto. (M2Options_SetFloatValueCheck): Ditto. (M2Options_SetWholeValueCheck): Ditto. (M2Options_GetISO): Ditto. (M2Options_GetPIM): Ditto. (M2Options_GetPIM2): Ditto. (M2Options_GetPIM3): Ditto. (M2Options_GetPIM4): Ditto. (M2Options_GetPositiveModFloor): Ditto. (M2Options_GetFloatValueCheck): Ditto. (M2Options_GetWholeValueCheck): Ditto. (M2Options_Setc): Ditto. (M2Options_Getc): Ditto. (M2Options_SetPPOnly): Ditto. (M2Options_GetPPOnly): Ditto. (M2Options_SetUselist): Ditto. (M2Options_SetAutoInit): Ditto. (M2Options_SetPositiveModFloor): Ditto. (M2Options_SetNilCheck): Ditto. (M2Options_SetWholeDiv): Ditto. (M2Options_SetIndex): Ditto. (M2Options_SetRange): Ditto. (M2Options_SetReturnCheck): Ditto. (M2Options_SetCaseCheck): Ditto. (M2Options_SetCheckAll): Ditto. (M2Options_SetExceptions): Ditto. (M2Options_SetStyle): Ditto. (M2Options_SetPedantic): Ditto. (M2Options_SetPedanticParamNames): Ditto. (M2Options_SetPedanticCast): Ditto. (M2Options_SetExtendedOpaque): Ditto. (M2Options_SetVerboseUnbounded): Ditto. (M2Options_SetXCode): Ditto. (M2Options_SetCompilerDebugging): Ditto. (M2Options_SetQuadDebugging): Ditto. (M2Options_SetDebugTraceQuad): Ditto. (M2Options_SetDebugTraceAPI): Ditto. (M2Options_SetSources): Ditto. (M2Options_SetUnboundedByReference): Ditto. (M2Options_SetDumpSystemExports): Ditto. (M2Options_SetOptimizing): Ditto. (M2Options_SetQuiet): Ditto. (M2Options_SetCC1Quiet): Ditto. (M2Options_SetCpp): Ditto. (M2Options_SetSwig): Ditto. (M2Options_SetWholeProgram): Ditto. (M2Options_SetDebugFunctionLineNumbers): Ditto. (M2Options_SetGenerateStatementNote): Ditto. (M2Options_GetCpp): Ditto. (M2Options_GetM2g): Ditto. (M2Options_SetM2g): Ditto. (M2Options_SetLowerCaseKeywords):
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109 --- Comment #9 from Jakub Jelinek --- Weird, at least on the current trunk when reverting all 4 i386.md hunks vs. all but the 3_3 one I see differences in both _Z22trx_undo_get_first_recRK11fil_space_tjtjRPK11buf_block_tP5mtr_tP7dberr_t and _ZL18trx_undo_free_pageP10trx_rseg_tbjjP5mtr_tP7dberr_t So, are you sure it is the latter that matters? There indeed is this shift + ior in page_id_t(rseg->space->id, page_no) How many times is this function called? What is rseg->space->id, hdr_page_no and page_no and what values receive the buf_page_get_gen callees?
[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109113
--- Comment #5 from Noé Lopez ---
(In reply to Andrew Pinski from comment #3)
> The code is invalid.
> If you change the first `FILE_MENU` to `{0, { fn }}`, you get an error
> message:
>
> :31:13: error: initialization of flexible array member in a nested
> context
>31 | {0, { fn }},
> | ^
> :31:13: note: (near initialization for 'WINDOW_MENU.items[0].items')
Thank you for pointing that out :) I'm gonna fix my code now have a good day!
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109 --- Comment #8 from Martin Liška --- (In reply to Martin Liška from comment #7) > Created attachment 54655 [details] > bad.s (3/4 of hunks reverted) > > Yes, it narrows down to a single function > _Z23trx_undo_free_last_pageP10trx_undo_tP5mtr_t (and it's split part > _ZL18trx_undo_free_pageP10trx_rseg_tbjjP5mtr_tP7dberr_t.cold). The diff in _ZL18trx_undo_free_pageP10trx_rseg_tbjjP5mtr_tP7dberr_t.cold can be ignored (I placed there ud2 instruction) and it's not met.
[Bug tree-optimization/109115] [13 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in upper_bound, at value-range.h:950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109115 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 54656 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54656=edit gcc13-pr109115.patch Untested fix.
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109 --- Comment #7 from Martin Liška --- Created attachment 54655 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54655=edit bad.s (3/4 of hunks reverted) Yes, it narrows down to a single function _Z23trx_undo_free_last_pageP10trx_undo_tP5mtr_t (and it's split part _ZL18trx_undo_free_pageP10trx_rseg_tbjjP5mtr_tP7dberr_t.cold).
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109 --- Comment #6 from Martin Liška --- Created attachment 54654 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54654=edit good.s (3/4 of hunks reverted)
[Bug tree-optimization/109115] [13 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in upper_bound, at value-range.h:950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109115 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I think it returns false if it is has a type which isn't representable with the particular range. Which isn't the case here. The type is representable, just the range is undefined_p ().
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #5 from Jakub Jelinek ---
(In reply to Martin Liška from comment #4)
> > Another possible way to narrow it down a little bit would be to undo the
> > i386.md hunks from that commit one by one and see which one it is, all the 4
> > changes are optimizations and all of them are independent of each other (any
> > of them dependent on the i386-expand.cc change which shouldn't change
> > anything on its own).
>
> All right, I was able to revert 3/4 of the hunks in i386.md and the
> problematic one that caused the miscompilation is:
>
> (define_insn_and_split "*concat3_3"
> [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r,")
> (any_or_plus:
> (ashift:
> (zero_extend:
> (match_operand:DWIH 1 "nonimmediate_operand" "r,m,r,m"))
> (match_operand: 2 "const_int_operand"))
> (zero_extend:
> (match_operand:DWIH 3 "nonimmediate_operand" "r,r,m,m"]
> "INTVAL (operands[2]) == * BITS_PER_UNIT"
> "#"
> "&& reload_completed"
> [(clobber (const_int 0))]
> {
Does using only that single hunk vs. no hunk at all narrow down further the
list of changed functions?
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #4 from Martin Liška ---
> Another possible way to narrow it down a little bit would be to undo the
> i386.md hunks from that commit one by one and see which one it is, all the 4
> changes are optimizations and all of them are independent of each other (any
> of them dependent on the i386-expand.cc change which shouldn't change
> anything on its own).
All right, I was able to revert 3/4 of the hunks in i386.md and the problematic
one that caused the miscompilation is:
(define_insn_and_split "*concat3_3"
[(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r,")
(any_or_plus:
(ashift:
(zero_extend:
(match_operand:DWIH 1 "nonimmediate_operand" "r,m,r,m"))
(match_operand: 2 "const_int_operand"))
(zero_extend:
(match_operand:DWIH 3 "nonimmediate_operand" "r,r,m,m"]
"INTVAL (operands[2]) == * BITS_PER_UNIT"
"#"
"&& reload_completed"
[(clobber (const_int 0))]
{
[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098 --- Comment #6 from joseph at codesourcery dot com --- For diagnosis of non-UTF-8 in strings / comments, see commit 0b8c57ed40f19086e30ce54faec3222ac21cc0df, "libcpp: Add -Winvalid-utf8 warning [PR106655]" (implementing a new C++ requirement).
[Bug rtl-optimization/109116] vector_pair register allocation bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109116 --- Comment #1 from Chip Kerchner --- This has been in GCC since the initial version that supported __vector_pair (10.x)
[Bug rtl-optimization/109116] New: vector_pair register allocation bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109116
Bug ID: 109116
Summary: vector_pair register allocation bug
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chip.kerchner at ibm dot com
Target Milestone: ---
There seems to be a bug in the register allocator when using a __vector_pair.
GCC didn't choose a register for the load that served the later instruction.
With this testcase
```
#include
#if !__has_builtin(__builtin_vsx_disassemble_pair)
#define __builtin_vsx_disassemble_pair __builtin_mma_disassemble_pair
#endif
int main() {
float A[8] = { float(1), float(2), float(3), float(4),
float(5), float(6), float(7), float(8) };
__vector_pair P;
__vector_quad Q;
vector float B, C[2], D[4];
__builtin_mma_xxsetaccz();
P = *reinterpret_cast<__vector_pair *>(A);
B = *reinterpret_cast(A);
__builtin_vsx_disassemble_pair((void*)(C), );
__builtin_mma_xvf32gerpp(, reinterpret_cast<__vector unsigned char>(C[0]),
reinterpret_cast<__vector unsigned char>(B));
__builtin_mma_xvf32gerpp(, reinterpret_cast<__vector unsigned char>(C[1]),
reinterpret_cast<__vector unsigned char>(B));
__builtin_mma_disassemble_acc((void *)D, );
return int(D[0][0]);
}
```
It produces an output with extra (unneeded) register moves.
```
plxvp 12,.LANCHOR0@pcrel
xxsetaccz 0
plxv 33,.LC1@pcrel
xxlor 45,13,13
xxlor 32,12,12
xvf32gerpp 0,45,33
xvf32gerpp 0,32,33
xxmfacc 0
```
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #6) > Created attachment 54652 [details] > Updated patch Actually that patch still produces the ICE mentioned in comment#1, which seems to follow from issues in namespace handling. So better wait till these issues are resolved. A hack to solve the present PR might not be what we want...
[Bug target/109093] [13 regression] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #9 from Jakub Jelinek ---
Perhaps better reduction which doesn't need inline asm. It contains a couple
of unused variables and two spots with uninitialized vars, but those should be
both in a block of code never executed at runtime. And the various ptr vs.
integral casts are also needed but I think they shouldn't do much harm (it is
true in one spot it creates a pointer from int, but only stores it somewhere
and doesn't actually use later).
/* PR target/109093 */
/* { dg-do run { target avx_runtime } } */
/* { dg-options "-O3 -mavx -mtune=znver1 -fno-strict-aliasing
-ftrivial-auto-var-init=zero" } */
int a, b = 1, c, d, e, f, g, h, i, j, k, l, m;
int *n = , *o = , *p =
static int q;
int *f2;
int **r = , **s =
char t;
int u[1];
int ***v;
static void
foo (int x)
{
int *w[7];
int y = y, i;
const int z[32] = { };
int aa = (__PTRDIFF_TYPE__) z;
for (i = 0; i < 7; i++)
w[i] = u;
lab:
*r = (int *) (__PTRDIFF_TYPE__) x;
if (k || p == 0)
{
int ab[1];
for (; g; g++)
{
int **ac[] = { w };
}
short ad[3];
if (j)
goto lab;
for (; y; y -= 1)
{
int *ae;
*ae = l;
for (; t; t += 1)
if (**r)
return;
for (; q; q += f)
;
}
}
}
static void
bar (int *x)
{
long w[] = { 1, 1, 4073709551607, 1, 1 };
if (*x + 6)
{
(void) ((**s |= a) > (__PTRDIFF_TYPE__) w);
foo (d);
}
for (e = 0; e <= 2; e += 1)
{
int *y[4];
r = (int **) x;
for (m = 0; m <= 2; m += 1)
for (b = 0; b <= 2; b += 1)
if (c)
{
q = 0;
***v = (__PTRDIFF_TYPE__) r;
}
}
}
int
main ()
{
if (b)
bar (n);
}
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #4 from David Malcolm --- Created attachment 54653 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54653=edit Generated diagnostic-format-sarif-file-4.c.sarif output file on my machine (In reply to Hans-Peter Nilsson from comment #3) > Can someone with a machine where this test passes, paste output of that > command? Sorry about this. The test works for me, with: === gcc Summary === # of expected passes5 # of expected failures 1 where: $ runtest --version emits: WARNING: Couldn't find the global config file. DejaGnu version 1.6.1 Expect version 5.45.4 Tcl version 8.6 What does the generated testsuite/gcc/diagnostic-format-sarif-file-4.c.sarif file look like? I'm attaching mine for reference.
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- Created attachment 54652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54652=edit Updated patch Hi Steve, the attachment contains a slightly simpler version of the patch in comment#2. It needs to be amended by the adjustment of gfortran.dg/pr87907.f90 and a modification of the patterns in gfortran.dg/c-interop/c1255-2.f90 . I've stripped the unrelated parts in comment#2. If you agree, I can prepare the patch for submission.
[Bug c++/96830] GCC does not complain about redeclaration with inconsistent requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/109115] [13 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in upper_bound, at value-range.h:950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109115
Andrew Pinski changed:
What|Removed |Added
Version|unknown |13.0
--- Comment #2 from Andrew Pinski ---
I would have assumed range_of_expr would return false if r had no range
information ...
if (ranger.range_of_expr (r, oprnd0, stmt))
{
wide_int max = r.upper_bound ();
Maybe there needs to be a check to make sure r.kind () is VR_RANGE then ...
[Bug libstdc++/109111] Definition of repeat_view::_Iterator has wrong template-head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109111 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96830 Last reconfirmed||2023-03-13 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Patrick Palka --- Confirmed, the corresponding compiler bug is PR96830
[Bug tree-optimization/109115] [13 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in upper_bound, at value-range.h:950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109115 Andrew Pinski changed: What|Removed |Added Summary|ICE on valid code at -O2|[13 Regression] ICE on |and -O3 on |valid code at -O2 and -O3 |x86_64-linux-gnu: in|on x86_64-linux-gnu: in |upper_bound, at |upper_bound, at |value-range.h:950 |value-range.h:950 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Target Milestone|--- |13.0 Last reconfirmed||2023-03-13 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Most likely introduced by r13-6619-g81fd62d1378b7d .
[Bug tree-optimization/109115] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in upper_bound, at value-range.h:950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109115
Bug ID: 109115
Summary: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu:
in upper_bound, at value-range.h:950
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it does not reproduce with 12.2.
Compiler Explorer: https://godbolt.org/z/Yjaj5qMvv
[569] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230313 (experimental) [master r13-6641-g23532dac3f6] (GCC)
[570] %
[570] % gcctk -Os small.c; ./a.out
[571] %
[571] % gcctk -O2 small.c
during GIMPLE pass: slp
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in upper_bound, at value-range.h:950
2 | int main() {
| ^~~~
0xc48c63 irange::upper_bound() const
../../gcc-trunk/gcc/value-range.h:950
0xc48c63 irange::upper_bound() const
../../gcc-trunk/gcc/value-range.h:947
0x1e9e7ca vect_recog_divmod_pattern
../../gcc-trunk/gcc/tree-vect-patterns.cc:3978
0x1e9808a vect_pattern_recog_1
../../gcc-trunk/gcc/tree-vect-patterns.cc:6244
0x1e9d3c1 vect_pattern_recog(vec_info*)
../../gcc-trunk/gcc/tree-vect-patterns.cc:6401
0x11a97dc vect_slp_analyze_bb_1
../../gcc-trunk/gcc/tree-vect-slp.cc:7310
0x11a97dc vect_slp_region
../../gcc-trunk/gcc/tree-vect-slp.cc:7419
0x11abac3 vect_slp_bbs
../../gcc-trunk/gcc/tree-vect-slp.cc:7610
0x11abe9c vect_slp_function(function*)
../../gcc-trunk/gcc/tree-vect-slp.cc:7698
0x11b6492 execute
../../gcc-trunk/gcc/tree-vectorizer.cc:1532
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[572] %
[572] % cat small.c
int a, b;
int main() {
unsigned short c = a, e = -1;
if (b) {
unsigned d = (a ^ 1U) / a & c;
int f = (~d >> ~a) / e;
if (a)
f = a;
a = f;
}
return 0;
}
[Bug c++/107128] armhf: floatn-common.h:214:9: error: multiple types in one declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128 --- Comment #10 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:538a0d0f29b12cff05681b6de2e0a3d7b33f3ef0 commit r13-6643-g538a0d0f29b12cff05681b6de2e0a3d7b33f3ef0 Author: Jason Merrill Date: Mon Mar 13 14:06:11 2023 -0400 c++: handle _FloatNN redeclaration like bool [PR107128] It's been inconvenient to compile testcases preprocessed with GCC 12 or earlier because they break on typedef __float128 _Float128; We already had code for handling this with bool and wchar_t, it just needs to be extended to _FloatNN as well. PR c++/107128 gcc/cp/ChangeLog: * parser.cc (cp_parser_set_decl_spec_type): Use redefined_builtin_type for extended_float_type_p. gcc/testsuite/ChangeLog: * g++.dg/warn/pragma-system_header6.h: New test. * g++.dg/warn/pragma-system_header6.C: New test.
[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109113
Andrew Pinski changed:
What|Removed |Added
Known to fail||8.1.0
Last reconfirmed||2023-03-13
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski ---
Reduced testcase:
```
struct menu_item_s {
void (*fn)(void);
};
struct menu_list_s {
int _a;
struct menu_item_s items[];
};
struct menu_s {
int _a;
struct menu_list_s items[];
};
void fn(void);
const struct menu_list_s FILE_MENU = {
.items = {
{ fn },
}
};
struct menu_s WINDOW_MENU = {
.items = {
FILE_MENU,
FILE_MENU,
},
};
```
Note GCC 7 and before used to reject it with:
```
:20:9: error: initializer element is not constant
FILE_MENU,
^
:20:9: note: (near initialization for 'WINDOW_MENU.items[0]')
```
[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109113
--- Comment #3 from Andrew Pinski ---
The code is invalid.
If you change the first `FILE_MENU` to `{0, { fn }}`, you get an error message:
:31:13: error: initialization of flexible array member in a nested
context
31 | {0, { fn }},
| ^
:31:13: note: (near initialization for 'WINDOW_MENU.items[0].items')
[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109113
--- Comment #2 from Noé Lopez ---
Here's the code in plain text:
#include
typedef struct menu_item_s {
void *fn;
} menu_item_t;
typedef struct menu_list_s {
int _a;
menu_item_t items[];
} menu_list_t;
typedef struct menu_s {
int _a;
menu_list_t items[];
} menu_t;
typedef struct region_s {
void *data;
} region_t;
static void fn(void) {
// Bug does not trigger when doing something inside this function
//int a = 0;
}
static const menu_list_t FILE_MENU = {
.items = {
{ fn },
}
};
const menu_t WINDOW_MENU = {
.items = {
FILE_MENU,
FILE_MENU,
},
};
void create_menu_region(region_t *dest, const menu_t *menu)
{
// Bug only happens when putting output in the region_t struct
dest->data = malloc(sizeof(menu));
// Does not trigger bug:
//menu_t *data = malloc(sizeof(menu));
// void *data = malloc(sizeof(menu));
// malloc(sizeof(menu));
}
// Just here so that ld doesn't complain
int main(void) {}
[Bug c++/109114] New: lambdas should be non-pod for ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109114
Bug ID: 109114
Summary: lambdas should be non-pod for ABI
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
Target Milestone: ---
See original bug filed against clang:
https://github.com/llvm/llvm-project/issues/59078
itanium-cxx-abi bug: https://github.com/itanium-cxx-abi/cxx-abi/issues/156
(inverted, so it fails with GCC and passes with Clang) example from the clang
bug: https://godbolt.org/z/45TxsPehe
```
template
struct Callables : T ... {
Callables(T ...t) : T(t) ... {}
using T::operator() ...;
};
inline auto f(int x, char y) {
Callables callables([x, y](void) {}, [y](int) {});
static_assert(sizeof(callables) == 8);
return callables;
}
int main(void) { f(0, 1)(42); }
```
Maybe still an open question about lambdas that don't capture - since they do
have a default ctor, but the spec still says they're non-aggregate.
[Bug c/109113] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109113 --- Comment #1 from Noé Lopez --- Created attachment 54651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54651=edit The preprocessed file
[Bug c/109113] New: internal compiler error: in output_constructor_regular_field, at varasm.cc:5521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109113
Bug ID: 109113
Summary: internal compiler error: in
output_constructor_regular_field, at varasm.cc:5521
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noe.lopez at epitech dot eu
Target Milestone: ---
Created attachment 54650
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54650=edit
The minimal code example
Hello :), I've recently come across an internal compiler error when trying to
compile my code.
The error seems to be triggered by assigning the result of a malloc of the size
of a structure containing static arrays of another structure containing static
arrays ???
It's a little complicated but I've done my best to produce a minimal example of
the bug that can be compiled with the following command:
`gcc minimal.c`
Here's my gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-unknown-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /builddir/gcc-12.2.0/configure
--build=x86_64-unknown-linux-gnu --enable-gnu-unique-object
--enable-vtable-verify --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --libexecdir=/usr/lib64 --libdir=/usr/lib64
--enable-threads=posix --enable-__cxa_atexit --disable-multilib
--with-system-zlib --enable-shared --enable-lto --enable-plugins
--enable-linker-build-id --disable-werror --disable-nls --enable-default-pie
--enable-default-ssp --enable-checking=release --disable-libstdcxx-pch
--with-isl --with-linker-hash-style=gnu --disable-sjlj-exceptions
--disable-target-libiberty --disable-libssp
--enable-languages=c,c++,objc,obj-c++,fortran,lto,go,ada
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)
Here's the compiler output:
minimal.c:50:1: internal compiler error: in output_constructor_regular_field,
at varasm.cc:5521
50 | int main(void) {}
| ^~~
0x7f514864820b __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f51486482bb __libc_start_main_impl
../csu/libc-start.c:381
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/109111] Definition of repeat_view::_Iterator has wrong template-head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109111 --- Comment #1 from John Drouhard --- https://godbolt.org/z/csozden6e example of gcc not diagnosing mismatched requires clauses (and clang correctly doing so).
[Bug tree-optimization/109112] [[assume(...)]] is not taken into account for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112 --- Comment #4 from Jakub Jelinek --- One way to improve this case would be to teach IPA SRA/CP etc. to perform some optimizations on the .ASSUME ifn calls and their corresponding functions, in this case if SRA would turn the argument from aggregate to scalar.
[Bug tree-optimization/109112] [[assume(...)]] is not taken into account for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112 --- Comment #3 from Andrew Pinski --- I also suspect this is a dup of bug 109045 really.
[Bug tree-optimization/109112] [missed optimization] odd behaviour with [[assume(...)]] and member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112 Andrew Pinski changed: What|Removed |Added URL|https://godbolt.org/z/nreM4 | |Y6dW| Component|c++ |tree-optimization Keywords||missed-optimization Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- https://godbolt.org/z/nreM4Y6dW
[Bug analyzer/105906] fanalyzer strdup false positive leak in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105906 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:23532dac3f602d6c29f5b7062c7fe30905061764 commit r13-6641-g23532dac3f602d6c29f5b7062c7fe30905061764 Author: David Malcolm Date: Mon Mar 13 14:53:05 2023 -0400 testsuite: add test coverage for analyzer leak false +ve [PR105906] Adding regression test coverage; I believe I fixed this leak false positive with r13-5113-g688fc162b76dc6. gcc/testsuite/ChangeLog: PR analyzer/105906 * gcc.dg/analyzer/leak-pr105906.c: New test. Signed-off-by: David Malcolm
[Bug c++/109112] [missed optimization] odd behaviour with [[assume(...)]] and member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- There is nothing odd on it. The extra optimization information assume provides is right now used solely by value range propagation and that works only on scalars. For anything else, the assumptions are noted but for now nothing takes advantage of them. And it will take a while before that changes. Assumptions provide optimization hints, the compiler isn't required to make use of them. There will always be assumptions which compiler won't be able to do anything with them.
[Bug analyzer/108045] analyzer: false positive memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108045 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:129664c67b774511b53bfeee9e80a142ae7cd026 commit r13-6640-g129664c67b774511b53bfeee9e80a142ae7cd026 Author: David Malcolm Date: Mon Mar 13 14:53:04 2023 -0400 testsuite: add test coverage for PR analyzer/108045 PR analyzer/108045 reports a leak false positive from -fanalyzer. The false +ve as reported seems to have been fixed by r13-6589-g14f5e56a8a766c, but with -fanalyzer-call-summaries there are two additional false +ves which aren't fixed by that commit. This patch adds test coverage for these cases. gcc/testsuite/ChangeLog: PR analyzer/108045 * gcc.dg/analyzer/leak-pr108045-with-call-summaries.c: New test. * gcc.dg/analyzer/leak-pr108045-without-call-summaries.c: New test. Signed-off-by: David Malcolm
[Bug c++/109112] New: [missed optimization] odd behaviour with [[assume(...)]] and member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112
Bug ID: 109112
Summary: [missed optimization] odd behaviour with
[[assume(...)]] and member variables
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ivan.lazaric.gcc at gmail dot com
Target Milestone: ---
Everything is built with flags: -std=c++23 -O3
[[assume(...)]] doesn't seem to work quite as well when dealing with member
variables.
First version of `fn`:
void do_something();
void fn(bool x){
[[assume(!x)]];
if (x) do_something();
}
`fn` compiles into nothing:
fn(bool):
ret
Second version of `fn`, wrapping the `bool` argument in a simple struct:
struct S { bool x; };
void do_something();
void fn(S s){
[[assume(!s.x)]];
if (s.x) do_something();
}
This no longer compiles into just `ret`:
fn(S):
testdil, dil
jne .L5
ret
.L5:
jmp do_something()
Expected behaviour was for `fn(S)` to reduce to just `ret`
Godbolt link with the examples: https://godbolt.org/z/nreM4Y6dW
[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087
--- Comment #12 from Jakub Jelinek ---
As for the .DEFERRED_INIT not being DSEd when it isn't used, cvise reduced
testcase is e.g.
int a;
int foo (void);
int bar (void);
void
baz (void)
{
int *b[6];
if (foo ())
a |= bar ();
}
while with a |= 1; instead dse1 removes it. Richi, any thoughts on that?
Of course, the real bug is on the x86 backend side.
[Bug analyzer/105906] fanalyzer strdup false positive leak in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105906 --- Comment #3 from David Malcolm --- (In reply to David Malcolm from comment #2) > Looks like this is fixed on trunk for GCC 13; seem to have been via > 688fc162b76dc6747a30fcfd470f4770da0f4924 aka r13-5113-g688fc162b76dc6
[Bug analyzer/105906] fanalyzer strdup false positive leak in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105906 --- Comment #2 from David Malcolm --- Looks like this is fixed on trunk for GCC 13; seem to have been via 688fc162b76dc6747a30fcfd470f4770da0f4924
[Bug target/109093] [13 regression] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093 --- Comment #8 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #7) > Started (or perhaps no longer latent) since > r13-4839-geef81eefcdc2a58111e50eb21. Most likely made no longer latent due to: (X86_TUNE_AVX256_MOVE_BY_PIECES): Add znver1-3. (X86_TUNE_AVX256_STORE_BY_PIECES): Add znver1-3. Just as I mentioned in PR 109087.
[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P1 --- Comment #11 from Jakub Jelinek --- Seems to be exact same thing as I've just described in PR109093. .DEFERRED_INIT isn't for whatever reason optimized away, expansion decides to use vector memset for it and somehow during pro_and_epilogue the memory slot for the variable isn't appropriately aligned.
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773 --- Comment #16 from kkeithle at redhat dot com --- Can confirm that the fix included in fedora gcc-13.0.1-0.7 works and I have now successfully built ceph in fedora koji. https://koji.fedoraproject.org/koji/taskinfo?taskID=98654634
[Bug libstdc++/109111] New: Definition of repeat_view::_Iterator has wrong template-head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109111 Bug ID: 109111 Summary: Definition of repeat_view::_Iterator has wrong template-head Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- In : template requires (is_object_v<_Tp> && same_as<_Tp, remove_cv_t<_Tp>> && (__detail::__is_integer_like<_Bound> || same_as<_Bound, unreachable_sentinel_t>)) class repeat_view : /* ... */ template requires __detail::__is_integer_like<_Bound> || same_as<_Bound, unreachable_sentinel_t> class repeat_view<_Tp, _Bound>::_Iterator The requires-clause should match. Clang trunk diagnoses this (but not GCC, so there's probably a compiler bug here too).
[Bug tree-optimization/103354] missed optimization with & and | and compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103354 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/103354] missed optimization with & and | and compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103354 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Andrew Pinski --- h in comment #0 was fixed by r13-4620-g4d9db4bdd458a4 which has a testcase for this: gcc.target/aarch64/if-compare_1.c (not a generic one though but I think that is ok for now) .
[Bug target/109092] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 when building libgcc on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- In this case that would be certainly better, because if the intent is to never match for move from vl register, then even subreg of vl would be a vl register and so if it punted just on moves from vl REG and not SUBREG thereof, after reload it could get vl REG from the SUBREG and fail at that point. Note, *zero_extendsidi2_internal uses the #c1 way...
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #3 from Jakub Jelinek ---
If you suspect that one, that is certainly the simplest, in C that would be
__attribute__((noipa)) void
foo (unsigned long long *a, unsigned int b, unsigned int c)
{
*a = (((unsigned long long) b) << 32) | c;
}
int
main ()
{
unsigned long long a;
foo (, 0xcafebabeU, 0xdeadbeefU);
if (a != 0xcafebabedeadbeefULL)
__builtin_abort ();
}
and you can see the same difference with say -O2 -m32 -fno-omit-frame-pointer.
But, that one works for both...
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109 --- Comment #2 from Jakub Jelinek --- Without an actual self-contained reproducer hard to guess. The above mentioned change changes the content of _ZN9page_id_tC2Ejj _Z22trx_undo_get_first_recRK11fil_space_tjtjRPK11buf_block_tP5mtr_tP7dberr_t _ZN5trx_t9apply_logEv _Z17trx_undo_add_pageP10trx_undo_tP5mtr_tP7dberr_t _ZL18trx_undo_free_pageP10trx_rseg_tbjjP5mtr_tP7dberr_t functions from what I can see, so which one of these it is? Another possible way to narrow it down a little bit would be to undo the i386.md hunks from that commit one by one and see which one it is, all the 4 changes are optimizations and all of them are independent of each other (any of them dependent on the i386-expand.cc change which shouldn't change anything on its own). If you narrow it down to one function, then I guess we need to turn it into a self-contained reproducer, add dummy wrapper which calls that function from main with the right arguments and supply dummy callees for the function for functions which aren't inlined.
[Bug c/109110] old style function declaration not causing incompatible type on calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109110 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #5 from Marek Polacek --- Closing out then.
[Bug c/109110] old style function declaration not causing incompatible type on calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109110 --- Comment #4 from Andreas Schwab --- 14.8 Certain Changes We Don't Want to Make == * Checking the number and type of arguments to a function which has an old-fashioned definition and no prototype.
[Bug c/109110] old style function declaration not causing incompatible type on calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109110 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The GCC behavior is correct, it is as if you moved the func1 definition to a different file, or just used void func1(); in the same file and the definition in another one.
[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 --- Comment #23 from Marek Polacek --- (In reply to Kohei Takahashi from comment #21) > (In reply to Marek Polacek from comment #18) > > (In reply to Barnabás Pőcze from comment #17) > > > The simple test case with std::span still triggers the warning: > > > https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code > > > analysis such a warning will generate too many false positives and people > > > will simply turn it off. > > > > There really haven't been that many, except this and one with range-based > > for loops. > > I think it warns many usage of zip_iterator idiom such as boost.iterator and > P2321 style flat_map. Those uses tuple of references like std::tuple > by dereferencing iterator, so that any algorithms may yield this warning. Ah, would you please have a testcase? If that's the case and the warning can't be taught to recognize that pattern, then I think we need to move it to -Wextra. Thanks.
[Bug c/109110] Function Declaration Syntax errors at callsite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109110 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Andrew Pinski --- And almost nobody cares about old style function declarations ...
[Bug c/109110] Function Declaration Syntax errors at callsite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109110 --- Comment #1 from Andrew Pinski --- Because this is a old style function definition and still not a prototype.
[Bug c/109110] New: Function Declaration Syntax errors at callsite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109110
Bug ID: 109110
Summary: Function Declaration Syntax errors at callsite
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bthomas at brave dot com
Target Milestone: ---
https://godbolt.org/z/Y8rbd35xP
```C
void func1(a)
int a[];
{
}
void func2(int a[])
{
}
int main(void) {
Foo f;
func1(f);
func1(1.0);
func2(f);
func2(1.0);
return 0;
}
```
These two Syntax for declaring a function works fine, however they behave
completely different.
`func2` gives compilation errors:
```
error: incompatible type for argument 1 of 'func2'
expected 'int *' but argument is of type 'Foo'
expected 'int *' but argument is of type 'double'
```
However, `func1` compiles and runs just fine. In fact, if I put a printf to
print the argument, `func1` will also give no warnings even with `-Werror`
unless I explicitly specific `-Wformat`, but `func2` will.
in Clang, all of the above gives both errors and warnings and won't compile.
[Bug target/109093] [13 regression] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #7 from Jakub Jelinek ---
Reduced testcase (unfortunately reduced into a form which is x86_64-linux
specific unless I want success to be an endless loop)
with -O2 -mavx -mtune=znver1 -ftrivial-auto-var-init=zero:
int a, b, c, d, e, f, g, h, i, j, k;
int *m;
int **l =
static void
bar (void)
{
l:
if (j)
for (;;)
;
short q[3];
if (g)
goto l;
for (; k; k -= 1)
{
int *r =
*r = i;
for (f = 0; f <= 6; f += 1)
{
if (*l)
{
d += 1;
for (; d;)
;
}
if (e)
break;
}
}
}
__attribute__((noipa)) void
foo (int *x)
{
int n;
long o = 1;
if (*x)
{
bar ();
++o;
n = a / o;
}
h |= n;
for (;;)
{
int *p[4];
*l = x;
for (b = 0; b <= 2; b += 1)
if (c)
{
asm ("pushq %rbp; xorl %edi, %edi; movq %rsp, %rbp; andq $-16,
%rsp; call exit");
break;
}
else
*m = 0;
}
}
int
main ()
{
int x = 1;
c = 1;
foo ();
return 0;
}
Started (or perhaps no longer latent) since
r13-4839-geef81eefcdc2a58111e50eb21.
[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 --- Comment #22 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:ced122b849b8961b854053f0d1ac96983c5802e5 commit r13-6633-gced122b849b8961b854053f0d1ac96983c5802e5 Author: Marek Polacek Date: Fri Mar 10 12:23:13 2023 -0500 c++: suppress -Wdangling-reference for std::span [PR107532] std::span is a view and therefore should be treated as a reference wrapper class for the purposes of -Wdangling-reference. I'm not sure there's a pattern that we could check for. PR c++/107532 gcc/cp/ChangeLog: * call.cc (reference_like_class_p): Check for std::span. gcc/testsuite/ChangeLog: * g++.dg/warn/Wdangling-reference10.C: New test.
[Bug c++/109095] ICE when specializing a template with an auto nontype template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109095
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
We ICE in tsubst
if (code == TEMPLATE_TYPE_PARM)
{
int quals;
/* When building concept checks for the purpose of
deducing placeholders, we can end up with wildcards
where types are expected. Adjust this to the deduced
value. */
if (TREE_CODE (arg) == WILDCARD_DECL)
arg = TREE_TYPE (TREE_TYPE (arg));
gcc_assert (TYPE_P (arg));
like a few other PRs. So it could be a dup.
[Bug modula2/109103] Missing function internal_error_at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109103 --- Comment #1 from Gaius Mulley --- Created attachment 54649 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54649=edit Proposed fix Here is a proposed patch.
[Bug sanitizer/109107] [10/11/12/13 Regression] UBsan since GCC-8 misses an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109107 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Hopefully just a missing TYPE_OVERFLOW_SANITIZED. Let me see...
[Bug analyzer/107017] RFE: support printf-style formatted functions in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107017 David Malcolm changed: What|Removed |Added CC||geoffreydgr at icloud dot com --- Comment #2 from David Malcolm --- *** Bug 109106 has been marked as a duplicate of this bug. ***
[Bug analyzer/109106] GCC Static Analyzer doesn't model printf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109106 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from David Malcolm --- Thanks for filing this, and for the comments; marking it as a dup of PR 107017 *** This bug has been marked as a duplicate of bug 107017 ***
[Bug sanitizer/109107] [10/11/12/13 Regression] UBsan since GCC-8 misses an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109107 Marek Polacek changed: What|Removed |Added Summary|UBsan since GCC-8 misses an |[10/11/12/13 Regression] |integer-overflow|UBsan since GCC-8 misses an ||integer-overflow Priority|P3 |P2 Ever confirmed|0 |1 Last reconfirmed||2023-03-13 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.5 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed. Started with r8-1516-ged73f46f30cabe so not a bug of PR108995 or PR109090. commit ed73f46f30cabeea4de64e7cce0682a7a610ffb6 Author: Marc Glisse Date: Wed Jun 21 13:16:27 2017 +0200 NOP conversions in X+CST+CST
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #1 from Martin Liška ---
The difference is somehow related to:
constexpr page_id_t(uint32_t space, uint32_t page_no) :
m_id(uint64_t{space} << 32 | page_no) {}
[Bug target/109109] [13 Regression] mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109 Richard Biener changed: What|Removed |Added Summary|mariadb fails in tests on |[13 Regression] mariadb |i586 (non-LTO mode) after |fails in tests on i586 |r13-4435-g2c089640279614e3 |(non-LTO mode) after ||r13-4435-g2c089640279614e3 Target Milestone|--- |13.0 Component|tree-optimization |target Target||i?86-*-*
[Bug tree-optimization/109109] New: mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109 Bug ID: 109109 Summary: mariadb fails in tests on i586 (non-LTO mode) after r13-4435-g2c089640279614e3 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jakub at gcc dot gnu.org, rguenth at gcc dot gnu.org Target Milestone: --- Created attachment 54648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54648=edit Unreduced test-case After the revision I see the following failure in mariadb package: ./mysql-test-run.pl --parallel=32 --force --retry=0 --ssl --suite-timeout=900 --testcase-timeout=30 --mysqld=--binlog-format=mixed --force-restart --shutdown-timeout=60 --max-test-fail=0 --skip-test=spider --skip-test-list=unstable-tests innodb_zip.bug36169 ... 2023-03-13 13:49:08 4 [ERROR] InnoDB: Cannot add field `col48` in table `test`.`table0` because after adding it, the row size is 708 which is greater than maximum allowed size (708 bytes) for a record on index leaf page. 2023-03-13 13:49:08 4 [ERROR] InnoDB: Trying to read 4096 bytes at 4294963200 outside the bounds of the file: ./ibdata1 2023-03-13 13:49:08 4 [ERROR] InnoDB: File './ibdata1' is corrupted 2023-03-13 13:49:08 4 [ERROR] InnoDB: Cannot add field `DB_ROW_ID` in table `test`.`table1` because after adding it, the row size is 537 which is greater than maximum allowed size (892 bytes) for a record on index leaf page. 2023-03-13 13:49:08 4 [ERROR] InnoDB: Trying to read 4096 bytes at 1879228416 outside the bounds of the file: ./ibdata1 2023-03-13 13:49:08 4 [ERROR] mariadbd: Index for table 'table2' is corrupt; try to repair it I reduced that to a single test-case and a function (see pragma GCC optimize "-O0"): g++ /tmp/trxundo.ii -o /var/tmp/build-root/standard-i586/home/abuild/rpmbuild/BUILD/mariadb-10.11.2/build/storage/innobase/CMakeFiles/innobase.dir/trx/trx0undo.cc.o -m32 -std=gnu++11 -fomit-frame-pointer -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -fno-lto -U_FORTIFY_SOURCE -g -DOPENSSL_LOAD_CONF -DPIC -fPIC -DFORCE_INIT_OF_VARS -Wno-unused-but-set-variable -fno-strict-aliasing -Wno-unused-parameter -Wno-error -felide-constructors -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -fPIC -Wconversion -Wno-sign-conversion -fomit-frame-pointer -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -ffat-lto-objects -fno-lto -U_FORTIFY_SOURCE -g -DOPENSSL_LOAD_CONF -DPIC -fPIC -DFORCE_INIT_OF_VARS -Wno-unused-but-set-variable -fno-strict-aliasing -Wno-unused-parameter -Wno-error -felide-constructors -fno-omit-frame-pointer -DDBUG_OFF -Wall -Wenum-compare -Wenum-conversion -Wextra -Wformat-security -Wmissing-braces -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -DHAVE_OPENSSL -DOPENSSL_API_COMPAT=0x1010L -fvisibility=hidden -std=gnu++11 -c
[Bug modula2/109103] Missing function internal_error_at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109103 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-03-13 Ever confirmed|0 |1
[Bug c/16186] gcc should have an option to warn about enumerations with duplicate values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16186
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
(In reply to trashyankes from comment #7)
> Should be way to disable/enable this warning per `enum`?
> Like:
>
> ```
> enum [[gnu::enum_unique]] X
> {
> I = 1,
> J = 2,
> };
>
> enum [[gnu::enum_not_unique]] Y
> {
> K = 1,
> L = 1,
> };
>
> ```
No, it should warn solely if enumerator gets implicitly assigned value of some
other enumerator. After all, the clang wording also mentions that:
element 'D' has been implicitly assigned 5 which another element has been
assigned [-Wduplicate-enum]
If there is = value for it, we should never warn, that is most likely
completely intentional.
Of course, we should use better wording, because we should talk about
enumerators, not elements...
[Bug target/109093] [13 regression] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug target/109093] [13 regression] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-03-13 Status|UNCONFIRMED |NEW --- Comment #6 from Jakub Jelinek --- #c3 looks very similarly, though have just looked at assembly: pushq %rbp .LCFI0: movl$36, %r11d movl$7, %eax vpxor %xmm0, %xmm0, %xmm0 movq%rsp, %rbp .LCFI1: pushq %r15 pushq %r14 pushq %r13 pushq %r12 .LCFI2: movl$127, %r13d pushq %rbx .LCFI3: leaq-48(%rsp), %rsi ... .L5: vmovdqa %xmm0, (%rsi) so again, %rbp after movq %rsp, %rbp is correctly 16-byte aligned, then 5 registers are pushed, so (%rsp & 15) == 8, %rsi is set to %rsp - 48 and an aligned store to that spot segfaults because (%rsi & 15) == 8. And similarly #c4: pushq %rbp .LCFI0: movabsq $434041037028460038, %rax movq%rsp, %rbp .LCFI1: pushq %rbx .LCFI2: movq%rax, -41(%rsp) movb$6, -33(%rsp) cmpl$-6, (%rdi) jne .L84 movl$2, %r8d leaq-32(%rsp), %rcx ... vmovdqa %xmm1, (%rcx) vmovdqa %xmm0, 16(%rcx) H.J., could you please have a look? Thanks.
[Bug preprocessor/67046] [10/11/12/13 Regression] Segmentation fault when a preprocessor directive follows the argument to _Pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Lewis Hyatt --- Fixed for GCC 13.
[Bug preprocessor/67046] [10/11/12/13 Regression] Segmentation fault when a preprocessor directive follows the argument to _Pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046
--- Comment #6 from CVS Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:336ce497fb266268a79544f00dd3bbd24cf3a4d6
commit r13-6631-g336ce497fb266268a79544f00dd3bbd24cf3a4d6
Author: Lewis Hyatt
Date: Sat Jan 14 13:29:22 2023 -0500
libcpp: Fix ICE on directive inside _Pragma() operator [PR67046]
get__Pragma_string() in directives.cc is responsible for lexing the parens
and the string argument from a _Pragma("...") operator. This function does
not handle the case when the closing paren is not on the same line as the
string; in that case, libcpp will by default reuse the token buffer it
previously used for the string, so that the string token returned by
get__Pragma_string() may be corrupted, as shown in the testcase. Fix using
the existing keep_tokens mechanism that temporarily disables the reuse of
token buffers.
libcpp/ChangeLog:
PR preprocessor/67046
* directives.cc (_cpp_do__Pragma): Increment pfile->keep_tokens to
ensure the returned string token is valid.
gcc/testsuite/ChangeLog:
PR preprocessor/67046
* c-c++-common/cpp/pr67046.c: New test.
[Bug target/109093] [13 regression] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #5 from Jakub Jelinek ---
My patch just caused far more .DEFERRED_INITs to be optimized away for dead
variables (though, as can be seen on #c0 apparently not all).
What I see on the #c0 testcase looks like a x86 backend bug to me.
In func_2.constprop.0.isra.0 there is in optimized dump:
uint64_t * * * * const * l_2254[6];
variable and the IL mentions it just in
l_2254 = .DEFERRED_INIT (48, 2, &"l_2254"[0]);
and
l_2254 ={v} {CLOBBER(eol)};
(the latter in 2 spots) statements. Why the .DEFERRED_INIT hasn't been DSEd is
certainly a question.
Anyway, l_2254 has 128-bit alignment (supposedly due to ix86_local_alignment
and psABI requirements).
Expansion expands that .DEFERRED_INIT into:
(insn 23 22 24 5 (parallel [
(set (reg:DI 162)
(plus:DI (reg/f:DI 19 frame)
(const_int -48 [0xffd0])))
(clobber (reg:CC 17 flags))
]) "runData/keep/in.16651.c":199:34 247 {*adddi_1}
(nil))
(insn 24 23 25 5 (set (reg:V32QI 163)
(const_vector:V32QI [
(const_int 0 [0]) repeated x32
])) "runData/keep/in.16651.c":199:34 1823 {movv32qi_internal}
(nil))
(insn 25 24 26 5 (set (mem/c:V16QI (reg:DI 162) [0 MEM [(void
*)_157]+0 S16 A128])
(vec_select:V16QI (reg:V32QI 163)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
(const_int 8 [0x8])
(const_int 9 [0x9])
(const_int 10 [0xa])
(const_int 11 [0xb])
(const_int 12 [0xc])
(const_int 13 [0xd])
(const_int 14 [0xe])
(const_int 15 [0xf])
]))) "runData/keep/in.16651.c":199:34 4383
{vec_extract_lo_v32qi}
(nil))
(insn 26 25 27 5 (set (mem/c:V16QI (plus:DI (reg:DI 162)
(const_int 16 [0x10])) [0 MEM [(void *)_157]+16
S16 A128])
(vec_select:V16QI (reg:V32QI 163)
(parallel [
(const_int 16 [0x10])
(const_int 17 [0x11])
(const_int 18 [0x12])
(const_int 19 [0x13])
(const_int 20 [0x14])
(const_int 21 [0x15])
(const_int 22 [0x16])
(const_int 23 [0x17])
(const_int 24 [0x18])
(const_int 25 [0x19])
(const_int 26 [0x1a])
(const_int 27 [0x1b])
(const_int 28 [0x1c])
(const_int 29 [0x1d])
(const_int 30 [0x1e])
(const_int 31 [0x1f])
]))) "runData/keep/in.16651.c":199:34 4384
{vec_extract_hi_v32qi}
(nil))
(insn 27 26 28 5 (set (mem/c:V16QI (plus:DI (reg:DI 162)
(const_int 32 [0x20])) [0 MEM [(void *)_157]+32
S16 A128])
(subreg:V16QI (reg:V32QI 163) 0)) "runData/keep/in.16651.c":199:34 1824
{movv16qi_internal}
(nil))
cmpelim dump still has:
(insn 279 6 25 4 (set (reg/f:DI 38 r10 [215])
(plus:DI (reg/f:DI 7 sp)
(const_int -48 [0xffd0]))) 241 {*leadi}
(expr_list:REG_EQUIV (plus:DI (reg/f:DI 19 frame)
(const_int -48 [0xffd0]))
(nil)))
(insn 25 279 26 4 (set (reg:V16QI 21 xmm1 [orig:218 MEM [(void
*)_157] ] [218])
(const_vector:V16QI [
(const_int 0 [0]) repeated x16
])) "runData/keep/in.16651.c":199:34 1824 {movv16qi_internal}
(expr_list:REG_EQUIV (const_vector:V16QI [
(const_int 0 [0]) repeated x16
])
(nil)))
(insn 26 25 34 4 (set (reg:V16QI 20 xmm0 [orig:219 MEM [(void
*)_157]+16 ] [219])
(reg:V16QI 21 xmm1)) "runData/keep/in.16651.c":199:34 1824
{movv16qi_internal}
(expr_list:REG_EQUIV (const_vector:V16QI [
(const_int 0 [0]) repeated x16
])
(nil)))
before the loop and
(insn 289 22 290 5 (set (mem/c:V16QI (reg/f:DI 38 r10 [215]) [0 MEM
[(void *)_157]+0 S16 A128])
(reg:V16QI 21 xmm1 [orig:218 MEM [(void *)_157] ] [218]))
"runData/keep/in.16651.c":199:34 1824 {movv16qi_internal}
(nil))
(insn 290 289 291 5 (set (mem/c:V16QI (plus:DI (reg/f:DI 38 r10 [215])
(const_int 16 [0x10])) [0 MEM [(void *)_157]+16
S16 A128])
(reg:V16QI 20 xmm0 [orig:219 MEM [(void *)_157]+16 ]
[219]))
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476 --- Comment #15 from Jiang An --- (In reply to Maciej S. Szmigiero from comment #14) > > This is not so useful in practice because most compilers don't make extern > > "C" and extern "C++" differentiate function types (implying calling > > conventions etc.). > > The standard allows different calling conventions for "C" and "C++" language > linkage and that's what matters when writing standard-compliant code - one > shouldn't write to a particular implementation (or implementations). > The problem in pratice is that most implementations are not standard-compliant here. If you rely on the standard guarantee that extern "C" and extern "C++" make function types different, you probably get compilation errors. > > > All functions and variables whose names have external linkage and all > > > function types have a language linkage. > > > > which implies that a function with internal linkage doesn't have a language > > > linkage, and thus [dcl.link]/7 doesn't apply to it. > > Nothing in the above quote says that *only* these specified have a language > linkage, just that these explicitly enumerated sure do. I think the italic style is "the thing", which should mean that the term "language linkage" is introduced and restricted here.
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476 --- Comment #14 from Maciej S. Szmigiero --- > This is not so useful in practice because most compilers don't make extern > "C" and extern "C++" differentiate function types (implying calling > conventions etc.). The standard allows different calling conventions for "C" and "C++" language linkage and that's what matters when writing standard-compliant code - one shouldn't write to a particular implementation (or implementations). > > All functions and variables whose names have external linkage and all > > function types have a language linkage. > > which implies that a function with internal linkage doesn't have a language > > linkage, and thus [dcl.link]/7 doesn't apply to it. Nothing in the above quote says that *only* these specified have a language linkage, just that these explicitly enumerated sure do.
[Bug libstdc++/108886] Add basic_string throw logic_error when assigned a nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108886 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jonathan Wakely --- (In reply to Jonny Grant from comment #4) > Defensive programming is carefulness in libraries too; particularly > interfaces. And libstdc++ tries to check every checkable precondition with debug assertions. > The C++ standard group have a paper "P2698R0 Unconditional termination is a > serious problem" you may have seen. That's about C++ contracts. When the library starts to use contracts, you'll be able to choose how your program handles contract violations, without forcing that choice on everybody. Until then, libstdc++ uses assertions for precondition checks. I'm not going to change basic_string::assign to throw.
[Bug libstdc++/108886] Add basic_string throw logic_error when assigned a nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108886 --- Comment #5 from Jonathan Wakely --- (In reply to Jonny Grant from comment #4) > It sounds like you know the implementation really well. I wrote it. > I doubt all uses of std::string are performance intensive. Just because some aren't, doesn't mean we can ignore the ones that are. > For performance > critical code identified by a profiler I just re-write that function in C. No. std::string is probably the most widely used vocabulary type in the entire C++ standard library, and "just use C instead" is utterly unacceptable as a response to performance concerns. > Usually graphics code. > > There is what might be a performance issue, I don't know if anyone has > measured, _M_construct() appears to copy copies byte by byte in > basic_string.tcc:177 rather than using an optimized memcpy(). I've not > measured this myself. You can't use memcpy from an input iterator, the data to be copied isn't contiguous in memory.
[Bug target/109092] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 when building libgcc on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092 --- Comment #2 from Uroš Bizjak --- (In reply to Andrew Pinski from comment #1) > The issue is register_operand accepts subreg but then REGNO is checked on it. > That is obviously wrong. It should be "REG_P (operands[1]) && REGNO > (operands[1]) == VL_REGNUM" instead ... reg_or_subregno is better.
[Bug c++/109096] __has_unique_object_representations does not account for unnamed bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109096 --- Comment #3 from Jakub Jelinek --- Created attachment 54647 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54647=edit gcc13-pr109096.patch Untested fix.
[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594 Roger Sayle changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100378 --- Comment #22 from Roger Sayle --- This issue is related to PR 100378, which is another combine-related regression. In fact, PR 100378 is resolved by the (now disapproved) patch in comment #8. Presumably a variant of Richard Sandiford's make_compound_operation fix should be able to handle PR100378 too. Resolving multiple (long-standing) regressions really should be suitable for stage 4.
[Bug analyzer/109094] [13 Regression] ICE in -fanalyzer seen in qemu's target/i386/tcg/translate.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/103354] missed optimization with & and | and compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103354
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Comment #2 from Roger Sayle ---
Hi Andrew,
I believe this missed-optimization is now implemented, and GCC generates the
same (or equivalent) code for all of:
int h1(int a, int b, int c, int d) {
return (c & -(a==b)) | (d & -(a!=b));
}
int h2(int a, int b, int c, int d) {
return (a==b) ? c : d;
}
int h3(int a, int b, int c, int d) {
int t1 = a==b ? c : 0;
int t2 = a==b ? 0 : d;
return t1 | t2;
}
int h4(int a, int b, int c, int d) {
int t1 = a==b ? c : 0;
int t2 = a!=b ? d : 0;
return t1 | t2;
}
If you agree we can close this PR. I don't think this needs a new test case in
the testsuite, but I'll leave that up to you.
