[Bug middle-end/29215] New: Unnecessary use of stack space
The attached file and the output of gcc -O2 -S illustrate the problem. The inlining of logarg seems to have resulted in a second buffer, which is only ever written to. -- Summary: Unnecessary use of stack space Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joerg at netbsd dot org GCC host triplet: i386--netbsdelf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
[Bug middle-end/29215] Unnecessary use of stack space
--- Comment #1 from joerg at netbsd dot org 2006-09-25 14:46 --- Created an attachment (id=12322) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12322&action=view) C source to compile with -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
[Bug middle-end/29215] Unnecessary use of stack space
--- Comment #2 from joerg at netbsd dot org 2006-09-25 14:46 --- Created an attachment (id=12323) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12323&action=view) Assembly output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
[Bug middle-end/29215] Unnecessary use of stack space
--- Comment #5 from joerg at netbsd dot org 2006-09-25 16:48 --- It is not violating aliasing rules (since a character string can alias with everything, 6.5p7) nor does it affect this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
[Bug middle-end/29215] Unnecessary use of stack space
--- Comment #8 from joerg at netbsd dot org 2006-09-25 16:57 ---
> Second this is just a memcpy issue, short testcase:
> #include
>
> char buf[21];
>
> int main(void)
> {
> int a = 0x;
> memcpy(buf, &a, 4);
This creates two movl, one for a and one to buf. When duplicating the memcpy
multiples times, it stays one for a and one for each memcpy.
Manually inline the original testcase shows the same behaviour.
I think the real problem is in this example a is written to the stack and not
optimised away. For the original test case the lazy stack cleanup would explain
the multiple assignments.
--
joerg at netbsd dot org changed:
What|Removed |Added
GCC host triplet||i386--netbsdelf
Keywords|missed-optimization |
Known to fail|4.0.0 4.1.0 4.2.0 |
Known to work|3.4.0 |
Summary|[4.0/4.1/4.2 Regression]|Unnecessary use of stack
|memcpy is not fully |space
|optimized any more |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
[Bug preprocessor/47047] Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 --- Comment #6 from Joerg Sonnenberger 2013-04-08 08:11:45 UTC --- Nothing has changed. It likely needs updates to apply to GCC 4.8+, but the general functionality is still desirable, IMO.
[Bug preprocessor/47047] New: Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 Summary: Support for path translation in __FILE__ Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: jo...@netbsd.org Created attachment 22841 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22841 Implement cpp -iremap __FILE__ expands to full path names in some situation, e.g. if it is used in a header found via -I/some/where. The resulting leak of the header location into the file binary is undesirable in certain situations. For NetBSD, two relevant cases are the visiblity protection in pkgsrc, which effectively turns /usr/pkg/include/foo into /.../work/.buildlink/include/foo and cross-compiling the system, which would leak /.../usr/include/foo instead of /usr/include/foo or the location of the source tree. The attached patch implements a CPP option to match the file path against a list of prefixes and substitute the prefix on match. With this patch, most references to the src and obj locations in NetBSD can be translated into the canonical positions. The patch is the version included in NetBSD against the system gcc, it can be updated if necessary.
[Bug preprocessor/47047] Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 --- Comment #4 from Joerg Sonnenberger 2011-02-06 04:10:12 UTC --- (In reply to comment #3) > Please fill in the form at > http://gcc.gnu.org/wiki/CopyrightAssignment > and send it to fsf-reco...@gnu.org and they will then send you the > appropriate assignment form. Done and processed.
[Bug c++/55361] New: Access control in templates only happens when instantiating a method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55361
Bug #: 55361
Summary: Access control in templates only happens when
instantiating a method
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jo...@netbsd.org
Consider the following example:
class C
{
bool blocked;
};
template < class > struct F
{
void operator* ()
{
C a;
a.blocked;
}
};
int main() {
F x;
}
The operator is violating the access specifications of C, but this isn't
detected until it is actually used. Nothing in it depends on the template
though, so this check should happen earlier.
[Bug c++/55368] New: Comma before semicolon in struct definition is not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55368
Bug #: 55368
Summary: Comma before semicolon in struct definition is not
rejected
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jo...@netbsd.org
Test case:
struct A { struct B *C,; };
[Bug other/81457] New: Inconsistent section flags for section attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81457
Bug ID: 81457
Summary: Inconsistent section flags for section attribute
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg at netbsd dot org
Target Milestone: ---
Created attachment 41767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41767&action=edit
Potential fix, relative to GCC 5.4.0.
Assemble the following input for any ELF target:
__attribute__((section("foo1s"))) const int foo1;
__attribute__((section("foo2s"))) const int foo2 = 42;
Note that foo1s has flags "AW", but foo2s has flags "A".
Bug reproduces on the GCC snapshot option of godbolt.org. The attached patch
applies against GCC 5.4.0, it might need shuffling for newer versions. The
additional null checks are required for correct handling of e.g. __thread
variables.
[Bug other/81458] New: Misdetection of gcc_cv_as_cfi_advance_working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81458 Bug ID: 81458 Summary: Misdetection of gcc_cv_as_cfi_advance_working Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: joerg at netbsd dot org Target Milestone: --- Created attachment 41768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41768&action=edit Problematic object file The gcc_cv_as_cfi_advance_working test case can misdetect support due to bugs in objdump. Please consider switching to readelf instead. Attached is the assembled test case from NetBSD. readelf --debug-dump=frames gives: 0018 0018 001c FDE cie= pc=..00012520 DW_CFA_advance_loc4: 75040 to 00012520 DW_CFA_def_cfa_offset: 192 ... and objdump -Wf gives: 0018 0018 001c FDE cie= pc=00012520..c00f252125200400 Augmentation data: 00 DW_CFA_nop DW_CFA_nop
[Bug other/81458] Misdetection of gcc_cv_as_cfi_advance_working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81458 --- Comment #1 from Joerg Sonnenberger --- Created attachment 41769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41769&action=edit Using readelf in configure.ac (against 5.4.0)
[Bug other/81458] Misdetection of gcc_cv_as_cfi_advance_working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81458 --- Comment #2 from Joerg Sonnenberger --- More testing seems to point to binutils 2.28 as fixing objcopy. It is still not clear whether there is any reason to preferring it though, especially as many systems ship older versions.
