[Bug c++/41533] New: ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
This macro chooses the encoding of pointers embedded in the exception handling sections. It needed to generate correct .cfi_personality derective. Without it we always have TEXTREL in C++ shared libraries and PIE, if it compiled with exceptions. -- Summary: ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kirill at shutemov dot name GCC build triplet: arm-none-linux-gnueabi GCC host triplet: arm-none-linux-gnueabi GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
--- Comment #1 from kirill at shutemov dot name 2009-10-01 08:02 --- Created an attachment (id=18686) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18686&action=view) Implement ASM_PREFERRED_EH_DATA_FORMAT macros for ARM This macro chooses the encoding of pointers embedded in the exception handling sections. It needed to generate correct .cfi_personality derective. Without it we always have TEXTREL in C++ shared libraries and PIE, if it compiled with exceptions. Signed-off-by: Kirill A. Shutemov -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
--- Comment #5 from kirill at shutemov dot name 2009-10-01 10:07 --- Ok. If .eh_frame should not be generated on ARM, we should to modify dwarf2out_do_cfi_asm() to always return false on ARM. Right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
--- Comment #7 from kirill at shutemov dot name 2009-10-01 11:08 --- Looks ok for me. I'll test it, but it takes some time. I'll report results tomorrow. This patch also fixes #40521, I guess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
--- Comment #8 from kirill at shutemov dot name 2009-10-02 07:34 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Ok. If .eh_frame should not be generated on ARM, we should to modify
> > dwarf2out_do_cfi_asm() to always return false on ARM. Right?
> >
>
> Look at this patch submitted here. Can you try this to see if it works for you
> ? http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00022.html
>
No, it doesn't help.
$ cat 1.cc
void m(){}
$ gcc-4.4 -S 1.cc
$ cat 1.s
.cpu arm9tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 6
.eabi_attribute 18, 4
.file "1.cc"
.text
.align 2
.global _Z1mv
.type _Z1mv, %function
_Z1mv:
.fnstart
.LFB0:
.cfi_startproc
.cfi_personality 0x0,__gxx_personality_v0
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
str fp, [sp, #-4]!
.cfi_def_cfa_offset 4
add fp, sp, #0
.cfi_offset 11, -4
.cfi_def_cfa_register 11
add sp, fp, #0
ldmfd sp!, {fp}
bx lr
.cfi_endproc
.LFE0:
.cantunwind
.fnend
.size _Z1mv, .-_Z1mv
.ident "GCC: (GNU) 4.4.1 20090725 (ALT Linux 4.4.1-alt1)"
.section.note.GNU-stack,"",%progbits
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
--- Comment #10 from kirill at shutemov dot name 2009-10-02 09:06 --- (In reply to comment #9) > (In reply to comment #8) > > Are you testing the correct compiler ? Yes. > After building my 4.4 tree (though a > cross compiler ) I see the code generated as below. > > The only reason why this might not work is if you are trying to build an > arm-linux and not an arm-linux-gnueabi toolchain but your bug report indicates > otherwise. $ gcc-4.4 -dumpmachine arm-alt-linux-gnueabi > As you can see there are no .cfi_* directives. Do you use c++ compiler with enabled exception handling? Do you have TEXTRELs in libstdc++ from this compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
--- Comment #12 from kirill at shutemov dot name 2009-10-05 19:34 --- Yes, it works. Thanks. -- kirill at shutemov dot name changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41533
[Bug c/41797] New: Segmentation fault on compiling using pre-compiled headers
Testcase attached. $ cd testcase $ make mkdir test.gch gcc -x c-header -c test.h -o test.gch/c gcc -c -include test test.c arm-alt-linux-gnueabi-gcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See <http://bugzilla.altlinux.org> for instructions. make: *** [test.o] Error 1 $ arm-alt-linux-gnueabi-gcc -v Using built-in specs. Target: arm-alt-linux-gnueabi Configured with: ../configure --host=arm-alt-linux-gnueabi --build=arm-alt-linux-gnueabi --target=arm-alt-linux-gnueabi --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --program-suffix=-4.4 --with-slibdir=/lib --with-bugurl=http://bugzilla.altlinux.org --enable-bootstrap --enable-shared --enable-__cxa_atexit --enable-threads=posix --enable-checking=release --with-system-zlib --without-included-gettext --enable-multilib --enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions Thread model: posix gcc version 4.4.2 20091018 (ALT Linux 4.4.2-alt1) (GCC) -- Summary: Segmentation fault on compiling using pre-compiled headers Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kirill at shutemov dot name GCC build triplet: arm-alt-linux-gnueabi GCC host triplet: arm-alt-linux-gnueabi GCC target triplet: arm-alt-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41797
[Bug c/41797] Segmentation fault on compiling using pre-compiled headers
--- Comment #1 from kirill at shutemov dot name 2009-10-22 15:13 --- Created an attachment (id=18866) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18866&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41797
[Bug c/41797] Segmentation fault on compiling using pre-compiled headers
--- Comment #3 from kirill at shutemov dot name 2009-10-22 16:34 --- (In reply to comment #2) > Works with 4.3 and 4.5 > Did you reproduce it on 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41797
[Bug target/41684] [4.4/4.5 regression] binutils testsuite failures when built with 4.4/4.5
--- Comment #12 from kirill at shutemov dot name 2009-10-26 11:06 --- (In reply to comment #11) > Did it fix your binutils testsuite failures ? Yes, it did. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41684
[Bug c/50171] New: False positive -Wuninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50171
Bug #: 50171
Summary: False positive -Wuninitialized warning
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kir...@shutemov.name
Created attachment 25085
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25085
test case
$ cat test.i
int baz(char **, const char *);
int quux(char *);
static int bar(char **out, const char *in)
{
char *t;
if (!baz(&t, in))
return -1;
*out = t;
return 0;
}
int foo(const char *a)
{
char *b;
if (!bar(&b, a))
return -1;
return quux(b);
}
$ gcc -c -O -Wuninitialized test.i
test.i: In function ‘foo’:
test.i:23:9: warning: ‘b’ may be used uninitialized in this function
[-Wuninitialized]
[Bug c/50171] False positive -Wuninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50171
--- Comment #3 from Kirill A. Shutemov 2011-08-24
10:57:30 UTC ---
Sorry, I've made mistake trying to simplify the test case.
Is it still correct to generate warning for the code below?
int error(void);
int baz(char **, const char *);
int quux(char *);
static int bar(char **out, const char *in)
{
char *t;
int err;
err = baz(&t, in);
if (err < 0)
return error();
*out = t;
return 0;
}
int foo(const char *a)
{
int err;
char *b;
err = bar(&b, a);
if (err < 0)
return error();
return quux(b);
}
[Bug c/50486] New: No warning at signed -> unsigned casting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50486
Bug #: 50486
Summary: No warning at signed -> unsigned casting
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kir...@shutemov.name
$ cat 1.c
enum e {
A,
B,
C
};
int a(enum e e)
{
if (e < 0)
return 1;
return 0;
}
int b(void)
{
return a(-1);
}
Since enum e has only positive values GCC states that enum is unsigned and
eliminates the if-check. I can see warning about it with -Wtype-limits.
But GCC generates no warning at a(-1), so it silently casts -1 to unsigned.
[Bug preprocessor/51303] New: -Wmissing-include-dirs warnings reported as [enabled by default]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51303 Bug #: 51303 Summary: -Wmissing-include-dirs warnings reported as [enabled by default] Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: kir...@shutemov.name $ cpp -I/some/dir < /dev/null > /dev/null $ cpp -I/some/dir -Wmissing-include-dirs < /dev/null > /dev/null cc1: warning: /some/dir: No such file or directory [enabled by default]
[Bug c/60937] New: -Os -fprofile-arcs breaks __attribute__((error()))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60937 Bug ID: 60937 Summary: -Os -fprofile-arcs breaks __attribute__((error())) Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kirill at shutemov dot name Created attachment 32660 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32660&action=edit Reduced test case Use of -Os and -fprofile-arcs break __attribute__((error())) behavior on attached test case. It false-positively triggers compile time error: $ gcc -Wall -Os -fprofile-arcs -c -o mm/.tmp_gup.o gup.i gup.i: In function ‘__get_user_pages’: gup.i:29:44: error: call to ‘__compiletime_assert’ declared with attribute error: BUILD_BUG failed __compiletime_assert(); Switching to other optimization level (above 0) or remove -fprofile-arcs does not lead to that: $ gcc -Wall -O1 -fprofile-arcs -c -o mm/.tmp_gup.o gup.i $ gcc -Wall -Os -c -o mm/.tmp_gup.o gup.i
[Bug debug/45447] ICE with `-g -femit-struct-debug-baseonly'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45447 Kirill A. Shutemov changed: What|Removed |Added CC||kirill at shutemov dot name --- Comment #4 from Kirill A. Shutemov 2010-11-04 20:11:35 UTC --- Any plans for branches?
[Bug c++/46364] New: basic_string.h:541:32: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46364
Summary: basic_string.h:541:32: internal compiler error:
Segmentation fault
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kir...@shutemov.name
Created attachment 22322
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22322
preprocessed source
$ cat test.cc
#include
void a() throw (int);
void b(std::string const &);
void c(std::string *e)
{
b("");
try {
a();
} catch (...) {
*e = "";
}
}
void d() {
c(0);
}
$ g++ -c -O3 test.cc
In file included from
/usr/lib/gcc/i586-alt-linux/4.5.1/../../../../include/c++/4.5.1/string:53:0,
from test.cc:1:
/usr/lib/gcc/i586-alt-linux/4.5.1/../../../../include/c++/4.5.1/bits/basic_string.h:
In function ‘void c(std::string*)’:
/usr/lib/gcc/i586-alt-linux/4.5.1/../../../../include/c++/4.5.1/bits/basic_string.h:541:32:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/.private/kas/cc9BCz1h.out file, please
attach this to your bugreport.
