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
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
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
---
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
---
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
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
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
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
---
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?
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
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
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
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
---
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
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
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
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
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++
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
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
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
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
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.
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
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
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
>
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
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
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.
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
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:
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
---
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
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
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:
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
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
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
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:
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
>c
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33437
jbeulich at suse dot com changed:
What|Removed |Added
Status|RESOLVED|NEW
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
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
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
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
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
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
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
49 matches
Mail list logo
