[Bug tree-optimization/116519] Arm64(?): undue array bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519 --- Comment #2 from jbeulich at suse dot com --- And how does it know "irq" _is_ -2 (and not -3, -4, let alone positive)? After all, without the earlier value range restriction there's no warning, despite gcc then similarly not knowing [-INF,-1] is an invalid range. If a diagnostic mentions one specific value, I expect the compiler to have proven that this is _the_ value in use (perhaps for a specialized instantiation). I could somehow see a diagnostic here saying [-INF,-1] _may be_ used as an array index, and then only as an "extra" warning, not one enabled by default or -Wall. (It becoming [-INF,-2] is an effect of irq < gic_number_lines() aiui.)
[Bug c/116519] New: Arm64(?): undue array bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519 Bug ID: 116519 Summary: Arm64(?): undue array bounds warning Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at suse dot com Target Milestone: --- Created attachment 59020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59020&action=edit shrunk down example The attached example compiles fine with 13.3, but raises a warning (fails with -Werror) on 14.2 with -Wall -O2, claiming an array subscript of -2 in __irq_to_desc() when inlined into route_irq_to_guest(). Changing __irq_to_desc()'s parameter to unsigned int makes the issue go away. Whether this is Arm64-specific I can't tell; the code in question takes this specific form just there in the project the issue was first observed in.
[Bug target/116339] arm-unknown-linux-gnueabihf fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116339 --- Comment #11 from jbeulich at suse dot com --- (In reply to Andrew Pinski from comment #5) > Note this is not a gcc bug but rather binutils and has already been reported. Mind me asking what you take this from? See the gas bug that you did already link to. Just because gas accepted broken code doesn't mean it'll need to continue to. We may need some transitional mode, yet how that's to look like is entirely unclear. (In reply to Sam James from comment #10) > Jan, can you have a look? I'm happy to report issues for the various > breakages if they look prima facie like real problems and not something > necessitating a change in the gas validation. I already looked at another instance in the same file that was pointed out: 97: cfi_pop 97b - \unwind, 0xe, 0x0 There are 5 arguments there, not (as gas previously parsed it) just three. Same for 98: cfi_push 98b - __aeabi_ldiv0, 0xe, -0x4, 0x8 which I think is the line in question here. Since macro arguments (and parameters as well) are permitted to be separated by just blanks, arguments including blanks need parenthesizing or quoting. But let's continue the discussion on a proper way forward in the binutils bug.
[Bug c/116069] New: tautological-compare warnings observed only with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116069
Bug ID: 116069
Summary: tautological-compare warnings observed only with
-save-temps
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
In a construct using a macro like
# define iommu_call(ops, fn, args...) ({ \
ASSERT((ops) == &iommu_ops); \
alternative_call(iommu_ops.fn, ## args); \
})
no warning appears when compiling normally, but a warning is raised on every
use site when using -save-temps. Together with -Werror this causes builds to
fail. (For context, this is an arch override for something that has a common
default of
# define iommu_call(ops, fn, args...) ((ops)->fn(args))
.)
Bug 78497 is somewhat related, yet there aren't any comments here to retain
(with -C, as suggested there).
[Bug libstdc++/115433] unexpected increase of testsuite execution time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115433 --- Comment #3 from jbeulich at suse dot com --- (In reply to Jonathan Wakely from comment #1) > What's the baseline for comparisons, the 13.x releases? Oh, sorry, I should of course have mentioned that: Yes, 13.3.0. > Another possible culprit is that you now have tbb-devel installed on the > test machine, which causes the PSTL tests to be run instead of skipped. Some > of those are slow too. I've never heard of tbb-devel, to be honest. And I can't spot any package with "tbb" in its name on any of the hosts I've been using. (These are all somewhat older distros, fwiw.)
[Bug libstdc++/115433] New: unexpected increase of testsuite execution time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115433 Bug ID: 115433 Summary: unexpected increase of testsuite execution time Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at suse dot com Target Milestone: --- With the usual, moderate increase of the number of tests it is somewhat unexpected that a testsuite run now takes 50% more time for x86-64 targets, and about 100% more for i686 targets (and there already with a 64-bit kernel underneath). For comparison, taking a representative 64-bit system, testsuite runs took - gcc: a little over an hour - g++: less than 40 min - libstdc++: 3 hours IOW what already took longest before has now further increased by a significant percentage. (Absolute numbers are bigger on two or three generations older hardware, but the relative values remain largely the same.) All of this said - I certainly understand that moderate increases of overall execution time is always to be expected for a new major release. It's just that this time it's not quite "moderate" anymore.
[Bug target/114590] [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590 jbeulich at suse dot com changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #3 from jbeulich at suse dot com --- Indeed. Just look at spec version 4.0. Omitting shift count operands has been consistently dropped - in line with the SDM. Wherever the legacy forms with omitted operands came from, that model simply cannot be continued anymore, for being confusing. SHLD/SHRD aren't directly affected by the confusing aspect, but need to follow suit to match the shifts/rotates.
[Bug target/43644] __uint128_t missed optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43644 jbeulich at suse dot com changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #4 from jbeulich at suse dot com --- I don't know what's different about my build, but I'm seeing the new pr43644-2.c test failing, with this code generated: foo:movq%rdx, %rcx movq%rdi, %rax movq%rsi, %rdx addq%rcx, %rax adcq$0, %rdx ret
[Bug target/110762] inappropriate use of SSE (or AVX) insns for v2sf mode operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762 --- Comment #15 from jbeulich at suse dot com --- (In reply to Richard Biener from comment #12) > _mm_storel_pi could be implemented using __builtin_shufflevector these days. > Which shows exactly the same issue: (also related to comment 10) I don't think the problem is how the registers are filled (and in my example I simply used the first approach that came to mind and worked). The problem is that the arithmetic insn assumes the upper parts to not hold certain special values (or pairs thereof). Aiui one could create the exact same situation with inline assembly instead of any of the builtins. This isn't any different from using 512-bit operations for more narrow vectors when AVX512VL isn't enabled. Afaict such uses are carefully avoided for floating point vectors, and are used only in a limited number of cases on integer vectors (Hongtao recently asked me to not go any further in that direction either).
[Bug target/110762] inappropriate use of SSE (or AVX) insns for v2sf mode operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762 --- Comment #9 from jbeulich at suse dot com --- (In reply to Richard Biener from comment #1) > So what's the issue? That this is wrong for -ftrapping-math? Even without that option MXCSR may be modified for reasons contained to just the upper halves of the registers. > Or that the > return value has undefined contents in the upper half? (I don't think the > ABI specifies how V2SF is returned) This part is fine, aiui.
[Bug target/110762] New: inappropriate use of SSE (or AVX) insns for v2sf mode operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
Bug ID: 110762
Summary: inappropriate use of SSE (or AVX) insns for v2sf mode
operations
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Perhaps related to work done for bug 95046, this code
typedef float __attribute__((vector_size(8))) v2sf_t;
typedef float __attribute__((vector_size(16))) v4sf_t;
v2sf_t test(v4sf_t x, v4sf_t y) {
v2sf_t x2, y2;
__builtin_ia32_storelps(&x2, x);
__builtin_ia32_storelps(&y2, y);
return x2 + y2;
}
compiled for a 64-bit target with -O2 translates to a single addps (besides the
ret instruction of course), coming from *mmx_addv2sf3. This cannot be right:
The contents of the upper halves of both registers aren't known at this point,
so the extra care mentioned in 95046 does not look to be applied here.
[Bug target/93768] Use vpternlog for composite logical operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93768 jbeulich at suse dot com changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #3 from jbeulich at suse dot com --- (In reply to ak from comment #2) > Most of it is already done as part of PR101989 "Most" really is just one 3rd of what was reported here, isn't it? 101989 is solely about "Three-input simple logicals" (beyond the small set mentioned here). In particular I haven't seen gcc do what is requested here as "Two-input inverted logicals" (I don't think I properly understand the 3rd item about ?:, as I can't imagine it's meant to apply to a vector of individual bits), prompting me to start working on some patches. Was marking the report here as duplicate really appropriate?
[Bug target/109954] x86-64's -m32 does not conform to documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954 --- Comment #19 from jbeulich at suse dot com --- (In reply to Thomas Schwinge from comment #17) > I'm still confused. > > Conversely this means that the x86_64 'm32' multilib isn't actually "code > that runs on any i386 system", right? (Unless configured with suitable > '--with-arch-32=[32-bit x86]'.) > > However, 'gcc/config/i386/i386.opt': > > m32 > Target RejectNegative Negative(m64) InverseMask(ISA_64BIT) > Var(ix86_isa_flags) Save > Generate 32bit i386 code. > > Note: "32bit i386 code". I think this wants correcting. Just "32-bit code" is accurate (with the intentions explained throughout this bug) and then no longer misleading. > Per 'info as': > > The i386 version of 'as' has a few machine dependent options: > > '--32 | --x32 | --64' > Select the word size, either 32 bits or 64 bits. '--32' implies > Intel i386 architecture, while '--x32' and '--64' imply AMD x86-64 > architecture with 32-bit or 64-bit word-size respectively. > > Note: "'--32' implies Intel i386 architecture" (thus, 32-bit x86 code?), > again. Whereas no, in the x86 assembler it's different: No matter whether i386 or x86-64, by default all extensions are enabled.
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 --- Comment #10 from jbeulich at suse dot com --- (In reply to Hongtao.liu from comment #9) > We don't have single instruction for V8HI/V16QImode broadcast without AVX2, > that's why the first splitter only have VI48_128. Does this matter? The splitters are about subsuming the "not". How the "vec_duplicate" is carried out isn't really relevant here, is it?
[Bug target/109954] x86-64's -m32 does not conform to documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954 --- Comment #3 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #2) > So s/on any i386 system/in 32-bit mode/ ? Not sure. So far I was under the (possibly wrong) impression that -m32 would produce objects sufficiently similar to those a 32-bit compiler would produce. After all environments like the Linux kernel use it with exactly that goal (aiui), albeit in combination with -march=. So if really it is documentation to be adjusted, I think this aspect wants emphasizing more.
[Bug target/109954] New: x86-64's -m32 does not conform to documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954 Bug ID: 109954 Summary: x86-64's -m32 does not conform to documentation Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at suse dot com Target Milestone: --- Quote from doc: "The -m32 option sets int, long, and pointer types to 32 bits, and generates code that runs on any i386 system." While it may well be that the documentation is misleading, I also won't exclude that generated code is wrong instead for a compiler that defaults to generate 64-bit code: cmov or SSE insns are happily used by the compiler, for example. Respective pre-processor symbols are also defined, including __k8__ and __FXSR__. Just to make it explicit: No -march= or -mtune= options were used, just -m32.
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 jbeulich at suse dot com changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #8 from jbeulich at suse dot com --- Since the commit doesn't really explain it (maybe it's obvious to others, but it isn't to me), may I ask why two splitters were introduced, yet then still not covering all possible modes? VI48_128 only covers two of the four possible SSE2 modes, while VI124_AVX2 leaves out all DI-element-size ones as well as all 512-bit ones. Shouldn't both be folded, using VI_AVX2 as the mode iterator? As an aside, it is also interesting that the 1st splitter uses TARGET_SSE without the corresponding testcase limiting itself to just SSE. When building that testcase with SSE2 turned off, foo() uses shufps and andnps as expected, but the splitter doesn't appear to come into play at all for bar(), when really it is only the broadcast that needs synthesizing, while andnps can be used regardless of mode.
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #22 from jbeulich at suse dot com --- (In reply to LIU Hao from comment #21) > oh really? I thought it would have to be implemented. If it's readily > available, we can start making use of it right now. Well, the general symbol part of it is there (with a few quirks, which I don't think would matter here). This missing part for quoted symbols matching register names was posted, see e.g. https://sourceware.org/pipermail/binutils/2023-May/127318.html.
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #20 from jbeulich at suse dot com --- (In reply to LIU Hao from comment #19) > (In reply to jbeulich from comment #11) > > I have a rough plan on the gas side, but that will then need a gcc side > > change as well: For a couple of years we have had quoted symbol names there. > > While this doesn't currently work right in a number of cases (including the > > one needed here) the plan is to make e.g. > > > > mov eax, "ecx" > > > > not be treated the same as > > > > mov eax, ecx > > > > but considering "ecx" a symbol name due to the quotation. Obviously gcc's > > I don't like double quotes here, because it looks something different, like > in C. This is assembly; I don't see how (dis)similarity with C would matter. I also don't see how your example is any different in this regard from mov eax, "symbol" which gas has been supporting for quite some time. > Would it make some sense if we take the approach for MIPS and AArch64 > [1], so > > mov eax, %ecx > > or > > mov eax, :ecx > > denotes `ecx` is the name of a label, and otherwise a register. Also, such a > prefix should be optional, so people who write assembly can omit it if they > carefully avoid such names. I can't find any indication of such syntax being supported by gas for either of these architectures. % on MIPS and : on Arm64 actually are involved in relocation specifiers instead. Are you suggesting to overload them? (Note that % is out of game here, for being the register prefix on x86.)
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #16 from jbeulich at suse dot com --- (In reply to LIU Hao from comment #15) > This is accepted by ML64: > > ``` > PUBLICmain > EXTRN rip:DWORD > _TEXT SEGMENT > main PROC > mov eax, DWORD PTR rip > ret 0 > main ENDP > _TEXT ENDS > END > ``` Which version? And did you try other register names? Unfortunately the newest I have access to right now is 12.x, and as said in #14 register names other than "rip" won't work there when (attempted to be) used as symbols. Clearly there's little point in dealing with "rip" alone. > Does it make sense to create kinda compatibility mode for ML, in addition to > MASM, if they are deemed to be incompatible? ML == MASM, at least for me (ML and ML64 are merely the names of the [non-ancient] executables).
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #14 from jbeulich at suse dot com --- (In reply to LIU Hao from comment #13) > MSVC outputs: > ``` > get_value PROC ; COMDAT > mov ecx, DWORD PTR eax > mov rax, QWORD PTR rip > mov eax, DWORD PTR [rax+rcx*4] > ret 0 > get_value ENDP > ``` Which as least MASM up to 12.x won't assemble. For one it complains about "rip" being undeclared. And then the load of "ecx" is _not_ a memory access (i.e. the "DWORD PTR" is ignored there). Which is in line with it also objecting to something like "extrn eax:dword". I say this because I'd be happy to help this on the gas side, but only without breaking MASM compatibility. My present plan for gas is (as already outlined in #11) to make quoted identifiers unambiguously mean symbols, not registers. But of course that would still require a gcc side change as well. Unfortunately there continue to be inconsistencies in gas with quoted identifiers in general, and it's not entirely clear yet whether those may need addressing first.
[Bug c++/109660] New: module path inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109660 Bug ID: 109660 Summary: module path inconsistency Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at suse dot com Target Milestone: --- The pathname underneath gcm.cache/ is determined from the effective name used for the main input file of a particular module. When modules are built, no canonicalization occurs for the main input file. Hence the module file wouldn't be found if a different (the canonicalized) file name was used when importing that same module. This is an effect of importing happening in the preprocessor, just like #include handling. See also (and quoted from) commit d76c343d6a62 working around the issue in the testsuite.
[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257 --- Comment #4 from jbeulich at suse dot com --- (In reply to LIU Hao from comment #3) > (In reply to jbeulich from comment #2) > > Sure, but there's no reason for gas to not accept what MASM would. You also > > don't really make clear why you think this is an issue, and hence why it > > should be changed in gcc. > > Why not? The syntax is invalid because Intel software developer manual has > no reference to such construction. The fact that MASM would accept it > doesn't render it valid. Being as compatible as possible with MASM has been the primary goal of supporting Intel syntax. Intel's SDM doesn't specify complete assembly language; it serves as a reference where possible/sensible.
[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257 --- Comment #2 from jbeulich at suse dot com --- (In reply to LIU Hao from comment #0) > ptc_to_foo: > jmp [QWORD PTR foo[rip]] > ``` > > The outer pair of brackets are superfluous. Sure, but there's no reason for gas to not accept what MASM would. You also don't really make clear why you think this is an issue, and hence why it should be changed in gcc. > The `foo[rip]` part is also invalid but it's a common issue for all > addressing operands for x86_64, not specifically about jmp. Why's that invalid? foo[eax] and [foo+eax] have always been equivalent in MASM, and I see no reason why this shouldn't hold for rip-relative addressing as well.
[Bug c/108941] Error: operand type mismatch for `shr' with binutils master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941 --- Comment #16 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #15) > Above you're mixing a 32-bit argument with 8-bit argument in an instruction > which > expects probably 2 32-bit arguments or at least both arguments with the same > width. > Just try to pass 2 variables to it and use "ri" and you'll see assembler > errors, > add %dl, %eax and the like. Of course, and I did say the example was over-simplified. If it helps, consider (as also indicated) invoking a macro instead, which then inspects the operands and decides what insn to produce. This could be particularly interesting with the .insn that I'm in the process of preparing to add to x86 gas, where one would then inspect arguments in order to select a suitable major opcode. Since x86 has different possible encodings for "add immediate", the wrongly represented value would then lead to silent bad code generation. And btw - what "size" to assign to e.g. a sign-extended 8-bit immediate is at least ambiguous. I can only repeat: Unless the anomaly is properly called out in non-internal documentation, I continue to think there's a bug here. And the reference to Clang getting it right, which you simply put off, isn't entirely meaningless imo (I agree we're talking about a GNU extension here, but that doesn't imply only GNU tools can get it right).
[Bug c/108941] Error: operand type mismatch for `shr' with binutils master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #14 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #5)
> GCC doesn't even have that information at all, at the RTL level it doesn't
> know
> if it was signed or unsigned.
> All it has is the constraint and operand for it, like (reg:QI 126) or
> (const_int -1).
Lack of information at a certain layer doesn't mean this isn't a bug. It merely
makes whatever possible bug one that's hard to fix.
Furthermore you did refer to gcc internal doc as to justifying the behavior.
But can you also point me at non-internal doc making explicit that e.g.
static inline unsigned aux(unsigned i, unsigned char j) {
#if 1
asm("add %1,%0" : "+rm" (i) : "i" (j));
return i;
#else
return i + j;
#endif
}
unsigned test(unsigned i, unsigned j) {
return aux(i, 255) * aux(j, -1);
}
does not do (at -O1 or -O2) what one would expect (again on x86)? The example
is intentionally over-simplified (and hence won't build at -O0); anything more
involved could be taken care of by using assembler macros, where it is not
overly difficult to separately deal with immediates and registers.
In the absence of such documentation I would also view the "has always been
like that" argument as at least questionable.
[Bug c/108941] Error: operand type mismatch for `shr' with binutils master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941 --- Comment #9 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #1) > How does that look like a gcc bug? It is either a binutils bug for not > accepting it anymore, or ffmpeg-4 bug for relying on the negative shifts. While I'm not sure in how far reduction from original code has discarded too much context, the impression I'm getting is that they use inline assembly because if the same way expressed in a similar way in C, the compiler would warn. And then, rather than making the expression match C standard requirements, assembly code was used instead to silence that diagnostic.
[Bug c/108941] Error: operand type mismatch for `shr' with binutils master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941 --- Comment #7 from jbeulich at suse dot com --- Maybe what would help is a discussion in the context of the binutils patch, despite it already having been committed. As said there and earlier here, there may be reasons to adjust (back) some of what it did, but there needs to be a sufficiently consistent pattern behind that and at least RCL/RCR, according to whichever pattern, have to remain unsigned-only.
[Bug c/108941] Error: operand type mismatch for `shr' with binutils master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941 --- Comment #6 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #5) > GCC doesn't even have that information at all, at the RTL level it doesn't > know > if it was signed or unsigned. > All it has is the constraint and operand for it, like (reg:QI 126) or > (const_int -1). > As I said earlier, constants are always sign-extended from their mode. > One could e.g. have during expansion (set (reg:QI 126) (const_int -1)) > and later on asm_operands with "ic" and (reg:QI 126). Same assignment for > int8_t x = -1 or int8_t x = 255 or uint8_t x = -1 or uint8_t x = 255, at > GIMPLE one can differentiate that based on types, at RTL one has just mode. While for int8_t x = -1 or int8_t x = 255 I can see that the result is as described, for uint8_t x = -1 or uint8_t x = 255 (or, as in the example, a constant the was cast to an unsigned 8-bit type) why is it not (const int 255)?
[Bug c/108941] Error: operand type mismatch for `shr' with binutils master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #4 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #1)
> GCC inline asm has always worked like that, the operand is 8-bit and in GCC
> constants are always sign-extended.
But then ...
> If you try just
> static inline unsigned int
> foo (unsigned int a, signed char s)
> {
> asm volatile ("# %1" : "+r" (a) : "ic" ((unsigned char) -s));
this should be sign-extension of the supplied value, i.e. the (potentially
negative) value cast to "unsigned char". And gas will be happy to accept that.
> In the assembly, if you have a spot which accepts 8-bit quantity, one
> shouldn't care if it is signed or unsigned.
I firmly disagree: I assume you did look at the description of the gas change.
A negative value for SHL may (by some) be viewed as reasonable (and as said in
the submission, I could have been convinced to further relax things, provided
fair arguments), but a negative value for RCL firmly is rubbish and hence
should have been rejected years ago.
[Bug analyzer/106741] suspicious %qE related warning when building gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106741 --- Comment #3 from jbeulich at suse dot com --- If I'm reading the log right, it's stages 2 and 3 where the warnings appear, while stage 1 (using gcc10) don't expose such a warning. Interestingly the warnings do appear (once) when doing cross builds (again using gcc10) - do stage1 builds have more warnings suppressed than (single-stage) cross builds? There also was no such warning when building 12.1.0. I guess this (in gcc/analyzer/analyzer.h) might matter: /* Disable -Wformat-diag; we want to be able to use pp_printf for logging/dumping without complying with the rules for diagnostics. */ #if __GNUC__ >= 10 #pragma GCC diagnostic ignored "-Wformat-diag" #endif This does neither suppress -Wformat= nor -Wformat-extra-args.
[Bug analyzer/106741] New: suspicious %qE related warning when building gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106741 Bug ID: 106741 Summary: suspicious %qE related warning when building gcc Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: jbeulich at suse dot com Target Milestone: --- This /usr/local/src/gcc-12.2.0/gcc/analyzer/diagnostic-manager.cc: In member function ‘void ana::saved_diagnostic::dump_as_dot_node(pretty_printer*) const’: /usr/local/src/gcc-12.2.0/gcc/analyzer/diagnostic-manager.cc:783:28: warning: unknown conversion type character ‘E’ in format [-Wformat=] 783 | pp_printf (pp, "var: %qE\n", m_var); |^ /usr/local/src/gcc-12.2.0/gcc/analyzer/diagnostic-manager.cc:783:20: warning: too many arguments for format [-Wformat-extra-args] 783 | pp_printf (pp, "var: %qE\n", m_var); |^~~~ suggests the use of %qE here is wrong, unlike elsewhere in the same file when calling other functions.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 --- Comment #17 from jbeulich at suse dot com --- Largely the same is actually true for the RNDSCALEPH test added for the PR here.
[Bug target/106104] PR 87007 testcase fails with 32-bit compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106104 jbeulich at suse dot com changed: What|Removed |Added Target||i?86-*-* --- Comment #1 from jbeulich at suse dot com --- Oddly enough the testcase succeeded in 9.3, failed in 10.3, succeeded again in 11.3, and now fails again.
[Bug target/106104] New: PR 87007 testcase fails with 32-bit compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106104 Bug ID: 106104 Summary: PR 87007 testcase fails with 32-bit compiler Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at suse dot com Target Milestone: --- Much like just pointed out in PR 102464, FPU insns are used despite -fpmath=sse, and hence no VXORPS would ever be emitted.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 jbeulich at suse dot com changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #16 from jbeulich at suse dot com --- (In reply to Hongtao.liu from comment #15) > Fixed in GCC12. Only almost - the new FMA testcase there fails for i?86-*-*. I don't think even the few uses of VFMA* actually match the expectations. The majority of the operations are carried in the FPU anyway, despite -mfpmath=sse.
[Bug target/105966] x86: operations on certain few-element vectors yield very inefficient code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105966 --- Comment #4 from jbeulich at suse dot com --- (In reply to Richard Biener from comment #3) > Is not having AVX512VL relevant in the real world? Wasn't the Xeon-Phi line of processors lacking VL? I have no idea how widespread their use (still) is, though. > Some operations (division) require different handling than zero-extending, > masking might be a way out but that might turn out to be (way?) more > expensive. By expensive, you mean in terms of compiler changes? I wouldn't expect execution to be severely affected by using masking, especially when it's zeroing-masking. Or if it is, then likely because there was not enough pressure to make this mode work efficiently (after all there were various performance quirks when AVX and AVX512F were first introduced).
[Bug target/105966] x86: operations on certain few-element vectors yield very inefficient code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105966 --- Comment #2 from jbeulich at suse dot com --- (In reply to Hongtao.liu from comment #1) > What's interesting is extending slp vectorizer to handle non-pow2p elements > with vector mask. Well, for starters I think proper pow2 element counts (and especially "native" vector widths like 128- or 256-bit ones) want dealing with efficiently. But I agree the principle can be extended to non-pow2 ones.
[Bug target/105966] New: x86: operations on certain few-element vectors yield very inefficient code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105966 Bug ID: 105966 Summary: x86: operations on certain few-element vectors yield very inefficient code Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at suse dot com Target Milestone: --- Respective operations on vectors with more than one element but less than enough elements to fill minimal available register width are decomposed into scalar FMA insns. While this may be on-par for small element counts, it certainly generates absurd code for e.g. AVX512-FP16 with, say, 128- or 256-bit vectors but AVX512VL not enabled. This would be far more efficient by zero-extending the vectors to 512 bits (to avoid exceptions on the unused elements), emitting the FMA insn on %zmm registers, and then using just the low part of the result. (The same likely applies to e.g. plain addition, subtraction, and multiplication.) If necessary the example code from bug 105965 can be re-used to easily see the odd behavior.
[Bug target/105965] New: x86: single-element vectors don't have scalar FMA insns used anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105965
Bug ID: 105965
Summary: x86: single-element vectors don't have scalar FMA
insns used anymore
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
While this used to work fine up to gcc8, gcc9 and newer use
vmuls[sdh]+vadds[sdh] instead. No similar issue exists when operating on
scalars, or when operating on multi-element vectors not matching any available
register size (so my guess of "target" as the component may not be correct).
This has regressed the test harness of the Xen Project's insn emulator [1],
which no longer exercises any scalar FMA insns because of the compiler not
emitting any. (Note that using intrinsics is not really an option, as the
primary goal is to test insns with memory operands. Yet the intrinsics don't
lend themselves to such because of using 128-bit parameter types.)
The issue is uniform for FMA, FMA4, AVX512F, and AVX512-FP16. It can be easily
seen by compiling
T test(T x, T y, T z) {
return x * y + z;
}
#define TEST(n) \
typedef T __attribute__((vector_size(n * sizeof(T v##n##_t; \
v##n##_t test##n(v##n##_t x, v##n##_t y, v##n##_t z) { \
return x * y + z; \
}
TEST(1)
TEST(2)
TEST(4)
TEST(8)
TEST(16)
TEST(32)
TEST(64)
with e.g. "-mfpmath=sse -O3 -c -mfma -DT=float", but obvious other option
combinations similarly demonstrate the issue.
[1] https://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=tools/tests/x86_emulator
[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967 --- Comment #8 from jbeulich at suse dot com --- (In reply to Martin Sebor from comment #7) > Both for the purposes of the warning (which can be more restrictive than > what the language considers valid), and in the C language, the semantics of > the -> expression depend on the first operand designating an object. In C > they're defined like so: > > A postfix expression followed by the -> operator and an identifier > designates a member of a structure or union object. The value is that of > the named member of the object to which the first expression points, and is > an lvalue. 106) While gcc 12 has meanwhile been released, it's still not clear how we could at least work around this (mis-)diagnostic, _without_ simplifying the conditional expression (which, as said, actually is the result of macro expansion, and the macro should not be open-coded [and then simplified] here). It's also not just an issue with the underlining in the diagnostic - the overall expression !() as well as the conditional expression on its own isn't "always true" or "always false". It's only the 2nd operand of the ternary expression which is, but that's not on its own used in boolean context. Otherwise why would if(ps ? (void*)1 : (void*)0) not result in a similar warning? And note that while if(ps ? &ps[10] : (void*)0) does, if(ps ? &(&ps[10])[-10] : (void*)0) again doesn't, while from &ps[10] being non-NULL (pointing at or one past a valid object) it imo ought to follow that &(&ps[10])[-10] is also necessarily non-NULL. Note further that if the two array indexes don't sum up to 0, the offset reported in the diagnostic also looks to be wrong - it appears to lack division by sizeof(*ps).
[Bug tree-optimization/104497] SEGV during GIMPLE pass: pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104497
--- Comment #1 from jbeulich at suse dot com ---
Actually, while trying to determine if there's any kind of workaround for the
actual code where the prior example was derived from, I found that this can be
further simplified:
typedef float __attribute__((mode(SF), vector_size(16))) vec_t;
extern vec_t src, inv;
void init(vec_t *x, unsigned i) {
(*x)[i] = (i & 1 ? inv : src)[i];
}
Producing a somewhat different stack trace:
$ gccver=11.2.0-base gccx -Wall -W -Os -msse2 -c simd-test2.c
during GIMPLE pass: pre
simd-test2.c: In function ‘init’:
simd-test2.c:8:6: internal compiler error: Segmentation fault
8 | void init(vec_t *x, unsigned i) {
| ^~~~
0x877d21a crash_signal
/usr/local/src/gcc-11.2.0/gcc/toplev.c:327
0x88d39c5 pre_expr_DFS
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:825
0x88d3e45 sorted_array_from_bitmap_set
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:906
0x88d409f clean
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:2009
0x88da33d compute_antic
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:2519
0x88da33d execute
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:4386
[Bug tree-optimization/104497] New: SEGV during GIMPLE pass: pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104497
Bug ID: 104497
Summary: SEGV during GIMPLE pass: pre
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Compiling this
// -msse2 (on ix86) or -msse4 or -mavx
// -O0 and -O1 are okay; -Os and -O2 are not
typedef float __attribute__((mode(SF), vector_size(16))) vec_t;
extern vec_t src, inv;
void aux(vec_t);
void test(void)
{
unsigned int i;
vec_t y;
for (i = 0; i < (16 / 4); ++i)
y[i] = (i & 1 ? inv : src)[i];
aux(y);
}
yields
$ gccver=11.2.0-base gccx -Wall -W -Os -msse2 -c simd-test2.c
during GIMPLE pass: pre
simd-test2.c: In function ‘test’:
simd-test2.c:10:6: internal compiler error: Segmentation fault
10 | void test(void)
| ^~~~
0x877d21a crash_signal
/usr/local/src/gcc-11.2.0/gcc/toplev.c:327
0x88d5bdd phi_translate_1
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:1717
0x88d67f9 phi_translate
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:1770
0x88d8d4b phi_translate_set
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:1815
0x88d9067 compute_antic_aux
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:2155
0x88da2c5 compute_antic
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:2501
0x88da2c5 execute
/usr/local/src/gcc-11.2.0/gcc/tree-ssa-pre.c:4386
This same code compiles fine with gcc 10.
[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967 --- Comment #5 from jbeulich at suse dot com --- (In reply to Martin Sebor from comment #4) > The expression pa->c is only valid if pa points to a valid object. Well, yes, you may not deref pa if it's NULL, i.e. I agree for pa->c. But is &pa->c actually a deref?
[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
jbeulich at suse dot com changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment #3 from jbeulich at suse dot com ---
(In reply to Martin Sebor from comment #1)
> The warning is intended: it points out that the second operand of the
> conditional expression is necessarily true:
>
> if ( !(pa ? &pa->c : NULL) )
> ^^
>
> There's no point in testing the address of a member for equality to null
> because the member of no object can reside at that address.
Except that if pa is NULL and c is the first member of typeof(*pa), then &pa->c
is also NULL, isn't it?
> The above can
> be simplified to
>
> if (!pa)
If there was no macro expansion involved in the former case, I'd agree with the
option of simplifying the expression. But the use of the macro expanding to
this construct may be intended, perhaps at least for the code to be
self-documenting. The macro itself, in turn, may be (and in our case is) also
used in contexts where the produced pointer actually gets used as such, not for
boolean NULL / non-NULL checks.
In any event I don't see how it matters here that, as you say, "the second
operand of the conditional expression is necessarily true". Especially
considering the macro aspect, changing to "pa ? 1 : NULL" or (to make the
construct type-correct) "pa ? 1 : 0" isn't an option, yet that's what you
appear to be suggesting (as intermediate step to arrive at simply "pa").
Imo the compiler wrongly connects the use of &pa->c in the conditional
expression to the boolean context of the enclosing if(), even irrespective of
the use of !() around the conditional operator. IOW
if ( pa ? &pa->c : NULL )
should also go through without any diagnostic (at least as long as the compiler
doesn't also take into account whether the expression is the result of macro
expansion). Otherwise all you do is force people to write less legible code,
e.g. the macro becoming
#define a_to_c(pa) ({ \
type_of_c *pc_ = (pa) ? &(pa)->c : NULL; \
pc_; \
})
based on Andrew's observation that breaking out the expression doesn't result
in any warning (didn't check whether that in practice extends to the case
above).
[Bug target/33437] potentially valid construct rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33437 jbeulich at suse dot com changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #3 from jbeulich at suse dot com --- (In reply to Andrew Pinski from comment #2) > This is not a valid C. As per "All the expressions in an initializer for an object that has static or thread storage duration shall be constant expressions or string literals." long l = (long)x; then either similarly isn't (yet the compiler accepts it), or both are (which is my reading of the sentence, albeit further restrictions make this invalid). Plus if it was strictly invalid, then why would a PPC compiler accept it (as you've said yourself many years ago)? It was for a reason that I did say "potentially" in the title. Without knowing what "x" is and what relocation types a target has, the compiler has no justification to say "initializer element is not computable at load time". It might use "may", but then it would still be overly limiting. As said in the original description, "x" may simply stand for a small constant value, which C does not allow to access any (meaningfully) other way than by expressing through either an array (as in the example) or by using the address operator in the initialization. > That is (int)(long)x where > sizeof(long)!=sizeof(int)!=sizeof(void*) the linker might not know the value > at link time and therefor will need a runtime relocation and then it might > not load at load time as the value would have gotten truncated. Hence it should be the assembler's job to determine whether a suitable relocation type is available and the (static and/or dynamic) linker's job to detect and report truncation / overflow. This is not the least because later the standard also says "An implementation may accept other forms of constant expressions."
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #11 from jbeulich at suse dot com --- I have a rough plan on the gas side, but that will then need a gcc side change as well: For a couple of years we have had quoted symbol names there. While this doesn't currently work right in a number of cases (including the one needed here) the plan is to make e.g. mov eax, "ecx" not be treated the same as mov eax, ecx but considering "ecx" a symbol name due to the quotation. Obviously gcc's configure mechanism would then need to detect the assemblers capability of understanding this, and quote symbol names accordingly (perhaps universally rather than special-casing any particular names). While this isn't MASM-compatible (MASM treats "ecx" in such a case as an immediate), I view this as less of a problem than using e.g. Arm's model of enclosing a register name in parentheses to designate it as a symbol name: mov eax, (ecx) MASM treats this the same as with no parentheses present, and I consider this form to be more likely to be used in code ported from MASM than double quoted literals used as immediate constants. (Regardless of the choice in the end it may turn out necessary to hide the new behavior behind a new command line option and/or directive extension.)
[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680 --- Comment #3 from jbeulich at suse dot com --- (In reply to Martin Sebor from comment #2) > The warning is by design: it considers a constant non-null pointer value a > likely result of (invalid) arithmetic on a null pointer, as in the example > in pr99578 comment #1. If the warning is by design, there ought to be a way to avoid these specific instances without disabling the warning altogether. I'm also observing such bogus warnings in cases other than pointer derivation from literal numbers, possibly along the lines of what Andi has said in that other bug in comment 12. For Xen I've submitted a patch to work around the issue without disabling the warning, but it's not really pretty: https://lists.xen.org/archives/html/xen-devel/2021-05/msg01058.html I also consider Richard's comment 7 in that other bug as quite relevant. The compiler _guessing_ that offsetting from a NULL pointer is an actual issue conflicts with people intentionally doing so. Warnings based on heuristics should imo always be separately controllable, such that they can - if the heuristics prove to be wrong - be turned off, without affecting other, non-heuristic warnings. This is even more relevant for all those projects (like the Xen hypervisor) building with -Werror, resulting in false positive warnings breaking the build.
[Bug c/100680] New: false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680
Bug ID: 100680
Summary: false positive warning for certain __builtin_memcmp()
argument
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
In this example
struct s {
char a[8];
int i;
long l;
};
extern char ea[8];
static char sa[8] = { 1, 2, 3, 4 };
int test(void) {
const struct s*ps = (const struct s *)0x12345678L;
if(__builtin_memcmp(ps->a, ps->a, 8))
return 0;
if(__builtin_memcmp(ps->a, ea, 8))
return 0;
if(__builtin_memcmp(ps->a, sa, 8))
return 0;
if(__builtin_memcmp(ps->a, "abcdABCD", 8))
return 0;
return 1;
}
all except, oddly enough, the first invocation cause "'__builtin_memcmp'
specified bound of 8 exceeds source size of 0 [-Wstringop-overread]". Obviously
the above example is heavily simplified from actual uses in the Xen hypervisor
sources, but clearly in (at least) OS and alike low-level development it is not
uncommon for pointers to get derived from known integer constants.
[Bug inline-asm/98778] asm() accepts certain "i" (symbol) constructs despite -fpie for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98778 --- Comment #3 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #2) > In particular it is up to the inline asm writer to ensure that the result is > PIC compatible through a wise choice of constraints etc. Perhaps the description wasn't clear enough (but I think the title disambiguates it): I don't mean this to be made work. I'd expect an error on all three constructs, like with -fpic, rather than just on one of them.
[Bug inline-asm/98778] New: asm() accepts certain "i" (symbol) constructs despite -fpie for x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98778
Bug ID: 98778
Summary: asm() accepts certain "i" (symbol) constructs despite
-fpie for x86-64
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
While in the example below all 3 variants get refused ("impossible constraint")
with -fpic or with "-m32 -fpie", the ones in cases 0 and 2 get accepted with
just -fpie, producing non-position-independent code (or more precisely
unsuitable relocations).
void efn(void);
void(*efp)(void);
void*test(int i) {
void*res;
switch(i) {
case 0:
asm("mov %1,%0" : "=r" (res) : "i" (test));
break;
#ifndef __PIE__
case 1:
asm("mov %1,%0" : "=r" (res) : "i" (efn));
break;
#endif
case 2:
asm("mov %1,%0" : "=r" (res) : "i" (&efp));
break;
default:
res = (void*)0;
break;
}
return res;
}
[Bug target/53929] Bug in the use of Intel asm syntax when a global is named "and"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #7 from jbeulich at suse dot com --- For the problem originally reported here (operator name space collision) a workaround could be introduced (e.g. a new operand to .intel_syntax to allow suppressing the recognition of MASM-like operands). I don't, however, see any option for register names (besides ".intel_syntax prefix" of course, but aiui this wouldn't work with the output gcc produces, and of course this mode isn't really "Intel Syntax" anymore anyway).
[Bug target/53929] Bug in the use of Intel asm syntax when a global is named "and"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #6 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #3) > The problem is that the intel asm syntax is just badly defined (broken by > design). I'm not aware of any compiler that would emit for such testcases > something that could be assembled correctly with gas. At the risk of stating the obvious, Intel syntax implies that global symbols would have a prefix character appended, typically an underscore, or that otherwise global symbols avoid the assembler recognized identifiers. This sadly is a growing set as new register extensions get added. IOW people wanting to avoid having to rename their symbols eventually would need to also restrict the set of recognized register names via suitable .arch directives.(In reply to Jakub Jelinek from comment #5) > It is far easier to use (the default) assembler syntax that is properly > designed and doesn't have flaws like this. While in the general case I agree, there are downsides when it comes to wanting to make use of macros to "stand in" for instructions, and then wanting to e.g. derive symbols from macro arguments specifying registers. Such macros need to go to some length to get rid of the % character.
[Bug inline-asm/96081] changed placement of file scope asm() contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081 --- Comment #4 from jbeulich at suse dot com --- Turns out I was wrong here, and the re-ordering was done even by older than gcc 9. The move from 9.2 to 9.3 also included a move to a newer gas, which made the issue noticable. Feel free to close as invalid. I'm sorry for the noise.
[Bug inline-asm/96081] changed placement of file scope asm() contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081 --- Comment #2 from jbeulich at suse dot com --- I wasn't even aware of -fno-toplevel-reorder, this suffices as a workaround here. Thanks. If nevertheless you're still interested in a testcase, please let me know; for the moment I'll assume this is intended behavior, even if such a change seems somewhat odd to make between minor version releases.
[Bug inline-asm/96081] New: changed placement of file scope asm() contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96081 Bug ID: 96081 Summary: changed placement of file scope asm() contents Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at suse dot com Target Milestone: --- >From 9.2 to 9.3 (and presumably then also to 10.1) a change in when, inside the resulting assembly, file scope asm()-s get output has caused a breakage in one of the Xen Project's auxiliary tools. What I can observe is that, with any kind of optimization enabled, all asm()-s get processed first, whereas the data that we want them to control gets output last. I realize the output order is really unspecified, but I'd still like to understand if there's at least a workaround here. What we want to achieve is control over the ELF type of certain symbols, and this without triggering modern gas'es "symbol '...' already has its type set" warnings (which the new behavior not triggers, thus becoming aware of the change in the first place). Up to gcc 9.2 we simply could put .type , STT_NOTYPE; .type , STT_FUNC; after the data definition and get gcc's respective ".type , @object" overridden this way. But of course in the more general case it may also be necessary / desirable to have certain asm()-s take effect _after_ compiler output.
[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94343 --- Comment #16 from jbeulich at suse dot com --- Oh, right - I didn't pay attention to the insn permitting masking to be used. Then still non-masked uses ought to be permitted, perhaps by having a VI48_AVX512VL one permitting masking and a VI12_AVX512VL one which doesn't?
[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94343 --- Comment #13 from jbeulich at suse dot com --- As to using 512-bit operations even on more narrow input types - is this correct when e.g. subsequently source code upcasts the vector? I.e. would such an upcast be carried out by emitting an insn to zero the upper portion, rather than simply considering this a re-interpretation of the same register (with no insn emitted at all)? In which case the fix would apparently boil down to using a mode iterator different from VI (VI48_AVX512VL if you really mean to exclude vectors of QI/HI, or a combination of this and VI12_AVX512VL otherwise).
[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94343 --- Comment #12 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #8) > Created attachment 48128 [details] > gcc10-pr94343.patch > > Updated patch. A variant to that would be 4 separate patterns I guess, not > sure if that would be shorter. May I suggest that the testcases also check for the 0x55 immediate? The potential of VPTERNLOG allows for much wider use (with different immediates) in principle, so the correct choice of immediate would imo better be validated here as well.
[Bug target/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94343
--- Comment #11 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #7)
> Though, there are other issues. There is only vpternlog{d,q}, so for
> V*[QH]Imode we shouldn't pretend we have masking support.
Why would this be? The element mode doesn't matter at all for bitwise
operations. Just like there's no VPANDB / VPANDW, but VPANDD/VPANDQ are quite
fine to use on vectors of QI or HI. Afaict the existence of VPAND{D,Q} in
AVX512 (as opposed to {,V}PAND in MMX/SSE2/AVX) is merely an oddity resulting
from EVEX.W handling (besides of course the element width's effect on embedded
broadcasting).
[Bug target/93526] x86-64: %c cannot be used in asm for "i" constraint operand and arbitrary constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93526 --- Comment #3 from jbeulich at suse dot com --- Let me quote documentation then: "Require a constant operand and print the constant expression with no punctuation." There's nothing said about valid value ranges or alike. To me as a user of the compiler it doesn't matter what CONSTANT_ADDRESS_P() actually means or does. Of course I'm not going to exclude that the documentation is wrong, and the code works as intended (less the signedness issue).
[Bug target/93526] x86-64: %c cannot be used in asm for "i" constraint operand and arbitrary constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93526 --- Comment #1 from jbeulich at suse dot com --- Bug 85344 may be related for the signedness aspect.
[Bug target/93526] New: x86-64: %c cannot be used in asm for "i" constraint operand and arbitrary constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93526
Bug ID: 93526
Summary: x86-64: %c cannot be used in asm for "i" constraint
operand and arbitrary constant value
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
In
//#define VAL 0x7fffUL // works
//#define VAL 0x8000 // works, but produces -0x8000L
#define VAL 0x8000U // works, but produces -0x8000L
//#define VAL -0x8000L // works
//#define VAL 0x8000L
//#define VAL 0x8000UL
//#define VAL 0x8000UL
unsigned long ul = VAL;
void test(void) {
asm ( ".equ C1, %c0; .global C1" :: "i" (VAL) );
asm ( ".equ C2, %c0; .global C2" :: "n" (VAL) );
// these all work
asm ( ".equ C3, -%n0; .global C3" :: "i" (VAL) );
asm ( ".equ C4, %p0; .global C4" :: "i" (VAL) );
asm ( ".equ C5, %P0; .global C5" :: "i" (VAL) );
}
play with the various values for VAL. The ones not marked "works" will produce
"operand is not a condition code" errors. But even among the ones that work
there looks to be a signedness issue with the produced constants in some cases.
(I realize the 'n' modifier is not documented. Perhaps it should be, or else
consider it here just for completeness.)
[Bug target/91710] [9/10 Regression] unexpected ABI change note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91710 --- Comment #4 from jbeulich at suse dot com --- (In reply to Andrew Pinski from comment #3) > @@ -4908,7 +4908,8 @@ aarch64_function_arg_boundary (machine_mode mode, > const_tree type) >bool abi_break; >unsigned int alignment = aarch64_function_arg_alignment (mode, type, >&abi_break); > - if (abi_break & warn_psabi) > + > + if (alignment >= STACK_BOUNDARY && abi_break & warn_psabi) > inform (input_location, "parameter passing for argument of type " > "%qT changed in GCC 9.1", type); Wouldn't this then want to be > PARM_BOUNDARY instead of >= STACK_BOUNDARY? In #1 you also say "But if it is equal to STACK_BOUNDARY ...", so perhaps even > PARM_BOUNDARY && <= STACK_BOUNDARY? I also find it a little odd for the adjustment not be to aarch64_function_arg_alignment()'s setting of abi_break, but I guess doing so would be incompatible with some of the other uses of the function. (Also I guess the opportunity should be taken to convert the slightly suspicious pre-existing & to &&.)
[Bug c/91710] New: unexpected ABI change note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91710
Bug ID: 91710
Summary: unexpected ABI change note
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Presumably as a result of the fix for bug 88469 on aarch64 there's now a
diagnostic apparently on any passing by value of a compound type using a
bitfield:
struct s {
unsigned int i:4;
};
unsigned int test1(struct s s) {
return s.i;
}
unsigned int test2(unsigned x, struct s s) {
return x - s.i;
}
unsigned int test3(unsigned x, unsigned y, struct s s) {
return x - y - s.i;
}
triggers three note diagnostics. Comparing the generated code there is (as
expected) no change at all from 8.x (same also when looking at the caller side
code).
I wonder whether this isn't simply because aarch64_function_arg_boundary()
guards its inform() invocation only by a condition not depending on the
function inputs.
For reference, the issue was originally noticed with p2m_mem_access_check() in
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/mem_access.c;h=3e3620294cbcee685f13c25a03f343f7d4422847;hb=refs/heads/staging
with struct npfec being declared in
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/xen/mm.h;h=8d0ddfb60cf4cd08bf907c1f0155049661e3370d;hb=refs/heads/staging
[Bug middle-end/91667] bogus -Wformat-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91667 --- Comment #2 from jbeulich at suse dot com --- (In reply to Martin Sebor from comment #1) > The warning is still in GCC 9 but has gone away in GCC 10.0 with r274837. While I trust you one this, ... > In bug 91490, comment #4 I said: I'm not sure this should be backported. It > suppresses bogus warnings but also introduces new warnings for invalid code." I'm struggling to see how said change affects the case here: There's no flexible array involved here, and also from other parts of the change I can't seem to be able to make a connection. Please forgive me asking, but I'd appreciate some explanation as to the connection. I'm in particular wondering whether it wouldn't be possible to backport a subset of the change, if there's worry about new warnings (personally I'd consider such fine when they only affect invalid code).
