[Bug preprocessor/41492] New: Please ignore #! on the first line of a file
I have a file that I would like to be able to either execute with a C
interpreter, or compile with GCC.
As you know, Unix uses "#!/path/to/interpreter" to invoke scripts. Consider
the following program:
#!/usr/bin/c-interpreter
int main() { printf("Hello World\n"); }
It would be nice if this could be compiled by GCC, simple by ignoring the first
line of the file. The current error message is:
hello.c:1:2: error: invalid preprocessing directive #!
One easy fix would be to define the preprocessing directive #! as a legal
directive, which swallows the rest of the line. This would work with C, C++,
and ObjC, but not the other languages. Another possibility that would work
universally is to make #! as the first two characters of an input file a
"special case" comment specifier in all front-ends. It doesn't need to be
recognized anywhere except as the first two bytes of a file.
Please consider this small but useful feature as it will help me with writing
portable code that can be interpreted as well as compiled.
--
Summary: Please ignore #! on the first line of a file
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drwowe at yahoo dot com
GCC build triplet: All
GCC host triplet: All
GCC target triplet: All
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41492
[Bug c++/52951] New: internal compiler error with c++11 initializer lists and C arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52951
Bug #: 52951
Summary: internal compiler error with c++11 initializer lists
and C arrays
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drw...@yahoo.com
Created attachment 27146
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27146
preprocessed source
The following trivial snippet produces "internal compiler error: Segmentation
fault". Tested with 4.7.0 and 4.6.3 on two different architectures.
g++-4.7 -c -std=c++11 test.cc
test.cc:
#include
std::pair foo = {1, {2} };
g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --program-suffix=-4.7
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug c++/44811] non controllable bogus warning: right/left shift count is negative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44811
D W changed:
What|Removed |Added
CC||drwowe at yahoo dot com
--- Comment #3 from D W 2012-04-12 21:36:14 UTC ---
I'm also getting a different but similar warning.
Trivial example:
int shiftifbig(int x) {
if (sizeof(x) > 4) {
return x>>32;
} else {
return x;
}
}
produces the following spurious warning:
warning: right shift count >= width of type [enabled by default]
Please gate this warning on something like -Wshift so that the corresponding
-Wno-shift could be used.
Even better, suppress the warning automatically from dead code like in the
above example.
[Bug c++/52966] New: ill-formed template constexpr functions are accepted?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52966
Bug #: 52966
Summary: ill-formed template constexpr functions are accepted?
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drw...@yahoo.com
The following code successfully compiles on g++ 4.7.0 with -std=c++11. I'm not
a language lawyer, but it seems like it shouldn't since the A::two() function
breaks the constexpr rules, either at template definition or template
instantiation time.
--
template
struct A {
static int two_nonconst() { return 2; }
static constexpr int two() { return two_nonconst(); }
}
constexpr int two() {
return A::two();
}
--
There is no error message until you actually try to use the two() function in
an appropriate context, which could be very confusing.
--
int x[two()];
--
error: size of array 'x' is not an integral constant-expression
[Bug c++/52951] internal compiler error with c++11 initializer lists and C arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52951 --- Comment #2 from D W 2012-04-13 16:22:28 UTC --- I built gcc from gcc-4_7-branch, svn186417. I can confirm it does not segfault on my example.
[Bug c++/52951] internal compiler error with c++11 initializer lists and C arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52951 --- Comment #3 from D W 2012-04-13 18:22:29 UTC --- After a little more investigation it turns out this was fixed by the fix to bug 52743. So I guess this is actually a dup.
[Bug c++/52743] g++-4.7.0 seg faults on overload functions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52743 D W changed: What|Removed |Added CC||drwowe at yahoo dot com --- Comment #4 from D W 2012-04-13 18:23:19 UTC --- *** Bug 52951 has been marked as a duplicate of this bug. ***
[Bug c++/52951] internal compiler error with c++11 initializer lists and C arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52951 D W changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #4 from D W 2012-04-13 18:23:19 UTC --- *** This bug has been marked as a duplicate of bug 52743 ***
[Bug target/53056] New: bad code generated for ARM NEON with vector types in structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53056
Bug #: 53056
Summary: bad code generated for ARM NEON with vector types in
structs
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drw...@yahoo.com
Consider the following snippet:
typedef int vi16 __attribute__((vector_size(16*sizeof(int;
vi16 add(vi16 a, vi16b) {
return a + b;
}
compile with arm-linux-gnueabi-gcc-4.7 -O2 -march=armv7-a -mhard-float
-mfpu=neon
Some fairly good code is produced:
sub sp, sp, #8
str r4, [sp, #-4]!
fstmfdd sp!, {d8, d9, d10, d11, d12, d13}
add ip, sp, #52
add r4, sp, #116
vldmia r4, {d24-d31}
stmia ip, {r2, r3}
vldmia ip, {d6-d13}
vadd.i32q8, q3, q12
vadd.i32q9, q4, q13
vadd.i32q10, q5, q14
vadd.i32q11, q6, q15
vstmia r0, {d16-d23}
fldmfdd sp!, {d8, d9, d10, d11, d12, d13}
ldmfd sp!, {r4}
add sp, sp, #8
bx lr
However, the the vector is embedded in a struct the code generation becomes
awful.
typedef struct A {
vi16 v;
} A;
vi16 add1(A a, A b) {
return a.v + b.v;
}
// Same code as add1
vi16 add2(A a, A b) {
vi16* av = &a.v;
vi16* bv = &b.v;
return a.v + b.v;
}
Both add1 and add2 produce the same code:
add1:
@ args = 128, pretend = 8, frame = 128
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #8
sub sp, sp, #128
add r1, sp, #128
stmia sp, {r2, r3}
stmia r1, {r2, r3}
ldr r3, [sp, #192]
ldr r2, [r1, #8]
str r3, [sp, #64]
ldr r3, [sp, #196]
str r2, [sp, #8]
ldr r2, [r1, #12]
str r3, [sp, #68]
ldr r3, [sp, #200]
... lots and lots of load and store instructions.
But adding an "optimization barrier" to add2 produces similar code to the
original example, by making the compiler "forget" the origin of the pointer.
vi16 add3(A a, A b) {
vi16* av = &a.v;
vi16* bv = &b.v;
asm("" : "+r"(av), "+r"(bv)); // causes good code to be generated.
return *av + *bv;
}
[Bug target/53056] bad code generated for ARM NEON with vector types in structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53056 --- Comment #1 from D W 2012-04-20 20:16:35 UTC --- Also tested arm-linux-gnueabi-gcc-4.8.0-svn186501. Same results.
[Bug target/53056] bad code generated for ARM NEON with vector types in structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53056
--- Comment #2 from D W 2012-04-20 20:20:46 UTC ---
Typo: add2 should be:
vi16 add2(A a, A b) {
vi16* av = &a.v;
vi16* bv = &b.v;
return *av + *bv;
}
