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
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=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 array
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:
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/./prev
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=54737
Bug #: 54737
Summary: ICE on PA-RISC with LTO and -ftrapv
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
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
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:
: 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=57708
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
CC||mikulas at artax
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=30362action=edit
another reproduction code
The code in the first attachment actually did some out
: 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
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
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
: 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
: 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-linux
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
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
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
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 stdio.h
#include stdlib.h
int main(void)
{
short *a = malloc(0x5000 * sizeof(short
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 that it doesn't
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
ptrdiff_t
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 which
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
: 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-linux-gnux32
Target: x86_64-linux-gnux32
Build: x86_64-linux-gnux32
The ffreep
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
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=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=51745
Bug #: 51745
Summary: Strange symbol appears when using commandline
definition without =
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
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
--- 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
--- 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 installation.
If I install
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
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=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 point
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 #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.
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't work
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=64543
--- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 34406
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34406action=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
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=64544
--- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 34407
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34407action=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
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 #7 from mikulas at artax dot karlin.mff.cuni.cz ---
#include stdatomic.h
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(b
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.uk/~pes20
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.
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=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?
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
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=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 #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 allocated memory
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80476
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
CC||mikulas
: 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 (using
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. Thread
: 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=81333
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 41691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41691=edit
another testcase
Another testcase - note that even if we have two static variables in
-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=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, beca
-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
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
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 properly
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=edit
a reduced testcase f
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 Stretch
arm
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
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
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 pa
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
ty: 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: x86_6
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"
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
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
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
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
sion: 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 attribute __a
83 matches
Mail list logo
