Re: Is this a compiler bug?
A Moore wrote: Using floats, floor() returns wrong result, as shown in this program: I assume you are doing this on an x86-linux machine, in which case this is the classic x86 excess-precision problem, as detailed in PR 323 in our bugzilla bug database. The old x87 FP stack uses 80-bit precision to compute the divide result, and gets a number slightly less than 15, which only becomes 15 when rounded to float. If you pass the unrounded number to the floor() function, then you get 14 as the result from floor. This is very hard to fix in gcc without destroying FP performance. There is unfortunately no good solution, and it may never be fixed. There are various workarounds, such as using -ffloat-store. x86_64-linux does not have this problem, as it avoids use of the old x87 FP stack, and instead uses SSE instructions for FP arithmetic which do not have this excess precision problem. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: bug report
Hayashi Eisuke wrote: 100: 400 (-1077752048) 2092728: Segmentatioin error (core dumped) The process is dying because you are exceeding unix process stack space limits. You probably have an 8MB per process limit, and the number you are using is a tad less than 2MB. If you are using bash, see the documentation for the ulimit command. If csh, I think it is limits. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Inconsistent floating point result when using G++ 3.3.6 with option -O0 or -O1 separately
I found our application tool gave the inconsistent floating point result when using different optimization level -O0 or -O1. Even if I used -O1 plus all the disabling options which includes in -O1, like -O1 -fno-merge-all-constants -fno-zero-initialized-in-bss -fno-function-cse -fno-keep-static-consts -fno-omit-frame-pointer -fno-merge-constants -fno-loop-optimize -fno-cprop-registers -fno-if-conversion -fno-if-conversion2 -fno-delayed-branch -fno-guess-branch-probability -fno-defer-pop -fno-crossjumping -fno-thread-jumps which command line setting should be equal to -O0, but I still didn't get the consistent result. I wonder whether there is any additional optimization enabled by -O1 for C++ language which is not documented in GCC manual? See http://gcc.gnu.org/bugs.html for info on how to submit a proper bug report. You didn't mention the target, but this is almost certainly an x86. This is a common problem for x86 users. This is partly a design flaw with the x87 FP register stack, and partly an implementation flaw with the gcc x86 back end. Unfortunately, there is no good solution that makes everyone happy, since the only way to get accurate FP results on the x87 is to sacrifice performance. GCC should at least provide this as an option, but unfortunately does not yet, even though the problem has been known for well over a decade. The only really good solution is to stop using the x87 FP register stack. This is done by default in x86_64-linux. For x86, there are some options that might help, such as -mfpmath=sse. This will only work with recent gcc versions and recent x86 processors, and may take some experimentation. Sometimes -ffloat-store helps. There is a lot of info about this problem in PR 323. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Bug in strtof
Qianli Zhang wrote: Sorry to bother you. Recently I met with a problem in strtof, a sample program is like: Compile with -Wall, and you get a warning saying that the return type of strtof is unknown, and the program fails. Compile with -Wall -std=c99 and you get no warning and the program works. It looks like glibc only enables full support for functions from the ISO C99 standard with extra preprocessor macros defined when -std=c99 is used. And it looks like this macro is _STDC_VERSION. There are also glibc tests for the _ISOC99_SOURCE and _ISOC9X_SOURCE macros which look like they are meant for users to define. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: GCC Compiling Problem
Joel C. Kampfer wrote: perl /usr/home/joelk/ftp/gcc-4.0.2/fastjar/../contrib/texi2pod.pl -D fastjar fastjar.pod So it is perl that is failing? There is probably not much we can do about that. What perl version do you have? If it is an old one, you should consider upgrading perl. An alternative solution is to avoid building fastjar which may work if this is the only place that is failing. fastjar is only used by java, so you could try configuring without java support if you don't need it, e.g. something like --enable-languages=c,c++ if you only need C and C++ support. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: long function name
Kornel wrote: g++ crashes for a very long function name ;) Bugs should be filed into bugzilla, rather than mailed to the gcc-bugs list. We won't track bugs mailed to the list. I took a quick look. I couldn't reproduce on my system. However, it occured to me that gcc is probably trying to copy function names into buffers on the stack. An 8MB function name means you need more than 8MB of stack space to compile it. Experimenting, I can compile the file with 16MB of stack space, but I can reproduce your error if I have only 8MB of stack space. Since stack space restriction is an OS limit, there isn't much gcc can do about it, except to ask you to increase it or reduce your function name length. It isn't reasonable to rewrite code to reduce stack space for this example. If you are using bash, try ulimit -s unlimited. If there is a per user system specified stack space limit, then you might need root access to increase it past this limit. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: asm outport
david pasha wrote: #include conio.h ... outport(0x56,0xf); You didn't mention what gcc error you got. You need to give complete info about a problem if you want a good answer. Since this is a very target dependent issue, you might try sending mail to a cyginw or mingw list. Gcc developers generally aren't Microsoft Windows experts. I tried a quick web search, it seems the answer is that win32 doesn't support direct access to the I/O ports, so you can't do what you are trying to do without a device driver. If you want a better answer, you need to ask people who know more about MS Windows programming. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Typo in gcc/config/kfreebsdgnu.h
Santiago Vila wrote: I'm following gcc from CVS and found this: -#define TARET_OS_CPP_BUILTINS()\ +#define TARGET_OS_CPP_BUILTINS() \ Thanks. I checked this in as an obvious fix. I did a partial cross-compiler build to verify that the patch had the intended effect. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com 2003-12-17 Santiago Vila [EMAIL PROTECTED] * config/kfreebsdgnu.h (TARGET_OS_CPP_BUILTINS): Rename from TARET_OS_CPP_BUILTINS. Index: kfreebsdgnu.h === RCS file: /cvs/gcc/gcc/gcc/config/kfreebsdgnu.h,v retrieving revision 1.1 diff -p -r1.1 kfreebsdgnu.h *** kfreebsdgnu.h 21 Oct 2003 09:52:47 - 1.1 --- kfreebsdgnu.h 18 Dec 2003 01:46:48 - *** Boston, MA 02111-1307, USA. */ *** 23,29 #define WCHAR_TYPE int #undef TARGET_OS_CPP_BUILTINS ! #define TARET_OS_CPP_BUILTINS() \ builtin_define (__GNU_KFreeBSD__=0); \ builtin_define (__gnu_kfreebsd__=0); \ builtin_define (__FreeBSD_kernel__=5);\ --- 23,29 #define WCHAR_TYPE int #undef TARGET_OS_CPP_BUILTINS ! #define TARGET_OS_CPP_BUILTINS() \ builtin_define (__GNU_KFreeBSD__=0); \ builtin_define (__gnu_kfreebsd__=0); \ builtin_define (__FreeBSD_kernel__=5);\
Re: IS IT A BUG ????
Srujan.K.V.S. wrote: The following is the program to print magic squares.I`m getting wierd output when i remove the printf statement printf(a) from the code. Please see http://gcc.gnu.org/bugs.html for info on how to submit bug reports. You did not include enough info for us to do anything with this bug report. We need to know the gcc version, the target (OS and CPU), the optimization options used, and possibly also other info. Also, bugs should be submitted into bugzilla rather than mailed to the list. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: PATCH: DWARF2 macinfo-related fixes for gdb and gcc
Alan Curry wrote: There is a function called maybe_emit_file() in gcc, which assigns the filenums, and takes care of mapping the file numbers in the main file list to the file numbers in the DWARF2 list. Someone forgot to use the return value of maybe_emit_file() This is FSF GCC PR 24070 which has already been fixed. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24070 By the way, for gcc, bugs should be filed into our bugzilla bug tracking system. We don't track bugs mailed to gcc-bugs, so this is a risky way to try to report bugs. Sometimes you will get an answer, sometimes you won't. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Compiler bug report
[EMAIL PROTECTED] wrote: I am using Altera provided Quartus II 4.0 tools. this tools also provide the arm-gnupro tool. which has arm-elf- cross- compiler. We can't fix problems in compiler releases made by other people. gnupro is a Red Hat trademark. We only support FSF gcc releases here. You can try contacting the people you got the compiler release from, or you can try an FSF gcc release. please! anyone suggest me the bug fix for this problem... now i am pasting the error report which i got while building the kernel image. This bug report is lacking info we normally need. Gcc version info. A testcase that can reproduce the bug. Etc. See http://gcc.gnu.org/bugs.html for info on how to report bugs. Also, bugs should be reported into our bugzilla bug database instead of emailed to this list. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: GCC bug report - Xubuntu kernel compile fails w/gcc bug report request
Jonathan Brickman wrote: as indicated by anyone who knows what I should be trying next! I tried to send this via the GCC web bug report system, but I could not find any way to attach this file, which the docs said is essential. First file the bug report, you will then immediately be taken to a page where you can attach the file to the newly created bug report. This is a bit awkward, yes, but I believe all bugzilla installations work this way. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: internal compiler error: is this a known problem?
Michael Abbott wrote: ../sysdeps/generic/s_fmax.c: In function `__fmax': ../sysdeps/generic/s_fmax.c:28: internal compiler error: in elim_reg_cond, at flow.c:3328 This looks the same as PR 15068 for which there is already a fix. You can get the patch from the PR. The PR also indicates that crosstools already has the patch, so maybe you can get it from there also. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Bugzilla administrator
Jarl Friis wrote: Can anyone here tell me who is (and the email of) the GCC bugzilla administrator gcc-bugs is mainly a list for output from our bug database. Posting here isn't very useful. Better to file a bug report, or send email to the gcc list. If you really need to reach an administrator, send mail to overseers. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: gcc bug WRT warning that should not be displayed
Mo DeJong wrote: long val2 = 1; /* incorrect warn when val2 is a long */ int c2 = ( ((long long) val2) ((long long)(-2147483647L - 1)) ); The result of the compare will always be false, so the warning is correct. The long variable val2 can not hold a value smaller than LONG_MIN. Adding casts to long long does not change this fact. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Bitfield conversion bug in 4.2?
Eric Lemings wrote: Is this a bug or new behavior? If the latter, what is this attributed to? FYI gcc-bugs isn't the best place to ask questions, as it is mostly used for output from our bug database. I'm not a C++ expert, so I'm not the right person to say for sure, but this looks like an accidental bug to me. There were patches added to change the bitfield type representation, the is_bitfield_expr_with_lowered_type change, which is for PR 26534. I believe these patches have an error. It looks to me like the bug is in standard_conversion in cp/calls.c at these lines if (bitfield_type) from = strip_top_quals (bitfield_type); This sets from, but fails to set fcode, resulting in an inconsistency. In this case, fcode is INTEGER_TYPE and from is now an enumeral type after originally being an integer type. This causes a failure further down in the tcode == BOOLEAN_TYPE code where we fail to match the conditions due to this inconsistency. I'd suggest opening a bug report. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Bug in g++ 4.1.2 when using inline function definied in cpp file but declared in h file
We don't track bugs reported via email. If you want to make sure you get an answer, use the bugzilla database instead. This doesn't seem to be a gcc bug though. In C++, the inline keyword is similar to what static inline means in GNU C, i.e. only emit the function if it is used. Since there is no use of the function in a.cpp, gcc does not emit it. You can see this if you compile a.cpp with -S and look at the assembler output. You can fix this by deleting the use of the inline keyword. Or you can fix it by putting the inline function definition into the a.h file instead of the a.cpp file. This way it will be visible in main.cpp when we call it, and then gcc will emit it. Or you can fix it by using pragma implementation and pragma interface as you discovered. I'm not a C++ expert. There may also be other ways to fix this. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: IEEE Math is not working on Alpha Rawhide
[EMAIL PROTECTED] wrote: checking if IEEE math works with the -mieee switch... not isnan(NaN) ... no Check config.log to see what went wrong ... The -mieee option should have worked. You will need to look at the config.log file to see what went wrong. How can I make gcc support IEEE- math on my system? It seems to be a bug, because on Kernel 2.4 I was able to compile the tool. If this worked on a different kernel with the same compiler version, then that indicates a kernel bug. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: code block simply not generated
stephane duverger wrote: Father was removed because of goto __end, simply because gcc thought that this code part will never be reached. But process is cloned() and it should have taken into account the jnz father Gcc does not look at the contents of an asm, so it does not know that there is a branch to father. Branches are not supported in asms. This is mentioned in the gcc manual. We can not get control flow correct in this case, and hence can not optimize correctly. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Couldn't install GCC properly in my cygwin!
poovizhi wrote: I've CYGWIN_NT-5.0 (1.3.22) version installed in my system. Here I try to install a fresh GCC version (GCC-3.4.6). But I don't have already any compiled version of GCC in my system. If you don't already have a compiler, then you won't be able to compile the gcc sources on your cygwin system. Download a gcc binary from the www.cygwin.com site. See the docs on this site for more info. Jim
Re: Works on dev-c..
beradero wrote: Hello, It's the code: http://www.nabble.com/file/p16128572/1.c 1.c Try enter the number 0010 (number then), 00010, etc.. and see the bizarre output.. Your code is buggy. This is an obvious string overflow problem. You can't fit a 6 character string into a 4 character array. Jim
Re: Building GCC-3.2.3 failed on i686-pc-cygwin
se7en_hills wrote: [EMAIL PROTECTED] /cygdrive/f/project/gcc_build $ make all-gcc make.exe: *** No rule to make target `Makefile.in', needed by `Makefile'. Stop. If you look in Makefile, you should find a line that reads something like Makefile: $(srcdir)/Makefile.in ... which means Makefile depends on Makefile.in. Now look for the line that defines srcdir. It should be something like srcdir = /cygdrive/f/project/gcc-3.2.3/ Apparently this line is confused, preventing make from finding $(srcdir)/Makefile.in. I see you are using a mixture of f:/project and /cygdrive/f. Maybe it would work better if you used /cygdrive/f always. You used the f:/project style when configuring, which might have confused make. You might want to look at http://cygwin.com That is probably a better place to ask cygwin questions than here. gcc-3.2.3 by the way is pretty old. You might find it easier to get help with more recent gcc versions. Jim
Re: gcc-4.3.0 configure can't identify ld 2.18 version
Yevgeniy Litvinenko wrote: I've found out that two configure scripts can not determine the linker version. These scripts are: gcc-4.3.0/libstdc++-v3/configure and gcc-4.3.0/libgomp/configure We don't track bugs mailed to the gcc-bugs mailing list. File a problem in bugzilla, or ask on gcc-help. You can find the code to extract the ld version number in the configure scripts. Try running it by hand to see what happens. Maybe you have a broken sed or awk program installed on your machine. Jim
Re: Building newlib-1.15.0 with gcc-4.3.0 for arm-elf
Mariusz Janiak wrote:
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:
Assembler messages:
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:123:
Error: SP not allowed in register list -- `stmea a1!,{v1-v7,fp,ip,sp,lr}'
../../../../../../../../newlib-1.15.0/newlib/libc/machine/arm/setjmp.S:145:
Error: SP not allowed in register list -- `ldmfd a1!,{v1-v7,fp,ip,sp,lr}'
This is an assembler error for a .S file, which means it has nothing to
do with gcc. It is either a newlib bug or a binutils bug. Probably a
newlib bug. Looks like newlib doesn't support thumb2.
By the way, we don't track bugs mailed to the gcc-bugs mailing list.
GCC bugs should be filed into bugzilla, or ask a question on the
gcc-help mailing list.
Jim
Re: can/should autoincrement get optimized away?
John Breitenbach wrote: char can't be less-than zero. However, can't make up my mind as to whether or not it should be allowed to optimize away the post-increment. It is not OK to optimize away the post-increment. This is a gcc optimization bug. Jim
Re: why - warning: array subscript is above array bounds
On 05/28/2015 12:41 PM, 田部 wrote:
gcc is, in this code, or put out a warning?
-O4 only???
-O3 and higher enables more aggressive loop unrolling. This happens in
the pass_complete_unrolli function. With -O3 or higher, the inner loop
is unrolled 12 times because the array size is 12. The array bounds
checking code then notices that the last 6 copies of the unrolled loop
body access past the end of the loop and emits warnings for them. Thus
you get 6 warnings. Without the unrolling, we don't have enough info to
generate any warnings. This is odd behaviour, but I'm not sure if it
should be a bug or not. Perhaps just an enhancement request to make it
work better.
+ cat -n bug.c
1#include stdio.h
2intary[2][12] ;
3voidfunc(intx,int y)
4{
5inti,j ;
6for(i = 0 ; i x ; i++) {
7for(j = 0 ; j y ; j++) {
8ary[i][j + y] = 0 ;
9}
10}
11}
The code is potentially unsafe, because there are no array bounds checks
in here. If I add a line
assert (x = 2 y = 6);
and include assert.h then the warnings go away at -O3.
FYI This mailing list is primarily for email from our bugzilla bug
database. It is better to file a bug into bugzilla than to send email
here, as email here isn't tracked.
Jim
Re: 10 x 1036778084 = ??
On 07/07/2016 10:07 PM, Nobby-Hirand wrote: I have just find strange answer, 10 x 1036778084 = 1777846248?? Your target has 32-bit integers. The value 1036778084 is close to the largest representable value. Multiplying by anything larger than 2 causes an overflow, and the result gets truncated. Try using %x to print hex values to see what is wrong. Or use long long instead of int to get 64-bit values. FYI With a more recent gcc version, you can compile with -fsanitize=undefined and get this: weathertop:2044$ ./a.out tmp.c:11:5: runtime error: signed integer overflow: 10 * 1036778084 cannot be represented in type 'int' FYI gcc-bugs@gcc.gnu.org is used for output from our bugzilla database. You shouldn't send email to this address. You should either send email to gcc-help or file a bug at https://gcc.gnu.org/bugzilla/ Jim
Re: Possible bug with switch when optimization is turned on.
On 12/05/2016 03:24 PM, luke B wrote: The following code seems to be correctly executed when compiled with GCC 4.4.7 and LLVM 6.1. It does not correctly compile with gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4). I created a bug report and added some info. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 Jim
Re: Problem with Factory Generated code g++ 4.x, 5.x, 6.x
On 12/18/2016 12:15 PM, Eduardo Yÿffe1nez via gcc-bugs wrote: >I wish to report a problem with g++ 4.x, g++ 5.x, g++ 6.x. I'm trying >to implement a very classic Factory Method Pattern in C++, I can do it >very easily in MS-Visual C++, but in Linux with g++ the code compiles >but I get a segmentation fault when I run it. The code is very simple >to follow and I reduced it to a very academic code example to try to >diagnose the problem. I am building with the C++11 version. It looks like a global static initializer ordering problem. You have two variables with static initializers: TResourceMap Factory::registry and BrandsFactory BrandsFactory::createThisFactory. The initializer for createThisFactory is referring to the registry variable. If the initializer for createThisFactory runs first, then it is referencing an uninitialized variable, and the code crashes. Order of global static initializers is probably unspecified or undefined. I don't have a copy of the C++ standard handy. I can reproduce the problem on linux if I put brands.cpp before resourcefactory.cpp on the link line. The code works if I put brands.cpp after resourcefactory.cpp on the link line. Changing the link order is changing the static initializer order. Jim
Re: sanitizer bug maybe.
On 07/10/2017 10:29 AM, George R Goffe via gcc-bugs wrote: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: In function ‘int __sanitizer::TracerThread(void*)’: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined struct sigaltstack handler_stack; If you are doing a build using glibc mainline, then this is FSF GCC bug 81066. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066 Jim
Re: bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint
On 04/23/2018 07:11 AM, Jason Vas Dias wrote:
I really do not think a '-Wpedantic -Wconversion' warning should
be generated for the following code, but it is
(with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :
$ echo '
typedef unsigned short U16_t;
static void f(void)
{ U16_t a = 1;
a-=1;
}' > t.C;
g...@gcc.gnu.org dropped as inappropriate. Note that gcc-bugs is output
from our bugzilla. Sending email here isn't very useful. If you want a
bug fixed, you have to open a bug report in bugzilla. You can ask gcc
questions on gcc help.
In the C language, operations on short and always performed as int, and
then converted back to short. Subtracting one may generated a negative
number, which converted to unsigned short will change its value. So the
warning seems appropriate.
Note that -Wconversion means different things in different gcc versions.
It current meaning is to warn for any implicit cast that may change a
value. This is not very useful in general, and is not an option that I
would recommend using by default. In old gcc versions, -Wconversion
warned for code that had different meaning in K C and ISO C. That was
useful, and some people used that option by default, but the option no
longer does that.
You can silence the warning by adding an explicit cast.
a = (U16_t) (a - 1);
Jim
Re: Complaint about webpage
On 7/4/19 11:08 PM, Christopher Faylor wrote: On Thu, Jul 04, 2019 at 02:44:05PM +0800, Jim Wilson wrote: On 7/3/19 8:02 PM, Tara Hamilton wrote: Every time these links show up in an email message they get archived and amplified for posterity. I wonder if that wasn't the actual intent of the OP given the template-like nature of their messages. A couple showed up to system accounts on sourceware.org too. Yes, I mentioned in another thread that this might be an SEO attempt, and that the right solution is to report them as bad actors to the search engines, but I don't know offhand how to do that. Jim
Re: Complaint about webpage
On 7/5/19 9:24 AM, Jim Wilson wrote: On 7/4/19 11:08 PM, Christopher Faylor wrote: On Thu, Jul 04, 2019 at 02:44:05PM +0800, Jim Wilson wrote: Yes, I mentioned in another thread that this might be an SEO attempt, and that the right solution is to report them as bad actors to the search engines, but I don't know offhand how to do that. I found the right google page and reported them, pointing at both of the threads that I saw. Jim
Re: Complaint about webpage
On 7/3/19 8:02 PM, Tara Hamilton wrote: I’ve just been looking at your website and I came across this webpage: https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple=9937 Unfortunately, when I click the link ‘ http://www.cuj.com/experts/2102/sutter.htm,’ it redirects me to a payday loan site. If you check the internet way back machine, you can see that the URL is actually correct given the time and date of the post. https://web.archive.org/web/20030207140937/http://www.cuj.com/experts/2102/sutter.htm I don't think we provide a way to edit old posts, and it doesn't appear to be a malicious site, so I don't see a real need to fix it. We aren't the only ones with links back to cuj.com. In general, editing all old links when domain names are sold and rebought is an intractable problem. We do maintain the documentation links though. Jim
