[Bug plugins/56754] some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 --- Comment #6 from PaX Team pageexec at freemail dot hu --- (In reply to Duncan Sands from comment #5) Was there any feedback on this patch? sadly, no response so far (this bug is still UNCONFIRMED even), so it's probably not going to make 4.8.1.
[Bug plugins/56795] New: gimple_seq_alloc and gimple_seq_free are still present in gcc-4.8's gimple.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56795 Bug #: 56795 Summary: gimple_seq_alloc and gimple_seq_free are still present in gcc-4.8's gimple.h Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassig...@gcc.gnu.org ReportedBy: pagee...@freemail.hu it seems that svn commmit 187053 removed gimple_seq_alloc and gimple_seq_free but left their declarations in gimple.h. this makes plugins using these functions compile but not load since the actual definitions are no longer present in the gcc binaries.
[Bug plugins/56754] New: some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 Bug #: 56754 Summary: some missing plugin headers during installation in gcc 4.8 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassig...@gcc.gnu.org ReportedBy: pagee...@freemail.hu it used to be the case before 4.8 that the following files were made available to plugins: target.h target.def target-hooks-macros.h now it seems that at least for a x86_64-pc-linux-gnu target they no longer get installed. i tried to find the related commit but came up empty so i'm wondering if this is the result of an oversight or some policy change? manually installing these files gets things back to normal, but it'd be nice to know what to expect in the future or if it's a bug, fix it for 4.8.1 ;).
[Bug middle-end/56288] New: always true conditional expression in verify_ssa_name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56288 Bug #: 56288 Summary: always true conditional expression in verify_ssa_name Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: pagee...@freemail.hu git commit ec11736b57986660deef21d6375d2f23edf290d2 introduced SSA_NAME_IDENTIFIER in addition to SSA_NAME_VAR where the latter can now return NULL_TREE. so far so good, all users have been adjusted for this new condition except there is i think a mistake in gcc/tree-ssa.c:verify_ssa_name that had this change: - if (TREE_TYPE (ssa_name) != TREE_TYPE (SSA_NAME_VAR (ssa_name))) + if (SSA_NAME_VAR (ssa_name) != NULL_TREE + TREE_TYPE (ssa_name) != TREE_TYPE (ssa_name)) i think the intention was more like preserving the original check for TREE_TYPE (ssa_name) != TREE_TYPE (SSA_NAME_VAR (ssa_name)) instead.
[Bug plugins/41757] Add PLUGIN_FINISH_DECL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757 pageexec at freemail dot hu changed: What|Removed |Added CC||pageexec at freemail dot hu --- Comment #5 from pageexec at freemail dot hu 2012-05-22 11:49:47 UTC --- this feature seems to have been implemented already in gcc 4.7.x, can it be backported to 4.5.x and 4.6.x perhaps? it would make life easier for plugin writers who would like to provide the same features for all the plugin capable gcc series.
[Bug middle-end/51071] [4.7 Regression] ICE in gimple_has_side_effects, at gimple.c:2513
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51071
--- Comment #6 from pageexec at freemail dot hu 2012-05-21 11:41:10 UTC ---
Created attachment 27458
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27458
test case for gcc 4.6.x
this is a compressed test case (would be too big to attach otherwise i think).
compile with:
gcc -c netdev.i -o netdev.o -O2 -fno-delete-null-pointer-checks
(the -fno-delete-null-pointer-checks switch is important). you'll also need a
debug build of gcc (i had
--enable-checking=assert,misc,rtl,rtlflag,runtime,tree here) and the error i
get is:
drivers/staging/sbe-2t3e3/netdev.c: In function 't3e3_open':
drivers/staging/sbe-2t3e3/netdev.c:85:5: internal compiler error: in
gimple_has_side_effects, at gimple.c:2329
with the code around gimple.c:2329 being:
2324 for (i = 0; i gimple_num_ops (s); i++)
2325 »···{
2326 »··· tree op = gimple_op (s, i);
2327 »··· if (op TREE_SIDE_EFFECTS (op))
2328 »···{
2329 »··· gcc_checking_assert (gimple_has_volatile_ops (s));
2330 »··· return true;
2331 »···}
2332 »···}
[Bug middle-end/51071] [4.7 Regression] ICE in gimple_has_side_effects, at gimple.c:2513
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51071 pageexec at freemail dot hu changed: What|Removed |Added CC||pageexec at freemail dot hu --- Comment #4 from pageexec at freemail dot hu 2012-05-18 15:02:57 UTC --- this bug affects the 4.6 branch as well (e.g., on linux-3.3.6/drivers/staging/sbe-2t3e3/netdev.c), so it should be backported there too if possible.
[Bug c/46354] New: attribute((aligned(...))) can incorrectly decrease structure field alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46354 Summary: attribute((aligned(...))) can incorrectly decrease structure field alignment Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: pagee...@freemail.hu while investigating a clang error when compiling the linux kernel i narrowed the problem down to what seems to be a gcc bug. what happens is that despite what the gcc documentation says about the aligned attribute, gcc does decrease structure field alignment even when the packed attribute is not specified. the attached example shows that the issue is only with the attribute attached to a typedef. the relevant part of the generated asm looks like this for gcc: movqxx+8(%rip), %rax addqx+4(%rip), %rax bug, should be +8 addqp+2(%rip), %rax should it be +4? addqpp+4(%rip), %rax and for clang: movqxx+8(%rip), %rax addqx+8(%rip), %rax addqp+2(%rip), %rax addqpp+4(%rip), %rax the tested gcc versions so far: gcc version 4.4.5 (Gentoo 4.4.5 p1.0, pie-0.4.5) gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) note that fixing this bug will have a non-trivial effect on linux as this construct is relied upon throughout the compat layer (that implements transforming syscall parameters between 32 bit userland and the 64 bit kernel) so when gcc stops decreasing the natural alignment of these structure fields, all such code will have to be changed to explicitly use the packed attribute lest the kernel/userland syscall ABI break... only to run into the next issue in that the packed attribute on the structure ignores the aligned attribute in the typedef (see the +2 above), both in gcc and clang (given both compilers are affected, i'm not sure if this is a bug or feature). more interestingly, if the aligned attribute is on the structure field itself then it is properly taken into account, both in gcc and clang. so this looks like a fine mess to clean up if/when the root bug gets fixed.
[Bug c/46354] attribute((aligned(...))) can incorrectly decrease structure field alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46354 --- Comment #1 from pageexec at freemail dot hu 2010-11-07 22:43:33 UTC --- Created attachment 22314 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22314 sample code to demonstrate structure field offsets
[Bug c/46354] attribute((aligned(...))) can incorrectly decrease structure field alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46354 --- Comment #3 from pageexec at freemail dot hu 2010-11-07 23:33:54 UTC --- (In reply to comment #2) Generally GCC lays out structures based on the types of the elemets, not based on the alignment specified on fields. according to the gcc docs, explicit alignment on structure fields *is* taken into account in that one can *increase* the natural alignment associated with a given type: The `aligned' attribute can only increase the alignment; but you can decrease it by specifying `packed' as well. See below. in this bug you can see that even without the packed attribute gcc can decrease the alignment. so either the docs or the implementation is buggy ;). the second issue is that when one does use the packed attribute on a structure, the resulting field alignment seems inconsistent depending on where the aligned attribute is (typedef vs. structure field). i don't see where the docs specify or imply this behaviour.
