Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
Created attachment 46829
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46829=edit
testcase
The attached example causes undue warnings - arrays of chars without nul
terminator ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88541
--- Comment #5 from jbeulich at novell dot com ---
So why -mavx instead of -mavx2? I think the way it was done for GFNI and SSE2
it should also be done there, here and for VAES wrt AVX: Only SSE2 provides
support for vectors of ints. Similarly
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
As per the specification, and just like is the case for VAES, it should be
usable with just AVX
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
Without them there's no way to invoke the SAE forms of VREDUCE{P,S}{D,S}.
See
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=reduce=AVX_512.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
Other than for the scalar float to/from integer conversion insns, the scalar
float <-> float ones allow a mask to be applied
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
The same issue had been present in gas, but was corrected by commit 6e041cf4b0:
YMM (and of course
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
This piece of code
#define x y
#pragma GCC target("avx512f")
#ifndef __AVX512F__
# define x z
#endif
wrongly triggers 'w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86079
--- Comment #8 from jbeulich at novell dot com ---
(In reply to Andreas Schwab from comment #6)
> In C mode, with line numbers, the newlines are required to preserve the line
> number of the tokens.
I don't think preserving line numbers i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86079
--- Comment #7 from jbeulich at novell dot com ---
(In reply to Andreas Schwab from comment #5)
> It's not plain C since the stray backslashes are invalid.
As said - try with the stray ones removed, i.e.
unsigned \
int \
u \
;
This _is_ va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86079
--- Comment #4 from jbeulich at novell dot com ---
(In reply to Andreas Schwab from comment #3)
> Did you use -xassembler-with-cpp? Without that it's INVALID.
No, I did not, and the example given also is plain C code (minus the too m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86079
--- Comment #1 from jbeulich at novell dot com ---
Interesting - with -P the problem goes away.
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
While gcc 4.3 looks to still handle this correctly, at least all versions from
4.7 onwards (I don't have the intermediate versions readily available to check)
fail to splice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78503
jbeulich at novell dot com changed:
What|Removed |Added
CC||jbeulich at novell dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79678
--- Comment #2 from jbeulich at novell dot com ---
(In reply to Richard Biener from comment #1)
> Just as a note you should always use intrinsics, not builtins.
Well, I probably would have, if there wasn't ...
> OTOH they return the g
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
At least builtins clearly acting on and/or returning packed unsigned data
should have parameter/return types derived from unsigned ones. Beside requiring
needless casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68095
jbeulich at novell dot com changed:
What|Removed |Added
CC||jbeulich at novell dot com
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Created attachment 33800
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33800action=edit
example
The attached example, derived after seeing x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #9 from jbeulich at novell dot com ---
But that's the point - the compiler takes the liberty to treat start != end
as always true, and start end as being replaceable with start = end.
Hence a respective for() loop could in the first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #5 from jbeulich at novell dot com ---
How that? How is code supposed to find out then?
Perhaps briefly explaining where this is coming from originally might help: The
Xen hypervisor (as much as Linux) has a number of linker script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #7 from jbeulich at novell dot com ---
That's why I gave the example of where this is coming from - the code obviously
wants to be able to determine whether the data block between the two labels is
empty. And no, using asm()-s
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Created attachment 30369
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30369action=edit
shared header
Both the Arrays of Length Zero and the Structures With No Members
extensions conflict with __attribute__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #1 from jbeulich at novell dot com ---
Created attachment 30370
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30370action=edit
main source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #2 from jbeulich at novell dot com ---
Created attachment 30371
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30371action=edit
auxiliary source (initialized data)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #3 from jbeulich at novell dot com ---
Created attachment 30372
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30372action=edit
auxiliary source (uninitialized data)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53425
jbeulich at novell dot com changed:
What|Removed |Added
CC||jbeulich at novell dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40825
jbeulich at novell dot com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
Known to work
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64
at novell dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40825
--- Comment #1 from jbeulich at novell dot com 2009-07-22 14:06 ---
Created an attachment (id=18238)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18238action=view)
example source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40825
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
--- Comment #4 from jbeulich at novell dot com 2009-07-22 14:17 ---
Just as the warning says - construction of 'd' is missing. The warning lead me
to look at the generated code, just to see that they are in sync (and hence
perhaps have the same root cause).
--
http://gcc.gnu.org
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35954
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet
not be assumed to be a pointer
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
GCC build triplet
--- Comment #3 from jbeulich at novell dot com 2007-09-19 09:39 ---
Isn't this the same as 16602 (which I don't really understand why it was
rejected as invalid)? Also, if this *is* invalid, then what proper mechanism
does one have to express what is intended here? And why does similar
: potentially valid construct rejected
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
GCC build triplet
--- Comment #41 from jbeulich at novell dot com 2006-12-07 08:15 ---
That's not a good idea, I think. The semantics of how to treat undefined
symbols in the symbol table that arten't used in any relocations depend on the
OS ABI, not the ELF file format. Non-gld linkers may interpret
--- Additional Comments From jbeulich at novell dot com 2005-03-31 06:44
---
Correct.
--
What|Removed |Added
Status|WAITING |RESOLVED
--- Additional Comments From jbeulich at novell dot com 2005-01-17 08:06
---
No, it was with my attempt to fix this. As I further thought about it, maybe the
whole difference was that I didn't do the TImode conversion prior to the
spill...
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From jbeulich at novell dot com 2005-01-14 08:58
---
Isn't the MEM case moving things in the wrong direction? If so, and since I
tried to fix this myself before submitting the bug, simply swapping the operands
of emit_move_insn doesn't seem to work (made
register
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
CC: gcc-bugs
--
What|Removed |Added
Known to fail||3.3.3 3.4.3 4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19357
--- Additional Comments From jbeulich at novell dot com 2005-01-07 10:21
---
Since the change originally having introduced this problem was also applied to
3_4-branch, will this here be applied there, too?
--
What|Removed |Added
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-*
http
--- Additional Comments From jbeulich at novell dot com 2005-01-03 12:47
---
I'm sorry, test case below. The expectation would be that the visibility
attribute gets inherited (as described above) from function template instances
and member functions of class template instances
section
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
CC
--- Additional Comments From jbeulich at novell dot com 2004-12-23 15:18
---
Hmm, it's not as severe as I first thought. The references use ltoff22x
relocations, so they are safe. It is just inefficient to have these data items
not live in short data.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From jbeulich at novell dot com 2004-12-17 14:28
---
Now that I have an Itanium2 system to test with, I can confirm that the problem
still exists in 3.4.3, and looking at the delta to 4.0.0's ia64.md there is no
reason to believe the problem would have been fixed
--- Additional Comments From jbeulich at novell dot com 2004-12-16 12:59
---
This happens when the ABI is (was) imprecise. Earlier versions did not special
case long double complex, but the current version does. Hence I have a patch
ready that partly reverses the original change
--- Additional Comments From jbeulich at novell dot com 2004-12-16 15:46
---
Patch for the x86-64 long double complex part submitted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17603
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
CC: gcc-bugs at gcc dot gnu dot
52 matches
Mail list logo
