[Bug target/105354] __builtin_shuffle for alignr generates suboptimal code unless SSSE3 is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105354 --- Comment #2 from Hongtao.liu --- (In reply to Hongtao.liu from comment #1) > Yes, and I think it's only available for simd128u8, not for > simd128u16/u32/u64. No, under sse2 the optimization is also availble for simd128u16, directly generates pshufd/shufpd for simd128u32/u64.
[Bug target/105354] __builtin_shuffle for alignr generates suboptimal code unless SSSE3 is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105354 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- Yes, and I think it's only available for simd128u8, not for simd128u16/u32/u64.
[Bug c/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #13 from Elliott M --- (In reply to Andrew Pinski from comment #12) > Actually this is NOT a gross mischaracterization of GCC's x86 inline-asm and Making the 6 registers most likely to be needed on x86 available as machine-specific constraints makes the spirit of this request available for x86. It doesn't /quite/ fully implement the request, but does cover 95% of use cases, for x86. Whereas for modern architectures it is unavailable. > not understanding that is misrepresenting the history of GCC's inline-asm > and how it just exposes internal details of GCC to the user. GCC's x86 > constraints are exactly this way because of instructions requirements (ISA > constraints) and all of these constraints are used internally too. The documented limitations of GCC's extended inline assembly language were most readily explained by it exposing GCC's internals. As such I had already guessed this was the case. Unfortunately these limitations makes it extremely painful to use for actual benefit. (I see why most cases use full assembly language .S files, instead of inline assembly language)
[Bug lto/94157] [10 Regression] error: lto-wrapper failed with -Wa,--noexecstack -Wa,--noexecstack since r10-6807-gf1a681a174cdfb82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94157 --- Comment #11 from jiawei --- (In reply to Martin Liška from comment #10) > Seems you are using the latest binutils ld, right? > > It's the newly added warning which tells that usage of executable stack is a > potential security issue: > https://sourceware.org/pipermail/binutils/2022-April/120476.html Yes, you are all right, so it seems not an error, thanks a lot!!
[Bug other/105335] libiberty does not handle script exit codes correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105335 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2022-04-23 Ever confirmed|0 |1 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #4 from Eric Botcazou --- I guess that a change like this needs a lot of testing...
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #1 from Segher Boessenkool ---
I actually had tested that:
$ make check-gcc-c
RUNTESTFLAGS="--target_board=unix'{-m64,-m32,-m32/-mpowerpc64}{-mcpu=power7,-mcpu=power8,-mcpu=power9,-mcpu=power10}'
powerpc.exp=bswap-br*"
=== gcc Summary ===
# of expected passes17
# of expected failures 1
# of unsupported tests 29
This is on powerpc64-linux. So what is different on your build, and what is
that output change?
[Bug sanitizer/105336] truncated address sanitizer stack traces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336 --- Comment #3 from Avi Kivity --- I have a multi-gigabyte reproducer. Unfortunately it's part of a huge program that didn't build with gcc until very recently. It will be quite a task to reduce it.
[Bug libfortran/105361] New: Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361 Bug ID: 105361 Summary: Incorrect end-of-file condition for derived-type I/O Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- The following test case module x implicit none type foo real :: r end type foo interface read(formatted) module procedure read_formatted end interface read(formatted) contains subroutine read_formatted (dtv, unit, iotype, vlist, iostat, iomsg) class (foo), intent(inout) :: dtv integer, intent(in) :: unit character (len=*), intent(in) :: iotype integer, intent(in) :: vlist(:) integer, intent(out) :: iostat character (len=*), intent(inout) :: iomsg read (unit,*,iostat=iostat,iomsg=iomsg) dtv%r print *,dtv%r end subroutine read_formatted end module x program main use x implicit none type(foo) :: a, b read (*,*) a, b print *,a,b end program main yields, when invoked with $ echo "1 2" | ./a.out 1. 2. At line 25 of file test.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file [...] The end-of-file condition is incorrect. The print statement in read_formatted is there just to show the input is read correctly.
[Bug d/105360] Inlined lazy parameters / delegate literals, still emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360 --- Comment #1 from Witold Baryluk --- https://godbolt.org/z/c8oT6E4cf
[Bug d/105360] New: Inlined lazy parameters / delegate literals, still emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360
Bug ID: 105360
Summary: Inlined lazy parameters / delegate literals, still
emitted
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: witold.baryluk+gcc at gmail dot com
Target Milestone: ---
```
extern bool g();
extern void f(int n);
void log(lazy int num) {
if (g()) {
const n = num();
f(n);
}
}
void p(int n) {
log(n * 137);
}
```
This should emit the same (or close to the same) as code with no `lazy` (and
num reference changed accordingly) on `log` function. (Because compiler knows
that `num ` is called once, has no side effects, is moderately expensive, etc).
And the code for p is exactly the same - log and `n * 137` fully inlined.
However, the anonymous dgliteral code is still emitted, despite not being
referenced anywhere:
```
pure nothrow @nogc @safe int example.p(int).__dgliteral2(): # < This should
not be in object file
imuleax, DWORD PTR [rdi], 137
ret
```
Rest of the object file is correct and optimal:
```
void example.log(lazy int):
pushrbp
pushrbx
mov rbp, rdi
mov rbx, rsi
sub rsp, 8
callbool example.g()
testal, al
je .L3
mov rdi, rbp
callrbx
add rsp, 8
pop rbx
pop rbp
mov edi, eax
jmp void example.f(int)
.L3:
add rsp, 8
pop rbx
pop rbp
ret
void example.p(int):
pushrbx
mov ebx, edi
callbool example.g()
testal, al
je .L6
imuledi, ebx, 137
pop rbx
jmp void example.f(int)
.L6:
pop rbx
ret
```
gdc
(Compiler-Explorer-Build-gcc-748d46cd049c89a799f99f14547267ebae915af6-binutils-2.36.1)
12.0.1 20220421 (experimental) via godbolt.org
For a code passing reasonably big literals, this can lead to object file code
duplication.
ldc2 shows no such problem.
[Bug testsuite/105267] [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105267 --- Comment #3 from Alexandre Oliva --- HaoChen Gui posted a proposal for a narrower pattern here https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593389.html
[Bug target/105359] New: _Float128 expanders and builtins disabled on ppc targets with 64-bit long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105359 Bug ID: 105359 Summary: _Float128 expanders and builtins disabled on ppc targets with 64-bit long double Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: aoliva at gcc dot gnu.org Target Milestone: --- Target: rs6000 As described elsewhere, some tests fail on targets with 64-bit long double, because of patterns that (IMHO incorrectly) use TARGET_LONG_DOUBLE_128 in their conditions, and because of type compatibility tests that only accept _Float128 types under the same condition. https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593257.html https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593515.html There doesn't seem to be a reason for the patterns to conditioned on long double being a 128-bit type: that's too strict. A laxer condition, covering the requirements for _Float128 to be *supported*, ought to be enough. Furthermore, there doesn't seem to be any reason for -mlong-double-64 to disable those patterns even on target variants that use 128-bit long double. It's too late to fix this for GCC 12, but hopefully some rs6000/powerpc maintainer will agree that there's no reason to tie support for insn patterns and builtins for _Float128 with long double's being the same type as _Float128. It looks like all of the troublesome patterns have TARGET_HARD_FLOAT && TARGET_LONG_DOUBLE_128. I hope this problem could be fixed by replacing the latter with TARGET_FLOAT128_TYPE, but I'll defer to more knowledgeable port maintainers.
[Bug c++/105351] [concepts] Constraint checking does correctly match static member attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105351 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #3 from ensadc at mailnesia dot com --- I believe that `T::attr2` is a valid expression when it appears in a requirement. So I think GCC and Clang are correct. [expr.prim.id.general]/3: An id-expression that denotes a non-static data member or non-static member function of a class can only be used: - [...] - if that id-expression denotes a non-static data member and it appears in an unevaluated operand. [expr.prim.req.general]/2: Expressions appearing within a requirement-body are unevaluated operands.
[Bug target/104118] gcc11 fails to build R for ppc64 on 10.5.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104118 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Iain Sandoe --- This should be fixed in 11.3.0 - please check (I could not reproduce this bug locally).
[Bug modula2/101391] Unresolved reference to module getopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101391 Gaius Mulley changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Gaius Mulley --- I'm closing this PR as I believe it to be fixed and there are additional regression tests to specifically catch the original link problem.
[Bug libgomp/105358] New: [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358
Bug ID: 105358
Summary: [12 Regression] scan* fails on targets without aligned
memory allocators.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
r12-4529-gc7abdf46fb7ac9a0c37 introduces a change to make use of efficient
allocators where they are available.
On i686/powerpc-darwin9 there are no such allocators (not even posix_memalign)
and so the GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC flags is false.
the following change:
struct gomp_work_share
{
/* This member records the SCHEDULE clause to be used for this construct.
@@ -324,7 +348,12 @@ struct gomp_work_share
are in a different cache line. */
/* This lock protects the update of the following members. */
+#ifdef GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC
gomp_mutex_t lock __attribute__((aligned (64)));
+#else
+ char pad[64 - offsetof (struct gomp_work_share_1st_cacheline, pad)];
+ gomp_mutex_t lock;
+#endif
causes struct gomp_work_share to become less aligned than 'long long' on the
32b host, which leads to wrong code in work.c which manipulates offsets with
__alignof__(long long).
So the underlying issue is that the target does guarantee malloc aligned to a
cache line [64 bytes on x86] (but only to the size of the largest vector
supported by the target [16 bytes]).
I'm not clear what the change above is implementing (since i'm not familiar
with how this interacts with the rest of the library) so I'm probably missing
some subtlety.
... but ISTM that we could omit that change, and the structure would always
claim 64 byte alignment (with the lock correctly at offset of 64 bytes).
Of course, on these older targets, malloc only returns something guaranteed to
be 16 byte aligned - but that *is* sufficient that any use of vector operations
to manipulate the content should see suitable alignment.
We could also just force the gomp_work_share struct to be aligned to
__alignof__(long long).
I guess we also have __BIGGEST_ALIGNMENT__ which would at least mean we could
align it suitably for the target default.
At present, I'm not proposing any patch - since I do not understand the
subtleties of how these objects interact with the library.
The reason that the fail is not seen on later versions (e.g. i686-darwin17) is
because posix_memalign () was introduced in Darwin10.
[Bug modula2/102342] gm2 testsuite failures for non-default multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102342 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Gaius Mulley --- Many thanks for the patch - now applied to the modula2 branch of gcc-12.
[Bug c/105357] dereferenced ptr on param stack gets over written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105357 --- Comment #4 from vwebber --- BTW, what happens in the rare occurrence of a bug report being found valid. Regards, Victor Webber V&T: 408-221-8467 V: 805-924-1953 vweb...@msn.com -Original Message- From: Victor Webber Sent: Saturday, April 23, 2022 2:04 AM To: pinskia at gcc dot gnu.org Subject: RE: [Bug c/105357] dereferenced ptr on param stack gets over written Thank you for the comments. However, the data being overwritten is on the stack in a function which is called after the problematic scanf() etc are are run. I would suggest running up GDB and do a break on access of the overwritten lvalue. Regards, Victor Webber V&T: 408-221-8467 V: 805-924-1953 vweb...@msn.com -Original Message- From: pinskia at gcc dot gnu.org Sent: Saturday, April 23, 2022 1:07 AM To: vweb...@msn.com Subject: [Bug c/105357] dereferenced ptr on param stack gets over written https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D105357&data=05%7C01%7C%7Cccc94c12b24440504a1d08da25003521%7C84df9e7fe9f640afb435%7C1%7C0%7C637862980067506332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Xv3EJ%2FCciXIGx8Y9sxvqo1rw9mcvMISwNFnGD5Dbowk%3D&reserved=0 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- You need better error checking in your code. scanf can fail and scanf with %s without a size can definitely have a buffer overflow. You might be able to detect some of this with -fsanitize=address or by using valgrind. This is almost definitely not a bug in GCC. -- You are receiving this mail because: You reported the bug.
[Bug c/105357] dereferenced ptr on param stack gets over written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105357 --- Comment #3 from vwebber --- Thank you for the comments. However, the data being overwritten is on the stack in a function which is called after the problematic scanf() etc are are run. I would suggest running up GDB and do a break on access of the overwritten lvalue. Regards, Victor Webber V&T: 408-221-8467 V: 805-924-1953 vweb...@msn.com -Original Message- From: pinskia at gcc dot gnu.org Sent: Saturday, April 23, 2022 1:07 AM To: vweb...@msn.com Subject: [Bug c/105357] dereferenced ptr on param stack gets over written https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D105357&data=05%7C01%7C%7Cccc94c12b24440504a1d08da25003521%7C84df9e7fe9f640afb435%7C1%7C0%7C637862980067506332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Xv3EJ%2FCciXIGx8Y9sxvqo1rw9mcvMISwNFnGD5Dbowk%3D&reserved=0 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- You need better error checking in your code. scanf can fail and scanf with %s without a size can definitely have a buffer overflow. You might be able to detect some of this with -fsanitize=address or by using valgrind. This is almost definitely not a bug in GCC. -- You are receiving this mail because: You reported the bug.
[Bug target/105338] [12 Regression] Regression: jump or cmove generated for pattern (x ? CST : 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1ceddd7497e15d262ead6f673f8f5ce79dd63714 commit r12-8233-g1ceddd7497e15d262ead6f673f8f5ce79dd63714 Author: Jakub Jelinek Date: Sat Apr 23 10:25:31 2022 +0200 i386: Improve ix86_expand_int_movcc [PR105338] The following testcase regressed on x86_64 on the trunk, due to some GIMPLE pass changes (r12-7687) we end up an *.optimized dump difference of: @@ -8,14 +8,14 @@ int foo (int i) [local count: 1073741824]: if (i_2(D) != 0) -goto ; [35.00%] +goto ; [35.00%] else -goto ; [65.00%] +goto ; [65.00%] - [local count: 697932184]: + [local count: 375809640]: [local count: 1073741824]: - # iftmp.0_1 = PHI <5(2), i_2(D)(3)> + # iftmp.0_1 = PHI <5(3), i_2(D)(2)> return iftmp.0_1; } and similarly for the other functions. That is functionally equivalent and there is no canonical form for those. The reason for i_2(D) in the PHI argument as opposed to 0 is the uncprop pass, that is in many cases beneficial for expansion as we don't need to load the value into some pseudo in one of the if blocks. Now, for the 11.x ordering we have the pseudo = i insn in the extended basic block (it comes first) and so forwprop1 undoes what uncprop does by propagating constant 0 there. But for the 12.x ordering, the extended basic block contains pseudo = 5 and pseudo = i is in the other bb and so fwprop1 doesn't change it. During the ce1 pass, we attempt to emit a conditional move and we have very nice code for the cases where both last operands of ?: are constant, and yet another for !TARGET_CMOVE if at least one of them is. The following patch will undo the uncprop behavior during ix86_expand_int_movcc, but just for those spots that can benefit from both or at least one operands being constant, leaving the pure cmov case as is (because then it is useful not to have to load a constant into a pseudo as it already is in one). We can do that in the op0 == op1 ? op0 : op3 or op0 != op1 ? op2 : op0 cases if op1 is a CONST_INT by pretending it is op0 == op1 ? op1 : op3 or op0 != op1 ? op2 : op1 2022-04-23 Jakub Jelinek PR target/105338 * config/i386/i386-expand.cc (ix86_expand_int_movcc): Handle op0 == cst1 ? op0 : op3 like op0 == cst1 ? cst1 : op3 for the non-cmov cases. * gcc.target/i386/pr105338.c: New test.
[Bug c/105357] dereferenced ptr on param stack gets over written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105357 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- You need better error checking in your code. scanf can fail and scanf with %s without a size can definitely have a buffer overflow. You might be able to detect some of this with -fsanitize=address or by using valgrind. This is almost definitely not a bug in GCC.
[Bug c/105357] dereferenced ptr on param stack gets over written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105357
--- Comment #1 from Andrew Pinski ---
scanf("%s", town_name);
Can be problematic.
Especially with just size of 6.
[Bug c/105357] New: dereferenced ptr on param stack gets over written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105357 Bug ID: 105357 Summary: dereferenced ptr on param stack gets over written Product: gcc Version: 9.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vwebber at msn dot com Target Milestone: --- Created attachment 52855 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52855&action=edit c file See function Send_all_acceptable_packages() in code file. Here is the debug output. uvweb@DESKTOP-JV8VVTB:/mnt/c/Users/vwebb/Documents/slickedit/SndBx/hr$ ./a.out < hr_town_tc1.txt Town with the most number of packages is B 107 enter 94635049350200 94635049350224 94635049350248 94635049350200 94635049350224 94635049350248 29 enter 94635049350224 94635049350248 94635049350200 94635049350224 67 enter 94635049350224 94635049349808 140727292475840 94635049350248 94635049350272 140727292475840 94635049350248 94635049350272 29 enter 94635049350248 94635049350272 140727292475840 94635049350272 67 enter 94635049350272 94635049349808 37 enter 41 exit 18 enter 25 exit 140727292475840 94635049350272 0 140727292475840 94635049350272 0 29 enter 94635049350272 0 140727292475840 0 67 enter 0 94635049349808 Segmentation fault
[Bug c++/105351] [concepts] Constraint checking does correctly match static member attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105351
--- Comment #2 from Gawain Bolton ---
Yes I believe this is a bug and strangely enough clang also seems to have this
issue.
>From the draft C++20 standard concerning "simple requirements" (cf.
https://isocpp.org/files/papers/N4860.pdf page 109):
A simple-requirement asserts the validity of an expression. [Note: The
enclosing requires-expression will evaluate to false if substitution of
template arguments into the expression fails. The expression is an unevaluated
operand (7.2). — end note] [Example:
template concept C =
requires (T a, T b) {
a + b; // C is true if a + b is a valid expression
};
— end example]
Clearly T::attr2 is not a valid expression for struct T { int attr2; }
