Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
I've found a problem on glibc-2.25 where glibc crashes at startup.
Minimal reproducer does not crash the progra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81996
--- Comment #1 from Sergei Trofimovich ---
Compiler version:
Target: powerpc-unknown-linux-gnu
Configured with: /dev/shm/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/configure
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81996
--- Comment #2 from Sergei Trofimovich ---
gcc master is slightly better here but is still inefficient in fPIC mode:
gcc -O2 -fno-PIC:
f:
mflr 3
blr
gcc -O2 -fPIC:
f:
stwu 1,-16(1)
mflr 0
stw 0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81996
--- Comment #3 from Sergei Trofimovich ---
Built vanilla gcc from head to make sure it's not local patches.
-fstack-protector-all is the trigger breaking return address:
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc/configure --p
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
The crash is extracted from ceph-10.2.9.
[1] is the minimal reproducer (a bit big as I did not clean it after
'creduce'):
Crashes o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82155
--- Comment #1 from Sergei Trofimovich ---
Created attachment 42143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42143&action=edit
ECBackend.ii
Attaching original reproducer as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 42492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42492&action=edit
_png.ii
Original build failure was fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82759
Sergei Trofimovich changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Commen
++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 42588
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42588&action=edit
gcc-bug.ii
Originally reported in https://bugs.gentoo.org/636646
Minimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82953
--- Comment #1 from Sergei Trofimovich ---
gdb backtrace:
(gdb) bt
#0 any_dependent_bases_p (type=type@entry=0x7003f7e0) at
../../gcc/gcc/cp/search.c:2617
#1 0x0083ee53 in finish_class_member_access_expr (object=...,
name=, name@en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78553
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60551
--- Comment #1 from Sergei Trofimovich ---
Clarification: 'a.cc' should be named as 'a.hh' as it's a header included in
many other .cc files.
interersting asm volatiles
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: slyfox at inbox dot ru
GCC build triplet: powerpc64-un
--- Comment #1 from slyfox at inbox dot ru 2010-03-21 20:09 ---
Created an attachment (id=20153)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20153&action=view)
ghc30321_0.i - preprocessed offending file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43470
--- Comment #2 from slyfox at inbox dot ru 2010-03-21 20:11 ---
Created an attachment (id=20154)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20154&action=view)
valgrind.log - sheds some light on SIGSEGV reason
...
==10526== Invalid write of size 8
==10526==at 0x1
--- Comment #5 from slyfox at inbox dot ru 2010-03-22 09:50 ---
Yes, i can confirm gcc-trunk does not fail on this file. What prevents this fix
to be merged to 4.4. branch?
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43470
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Created attachment 32182
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32182&action=edit
ghc14232_3.hc.i.bz2 - compressed source file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60291
--- Comment #1 from Sergei Trofimovich ---
For -ftime-report -O1 most highlighting lines are:
phase opt and generate : 175.81 (98%) usr 4.61 (51%) sys 180.95 (95%) wall
1833542 kB (86%) ggc
expand : 20.05 (11%) usr 0.71 (
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
// a.cc:
// I plan to implement it in only one .cc module
// and not this one, thus I don't need external visibility.
static void fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #30 from Sergei Trofimovich ---
Aha, got it.
I've factored out GNU_HASH section setup crash into separate
very simple function:
void __attribute__ ((unused, noinline))
do_it_again (struct link_map *l, ElfW(Dyn) *dyn)
{
Elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #32 from Sergei Trofimovich ---
(In reply to Andreas Schwab from comment #31)
> @ltoffx on symbol+addend doesn't make any sense. This computes an offset
> into the GOT, so any addend needs to be added _after_ loading the actual
> sym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #33 from Sergei Trofimovich ---
Sent glibc workaround for review as:
https://sourceware.org/ml/libc-alpha/2015-12/msg00556.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #34 from Sergei Trofimovich ---
Wrote more details on how exactly things were broken:
http://trofi.github.io/posts/189-glibc-on-ia64-or-how-relocations-bootstrap.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #35 from Sergei Trofimovich ---
Created attachment 37180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37180&action=edit
0001-ia64-don-t-use-dynamic-relocations-for-local-symbols.patch
0001-ia64-don-t-use-dynamic-relocations-f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #36 from Sergei Trofimovich ---
Tested the patch on top of gcc-5.3.0 / glibc-2.22-r1.
Relocation in rtld.os is R_IA64_GPREL64I and is just an immediate offset in
ld.so:
# objdump -r -d elf/rtld.os | grep -C4 rtld_local+0x38
97c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #37 from Sergei Trofimovich ---
The patch also fixes this old bug:
https://bugzilla.redhat.com/show_bug.cgi?id=33354
Despite being marked as fixed it fails on modern toolchain with slight
overflow.
Address of local constant was d
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Created attachment 37298
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37298&action=edit
sample with broken ABI
This came up as a miscompilation of GHC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69221
--- Comment #2 from Sergei Trofimovich ---
(In reply to Andreas Schwab from comment #1)
> The declaration of f isn't compatible with its defintion. A cast doesn't
> change that fact.
Correct. But is it relevant here? Cast is the only real thing
erity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Target: x86_64-pc-linux-gnu
Was originally found in GHC:
https://ghc.haskell.org/trac/ghc/ticket/10986#comment:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69351
--- Comment #2 from Sergei Trofimovich ---
My failing versions are:
$ LANG=C gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper
Target: x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69351
--- Comment #3 from Sergei Trofimovich ---
Built gcc from master (binutils 2.25.1). Error does not happen there:
Using built-in specs.
COLLECT_GCC=bin/gcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick-installed/bin/../libexec/gcc/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69351
--- Comment #4 from Sergei Trofimovich ---
One more data point: gcc-5-branch still has the bug:
LANG=C bin/gcc -v
Using built-in specs.
COLLECT_GCC=bin/gcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick-installed/bin/../libexec/gcc/x8
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: slyfox at inbox dot ru
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42506
--- Comment #2 from slyfox at inbox dot ru 2009-12-26 15:34 ---
(In reply to comment #1)
> It is not useless, the reason you in some cases want to keep out of line
> copies
> of inline functions is e.g. debugging, if there is no out of line copy of a
> function, you can&#x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46075
Summary: g++ wrongly lookups builtin types in ADL (compiles
wrong code)
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46075
--- Comment #1 from Sergei Trofimovich 2010-10-18
20:23:10 UTC ---
Created attachment 22084
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22084
test example. compilation should fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46075
--- Comment #4 from Sergei Trofimovich 2010-10-18
20:43:24 UTC ---
(In reply to comment #2)
> Actually there is an open question if clang or gcc is correct according to the
> C++ standards committee. There is a defect report about foundational t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85621
Sergei Trofimovich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
201 - 241 of 241 matches
Mail list logo
