[Bug c/108768] New: bogus -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108768 Bug ID: 108768 Summary: bogus -Warray-bounds warnings Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mi+gcc at aldan dot algebra.com Target Milestone: --- Created attachment 54453 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54453&action=edit Test case (otpcode.c after passing preprocessor) Compiling the attached file (part of TCL-TRF package) with: gcc12 -O2 -Wall -Werror -c otpcode.i -o otpcode.o You'll get: In function 'extract', inlined from 'FlushDecoder' at otpcode.i:6170:21: otpcode.i:6262:9: error: array subscript 9 is outside array bounds of 'char[9]' [-Werror=array-bounds] 6262 | cc = s[start/8 +1]; |~^~~~ otpcode.i: In function 'FlushDecoder': otpcode.i:6131:8: note: at offset 9 into object 'b' of size 9 6131 | char b[9]; |^ In function 'extract', inlined from 'FlushDecoder' at otpcode.i:6170:21: otpcode.i:6263:9: error: array subscript 10 is outside array bounds of 'char[9]' [-Werror=array-bounds] 6263 | cr = s[start/8 +2]; |~^~~~ otpcode.i: In function 'FlushDecoder': otpcode.i:6131:8: note: at offset 10 into object 'b' of size 9 6131 | char b[9]; |^ Note, how the "start/8 + 1" is being misread as "9"...
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #14 from mi+gcc at aldan dot algebra.com --- (In reply to H.J. Lu from comment #13) > Please try binutils 2.31 branch from: > > https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/ > binutils-2_31-branch I'm sorry, I can not do that at this time -- I need to deliver the software for my employer and rebuilding the gcc suit with --disable-gold provides a work-around. I think, this bug-report -- against the compiler suit neither working with the latest release of binutils, nor warning about it -- ought to remain open for reasons I put forth in comment#4. The underlying problem with binutils deserves its own ticket, as Andrew suggests in comment#3. I think, I've given enough information for anyone to be able to reproduce the problem: 1. Build the gcc suit with the configure-arguments provided 2. Attempt to use the newly-built gfortran to build a FORTRAN program: PRINT *, "Hello World!" END I could create this ticket for you, if you insist, but you should be able to reproduce the problem yourself now. Thank you.
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #12 from mi+gcc at aldan dot algebra.com --- (In reply to H.J. Lu from comment #11) > Please show the output of: > > $ objdump -T > /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran. > so | grep corrupt Neither the stock /usr/bin/objdump nor the newer /prod/pfe/local/bin/objdump report any corruption (used grep -i just in case).
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #10 from mi+gcc at aldan dot algebra.com --- (In reply to mi+gcc from comment #9) > Is this it, for example: > > https://sourceware.org/ml/binutils/2018-08/msg00227.html Applied the patch to the 2.31 release, rebuilt/reinstalled binutils -- problem is still here...
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #9 from mi+gcc at aldan dot algebra.com --- > I said binutils 2.31 branch, not 2.31 release. The work I'm doing is meant for eventual production use. The company has swallowed the use of free software, but using _unreleased_ versions may be too much. Is there a particular patch, you want me to apply to 2.31 release? I could do that... Is this it, for example: https://sourceware.org/ml/binutils/2018-08/msg00227.html ?
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 mi+gcc at aldan dot algebra.com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|MOVED |--- --- Comment #7 from mi+gcc at aldan dot algebra.com --- (In reply to H.J. Lu from comment #6) > This sounds like > > https://sourceware.org/bugzilla/show_bug.cgi?id=23499 > > Please try binutils 2.31 branch. Actually, I have binutils-2.31 already -- the /usr/bin/as, that comes with RHEL6, does not understand the AVX2 instructions, so I had to build binutils of my own, and, of course, used the latest available: % /prod/pfe/local/bin/ld -v GNU ld (GNU Binutils) 2.31 and the ld used by gfortran (see the verbose output I posted) is a hardlink to the above: % /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld GNU ld (GNU Binutils) 2.31
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #4 from mi+gcc at aldan dot algebra.com --- (In reply to Andrew Pinski from comment #3) > This is a binutils bug, in gold. > --enable-gold > > Please report this to binutils instead. Is there a work-around, perhaps? Some additional command-line option I could give to gfortran now to avoid rebuilding/reinstalling the entire gcc with --disable-gold? (I already tried -fuse-ld=bfd to no avail.) Also, this may indeed be a binutils bug, but all I did was run configure with the advertised options -- and got an unusable Fortran compiler for my troubles... If --enable-languages=fortran is incompatible with --enable-gold, configure should've errored (or warned) right there, should it not have? If this is a known problem, then either this bug should be used to track it -- or the resolution should be DUPLICATE, with reference to the earlier bug describing the same... Thank you for the prompt response.
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #2 from mi+gcc at aldan dot algebra.com --- BTW, I'd dearly love if not a fix, then a work-around ASAP. Is there some kind of command-line option I can add to gfortran's command-line? Thanks!
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #1 from mi+gcc at aldan dot algebra.com --- Invoking gfortran with -v I get the following details: Driving: gfortran -v -o xscblat1 c_sblat1.o c_sblas1.o ../lib/cblas_LINUX.a -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --enable-cxx --enable-alloca --prefix=/prod/pfe/local --with-gmp=/prod/pfe/local --with-mpfr=/prod/pfe/local --with-mpc=/prod/pfe/local --enable-valgrind-tests --with-system-libz --with-gcc-major-version-only --enable-lto --enable-gold --enable-ld --enable-libssp --with-pkgversion=Misha@Local --with-as=/prod/pfe/local/bin/as --enable-languages=c,c++,fortran,lto,jit,objc --enable-vtable-verify --enable-gnu-indirect-function --enable-initfini-array --enable-host-shared Thread model: posix gcc version 8.2.0 (Misha@Local) Reading specs from /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-o' 'xscblat1' '-shared-libgcc' '-mtune=generic' '-march=x86-64' COMPILER_PATH=/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/:/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/:/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/lib/:/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-o' 'xscblat1' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/collect2 -plugin /prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/liblto_plugin.so -plugin-opt=/prod/pfe/local/libexec/gcc/x86_64-pc-linux-gnu/8/lto-wrapper -plugin-opt=-fresolution=/tmp/ccKgaJkR.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o xscblat1 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/crtbegin.o -L/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8 -L/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/lib -L/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../.. c_sblat1.o c_sblas1.o ../lib/cblas_LINUX.a -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/crtend.o /usr/lib/../lib64/crtn.o /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld: /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so: _edata: invalid version 21 (max 4) /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld: /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so: error adding symbols: bad value collect2: error: ld returned 1 exit status
[Bug fortran/87341] New: gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 Bug ID: 87341 Summary: gfortran can not link executables: _edata: invalid version 21 (max 4) Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mi+gcc at aldan dot algebra.com Target Milestone: --- The entire gcc-8.2 configured with the following: ./configure --enable-cxx --enable-alloca --prefix=/prod/pfe/local --with-gmp=/prod/pfe/local --with-mpfr=/prod/pfe/local --with-mpc=/prod/pfe/local --enable-valgrind-tests --with-system-libz --with-gcc-major-version-only --enable-lto --enable-gold --enable-ld --enable-libssp --with-pkgversion=Misha@Local --with-as=/prod/pfe/local/bin/as --enable-languages=c,c++,fortran,lto,jit,objc --enable-vtable-verify --enable-gnu-indirect-function --enable-initfini-array --enable-host-shared The resulting C++ and C compilers both seem to work well. Gfortran also creates object files with ease, however linking the executables (and the shared libraries) fails thus: gfortran -o xscblat1 c_sblat1.o c_sblas1.o ../lib/cblas_LINUX.a /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld: /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so: _edata: invalid version 21 (max 4) /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld: /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so: error adding symbols: bad value
[Bug middle-end/62029] New: Requesting new warning: missing const-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62029
Bug ID: 62029
Summary: Requesting new warning: missing const-qualifier
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mi+gcc at aldan dot algebra.com
To help facilitate "const-poisoning" of the entire body of C (and C++) code out
there, I'd like to see a new warning, that would fire, when a pointer to any
object in any scope, that could've been marked as "const", is not.
For example:
size_t
mylen(char *string)
{
if (string == NULL)
return 0;
else
return strlen(string);
}
void
example(struct object *o)
{
char *text = get_text(o);
size_t len = mylen(text);
}
The above code would warn in mylen, because the function's parameter could be
made const. As the developer fixes the low-level function to address the
warning, the higher level callers of these functions (such as example()) will
start warning -- and that will be a beautiful thing...
Some day the warning may even become part of -Wall.
[Bug c/42643] "may be used uninitialized" compiled with "-Wall -O"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42643 --- Comment #2 from mi+gcc at aldan dot algebra.com 2012-01-06 20:08:54 UTC --- Created attachment 26259 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26259 Live test case (file from Mozilla's NSS package) Even when using gcc-4.6 (more specifically gcc version 4.6.3 2004 (prerelease) (FreeBSD Ports Collection)), I still get a bogus warning on the attached file, unless the optimization level is at -O3 AND the -fPIC is not specified: mi@narawntapu:nss/lib/util (1778) gcc46 -Wall -O3 -c nssb64e.i mi@narawntapu:nss/lib/util (1779) gcc46 -Wall -O2 -c nssb64e.i nssb64e.i: In function 'NSSBase64_EncodeItem_Util': nssb64e.i:3239:15: warning: 'out_len' may be used uninitialized in this function [-Wuninitialized] mi@narawntapu:nss/lib/util (1780) gcc46 -Wall -O3 -fPIC -c nssb64e.i nssb64e.i: In function 'NSSBase64_EncodeItem_Util': nssb64e.i:3239:15: warning: 'out_len' may be used uninitialized in this function [-Wuninitialized]
