Re: onlinedocs formated text too small to read
Georg-Johann Lay wrote, On 01/08/11 09:40: Jon Grant wrote: [.] http://gcc.gnu.org/ml/gcc/2011-07/msg00106.html CCed Gerald, I think he cares for that kind of things. If he does not answer (it's vacation time) file a PR so that it won't be forgotten. Johann Thank you. I filled a PR now: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50642 Best regards, Jon
Re: cc1.exe: warnings being treated as errors
Jonathan Wakely wrote, On 26/09/11 09:57: [.] Feel free to request a new option in Bugzilla to suppress the note, that's the right place for this discussion. Good point. I've created a ticket: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50643 Regards, Jon
Re: No pointer conversion warning for bool in C/C++
Hello Jonathan Wakely wrote, On 26/09/11 08:10: On 26 September 2011 05:29, Ian Lance Taylor wrote: Jon Grantj...@jguk.org writes: Currently gcc, and g++ don't give a warning when a pointer was converted to a bool, in the same way it is for other types. At least in C++, it's not really true to say in the same way it is for other types because you cannot convert from a pointer to any integer type except bool. Your test uses NULL for the other integer types, which is an integral constant expression with value zero, so it's ok to convert that to an integer type. That's not true for general pointer values: if your test used m_int(g_glob) then it wouldn't compile. Good point. My test should have used g_glob due to NULL being a macro of 0 in C++. There is a lot of code which uses if (p) where p is a pointer to test whether p is not NULL. I don't think we could reasonably have gcc warn about such a case. We might be able to separate out conversion to bool on assignment from conversion to bool in a test, though. That would still break this: Base* p = getObj(); bool is_derived = dynamic_castDerived*(p); What problem is the warning supposed to solve? A programmer assigning a bool with a pointer, there's an implicit evaluation there isn't there? rather than: bool invalid = (NULL == p); I expect this depends on what the standard allows then. Regards, Jon
Re: cc1.exe: warnings being treated as errors
Hi Jonathan Jonathan Wakely wrote, On 24/09/11 15:55: On 24 September 2011 15:40, Jon Grant wrote: It's kind of re-iterating the command line options, that the user will choose to be aware of already. I don't recall seeing that text output before about ~1 year ago. It was there in GCC 4.1, maybe earlier, I didn't check. However, coming back to my query: Is there a need to remind the user that warnings on the build are being treated as errors? Is this a special case because it would cause the build to stop? For example: -Wall means I see control reaches end of non-void function messages, but doesn't output cc1.exe: all warnings turned on I'd thought because the previous line of output said gcc -Werror -Wall -o main main.c, the options clear. Not if you run make and it doesn't echo the compiler command, or run the compiler from an IDE, or anything else which shows the errors but not the command. I would have though that it's not GCC's responsibility to echo the options passed to it. Like the IDE example, the IDE can inform the user of what compiler options are in use; I don't see why GCC can't keep quiet about -Werror. Best regards, Jon
Re: No pointer conversion warning for bool in C/C++
Jonathan Wakely wrote, On 26/09/11 09:53: On 26 September 2011 09:32, Jon Grant wrote: [.] bool invalid = (NULL == p); Why is that preferable? It would be clearer IMHO what was happening. I expect this depends on what the standard allows then. 4.12 Boolean conversions [conv.bool] 1 A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true. A prvalue of type std::nullptr_t can be converted to a prvalue of type bool; the resulting value is false. I stand corrected. No reason to change anything if it is in the standard. Thank you for discussing this point. Best regards, Jon
No pointer conversion warning for bool in C/C++
Hello
Currently gcc, and g++ don't give a warning when a pointer was converted
to a bool, in the same way it is for other types.
Could I ask for opinion on this, and if I should create a bug ticket.
Please find below output from compilation, and attachments showing the
two tests.
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
$ gcc -Wconversion -Wall -o t bool_conversion.c
bool_conversion.c: In function ‘main’:
bool_conversion.c:14:8: warning: assignment makes integer from pointer
without a cast
bool_conversion.c:15:9: warning: assignment makes integer from pointer
without a cast
^ I expected to see a warning on line 13.
$ g++ -Wconversion -o t bool_conversion.cpp
bool_conversion.cpp: In constructor ‘A::A()’:
bool_conversion.cpp:16:41: warning: converting to non-pointer type ‘int’
from NULL
bool_conversion.cpp:16:41: warning: converting to non-pointer type
‘unsigned int’ from NULL
^ I expected to see a bool warning on line 16.
I tested assigning NULL in these tests (Note, I also confirmed that
assigning a pointer variable produced the same lack of warning output.)
Please include my email address in any replies
Best regards, Jon
// g++ -Wconversion -o t main.cpp
// Should this not give a warning for the bool conversion
// include to get definition of NULL
#include string.h
void * g_glob = NULL;
class A
{
public:
A();
bool m_bool;
int m_int;
unsigned int m_uint;
};
A::A()
: m_bool(g_glob), m_int(NULL), m_uint(NULL)
{
}
int main()
{
return 0;
}
// gcc -Wconversion -o t bool_conversion.c
// Should this not give a warning for the bool conversion
// include to get definition of NULL
#include string.h
#include stdbool.h
int main(void)
{
bool m_bool;
int m_int;
unsigned int m_uint;
m_bool = NULL;
m_int = NULL;
m_uint = NULL;
return 0;
}
Trying to find a gcc warning to detect different parameter names
Hello
I am looking for a gcc option to give a warning when parameter names
don't match between the prototype in C, and the definition. Could
someone point me to the option if there is one please.
Example provided below, where offset miss-spelt offest. (I found
-Wstrict-prototypes, but that only warns if types are not specified.).
Would be quite handy to have this ability to check parameter names are
consistent.
Please include my email address in any replies.
Best regards, Jon
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
// gcc -Wall -o main main.c
#include stdio.h
void test_func(int offest);
void test_func(int offset)
{
printf(%d\n, offset);
}
int main(void)
{
test_func(1);
return 0;
}
Re: cc1.exe: warnings being treated as errors
Jonathan Wakely wrote, On 19/09/11 19:40: On 19 September 2011 18:59, Jon Grant wrote: Hello I noticed that when compiling C files with GCC and using the -Werror option, I see this additional output: cc1.exe: warnings being treated as errors ./src/main.c: In function 'main': ./src/main.c:41:15: error: unused variable 'hello' Is the cc1 line output needed? Just wondering if it could be removed. Appears superfluous. It's not superfluous, it says that the error following might have been a warning, except that -Werror was used. If you don't want it you can either fix the warning or not use -Werror. It's kind of re-iterating the command line options, that the user will choose to be aware of already. I don't recall seeing that text output before about ~1 year ago. I'd thought because the previous line of output said gcc -Werror -Wall -o main main.c, the options clear. If it's really vauluble, that output could be turned on by an option itself! -Wdisplay-warning-upgrade. Leaving it off by default. Best regards, Jon
cc1.exe: warnings being treated as errors
Hello I noticed that when compiling C files with GCC and using the -Werror option, I see this additional output: cc1.exe: warnings being treated as errors ./src/main.c: In function 'main': ./src/main.c:41:15: error: unused variable 'hello' Is the cc1 line output needed? Just wondering if it could be removed. Appears superfluous. If compiling with g++ it is : cc1plus: warnings being treated as errors I saw this in two slightly old builds of GCC: arm-none-eabi-gcc-4.5.1.exe (Sourcery G++ Lite 2010.09-51) 4.5.1 gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Please keep my email address in any replies as I'm not on the mailing list. Best regards, Jon
Re: onlinedocs formated text too small to read
Hello Georg-Johann Lay wrote, On 08/07/11 19:08: [.] I can confirm that it's hardly readable on some systems. I use Opera and several FF versions, some worse, some a bit less worse. IMO it's definitely to small, I already thought about complaining, too. Johann Could I ask, what would be the best way to progress this request? e.g. Should I create a bugzilla ticket. Best regards, Jon
gcc bitfield order control
Hello
I have a build with a lot of structures in a big-endian style layout.
[I recognise that bit-fields are not portable due to their ordering
not being locally MSB first like the regular bit shift operation
is.i.e.(12) == 4 ]
typedef struct reg32 {
union {
_uint32 REG32;
struct {
_uint32 BIT31:1;
_uint32 BIT30:1;
_uint32 BITS:30;
} B;
} R;
} reg32_t;
On a little-endian ARM build. Using :
arm-none-eabi-gcc (Sourcery G++ Lite 2010.09-51) 4.5.1
Writing reg.R.REG32 = 1, results in BIT31 containing 1. Rather than
the 1 being in the BITS field.
My thought is I'll need to swap every structure to be in little-endian
style ordering. Does anyone have any other ideas how to handle this
with gcc?
I was thinking to write a little program to make the changes to the header file.
Please include my email address in any replies.
Best regards, Jon
onlinedocs formated text too small to read
Hello
I'm using latest Firefox looking at the onlinedocs with a default
Firefox install, default font sizes, no change in zoom level.
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
The monospace text is tiny, e.g.:
pre class=smallexample struct foo { int x[2]
__attribute__ ((aligned (8))); };
/pre
The fix is pretty easy, just change the embedded CSS that is generated:
pre.smallexample { font-size:smaller }
I propose this be changed to:
pre.smallexample { font-size:normal }
Note: There are some other CSS tags with smaller, but they are
unused on that page, perhaps worth checking if the others are used in
other files and can be changed to normal as well.
I'm not on the mailing list, so please keep my email address in any replies.
Thanks, Jon
Re: Long paths with ../../../../ throughout
Ian Lance Taylor wrote, On 03/07/11 05:27: Jon Grantj...@jguk.org writes: [.] Another reply for this old thread. I wondered, if collect2 is possibly not needed in normal use on GNU/Linux, could GCC be configured to call ld directly in those cases to save launching another binary. collect2 is needed if you use -frepo or -flto. Hi Ian. Not sure how easy this is, but could those options simply be checked to determine if the linker could be called directly? Would save launching collect2 then, to speed up builds a bit! Best regards, Jon
Re: Long paths with ../../../../ throughout
On 2 February 2010 22:47, Ian Lance Taylor i...@google.com wrote: Jon j...@jguk.org writes: Is there a way to get collect2 to save the temporary .c file it generates to have a look at it? I believe it may be the __main() function, with the -debug option it gives the attached gplusplus_collect2_log.txt, looking at the [/tmp/ccyBAI9V.c] file though it is empty, any ideas? Using -debug will direct collect2 to save the temporary .c file when it creates one. However, in ordinary use on GNU/Linux, collect2 will never generate a temporary .c file. Hello Ian, Another reply for this old thread. I wondered, if collect2 is possibly not needed in normal use on GNU/Linux, could GCC be configured to call ld directly in those cases to save launching another binary. Best regards, Jon
Re: GAS GCC FAQ query
Gerald Pfeifer wrote, On 08/05/11 14:02: On Fri, 6 May 2011, Jonathan Wakely wrote: I would propose to clarify as: To ensure that GCC finds the GNU assembler (or the GNU linker), I see no harm in that change, Gerald, what do you think? Agreed. Things would have been different twenty years ago, but these days using linker is a lot more natural and common (as a grep in gcc/doc confirms, too). I went ahead and applied the patch below. Thanks for suggesting this! Great the change has been made Gerald, Jonathan, thank you. Best regards, Jon
Re: gcc detect multiple -o passed on one command line
Dave Korn wrote, On 07/05/11 16:01: On 06/05/2011 09:00, Andreas Schwab wrote: Ian Lance Taylor writes: The difference is that with -E the -o option is passed to cc1, whereas without it the -o option is passed to the assembler or the linker. The GNU assembler and linker both have the usual Unix behaviour of only using the last -o option. Nevertheless it might be a good idea to file a bug for binutils. Consistency is probably more important, and it helps in case of typos. In this case, I don't think consistency should win over maintaining long-established behaviour. I'm more inclined to say that cc1 should change to follow long-established *nix tradition. (I have absolutely found it useful on at least one occasion to be able to add a -o option into CFLAGS and know it would come last on the command-line and win.) Hello Would it be useful to have an option to enable warning if there are duplicates? From my point of view, I feel that not warning duplicates may let mistakes in the way gcc is invoked slip through, e.g. assist tracking down these issues in makefiles. Best regards, Jon
Re: GAS GCC FAQ query
Hello. thank you for your reply. Jonathan Wakely wrote, On 05/05/11 22:47: On 5 May 2011 22:30, Jon Grant wrote: Hello Just looking at this page: http://gcc.gnu.org/faq.html#gas I saw this text (the GNU loader). Is this really an alternative name for gas? I've not seen it called GNU loader elsewhere. I was wondering if the text could just be removed. It refers to the linker, ld, not to gas, and shouldn't be removed. The parenthesized text represents an alternation, the paragraph should be read as referring to the GNU assembler or to the the GNU linker (aka loader). Not read ld called a GNU loader in binutils documentation, the common name I have seen is GNU linker. (I do recall ld is an abbreviation for load though.) I would propose to clarify as: To ensure that GCC finds the GNU assembler (or the GNU linker), Best regards, Jon
GAS GCC FAQ query
Hello Just looking at this page: http://gcc.gnu.org/faq.html#gas I saw this text (the GNU loader). Is this really an alternative name for gas? I've not seen it called GNU loader elsewhere. I was wondering if the text could just be removed. Please keep my email address in any replies. Best regards, Jon
gcc detect multiple -o passed on one command line
Hello Is it expected that more than one -o option should be allowed by GCC on command line? The later -o option overriding earlier. I had expected the parameter checking to detect this duplication of options. gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 $ gcc -W -Wall -o main main.c -omup.o $ ls main.c mup.o I can create a bug ticket if needed. Let me know. Please keep my email address included in any replies. Best regards, Jon
Re: Long paths with ../../../../ throughout
Hello Ian Thank you for the quick reply with explanations. 2010/1/19 Ian Lance Taylor i...@google.com: Jon Grant j...@jguk.org writes: Any easy way to evaluate and reduce command lines? Consider this: /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o Is actually the same as: /usr/lib/crt1.o -- which is much clearer! Using this form of path makes it easy to move an installed gcc tree to a new location and have it continue to work correctly. Since normal users never see these paths, the goal is correctness rather than clarity. Ok I understand. The reason to build it up from a root and a target /lib/crt*.o file. I thought it would be possible to resolve the back to a direct pathname though to use for the parameters. I see that some of the files are located in the -L library directory specified, crtbegin.o, crtend.o in which case, perhaps they both do not need their full long path specified. Also I notice lots of duplicate parameters: Is this directory really needed twice? -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3 No. I would encourage you to investigate why it is happening. i tried: gcc -o t -Wl,-debug test.c, I see collect2 gets the duplicates passed to it, and then it passes it on to ld. I would have thought that if collect2 was compiled with define LINK_ELIMINATE_DUPLICATE_LDIRECTORIES it would strip out the duplicate parameters before calling ld. It does not appear to be switched on in this Ubuntu package I am using though. Is it on by default? also -lgcc_s is mentioned twice, as is -gcc This is because on some systems there is a circular dependency between -lgcc and -lc. Some of the functions in -lgcc require functions in -lc. If -lc was compiled with gcc, then on some systems some of the functions in -lc will require -lgcc. Fortunately the functions which -lc requires in -lgcc will never themselves require -lc. So mentioning -lgcc twice, once before -lc and once after, suffices on all systems. Finally, could collect2 output command lines when in -verbose mode? Currently I can't see what parameters it is calling ld with.. when ld fails. To see what collect2 is doing, use -Wl,-debug. Is this documented If I add this to my existing command line I see there not any output: $ gcc -### -o t -Wl,-debug test.c If I change to not have -### I see it does work, not sure why. So I understand that this passes -debug to collect2. As collect2 only has -v mode to display version. Would a patch to add --help to it be supported? Also could describe something about collect2's purpose at the top of that --help output. Additional queries: 1) collect.c:scan_libraries may not find ldd, in which case it displays message on output, and returns as normal. Should it not be fatal if ldd is required? 2) in collect2.c:main -debug is checked, and variable debug set to 1 (perhaps that should be true to match the style of other flags) Please keep my email address in any reply. Cheers, Jon
Long paths with ../../../../ throughout
Hello gcc -o t -### test.c Any easy way to evaluate and reduce command lines? Consider this: /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o Is actually the same as: /usr/lib/crt1.o -- which is much clearer! I'm using Ubuntu 9.04. Cheers, Jon $ gcc -o t -### test.c Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) COLLECT_GCC_OPTIONS='-o' 't' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.3/cc1 -quiet test.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase test.c -mtune=generic -auxbase test -fstack-protector -o /tmp/ccoCNitV.s COLLECT_GCC_OPTIONS='-o' 't' '-mtune=generic' as -Qy -o /tmp/ccKSwMpH.o /tmp/ccoCNitV.s COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 't' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.3/collect2 --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o t -z relro /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.3.3/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.. /tmp/ccKSwMpH.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.3.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crtn.o
Re: Long paths with ../../../../ throughout
I should add, I'm not on this mailing list, so please include my email address in any replies. Cheers, Jon
Re: Long paths with ../../../../ throughout
2010/1/19 Jon Grant j...@jguk.org: I should add, I'm not on this mailing list, so please include my email address in any replies. Also I notice lots of duplicate parameters: Is this directory really needed twice? -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3 also -lgcc_s is mentioned twice, as is -gcc Finally, could collect2 output command lines when in -verbose mode? Currently I can't see what parameters it is calling ld with.. when ld fails. I'm not on this mailing list, so please include my email address in any replies. Cheers, Jon
