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 wo
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, n
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
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
: 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
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'
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
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 i
NCONFIRMED
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
#
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.
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 a
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
: 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 in
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 suc
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
ty: 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 "
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.
Perha
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
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 e
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
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
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
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 #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
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
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
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
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) w
-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
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
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=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.
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 semant
ormal
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 oper
: 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
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 ele
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 us
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
: 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.
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=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=33437
jbeulich at suse dot com changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution
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
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
t
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
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=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
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
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 k
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 f
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
++
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
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
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 P
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:
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
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=100711
jbeulich at suse dot com changed:
What|Removed |Added
CC||jbeulich at suse dot com
y: 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 w
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 sufficien
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
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
>
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
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
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 possi
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
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Created attachment 59477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59477&action=edit
respectively adjusted example
As requested there, cloning from bug 1173
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Created attachment 59476
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59476&action=edit
example code
There are two issues.
First, the attached example causes an
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
At the example of __stack_chk_guard, accesses to which result from
-fstack-protector -mstack-protector-guard=global, there is a problem for
special purpose environments like the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32434
jbeulich at suse dot com changed:
What|Removed |Added
CC||jbeulich at suse dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118473
--- Comment #4 from jbeulich at suse dot com ---
(In reply to Andrew Pinski from comment #1)
> Does this happen only for x86_64 or also for aarch64?
As per a quick experiment - yes, same issue there. Not surprising considering
that both targ
71 matches
Mail list logo
