[Bug driver/27237] New: gcc driver should pass -mthumb option to arm assembler
This bug appears to be present in all version of gcc 3.x.x and 4.x.x When invoking gas via gcc the -mthumb option is not passed by the compiler driver to the assembler. Repeat by: 1) build an arm cross compiler. 2) attempt to assemble an arm thumb .S file, using gcc as the driver: arm-elf-gcc -v -c foo.S 3) note that the assembler is invoked without the -mthumb option. Further, if the .S file is valid thumb assembler that happens to be valid arm assembler, the assembler will assemble it as arm code rather than thumb code. -- Summary: gcc driver should pass -mthumb option to arm assembler Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mf dot danger at gmail dot com GCC build triplet: any GCC host triplet: any GCC target triplet: arm-any-any http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug driver/27237] gcc driver should pass -mthumb option to arm assembler
--- Comment #2 from mf dot danger at gmail dot com 2006-04-21 20:08 --- I guess I didn't make it clear that this is a bug against the gcc _driver_ not the compiler. I am using gcc _driver_ to invoke gas to assemble an assembler *source* file. 'gcc -mthumb -c foo.S' should cause gas to assemble foo.S as thumb code, rather than arm code, but it does not because when gcc _driver_ invokes gas, it doesn't pass the '-mthumb' option on to it. (Why use gcc to invoke the assembler? because that's what the default make rule does, and this is in a make file...) -- mf dot danger at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug driver/27237] gcc driver should pass -mthumb option to arm assembler
--- Comment #3 from mf dot danger at gmail dot com 2006-04-21 20:24 --- Created an attachment (id=11313) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11313&action=view) Example .S file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug driver/27237] gcc driver should pass -mthumb option to arm assembler
--- Comment #4 from mf dot danger at gmail dot com 2006-04-21 20:30 --- Perhaps a precise example would make this clearer. I have a human-written thumb assembler file. (see attached) I attempt to assemble it using arm-elf-gcc -v -g -mthumb -c -o bdidown.o bdidown.S The following appears in the '-v' output: /usr/local/armdev-3.4.3/lib/gcc/arm-elf/3.4.3/../../../../arm-elf/bin/as --gdwarf2 -o bdidown.o /tmp/ccBSZyCm.s Note that the -mthumb option is not passed to the assembler. Further, if you run arm-elf-objdump -d bdidown.o you can see from this fragment 0: e10fmrs r0, CPSR 4: e3c0bic r0, r0, #0 ; 0x0 8: e38000d3orr r0, r0, #211; 0xd3 c: e129f000msr CPSR_fc, r0 10: e3a00302mov r0, #134217728 ; 0x800 that the assembler has generated arm code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug target/27237] gcc driver should pass -mthumb option to arm assembler
--- Comment #6 from mf dot danger at gmail dot com 2006-04-21 20:36 --- That's fine, so long as you turn it into a documentation bug and fix the documentation, as it's an option that's documented as being passed to the assembler. -- mf dot danger at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug target/27237] gcc driver should pass -mthumb option to arm assembler
--- Comment #8 from mf dot danger at gmail dot com 2006-04-21 22:43 --- On the question of documentation: >From the GNU Info node for invoking gas: Usually you do not need to use this `-Wa' mechanism, since many compiler command-line options are automatically passed to the assembler by the compiler. Then the ARM specific section mentions -mtumb as a valid option. It violates the principle of least astonishment that an option that is valid for the driver and the driven program can't be passed directly to the driven program. - On the question of '.thumb': Setting '.thumb' in the assembler file works for some files, but there are occassions when the same .S file is compiled as either thumb or arm, depending on the circumstance it will be used in. - On the level of work: That's a fine reason to defer the fix. I did enter the bug as a 'minor' after all. ;) -- mf dot danger at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug target/27237] gcc driver should pass -mthumb option to arm assembler
--- Comment #10 from mf dot danger at gmail dot com 2006-04-21 23:52 --- Gas is part of binutils, but the driver is part of gcc, and it *is* a violation of the principle of least astonishment to have to pass the same option two different ways through the driver depending on what option is being passed. Also, the same information is present in the gcc info node. (see 3.17.2 ARM Options) and the GCC Command Options section says that options are passed on to the various stages. If any of the passes recognizes an option that the driver understands, the driver should pass that option on to that pass. Any other behavior violates least-astonishment. -- mf dot danger at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug target/27237] gcc driver should pass -mthumb option to arm assembler
--- Comment #12 from mf dot danger at gmail dot com 2006-04-22 01:16
---
actually, gcc itself says so:
printf (_("\
\nOptions starting with -g, -f, -m, -O, -W, or --param are automatically\n\
passed on to the various sub-processes invoked by %s. In order to pass\n\
other options on to these processes the -W options must be used.\n\
"), programname);
/* The rest of the options are displayed by invocations of the various
sub-processes. */
}
(taken from 3.4.3 gcc/gcc.c)
Having discovered that, I'm now convinced that it is *NOT* a documentation bug.
*IS* a driver bug, and should be fixed.
--
mf dot danger at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug target/27237] gcc driver should pass -mthumb option to arm assembler
--- Comment #14 from mf dot danger at gmail dot com 2006-04-22 01:51 --- I doubt there is anyone anywhere who would be able to devine that "various" meant this subset of the processes and not that. Further, the sentence that describes the use of '-W' specifically says "other options to THESE processes". So, if your interpretation of the first sentence is correct, then the second sentence is wrong. However, the second sentence implies that "various" means any of the subprocesses. Close the bug as 'won't fix', fix the documentation to match the reality, or, prefered, fix the bug, please. -- mf dot danger at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug c/28912] Non-functional -funsigned-char: signed/unsigned mismatch is reported
--- Comment #6 from mf dot danger at gmail dot com 2006-09-25 18:47 --- After consulting the oracle (In the this case ANSI X3.159-1989,) and being unable to find any information to support the claim that char is always different type than unsigned char or signed char, I'd like to have this bug reopened, at least as amended by my comments below. 3.5.4.1 (Pointer Declarators) and 3.3.3.2 (Address and Indirection Operators) the sections that deal with pointers make no mention, and 3.1.2.5 definitely says that whether char is signed or not is implementation defined. However, it seems to me, the discussion of what type char is is missing the one point of the original bug. The original bug points out that when the default type of char is set to one of signed or unsigned, the compiler does not treat pointers to char as if they have the same signedness as char. I'd like to at least see that much fixed, so that if -funsigned-char is used, then references through pointers are treated to the same warnings as direct references. By the way, there is no 6.2 in the the C '89 spec, as far as I can tell. Which spec were you referencing? Aside: char serves two distinct roles in C. While it is the character type, it is _also_ the smallest integer type. It is the only 8 bit integer type on most processors, and so serves the purpose of 8 bit integer arithmetic. This turns out to be important in cryptographic applications, among other things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28912
