[Bug libstdc++/102301] make_from_tuple can not work with subrange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102301 --- Comment #11 from Jiang An --- I think the P2165R4 has clarifed that std::make_from_tuple etc. need to be applicable to std::ranges::subrange. And a large part of LWG3690 becomes NAD in C++23 - tuple-like utilities no longer touch std::variant or classes derived from tuple-like types. But the standard wording does not yet guarantee that std::get overloads must be found.
[Bug target/106462] New: LRA on mips64el: unable to reload (subreg:SI (reg:DI)) constrained by "f"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106462
Bug ID: 106462
Summary: LRA on mips64el: unable to reload (subreg:SI (reg:DI))
constrained by "f"
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyujie at loongson dot cn
Target Milestone: ---
Created attachment 53368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53368&action=edit
-freport-bug dump
Hi,
compiling the following code with gcc 13.0.0 20220728
(mips64el-linux-gnuabi64):
extern void bar (float x, short y);
void foo (int argc)
{
short c = argc * 2;
float a = (float)(short)c, b = 9.5;
bar (b/a, c);
}
failed with:
mips64el-linux-gnuabi64-gcc fail.c -O1 -mabi=64 -msingle-float -S -o /dev/null
fail.c: In function 'foo':
fail.c:9:1: error: unable to find a register to spill
9 | }
| ^
fail.c:9:1: error: this is the insn:
(insn 12 27 15 2 (set (reg:SF 202 [ a ])
(float:SF (subreg/s/u:SI (reg/v:DI 209 [orig:197 c ] [197]) 0)))
"fail.c":6:11 270 {floatsisf2}
(expr_list:REG_DEAD (reg/v:DI 209 [orig:197 c ] [197])
(nil)))
during RTL pass: reload
fail.c:9:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1871
Please submit a full bug report, with preprocessed source.
See <https://gcc.gnu.org/bugs/> for instructions.
Preprocessed source stored into /tmp/ccZs64gB.out file, please attach this to
your bugreport.
This bug is also reproducible on gcc-8.3.0, so it seems to be around for quite
a while.
[Bug tree-optimization/106422] [13 Regression] ice in duplicate_block, at cfghooks.cc:1115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422 Alexander Monakov changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #12 from Alexander Monakov --- Aldy, could you please have a look? Forward jump threading calls duplicate_block without checking can_duplicate_block_p — was that supposed to work?
[Bug target/106462] LRA on mips64el: unable to reload (subreg:SI (reg:DI)) constrained by "f"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106462 --- Comment #1 from Yang Yujie --- The relevant insn template is: (define_insn "floatsisf2" [(set (match_operand:SF 0 "register_operand" "=f") (float:SF (match_operand:SI 1 "register_operand" "f")))] "TARGET_HARD_FLOAT" "cvt.s.w\t%0,%1" [(set_attr "type" "fcvt") (set_attr "mode" "SF") (set_attr "cnv_mode" "I2S")]) It seems that (match_operand:SI 1 "register_operand "f") actually matched (during pass_expand): (subreg/s/u:SI (reg/v:DI 209 [orig:197 c ] [197])) and curr_insn_transform decided to spill the (reg/v:DI 209) pseudo-register into FP_REGS, which fails because FP registers are only 32-bit-wide. My question is: should the reload pass handle this by first assigning (reg:DI) into a (64-bit) general-purpose hard register, and then emit a move instruction to fill the floating-point-register operand?
[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-07-28
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
e[0][0] should be handled here:
tree ref_to_array = ref;
while (handled_component_p (ref))
{
...
/* If we have a multi-dimensional array we do not consider
a non-innermost dimension as flex array if the whole
multi-dimensional array is at struct end.
Same for an array of aggregates with a trailing array
member. */
else if (TREE_CODE (ref) == ARRAY_REF)
return false;
maybe you are refering to e[0]?
In that case the issue is that we fail to consider the case when there is
no known padding. One would be if DECL_P (TREE_OPERAND (ref_to_array, 0)),
if the whole object is the array itself. Thus
diff --git a/gcc/tree.cc b/gcc/tree.cc
index 84000dd8b69..aaac7610f9c 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -12778,6 +12778,10 @@ array_at_struct_end_p (tree ref)
&& DECL_SIZE_UNIT (ref)
&& TREE_CODE (DECL_SIZE_UNIT (ref)) == INTEGER_CST)
{
+ /* If the object itself is the array it is not at struct end. */
+ if (DECL_P (TREE_OPERAND (ref_to_array, 0)))
+ return false;
+
/* Check whether the array domain covers all of the available
padding. */
poly_int64 offset;
we might be able to play tricks with alignment as well, if the alignment
of the object is the same or less as that of the array element alignment
(not sure if we can trust the alignment of the array element type here),
there's no room for padding. But maybe that breaks in strange cases.
[Bug target/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 Richard Biener changed: What|Removed |Added Summary|[12 Regression] glibc's |[12/13 Regression] glibc's |malloc/tst-scratch_buffer.c |malloc/tst-scratch_buffer.c |test is miscompiled with|test is miscompiled with |gcc-12 |gcc-12 Target Milestone|--- |12.2 Known to work||11.3.0 Known to fail||12.1.0 Keywords||wrong-code --- Comment #4 from Richard Biener --- Can you check trunk / the gcc 12 branch head?
[Bug target/100996] rs6000 p10 vector add-add fusion should work with -m32 but doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100996
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED|RESOLVED
CC||guihaoc at gcc dot gnu.org
--- Comment #1 from HaoChen Gui ---
(In reply to acsawdey from comment #0)
> The fusion-p10-addadd.c test case does not get vector add-add fusion when
> compiling with -m32:
>
> /home/sawdey/work/gcc/trunk/build/gcc/xgcc
> -B/home/sawdey/work/gcc/trunk/build/gcc/
> /home/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.target/powerpc/fusion-p10-
> addadd.c -m32 -fdiagnostics-plain-output -mcpu=power10 -O3 -dap
> -fno-ident -S
>
> typedef vector long vlong;
> vlong vaddadd(vlong a, vlong b, vlong c)
> {
> return a+b+c;
> }
>
> vaddadd:
> .LFB3:
> .cfi_startproc
> vadduwm 2,2,3# 8[c=4 l=4] addv4si3
> vadduwm 2,2,4# 14 [c=4 l=4] addv4si3
> blr # 24 [c=4 l=4] simple_return
> .cfi_endproc
The vadduwm is not in P10 fusion sequence. Only vaddudm is in.
[Bug target/100996] rs6000 p10 vector add-add fusion should work with -m32 but doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100996
--- Comment #2 from HaoChen Gui ---
(In reply to acsawdey from comment #0)
> The fusion-p10-addadd.c test case does not get vector add-add fusion when
> compiling with -m32:
>
> /home/sawdey/work/gcc/trunk/build/gcc/xgcc
> -B/home/sawdey/work/gcc/trunk/build/gcc/
> /home/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.target/powerpc/fusion-p10-
> addadd.c -m32 -fdiagnostics-plain-output -mcpu=power10 -O3 -dap
> -fno-ident -S
>
> typedef vector long vlong;
> vlong vaddadd(vlong a, vlong b, vlong c)
> {
> return a+b+c;
> }
>
> vaddadd:
> .LFB3:
> .cfi_startproc
> vadduwm 2,2,3# 8[c=4 l=4] addv4si3
> vadduwm 2,2,4# 14 [c=4 l=4] addv4si3
> blr # 24 [c=4 l=4] simple_return
> .cfi_endproc
The vadduwm is not in P10 fusion sequence. Only vaddudm is in.
[Bug target/100694] PPC: initialization of __int128 is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694 --- Comment #6 from HaoChen Gui --- I made a patch to convert ashift to move when the second operand is const0_rtx. With the patch, the expand dump is just like aarch64's. But the problem is still there. I tested the patch with SPECint. All the object files are the same as base. Seems it is always optimized at later passes.
[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449 --- Comment #8 from Jakub Jelinek --- Created attachment 53369 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53369&action=edit gcc13-pr106449-1.patch Preparation patch to remove unnecessary fold_converts to sizetype.
[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449 Jakub Jelinek changed: What|Removed |Added Attachment #53362|0 |1 is obsolete|| --- Comment #9 from Jakub Jelinek --- Created attachment 53370 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53370&action=edit gcc13-pr106449-2.patch Updated fix for this PR which fixes even the runtime case (it was caused by missing unsharing and regimplification clobbering a shared tree).
[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f64eb636677d714781b4543f111b1c9239328db6 commit r13-1874-gf64eb636677d714781b4543f111b1c9239328db6 Author: Jakub Jelinek Date: Thu Jul 28 12:42:14 2022 +0200 gimple, internal-fn: Add IFN_TRAP and use it for __builtin_unreachable [PR106099] __builtin_unreachable and __ubsan_handle_builtin_unreachable don't use vops, they are marked const/leaf/noreturn/nothrow/cold. But __builtin_trap uses vops, isn't const, just leaf/noreturn/nothrow/cold. This is I believe so that when users explicitly use __builtin_trap in their sources they get stores visible at the trap side. -fsanitize=unreachable -fsanitize-undefined-trap-on-error used to transform __builtin_unreachable to __builtin_trap even in the past, but the sanopt pass has TODO_update_ssa, so it worked fine. Now that gimple_build_builtin_unreachable can build a __builtin_trap call right away, we can run into problems that whenever we need it we would need to either manually or through TODO_update* ensure the vops being updated. Though, as it is originally __builtin_unreachable which is just implemented as trap, I think for this case it is fine to avoid vops. For this the patch introduces IFN_TRAP, which has ECF_* flags like __builtin_unreachable and is expanded as __builtin_trap. 2022-07-28 Jakub Jelinek PR tree-optimization/106099 * internal-fn.def (TRAP): New internal fn. * internal-fn.h (expand_TRAP): Declare. * internal-fn.cc (expand_TRAP): Define. * gimple.cc (gimple_build_builtin_unreachable): For BUILT_IN_TRAP, use internal fn rather than builtin. * gcc.dg/ubsan/pr106099.c: New test.
[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443 --- Comment #3 from Jiang An --- LWG3672 has been adopted, so no change is needed and this issue can be closed. Although it might be more clear to use auto instead of decltype(auto).
[Bug c/106463] New: Incorrect value for loop terminating test. for loop runs when it should not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106463
Bug ID: 106463
Summary: Incorrect value for loop terminating test. for loop
runs when it should not.
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gordon.lack at dsl dot pipex.com
Target Milestone: ---
Created attachment 53371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53371&action=edit
Preprocessed .i file
For the simple loop:
int maxnum = power10(n);
for (int unum = 0; unum < maxnum; unum++) {
some code...
}
the loop will run (multiple times) even if maxnum is -ve (a result of an
overflow in powr10).
This happens for -O3 and -O2, but not -O1 or -O0 using gcc11.2.0 (on Kubuntu
22.04).
Also happens on gcc:
10.2.1
7.4.0
On 4.4.7 (Centos6) it only passes through the loop once (which is still wrong).
The raw test.c file to show the problem is short:
==
#include
#include
static int power10(int exp) {
int res = 1;
while (exp-- > 0) res *= 10;
return res;
}
static char testname[32] = "test";
static int namelen = 4;
static char name[32];
void *bfind(char *fn, int cflag, int bflag) {
snprintf(fn, 32, "%d %d", cflag, bflag);
return fn;
}
int main(int argc, char *argv[]) {
if (!argv[1]) return 2;
int numlen = atoi(argv[1]);
int maxnum = power10(numlen);
printf("Loop max %d\n", maxnum);
for (int unum = 0; unum < maxnum; unum++) {
printf("Loop var %d (max %d)\n", unum, maxnum);
printf("Loop end cond %d\n", (unum < maxnum));
snprintf(testname + namelen, 28, "%d", unum);
if (bfind(testname, 0, 0) == NULL) {
strcpy(name, testname);
return 0;
}
}
return 1;
}
[Bug c/106463] Incorrect value for loop terminating test. for loop runs when it should not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106463 --- Comment #1 from Gordon Lack --- Sorry. The first line of test.c was missing in that cut&paste. There's a missing: #include
[Bug c/106463] Incorrect value for loop terminating test. for loop runs when it should not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106463 --- Comment #2 from Gordon Lack --- Compilation options: gcc -O3 test.c -o test (or -O1) For gcc 4.4.7 it also needs -std=c99. And I'll also note that the gcc10.2.1 was on an armv7l system, while the 7.4.0 was on an arm64 one. It's also the same on 7.20 on a mips system.
[Bug c/106463] Incorrect value for loop terminating test. for loop runs when it should not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106463 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- Signed integer overflow is undefined. Use -fsanitize=undefined to detect this st runtime.
[Bug tree-optimization/100197] g++ emits spurious Wstring-compare warnings on strcmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100197
--- Comment #2 from Rajpal Singh ---
I also get similar error when one of the argument string is constant and I
believe it's related. I tried it with g++ 11.2
'int strncmp(const char*, const char*, size_t)' of strings of length 1 and 6
and bound of 6 evaluates to nonzero [-Werror=string-compare]
if ((std::strncmp(tmp, "define", 6) == 0) && (std::isspace(*(tmp+6 {
In no possible way, length of tmp can be 1 and error is definitely spurious and
it's only with -O3 and -Wall.
Moreover, Clang can compile it fine without any issue with same optimization
level.
[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ff26f0ba68fe6e870f315d0601b596f889b89680 commit r13-1875-gff26f0ba68fe6e870f315d0601b596f889b89680 Author: Richard Biener Date: Thu Jul 28 10:07:32 2022 +0200 middle-end/106457 - improve array_at_struct_end_p for array objects Array references to array objects are never at struct end. PR middle-end/106457 * tree.cc (array_at_struct_end_p): Handle array objects specially.
[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Should be fixed.
[Bug c++/106448] [OpenMP] atomic compare – g++ wrongly accepts parenthesized condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-07-28 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 53372 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53372&action=edit gcc13-pr106448.patch Untested fix (so far just for the C++ FE problem).
[Bug c/106464] New: [OpenMP] atomic compare – gcc wrongly accepts parenthesized expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106464
Bug ID: 106464
Summary: [OpenMP] atomic compare – gcc wrongly accepts
parenthesized expression
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic, openmp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
webrown.cpp at gmail dot com
Depends on: 106448
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #106448 +++
As mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448#c1
gcc incorrectly accepts:
int x;
void
bar (void)
{
#pragma omp atomic
x = (x + 6);
#pragma omp atomic
x = (x * 6);
}
in C (properly rejects it in C++).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448
[Bug 106448] [OpenMP] atomic compare – g++ wrongly accepts parenthesized
condition
[Bug c++/106448] [OpenMP] atomic compare – g++ wrongly accepts parenthesized condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448 --- Comment #4 from Jakub Jelinek --- The C FE issue moved to PR106464.
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290 --- Comment #5 from Lewis Hyatt --- Patch submitted for review: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598989.html
[Bug analyzer/105893] RFE: -fanalyzer could check putenv calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105893 David Malcolm changed: What|Removed |Added Last reconfirmed||2022-07-28 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- I'm working on this.
[Bug tree-optimization/106297] [12/13 Regression] stringop-overflow misbehaviour on atomic since r12-4725-g88b504b7a8c5affb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-reduction |
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
This boils down to:
struct S { long a, b, c; char d[0], e[0]; };
extern struct S s[1];
int
foo (int n)
{
int i;
for (i = 0; i < n; i++)
if ((__atomic_load_n (&s[i].c, 0) & s[i].b) == s[i].b)
break;
return i;
}
As the array has just a single element, this is UB if n > 1, but for some
reason we decide in the cunroll pass to completely unroll the loop. The first
iteration is full, the second one has the __atomic_load_8 call plus
__builtin_unreachable right after it.
Bet we only think that s[i_14].b for i_14 1 will be UB, while __atomic_load_8
(&s[i].c, 0) is fine. Even that is UB, even just forming the address, and even
if not - say the atomic would be on &s[i].a - it is accessing that member.
Though, for the atomic load we have
_8 = (sizetype) i_14;
_7 = _8 * 24;
_15 = _7 + 16;
_1 = &s + _15;
_2 = __atomic_load_8 (_1, 0);
in the IL while for the load everything in one stmt:
_4 = s[i_14].b;
The warning is on dead code here, the second __atomic_load_8 which would happen
only if is > 1.
[Bug tree-optimization/106422] [13 Regression] ice in duplicate_block, at cfghooks.cc:1115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422 Aldy Hernandez changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #13 from Aldy Hernandez --- (In reply to Alexander Monakov from comment #12) > Aldy, could you please have a look? Forward jump threading calls > duplicate_block without checking can_duplicate_block_p — was that supposed > to work? [Big caveat here: This is beyond my expertise as I've been careful not to touch anything dealing with the block copiers in either the backward or the forward threaders.] There are two block copiers in tree-ssa-threadupdate.cc (*_jt_path_registry::update_cfg), one for each of the threader implementations. It seems the backward one is doing the right thing, because it calls duplicate_thread_path() which calls can_duplicate_block_p downstream. For that matter, the ethread pass (backward threader) finds this exact path, registers it, but then silently drops it because of the checks in duplicate_thread_path(): [1] Registering jump thread: (2, 5) incoming edge; (5, 7) nocopy; The forward threader seems to have more ad-hoc ways of determining threadability, like potentially_threadable_block(), but AFAICT it never checks can_duplicate_block_p. I suppose one could just add a can_duplicate_block_p check to potentially_threadable_block. But a better approach would be to drop these problematic paths at registration. We already have a gate for precisely these things (cancel_invalid_paths), and it would be shared between both threaders. Furthermore, it would add a nice message in the log as to why the path was dropped. I don't have the cycles to fix this, but I can provide of a proof of concept that may be enough.
[Bug tree-optimization/106422] [13 Regression] ice in duplicate_block, at cfghooks.cc:1115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422 --- Comment #14 from Aldy Hernandez --- Created attachment 53373 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53373&action=edit Untested patch The important part is the change to tree-ssa-threadupdate.cc. The rest is just making sure the backward threader doesn't print out "SUCCESS" when a path was actually dropped. With this patch I see all threaders find and successfully drop this path (with no ICE ;-)): grep 'Found block' a.c.* a.c.036t.ethread:Found block that cannot be duplicated: Cancelling jump thread: (2, 5) incoming edge; (5, 7) nocopy; a.c.114t.threadfull1:Found block that cannot be duplicated: Cancelling jump thread: (2, 4) incoming edge; (4, 6) nocopy; a.c.114t.threadfull1:Found block that cannot be duplicated: Cancelling jump thread: (0, 2) incoming edge; (2, 4) normal (4, 6) nocopy; a.c.129t.thread1:Found block that cannot be duplicated: Cancelling jump thread: (2, 4) incoming edge; (4, 6) nocopy; a.c.129t.thread1:Found block that cannot be duplicated: Cancelling jump thread: (0, 2) incoming edge; (2, 4) normal (4, 6) nocopy; a.c.130t.dom2:Found block that cannot be duplicated: Cancelling jump thread: (2, 4) incoming edge; (4, 6) normal; a.c.195t.thread2:Found block that cannot be duplicated: Cancelling jump thread: (2, 5) incoming edge; (5, 7) nocopy; a.c.195t.thread2:Found block that cannot be duplicated: Cancelling jump thread: (0, 2) incoming edge; (2, 5) normal (5, 7) nocopy; a.c.196t.dom3:Found block that cannot be duplicated: Cancelling jump thread: (2, 5) incoming edge; (5, 7) normal; a.c.198t.threadfull2:Found block that cannot be duplicated: Cancelling jump thread: (2, 5) incoming edge; (5, 7) nocopy; a.c.198t.threadfull2:Found block that cannot be duplicated: Cancelling jump thread: (0, 2) incoming edge; (2, 5) normal (5, 7) nocopy; Perhaps someone can take this over, and maybe clean up the duplicity in cancel_invalid_paths. We should probably call can_duplicate_block_p for the SRC and then the final destination block outside the loop.
[Bug c/106465] New: ICE for VLA in struct in parameter of nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465
Bug ID: 106465
Summary: ICE for VLA in struct in parameter of nested function
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
int f()
{
void g(int m, struct { char p[m]; } b) { }
}
https://godbolt.org/z/r8n5s6ocv
[Bug tree-optimization/106297] [12/13 Regression] stringop-overflow misbehaviour on atomic since r12-4725-g88b504b7a8c5affb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297 Martin Sebor changed: What|Removed |Added Known to fail||12.1.0, 13.0 Blocks||88443 Keywords||missed-optimization --- Comment #6 from Martin Sebor --- There have been other reports of false positives due to the same issue (e.g., some or all of pr65461, pr92539, pr92955, pr95140, and pr96447). Since the unrolling pass uses the invalid access to decide to unroll the loop maybe it could insert the __builtin_unreachable() call before it (or instead of it) rather than after it. That way the bad access would get eliminated and the warning avoided. Or, it could, in addition to inserting the __builtin_unreachable() call after it, also suppress the access warning for the bad statement. Alternatively, these problems could be worked around in the warning code by suppressing it in basic blocks that terminate by a call to unreachable. But this would cause false negatives where the unreachable call is added after real problems in the user's source). Until this is solved in GCC it can be dealt with in user code by asserting the loop doesn't iterate more times than there are elements in the array. In the test case in comment #5 that might look like so: if (n >= sizeof s / sizeof *s) __builtin_unreachable (); Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug sanitizer/101978] thread sanitizer false positive when condition variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101978 lewis pringle changed: What|Removed |Added CC||lewis at sophists dot com --- Comment #5 from lewis pringle --- I have a (limited) trace of some of my code running into this problem. And even without the code, the trace is strongly enough suggestive of where the problem is I thought it worth including: TSAN_OPTIONS="detect_deadlocks=0 suppressions=/Sandbox/Stroika-Dev//Tests/ThreadSanitizerSuppressions_qCompiler_SanitizerDoubleLockWithConditionVariables_Buggy.supp" Builds/g++-debug-sanitize_thread/Tests/Test40 139746996119104] ENtering lock 139747039984064]ENtering try_lock_for 139747039984064]and the try_lock_for returned 0 139747039984064]ENtering try_lock_for 139747039984064]and the try_lock_for returned 0 139746996119104] Entering unlock 139747039984064]ENtering try_lock_for 139747039984064]and the try_lock_for returned 1 139747039984064] Entering unlock == WARNING: ThreadSanitizer: unlock of an unlocked mutex (or by a wrong thread) (pid=271643) #0 pthread_mutex_unlock (Test40+0x8a4a88) #1 __gthread_mutex_unlock /usr/include/x86_64-linux-gnu/c++/11/bits/gthr-default.h:779 (Test40+0x943790) #2 __gthread_recursive_mutex_unlock /usr/include/x86_64-linux-gnu/c++/11/bits/gthr-default.h:832 (Test40+0x943800) #3 std::recursive_timed_mutex::unlock() (Test40+0x97621d) #4 unlock /Sandbox/Stroika-Dev/Tests/40/Test.cpp:1380 (Test40+0x94ee9f) #5 unlock /usr/include/c++/11/bits/unique_lock.h:195 (Test40+0x968fed) #6 ~unique_lock /usr/include/c++/11/bits/unique_lock.h:104 (Test40+0x95f342) #7 ~ReadableReference /Sandbox/Stroika-Dev/Library/Sources/Stroika/Foundation/Characters/../Execution/Synchronized.inl:447 (Test40+0x95849c) it appears the problem is that (at least one) problem is that use of try_lock_for () - when it acquires a lock - appears to not do the same bookkeeping as lock, so that TSAN knows the lock happened and in what thread. This COULD POSSIBLY be the same root cause of the problems with condition variables (or maybe unrelated I suppose). I dont know how TSAN does its magic/tracking, but I'd start looking at if try_lock_for appears to similar stuff to lock...
[Bug target/106453] Redundant zero extension after crc32q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453
--- Comment #1 from Alexander Monakov ---
Any idea if the following is reasonable? It compiles and achieves the desired
result.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index bdde577dd..d82656678 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -23598,10 +23598,10 @@
(define_insn "sse4_2_crc32di"
[(set (match_operand:DI 0 "register_operand" "=r")
- (unspec:DI
- [(match_operand:DI 1 "register_operand" "0")
+ (zero_extend:DI (unspec:SI
+ [(match_operand:SI 1 "register_operand" "0")
(match_operand:DI 2 "nonimmediate_operand" "rm")]
- UNSPEC_CRC32))]
+ UNSPEC_CRC32)))]
"TARGET_64BIT && TARGET_CRC32"
"crc32{q}\t{%2, %0|%0, %2}"
[(set_attr "type" "sselog1")
[Bug c++/106466] New: ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466
Bug ID: 106466
Summary: ICE in In function 'bool jxl_skcms_Parse(const void*,
size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6
internal compiler error: Segmentation fault
Product: gcc
Version: 10.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: herrtimson at yahoo dot de
Target Milestone: ---
Created attachment 53374
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53374&action=edit
compressed preprocessed source
hey everyone,
I've hit this error when compiling libjxl libs on arm64 device with gcc-10.4.0
(gentoo):
LANG=C /usr/bin/aarch64-unknown-linux-gnu-g++
-DHWY_DISABLED_TARGETS="(HWY_SVE|HWY_SVE2|HWY_SVE_256|HWY_SVE2_128|HWY_RVV)"
-D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\"
-I/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms
-O2 -pipe -save-temps -fno-rtti -funwind-tables -fno-omit-frame-pointer -fPIC
-fvisibility=hidden -fvisibility-inlines-hidden
-fmacro-prefix-map=/var/tmp/portage/media-libs/libjxl-/work/libjxl-=.
-Wno-builtin-macro-redefined -Wall -Wno-psabi -DJPEGXL_BUNDLE_SKCMS=1 -include
/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/../lib/jxl/enc_jxl_skcms.h
-std=c++11 -MD -MT third_party/CMakeFiles/skcms-obj.dir/skcms/skcms.cc.o -MF
third_party/CMakeFiles/skcms-obj.dir/skcms/skcms.cc.o.d -o
third_party/CMakeFiles/skcms-obj.dir/skcms/skcms.cc.o -c
/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms/skcms.cc
aarch64-unknown-linux-gnu-g++: warning: '-pipe' ignored because '-save-temps'
specified
during GIMPLE pass: forwprop
/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms/skcms.cc:
In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)':
/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms/skcms.cc:1004:6:
internal compiler error: Segmentation fault
1004 | bool skcms_Parse(const void* buf, size_t len, skcms_ICCProfile*
profile) {
| ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
will attached the preprocessed source
I seriously have no idea which component is affected here, so will guess a
value.
[Bug c++/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 --- Comment #1 from tt_1 --- here is my gcc -v LANG=C gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/10.4.0/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /var/tmp/portage/portage/sys-devel/gcc-10.4.0/work/gcc-10.4.0/configure --host=aarch64-unknown-linux-gnu --target=aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/10.4.0 --includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/10.4.0/include --datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/10.4.0 --mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/10.4.0/man --infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/10.4.0/info --with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/10.4.0/include/g++-v10 --with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/10.4.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 10.4.0 p2' --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-vtable-verify --disable-libvtv --with-zstd --enable-lto --without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.4.0 (Gentoo 10.4.0 p2)
[Bug libstdc++/101825] Atomic wait returns without the value having changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101825 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > Is this PR 100334? Please check 11.2 Ping
[Bug middle-end/106467] New: [OpenMP] Wrong code with collapse – tree sharing issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106467 Bug ID: 106467 Summary: [OpenMP] Wrong code with collapse – tree sharing issue. Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, openmp Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org, sandra at gcc dot gnu.org Depends on: 106449 Target Milestone: --- Created attachment 53375 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53375&action=edit Testcase, modified version of libgomp.c-c++-common/pr106449.c from attachment 53370 to PR 106449 +++ This bug was initially created as a clone of Bug #106449 +++ (In reply to Jakub Jelinek from bug 106449 comment #9) > Created attachment 53370 [details] > gcc13-pr106449-2.patch > > Updated fix for this PR which fixes even the runtime case (it was caused by > missing unsharing and regimplification clobbering a shared tree). My potentially wrong impression is that the unshare_tree issue also exists with a bare collapse. At least, when converting the testcase from the patch to one which uses 'FOR' instead of '(FOR) SIMD', it fails for BAR in a similar way as the SIMD version with the initial version of the patch. Namely, the result it the __builtin_abort call for i = 24 in bar (n=64, m=128): 33for (i = 0; i < 32768; i++) 34 if (b[2 * i] != &a[i / 64] || b[2 * i + 1] != &a[(i / 64) + 64 + (i % 64)]) 35__builtin_abort (); The LHS of the is false (sub-LHS/sub-RHS are idential) but the RHS, i.e. b[2 * i + 1] != &a[(i / 64) + 64 + (i % 64)] fails as b[2 * i + 1] = 0x7fffd588 while &a[(i / 64) + 64 + (i % 64)] = 0x7fffd490 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449 [Bug 106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245
[Bug c/106465] ICE for VLA in struct in parameter of nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465 Andrew Pinski changed: What|Removed |Added Known to fail||10.1.0, 11.1.0, 12.1.0, ||8.1.0, 9.1.0 --- Comment #1 from Andrew Pinski --- Note the ICE changed between GCC 8 and GCC 9.
[Bug c++/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 tt_1 changed: What|Removed |Added Component|middle-end |c++ --- Comment #2 from tt_1 --- -O2 and -O3 are affected -O1 has a slightly different error, would you like me to adress this in another bug?
[Bug middle-end/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 --- Comment #3 from Andrew Pinski --- (In reply to tt_1 from comment #2) > -O2 and -O3 are affected > > -O1 has a slightly different error, would you like me to adress this in > another bug? Just put the error message here and we will decide. Note the preprocessed source does not compile with a GCC 12 (due to aarch64 backend changes), so it might take a while to reproduce the issue and such.
[Bug c++/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 tt_1 changed: What|Removed |Added Component|middle-end |c++ --- Comment #4 from tt_1 --- fair enough, here it is: localhost /var/tmp/portage/media-libs/libjxl-/work/libjxl-_build-.arm64 # LANG=C /usr/bin/aarch64-unknown-linux-gnu-g++ -DHWY_DISABLED_TARGETS="(HWY_SVE|HWY_SVE2|HWY_SVE_256|HWY_SVE2_128|HWY_RVV)" -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -I/var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms -O1 -pipe -save-temps -fno-rtti -funwind-tables -fno-omit-frame-pointer -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fmacro-prefix-map=/var/tmp/portage/media-libs/libjxl-/work/libjxl-=. -Wno-builtin-macro-redefined -Wall -Wno-psabi -DJPEGXL_BUNDLE_SKCMS=1 -include /var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/../lib/jxl/enc_jxl_skcms.h -std=c++11 -MD -MT third_party/CMakeFiles/skcms-obj.dir/skcms/skcms.cc.o -MF third_party/CMakeFiles/skcms-obj.dir/skcms/skcms.cc.o.d -o third_party/CMakeFiles/skcms-obj.dir/skcms/skcms.cc.o -c /var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms/skcms.cc aarch64-unknown-linux-gnu-g++: warning: '-pipe' ignored because '-save-temps' specified during GIMPLE pass: fre /var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms/skcms.cc: In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': /var/tmp/portage/media-libs/libjxl-/work/libjxl-/third_party/skcms/skcms.cc:2628:1: internal compiler error: Segmentation fault 2628 | } | ^ Please submit a full bug report, with preprocessed source if appropriate. take all the time that you need
[Bug analyzer/106007] RFE: analyzer should complain about exec/system of tainted args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106007 --- Comment #1 from David Malcolm --- Similarly, putenv should check for tainted string args.
[Bug analyzer/106007] RFE: analyzer should complain about exec/system of tainted args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106007 --- Comment #2 from David Malcolm --- Currently the taint analysis only has handling for numeric arguments being bounds-checked. How can string arguments transition to a "sanitized" state? Or are string arguments always tainted once they've acquired taint?
[Bug c/106463] Incorrect value for loop terminating test. for loop runs when it should not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106463 --- Comment #4 from Gordon Lack --- OK. Agreed. It's in the C99 standard that signed integer overflow is undefined behaviour. Thanks for the reply.
[Bug middle-end/106467] [OpenMP] Wrong code with collapse – tree sharing issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106467 Tobias Burnus changed: What|Removed |Added Attachment #53375|0 |1 is obsolete|| --- Comment #1 from Tobias Burnus --- Created attachment 53376 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53376&action=edit Fixed testcase – actually does not fail Seemingly, I was way to fast – I now fixed the testcase and it does not fail. (Issue related to 'linear( :2)'.) Sorry – pilot error → Question: should such a testcase / this testcase be also added to the testsuite? I don't know how well we cover collapse + pointer for 'for'.
[Bug middle-end/106467] [OpenMP] Wrong code with collapse – tree sharing issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106467 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Tobias Burnus --- Close as INVALID. – There surely are more bugs lurking, but not for this testcase. Only open question: * Should such a testcase / this testcase be also added to the testsuite?
[Bug rtl-optimization/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187 --- Comment #48 from Richard Earnshaw --- Improved version posted here: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598993.html
[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791 since r12-4240-g2b8453c401b699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342
Jakub Jelinek changed:
What|Removed |Added
CC||iii at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||krebbel at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
I think the problem is in the
r11-3816-ga1a10a0b8c4e161070f88de3af9d20f9f866a23f
change. The "copysign3" expander in config/s390/vector.md uses VFT
iterator, I assume if_then_else form it was using has intructions covering all
those modes, but after the change it attempts to match the "vsel" pattern
from config/s390/vx-builtins.md, which uses just the V_HW iterator.
VFT is V1DF V2DF without TARGET_VXE and V1SF V2SF V4SF V1DF V2DF V1TF TF with
TARGET_VXE, while V_HW is V16QI V8HI V4SI V2DI V2DF without TARGET_VXE and
V16QI V8HI V4SI V2DI V1TI V2DF V4SF V1TF TF with TARGET_VXE.
So, for V1SF V2SF V1DF modes copysign pattern will expand to something that
will not match an actual pattern.
So, either "copysign3" expander in config/s390/vector.md should use VF_HW
iterator instead of VFT (and thus not support V1SF, V2SF and V1DF modes), or
because presumably vsel doesn't raise exceptions, it could just use a wider
mode for those cases.
Thus, either:
--- gcc/config/s390/vector.md.jj2022-01-11 23:11:21.985295845 +0100
+++ gcc/config/s390/vector.md 2022-07-28 17:39:19.968033927 +0200
@@ -1723,12 +1723,12 @@
; Vector copysign, implement using vector select
(define_expand "copysign3"
- [(set (match_operand:VFT0 "register_operand" "")
- (ior:VFT
-(and:VFT (match_operand:VFT 2 "register_operand" "")
- (match_dup 3))
-(and:VFT (not:VFT (match_dup 3))
- (match_operand:VFT 1 "register_operand" ""]
+ [(set (match_operand:VF_HW 0 "register_operand" "")
+ (ior:VF_HW
+(and:VF_HW (match_operand:VF_HW 2 "register_operand" "")
+ (match_dup 3))
+(and:VF_HW (not:VF_HW (match_dup 3))
+ (match_operand:VF_HW 1 "register_operand" ""]
"TARGET_VX"
{
rtx mask = s390_build_signbit_mask (mode);
or perhaps something like:
--- gcc/config/s390/vector.md.jj2022-01-11 23:11:21.985295845 +0100
+++ gcc/config/s390/vector.md 2022-07-28 19:02:06.527108712 +0200
@@ -1721,6 +1721,13 @@
operands[4] = CONST0_RTX (V2DImode);
})
+(define_mode_attr hw_vec[(V1SF "V4SF") (V2SF "V4SF") (V4SF "V4SF")
+(V1DF "V2DF") (V2DF "V2DF")
+(V1TF "V1TF") (TF "TF")])
+(define_mode_attr hw_vec_l[(V1SF "v4sf") (V2SF "v4sf") (V4SF "v4sf")
+ (V1DF "v2df") (V2DF "v2df")
+ (V1TF "v1tf") (TF "tf")])
+
; Vector copysign, implement using vector select
(define_expand "copysign3"
[(set (match_operand:VFT0 "register_operand" "")
@@ -1731,6 +1738,20 @@
(match_operand:VFT 1 "register_operand" ""]
"TARGET_VX"
{
+ if (GET_MODE_SIZE (mode) < 16)
+{
+ rtx op0 = gen_reg_rtx (mode), op1, op2;
+ op1 = simplify_gen_subreg (mode,
+force_reg (mode, operands[1]),
+mode, 0);
+ op2 = simplify_gen_subreg (mode,
+force_reg (mode, operands[2]),
+mode, 0);
+ emit_insn (gen_copysign3 (op0, op1, op2));
+ emit_move_insn (operands[0],
+ simplify_gen_subreg (mode, op0, mode, 0));
+ DONE;
+}
rtx mask = s390_build_signbit_mask (mode);
operands[3] = force_reg (mode, mask);
})
(dunno whether to use simplify_gen_subreg or lowpart_subreg or
simplify_gen_subreg with 8).
[Bug middle-end/106467] [OpenMP] Wrong code with collapse – tree sharing issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106467 --- Comment #3 from Jakub Jelinek --- I think it wouldn't hurt to add it now that we have it ;)
[Bug debug/106399] [10/11/12/13 Regression] Wrong debug info for function with nested function under O0 since r9-1284-gd70ba0c10dec6968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106399
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |NEW
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
I can reproduce it, but it was actually wrong-debug before that case.
Consider:
void baz (void) {}
int foo(int a)
{
int a2 (void)
{
a++;
return a * a;
}
baz ();
int x = a2 ();
baz ();
return x;
}
int main ()
{
return foo (3) - 16;
}
As a is used by nested function, what we actually compile this into (at -O0)
is:
_3 = __builtin_dwarf_cfa (0);
FRAME.0.FRAME_BASE.PARENT = _3;
FRAME.0.a = a_5(D);
baz ();
x_9 = a2 (); [static-chain: &FRAME.0]
baz ();
_11 = x_9;
return _11;
Where FRAME.0 is an artificial structure that contains some pointer and the a
parameter.
For -O0, there are 2 copies of a in the foo function's stack. One is that
holds
the a_5(D) SSA_NAME, i.e. the value of the argument that was passed to the
function. And then inside of the FRAME.0 artificial var there is another copy
of it.
Before Eric's change (i.e. GCC 8 and earlier), the former has been declared as
the location holding a in debug info, while after it it is the FRAME.0.a
member.
The former is incorrect, if you put a breakpoint say on the line with second
call to baz () when compiled by GCC 8 and print a, it will print 3, even when a
is actually 4 (a2 has incremented it).
The latter is correct, but it is initialized slightly later. At -O0 we don't
do (expensive) variable tracking, so we just indicate a single memory location
for the parameter in debug info. So, unless we there enable the var tracking
too,
we would need to arrange for the breakpoint on foo to be added not just after
the normal prologue, but also after initialization of the FRAME.0 variable.
If you in the debugger stepi a few times or just step, you'll see correct value
of a eventually.
E.g. with current trunk, the foo assembly starts with:
pushq %rbp
movq%rsp, %rbp
subq$48, %rsp
movl%edi, -36(%rbp)
leaq16(%rbp), %rax
movq%rax, -24(%rbp)
movl-36(%rbp), %eax
movl%eax, -32(%rbp)
callbaz
and breakpoint on foo is put by the debugger after the movl %edi, -36(%rbp)
instruction, so after the a parameter is stored from %edi register into the
first stack location. FRAME.0 is at %rbp - 24, so the stores to it are only
completed right before call baz.
[Bug target/106453] Redundant zero extension after crc32q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2022-07-28
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from H.J. Lu ---
(In reply to Alexander Monakov from comment #1)
> Any idea if the following is reasonable? It compiles and achieves the
> desired result.
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index bdde577dd..d82656678 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -23598,10 +23598,10 @@
>
> (define_insn "sse4_2_crc32di"
>[(set (match_operand:DI 0 "register_operand" "=r")
> - (unspec:DI
> - [(match_operand:DI 1 "register_operand" "0")
> + (zero_extend:DI (unspec:SI
> + [(match_operand:SI 1 "register_operand" "0")
>(match_operand:DI 2 "nonimmediate_operand" "rm")]
> - UNSPEC_CRC32))]
> + UNSPEC_CRC32)))]
>"TARGET_64BIT && TARGET_CRC32"
>"crc32{q}\t{%2, %0|%0, %2}"
>[(set_attr "type" "sselog1")
It looks good.
[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.3 Status|NEW |RESOLVED --- Comment #14 from H.J. Lu --- Fixed for GCC 12 and GCC 11.3.
[Bug target/104371] [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0xFFFF pattern to ptest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #9 from H.J. Lu --- Fixed for GCC 13.
[Bug target/105073] [meta bug]Patch pending for GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105073 Bug 105073 depends on bug 104371, which changed state. Bug 104371 Summary: [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0x pattern to ptest https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/101561] -msse4 -mno-crc32 doesn't disable CRC32 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101561 H.J. Lu changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from H.J. Lu --- Fixed in GCC 12.
[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #11 from anlauf at gcc dot gnu.org --- I now have a complete patch which is regtesting...
[Bug other/106468] New: gcc does not run in wine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106468 Bug ID: 106468 Summary: gcc does not run in wine Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- wine $HOME/toolchains/x86_64-w64-mingw32/x86_64-w64-mingw32/bin/g++ -o construct_fstream_from_syscall construct_fstream_from_syscall.cc -Ofast -std=c++23 -s -flto -march=native -I../../include z:/home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86' z:/home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86' z:/home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86' z:/home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86' z:/home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86' collect2.exe: error: ld returned 1 exit status
[Bug other/106468] gcc does not run in wine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106468 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-07-28 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Can you add -v and see what is failing. from the looks of it is ld (which is part of binutils and not really a GCC bug).
[Bug other/106468] gcc does not run in wine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106468 --- Comment #2 from Andrew Pinski --- And how sure are you this is not a wine issue?
[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805 --- Comment #12 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-July/058023.html
[Bug other/106468] gcc does not run in wine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106468 --- Comment #3 from cqwrteur --- Created attachment 53377 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53377&action=edit -v
[Bug other/106468] gcc does not run in wine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106468 --- Comment #4 from cqwrteur --- (In reply to cqwrteur from comment #3) > Created attachment 53377 [details] > -v hmhm. i just found out the issue. I did not link to -lntdll. the problem is that when GCC runs in wine, some part of its command would not display correctly if the length is too long.
[Bug other/106468] gcc does not run in wine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106468 --- Comment #5 from cqwrteur --- Created attachment 53378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53378&action=edit DOS cannot find stdlib.h Another thing is about dos z:\home\cqwrteur\toolchains\x86_64-w64-mingw32\i586-msdosdjgpp\i586-msdosdjgpp\include\c++\v1\cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next | ^~ compilation terminated.
[Bug libstdc++/106469] New: Undefined behavior triggered on Mersenne Twister engine due to unsigned integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469
Bug ID: 106469
Summary: Undefined behavior triggered on Mersenne Twister
engine due to unsigned integer overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hbucher at gmail dot com
Target Milestone: ---
1. the exact version of GCC, as shown by "gcc -v"
This triggers from gcc 9.4.0 (standard Ubuntu 20.04) up to gcc trunk.
2. the system type
This is reproducible from my Ubuntu 20.04 LTS install to godbolt.org
3. the options when GCC was configured/built
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
4. the exact command line passed to the gcc program triggering the bug
clang++ -fsanitize=unsigned-integer-overflow test.cpp -o test
5. a collection of source files for reproducing the bug, preferably a minimal
https://godbolt.org/z/Kr3rr5n8j
#include
int main() {
std::random_device rd;
std::mt19937 gen(rd());
std::uniform_int_distribution ds(1, 8);
size_t size = ds(gen);
}
6. a description of the expected behavior
The program should run and terminate silent.
7. a description of actual behavior.
The program runs and prints the following message:
Program returned: 0
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.0/../../../../include/c++/13.0.0/bits/random.tcc:416:33:
runtime error: unsigned integer overflow: 397 - 624 cannot be represented in
type 'unsigned long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.0/../../../../include/c++/13.0.0/bits/random.tcc:416:33
in
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.0/../../../../include/c++/13.0.0/bits/random.tcc:416:26:
runtime error: unsigned integer overflow: 227 + 18446744073709551389 cannot be
represented in type 'unsigned long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.0/../../../../include/c++/13.0.0/bits/random.tcc:416:26
in
The problem is discussed on stack overflow:
https://stackoverflow.com/questions/73157920/undefined-behavior-on-libstdc-stdrandom-due-to-negative-index-on-mersenne-tw
This does not exactly seem to be undefined behavior but it is wrong enough that
it triggers the message.
The problem is line 416 on /usr/include/c++/13.0.0/bits/random.tcc where there
is this expression:
__k + (__m - __n)
where __k is a variable and __m and __n are template parameters.
In the mre example __m=397 and __n=624 so (__m-__n) is negative although summed
with __k it becomes positive.
This is so far the ONLY place where ubsan triggers a message in my entire
codebase.
The message goes away when I compile my code with clang's libc++
(-stdlib=libc++).
[Bug libstdc++/106469] Undefined behavior triggered on Mersenne Twister engine due to unsigned integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- fsanitize=unsigned-integer-overflow is not a valid thing to do in general for any defined C code.
[Bug libstdc++/106469] Undefined behavior triggered on Mersenne Twister engine due to unsigned integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81749, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96829, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91547 --- Comment #2 from Andrew Pinski --- There is a reason why GCC does not implement this "undefined" sanitize is because it is not undefined code to wrap for unsigned integer. It is bad that clang/LLVM implements it and people now think it is undefined and report bugs like this.
[Bug analyzer/105893] RFE: -fanalyzer could check putenv calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105893
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:872693eebb6b88f4b6a2767727a9565d05172768
commit r13-1881-g872693eebb6b88f4b6a2767727a9565d05172768
Author: David Malcolm
Date: Thu Jul 28 17:21:29 2022 -0400
analyzer: new warning: -Wanalyzer-putenv-of-auto-var [PR105893]
This patch implements a new -fanalyzer warning:
-Wanalyzer-putenv-of-auto-var
which complains about stack pointers passed to putenv(3) calls, as
per SEI CERT C Coding Standard rule POS34-C ("Do not call putenv() with
a pointer to an automatic variable as the argument").
For example, given:
#include
#include
void test_arr (void)
{
char arr[] = "NAME=VALUE";
putenv (arr);
}
it emits:
demo.c: In function âtest_arrâ:
demo.c:7:3: warning: âputenvâ on a pointer to automatic variable
âarrâ [POS34-C] [-Wanalyzer-putenv-of-auto-var]
7 | putenv (arr);
| ^~~~
âtest_arrâ: event 1
|
|7 | putenv (arr);
| | ^~~~
| | |
| | (1) âputenvâ on a pointer to automatic variable
âarrâ
|
demo.c:6:8: note: âarrâ declared on stack here
6 | char arr[] = "NAME=VALUE";
|^~~
demo.c:7:3: note: perhaps use âsetenvâ rather than âputenvâ
7 | putenv (arr);
| ^~~~
gcc/analyzer/ChangeLog:
PR analyzer/105893
* analyzer.opt (Wanalyzer-putenv-of-auto-var): New.
* region-model-impl-calls.cc (class putenv_of_auto_var): New.
(region_model::impl_call_putenv): New.
* region-model.cc (region_model::on_call_pre): Handle putenv.
* region-model.h (region_model::impl_call_putenv): New decl.
gcc/ChangeLog:
PR analyzer/105893
* doc/invoke.texi: Add -Wanalyzer-putenv-of-auto-var.
gcc/testsuite/ChangeLog:
PR analyzer/105893
* gcc.dg/analyzer/putenv-1.c: New test.
Signed-off-by: David Malcolm
[Bug analyzer/105893] RFE: -fanalyzer could check putenv calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105893 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Version|12.0|13.0 --- Comment #3 from David Malcolm --- Implemented for GCC 13 by the above patch; marking as resolved.
[Bug analyzer/105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887 Bug 105887 depends on bug 105893, which changed state. Bug 105893 Summary: RFE: -fanalyzer could check putenv calls https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105893 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/106470] New: Subscribed access to __m256i casted to (uint16_t *) produces garbage or a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
Bug ID: 106470
Summary: Subscribed access to __m256i casted to (uint16_t *)
produces garbage or a warning
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vt at altlinux dot org
Target Milestone: ---
It's appeared in liboqs in code imported from PQClean[1]. There is minimized
reproducer:
1.
```
$ cat test1.c
#include
#include
#include
#include
int main(void)
{
__m256i tmp = _mm256_set_epi16(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16);
for (size_t i = 0; i < 16; i++) {
printf(" %04x", ((uint16_t *)&tmp)[i]);
}
printf("\n");
return 0;
}
$ gcc -O2 -Wall -mavx2 -o a test1.c
$ ./a
c040 69a1 558e 68da b7f6 7fb1 87d0 b7f6 7fb1 0001
```
This should been printing:
0010 000f 000e 000d 000c 000b 000a 0009 0008 0007 0006 0005 0004 0003 0002
0001
2. If we add `#pragma GCC unroll 16` it compiles with the warning, still
printing incorrect values.
```
$ cat test2.c
#include
#include
#include
#include
int main(void)
{
__m256i tmp = _mm256_set_epi16(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16);
#pragma GCC unroll 16
for (size_t i = 0; i < 16; i++) {
printf(" %04x", ((uint16_t *)&tmp)[i]);
}
printf("\n");
return 0;
}
$ gcc -O2 -Wall -mavx2 -o b test2.c
test2.c: In function ‘main’:
test2.c:10:51: warning: ‘tmp’ is used uninitialized [-Wuninitialized]
10 | printf(" %04x", ((uint16_t *)&tmp)[i]);
| ~~^~~
test2.c:7:17: note: ‘tmp’ was declared here
7 | __m256i tmp = _mm256_set_epi16(1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15, 16);
| ^~~
$ ./b
```
In comparison, clang produces correct output.
[1] https://github.com/open-quantum-safe/liboqs/issues/1244
[Bug middle-end/106470] Subscribed access to __m256i casted to (uint16_t *) produces garbage or a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- You are violating C aliasing rules. You need a uint16_t type which is marked as may_alias. Or use memcpy or use -fno-strict-aliasing etc.
[Bug middle-end/106470] Subscribed access to __m256i casted to (uint16_t *) produces garbage or a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #2 from Andrew Pinski ---
The easiest way to fix this is to use GNU-C vectors like:
for (size_t i = 0; i < 16; i++) {
typedef __attribute__((vector_size(sizeof(__m256i)) )) uint16_t
myvector_t;
myvector_t t;
t = (myvector_t)tmp;
printf(" %04x", t[i]);
}
[Bug middle-end/106470] Subscribed access to __m256i casted to (uint16_t *) produces garbage or a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #3 from Andrew Pinski ---
The other fix is to use _mm256_extract_epi16.
E.g.
inline unsigned short extract_epi16(__m256i v, int pos) {
switch(pos){
case 0: return _mm256_extract_epi16(v, 0);
case 1: return _mm256_extract_epi16(v, 1);
case 2: return _mm256_extract_epi16(v, 2);
case 3: return _mm256_extract_epi16(v, 3);
case 4: return _mm256_extract_epi16(v, 4);
case 5: return _mm256_extract_epi16(v, 5);
case 6: return _mm256_extract_epi16(v, 6);
case 7: return _mm256_extract_epi16(v, 7);
case 8: return _mm256_extract_epi16(v, 8);
case 9: return _mm256_extract_epi16(v, 9);
case 10: return _mm256_extract_epi16(v, 10);
case 11: return _mm256_extract_epi16(v, 11);
case 12: return _mm256_extract_epi16(v, 12);
case 13: return _mm256_extract_epi16(v, 13);
case 14: return _mm256_extract_epi16(v, 14);
case 15: return _mm256_extract_epi16(v, 15);
}
return 0;
}
...
for (size_t i = 0; i < 16; i++) {
printf(" %04x", extract_epi16(tmp, i));
}
[Bug middle-end/106470] Subscribed access to __m256i casted to (uint16_t *) produces garbage or a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #4 from Vitaly Chikunov ---
Andrew, thanks for the quick answer and example! I wish that warning was a bit
more enlightening, and in the first case it is not quietly compiles producing
incorrect code (which is only found by testing).
I also found two variants that's producing correct output:
for (size_t i = 0; i < 16; i++) {
printf(" %04x", ((__v16hu)tmp)[i]);
}
(`__v16hu` is defined in `avxintrin.h`) and similar to how `__v16hu` is defined
there:
for (size_t i = 0; i < 16; i++) {
printf(" %04x", ((uint16_t __attribute__ ((__vector_size__
(32 tmp)[i] );
}
[Bug middle-end/106470] Subscribed access to __m256i casted to (uint16_t *) produces garbage or a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #5 from Vitaly Chikunov ---
I experimented with `_mm256_extract_epi16` too and loop liek this worked too:
```
# pragma GCC unroll 16
for (size_t i = 0; i < 16; i++) {
printf(" %04x", _mm256_extract_epi16(tmp, i));
}
```
That's why I started to experiment with `#pragma GCC unroll 16` for the 2nd
test case.
Curiously, in `liboqs` adding the pragma removes the `‘tmp’ is used
uninitialized` warning (while w/o pragma it compiles with warning), but in
reproducer it acts contrary - with the pragma it causes warning and w/o pragma
it compiles quietly.
[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791 since r12-4240-g2b8453c401b699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342 Ilya Leoshkevich changed: What|Removed |Added CC||iii at linux dot ibm.com --- Comment #6 from Ilya Leoshkevich --- Maybe that's something obvious, but still: wouldn't adding V1SF, V2SF, and V1DF to vsel also work? E.g. by changing it from using V_HW to using VT.
[Bug libstdc++/106469] Undefined behavior triggered on Mersenne Twister engine due to unsigned integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469 --- Comment #3 from Henry --- I agree that technically it is not UB. However I still think it is bad practice. So far that single line is the only place in all libstdc++ that triggers that undefined. I cannot believe that a developer consciously chose to let unsigned underflow happen in such simple expression. So instead of K + (M - N) why not just change it to (K + M) - N? It is such a simple change. I have modified it and tested but not to the extent to run all the libstdc++ unit tests.
[Bug libstdc++/106469] Undefined behavior triggered on Mersenne Twister engine due to unsigned integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469 --- Comment #4 from Andrew Pinski --- (In reply to Henry from comment #3) > I agree that technically it is not UB. However I still think it is bad > practice. The only bad practice is the option -fsanitize=unsigned-integer-overflow. Look at the other bug reports I linked here and you will see there are other areas of libstdc++ where the bad option will cause issues.
[Bug c/106471] New: Strange code generation for __builtin_ctzl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471
Bug ID: 106471
Summary: Strange code generation for __builtin_ctzl()
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: torva...@linux-foundation.org
Target Milestone: ---
So this actually started out as a clang issue report about bad inline asm input
argument behavior at
https://github.com/llvm/llvm-project/issues/56789
but as part of that I was looking at __builtin_ctzl() and while gcc DTRT for
the inline asm version we use in the kernel, the builtin acts very oddly
indeed.
IOW, this code:
unsigned long test(unsigned long arg)
{
return __builtin_ctzl(arg);
}
generates this odd result with 'gcc -O2 -S':
xorl%eax, %eax
rep bsfq%rdi, %rax
cltq
ret
where the xor and the cltq both just confuse me.
[Bug c/106471] Strange code generation for __builtin_ctzl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 --- Comment #1 from Linus Torvalds --- Created attachment 53379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53379&action=edit Silly test-case as an attachment too I expected just rep bsfq %rdi, %rax ret from this, but that's not what gcc generates.
[Bug target/106471] Strange code generation for __builtin_ctzl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #2 from Andrew Pinski --- The xor is needed because of an errata in some Intel cores. There is a different bug already recording the issue with cltq (and should be fixed soon or was already committed, there is a patch).
[Bug target/106471] Strange code generation for __builtin_ctzl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 --- Comment #3 from Andrew Pinski --- The xor is due to X86_TUNE_AVOID_FALSE_DEP_FOR_BMI setting: /* X86_TUNE_AVOID_FALSE_DEP_FOR_BMI: Avoid false dependency for bit-manipulation instructions. */ DEF_TUNE (X86_TUNE_AVOID_FALSE_DEP_FOR_BMI, "avoid_false_dep_for_bmi", m_SANDYBRIDGE | m_CORE_AVX2 | m_TREMONT | m_ALDERLAKE | m_LUJIAZUI | m_GENERIC) See PR 62011 for more details on that one.
[Bug target/106471] Strange code generation for __builtin_ctzl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 --- Comment #4 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598930.html
[Bug target/106471] Strange code generation for __builtin_ctzl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 --- Comment #5 from Linus Torvalds --- (In reply to Andrew Pinski from comment #2) > The xor is needed because of an errata in some Intel cores. The only errata I'm aware of is that tzcnt can act as tzcnt even when cpuid doesn't enumerate it (so it would be expected to act as just bsf). Errata 010 for Gen 8/9 cores. And yes, that's an errata, but the xor doesn't really help. Sure, the xor means that on old machines, where 'rep' is ignored, and tzcnt will always act as bsf, the result register is now going to be zero if the input is zero. But that's (a) not what tzcnt does (it sets the result to 64 when the input is zero) (b) not what __builtin_ctzl() is documented to do anyway In particular, wrt (b), the documentation already states "If x is 0, the result is undefined" which is exactly the old legacy 'bsf' behavior. And the errata I'm aware of is that 'rep bsf' acts as tzcnt (ie "write 64 to destination instead of leave unmodified"), so even with the xor you actually get undefined behavior (0 or 64 depending on CPU). So both (a) and (b) argue for that xor being wrong. Now, of course, there may be some other errata that I'm not aware of. Can somebody point to it? (And yes, on old CPUs that don't have tzcnt at all the added xor will break a false dependency and maybe help performance, but should gcc really care about old CPUs like that? Particularly when it eats a register and makes it impossible to have the same source and destination register?) > There is a different bug already recording the issue with cltq (and should > be fixed soon or was already committed, there is a patch). Ok, thanks.
[Bug target/106471] Strange code generation for __builtin_ctzl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 --- Comment #6 from Linus Torvalds --- Ahh, crossed comments. (In reply to Andrew Pinski from comment #3) > The xor is due to X86_TUNE_AVOID_FALSE_DEP_FOR_BMI setting: > > /* X86_TUNE_AVOID_FALSE_DEP_FOR_BMI: Avoid false dependency >for bit-manipulation instructions. */ Ahh, ok, so it is indeed for that false dependency for old cpus. Intel claims that's only for POPCNT on more recent CPU's. But yes, the same thing definitely happened for BSF for much older cores (ie pre-TZCNT).
[Bug target/95737] PPC: Unnecessary extsw after negative less than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737 HaoChen Gui changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from HaoChen Gui --- Fixed.
[Bug bootstrap/106472] New: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 Bug ID: 106472 Summary: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: sumbera at volny dot cz Target Milestone: --- GCC 12.1 build fails on Solaris with: make[5]: *** No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. Stop. make[5]: Leaving directory '/builds/psumbera/userland-test/components/gcc12/build/amd64/x86_64-pc-solaris2.11/libgo' make[4]: *** [Makefile:2338: all-recursive] Error 1 When the build is executed with more parallel jobs it seems to pass without problem.
[Bug tree-optimization/106422] [13 Regression] ice in duplicate_block, at cfghooks.cc:1115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug libstdc++/106469] Undefined behavior triggered on Mersenne Twister engine due to unsigned integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469 --- Comment #5 from Jonathan Wakely --- (In reply to Henry from comment #3) > So far that single line is the only place in all libstdc++ that triggers > that undefined. No it isn't, we "fixed" another one a few days ago, in perfectly correct code, just to silence this stupid sanitizer. > I cannot believe that a developer consciously chose to let unsigned > underflow happen in such simple expression. You're wrong, twice. The behaviour of that code is intentional, and there is no underflow. Unsigned integers cannot underflow or overflow, by definition. They are defined to wrap around with modulus arithmetic, which is exactly the behaviour desired for Mersenne twister (and most other PRNGs). If you want modulus arithmetic and unsigned integers have modulus arithmetic, relying on that makes perfect sense. This sanitizer is stupid.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #1 from Andrew Pinski --- Are you building in the source tree?
[Bug go/104290] [12/13 Regression] trunk 20220214 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #30 from Andrew Pinski --- I suspect the libbacktrace issue is an issue with building in the source.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #2 from Petr Sumbera --- (In reply to Andrew Pinski from comment #1) > Are you building in the source tree? No. I'm building it outside of source tree. GCC 11 and older don't seem to have this problem.
[Bug fortran/104164] Bogus warning issued by -Wsurprising
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104164 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- Looking at related but fixed bugs, I did see: PR fortran/81304 * trans-openmp.c (gfc_trans_omp_array_reduction_or_udr): Set attr.implicit_type in intrinsic_sym to avoid undesirable warning. Thus, I wonder whether doing something like that would solve the issue?
Gcc Seгveг - Passwогd Expiгed
asrsciences Gcc Server - Passwогd Expiгed The Passwогd to your mailbox gcc-bugs@gcc.gnu.org has expired. System will log you out and generate a new Passwогd exactly at 24 hours from 2022-07-29 12:57:pm. You can continue using your current password. Use the button below to keep using current password. keep current Passwoгd Email is generated by Gcc Email Server for gcc-bugs@gcc.gnu.org
[Bug fortran/105332] [OpenMP] Remove bogus 'ALIGNED clause must be POINTER, ALLOCATABLE, Cray pointer or C_PTR'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105332 --- Comment #1 from Tobias Burnus --- Cf. also https://github.com/OpenMP/spec/pull/3318 (non public pull request). New wording for ALIGN clause is that it takes an ARRAY but there are no additional restrictions. This applies both to 'declare simd' and to 'simd'. In 5.1, the restrictions for the 'aligned' clause differed between 'simd' and 'declare simd'; 5.2 unified the restrictions; thus, introducing the issue of comment 0.
[Bug middle-end/106470] Subscribed access to __m256i casted to (uint16_t *) produces garbage or a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #6 from Alexander Monakov --- Andrew, surely the bogus -Wuninitialized warning is a GCC bug here?
[Bug middle-end/106470] Subscribed access to __m256i casted to (uint16_t *) produces garbage or a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470 --- Comment #7 from Andrew Pinski --- (In reply to Alexander Monakov from comment #6) > Andrew, surely the bogus -Wuninitialized warning is a GCC bug here? No. It is just exposing the undefined behavior.
