: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Hi
This is just a suggestion for enhancement - would it be possible to support the
flags -ffixed, -fcall
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
struct s {
int a[1];
};
void assign(struct s *s1, struct s *s2)
{
*s1 = *s2;
}
compiling
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
If a function has the attribut
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
MIPS64R6 has new instructions for multiplication and division. GCC uses them,
however it miscompiles 128-bit multiplication.
When you compile and run
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Compile this piece of code on 64-bit Cygwin distribution with gcc 11.3.0 with
or without optimizations.
The result is:
during RTL pass
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
GCC uses the instructions fildq and fistpq to read and write atomic 8-byte
quantities.
According to Intel
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
This simple program takes 34 seconds to compile on 1GHz parisc machine.
#define GR_64 0x61C886f680B583EBULL
Assignee: ian at airs dot com
Reporter: mikulas at artax dot karlin.mff.cuni.cz
CC: cmang at google dot com
Target Milestone: ---
Compiling gcc on ARM64 with these options fails. It worked on gcc 9.
#!/bin/sh
set -e
MAKEFLAGS=-j4
export MAKEFLAGS
../gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90346
--- Comment #5 from mikulas at artax dot karlin.mff.cuni.cz ---
On non-SSE2 CPUs, it should generate "lock; addl $0,(%esp)" That provides
barrier equivalent to "mfence"
everity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build:
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Stores with memory_order_relaxed can be implemented as simple store
instructions. For the RISC-V target, gcc generates less efficient atomic
instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83638
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
>From performance point of view it doesn't matter if the lock is taken inside
the kernel or inside the gcc library.
If the userspace wants to optimize different code p
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
With -frounding-math, gcc should not do optimizations if the result is affected
by the rounding mode. But it still does some of them - it
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
See this simple function and compile it with -O2 on x86-64:
#include
#include
int cmp(double a, double b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
I can reproduce it with
gcc-4.8.4 on Ubuntu 14.04 on native armhf (it doesn't reproduce with gcc-4.9 on
the same machine)
arm-linux-gnueabi-gcc-6 cross-compiler on Debian Stretc
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Created attachment 43050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43050&action=edit
a reduced
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
The pa-risc architecture doesn't have atomic instructions, all atomic writes or
modifications require taking a lock. These locks are generated pro
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
The alpha architecture has instructions s4add, s8add, s4sub and s8sub. These
instructions shift the first argument left by 4 or 8 bits and add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83253
--- Comment #15 from mikulas at artax dot karlin.mff.cuni.cz ---
> Well, in theory multiplication by 3 isn't that expensive on i?86/x86_64,
> because lea can do that. But multiplication by 4 should be still cheaper or as
> cheap as,
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
The straight-line strength reduce optimization causes code size increase and
performance degradation in some cases. I reduced it to this simple function
-optimization, openmp
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81333
--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
> Only C11 and above. C99 and C98 does not have any requirements like that :)
Accessing any variable with the char pointer is allowed in C89 and newer
standards. Threading is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81333
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 41691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41691&action=edit
another testcase
Another testcase - note that even if we have two static varia
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Host: alpha-linux-gnu
Target: alpha-linux-gnu
Build: alpha-linux-gnu
Created attachment 41690
--> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80476
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
CC||mikulas at
onent: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
When compiling GCC 7 with -O3 (usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63264
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
Version|4.9.1 |6.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64543
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #5 from mikulas at artax dot karlin.mff.cuni.cz ---
And if you add a new type __float256 with 32-byte alignment - does it mean that
glibc suddenly starts being buggy, because it couldn't anticipate what types
with what alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
BTW. gcc thinks that with -m32, allocated memory is aligned to 4 bytes and with
-m64 and -mx32, allocated memory is aligned to 16 bytes. You can try to compile
this program into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Glibc doesn't support types __float128 and decimal float. Only GCC does.
Glibc can't be responsible for decisions made by the GCC developers. Glibc has
been aliging alloca
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72848
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
gcc/hwint.h always defines HOST_WIDE_INT as 64-bit value. How could it be
32-bit?
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Host: sparc64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888
--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
I think you should treat these artifical variables as private, not shared. If
you treated them as shared, threads would race with each other when accessing
them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
--- Comment #7 from mikulas at artax dot karlin.mff.cuni.cz ---
#include
atomic_int a = ATOMIC_VAR_INIT(0);
atomic_int b = ATOMIC_VAR_INIT(0);
atomic_int p = ATOMIC_VAR_INIT(0);
int thread_1(void)
{
atomic_store_explicit(&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
--- Comment #5 from mikulas at artax dot karlin.mff.cuni.cz ---
So, please pinpoint specific parahraph(s) in the standard that specify that
this behavior is acceptable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
The problem here is that we don't really know what does the standard specify.
People often suggest the Batty's paper Mathematizing C++ Concurrency (
http://www.cl.cam.ac
tizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Undefined behavior sanitizer and openmp don&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64545
--- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz ---
It is caused by profiledbootstrap, when I change it to boostrap, the build
succeeds.
Severity: major
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64544
--- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 34407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34407&action=edit
The failed build log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64544
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
Severity|normal |major
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64543
--- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 34406
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34406&action=edit
failed build log
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #11 from mikulas at artax dot karlin.mff.cuni.cz ---
Richard Biener: if the middle end tells us that one pointer is greater or equal
than the other pointer, we could do unsigned subtraction and shift.
But if we don't know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #9 from mikulas at artax dot karlin.mff.cuni.cz ---
> See what I wrote, any object size bigger than half of address space really
> isn't supportable, because then (char *) (P) - (char *) (Q) might not fit into
> ptrdif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #6 from mikulas at artax dot karlin.mff.cuni.cz ---
"you really can't have an object bigger than half of the address space in
C/C++" - where does the standard claim this? If this is true, we should change
malloc so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #4 from mikulas at artax dot karlin.mff.cuni.cz ---
... and another related problem (try this on 32-bit system):
#include
#include
int main(void)
{
short *a = malloc(0x5000 * sizeof(short));
short *b = a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Jakub Jelinek: I know, but the problem happened in perfectly valid program.
Suppose that you do:
char *p = malloc(0x2000); - the allocator allocates the array at
0x7000
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-linux-gnux32
Target: x86_64-linux-gnux32
Build: x86_64-linux-gnux32
The undefined behavior sanitizer
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-linux-gnux32
Target: x86_64-linux-gnux32
Build: x86_64-linux-gnux32
This piece of code:
void f
onent: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-linux-gnux32
Target: x86_64-linux-gnux32
Build: x86_64-linux-gnux32
When gcc is configured and compiled for x32 mode (x86_64-
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Created attachment
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60496
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
Host|x86_64-linux-gnu|x86_64-linux
minor
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-linux-gnux32
Target: x86_64-linux-gnux32
Build: x86_64-linux-gnux32
The f
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: arm-linux-gnueabihf
Target: arm-linux-gnueabihf
Build: arm-linux-gnueabihf
When compiling this piece of code with or without
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
The
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-pc-cygwin
Target: x86_64-pc-cygwin
Build: x86_64-pc-cygwin
Windows on x86-64 uses a different calling standard than Linux. On Windows x64
ABI
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Host: x86_64-unknown-linux-gnu
Target: i586-pc-msdosdjgpp
Build: x86_64-unknown-linux-gnu
Configure gcc-4.7.3 with these options:
../gcc-4.7.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 30362
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30362&action=edit
another reproduction code
The code in the first attachment actually did some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
CC||mikulas at artax
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Compile the attached code with -O3 -mcpu=cortex-a15 -marm on ARM EABI (the bug
happens with hardfp or without). The functions html_h3, html_h4, html_h5,
html_h6 clobber the register r5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55274
Bug #: 55274
Summary: gcc build hangs on HP-UX 11.11
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54848
Bug #: 54848
Summary: -ftrapv doesn't work when assigning to an integer with
smaller size
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54846
Bug #: 54846
Summary: -ftrapv doesn't work in 64-bit mode
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54737
Bug #: 54737
Summary: ICE on PA-RISC with LTO and -ftrapv
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54705
--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz 2012-09-26 23:16:04
UTC ---
Created attachment 28289
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28289
a full log of failed compiletion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54705
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz 2012-09-26 23:12:18
UTC ---
My script doesn't have -g, but it is somehow added by gcc build scripts. I can
see lines like this that have -g.
/usr/src/gcc-4.7.2-build-5.1/.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54705
Bug #: 54705
Summary: Building gcc with ADA and LTO results in an internal
error
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54454
--- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz 2012-09-02 01:52:54
UTC ---
Another specification violation:
section 6.7.2.1 paragraph 20 says that assignment of a structure with flexible
array member doesn't copy any of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54454
Bug #: 54454
Summary: gcc violates c99 specification w.r.t. flexible arrays
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52778
--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz 2012-03-29 18:46:17
UTC ---
BTW. I found that there is another bug #52776 with -flto crash at the same
place.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52778
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz 2012-03-29 18:29:34
UTC ---
Created attachment 27038
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27038
gdb session analyzing the core file
This is the gdb session analyzing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52778
--- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz 2012-03-29 18:25:43
UTC ---
I couldn't attach the file, so I placed in on
http://jikos.cz/~mikulas/gcc-crash-files.tar.bz2 . Download the archive, change
CC in the Makefile to poi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52778
Bug #: 52778
Summary: gcc crashes with -flto on PA-RISC
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51814
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz 2012-01-10 19:23:31
UTC ---
After further testing it turns out that "make install -j8" produces the invalid
Ada installation and "make install" produces a working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51745
--- Comment #4 from mikulas at artax dot karlin.mff.cuni.cz 2012-01-10 18:59:06
UTC ---
If you input garbage into a compiler, it should report an error, not output
garbage.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51814
Bug #: 51814
Summary: only 32-bit ada library is built on 64-bit system
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51745
Bug #: 51745
Summary: Strange symbol appears when using commandline
definition without "="
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51300
Bug #: 51300
Summary: Internal error when using -flto with -O0 in the linker
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49904
Summary: Internal error with multiplication and -msoft-float
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedT
85 matches
Mail list logo
