[Bug c++/28448] New: doc reference to -fdiagnostics-show-options looks like it should be -fdiagnostics-show-option
docs describe:
http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html#Language-Independent-Options
-fdiagnostics-show-options
This option instructs the diagnostic machinery to add text to each
diagnostic emitted, which indicates which command line option directly controls
that diagnostic, when such an option is known to the diagnostic machinery.
however, it appears that the option name is actually:
-fdiagnostics-show-option
and an attempt to use options (plural) yields:
cc1plus: error: unrecognized command line option "-fdiagnostics-show-options"
g++ -v output:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1.1/configure --enable-threads=posix
--prefix=/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1 --enable-languages=c,c++
--enable-shared --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.1
/view/peeterj_hc/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.1.1/cc1plus
-quiet -v -iprefix
/view/peeterj_hc/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.1.1/
-D_GNU_SOURCE t.c -quiet -dumpbase t.c -mtune=k8 -auxbase t -version
-fdiagnostics-show-options -o /home/peeterj/tmp/cc7r36nu.s
cc1plus: error: unrecognized command line option "-fdiagnostics-show-options"
ignoring nonexistent directory
"/view/peeterj_hc/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../include/c++/4.1.1"
ignoring duplicate directory
"/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../include/c++/4.1.1/x86_64-unknown-linux-gnu"
ignoring duplicate directory
"/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../include/c++/4.1.1/backward"
ignoring duplicate directory
"/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/include"
ignoring nonexistent directory
"/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/view/peeterj_hc/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../include/c++/4.1.1
/view/peeterj_hc/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../include/c++/4.1.1/x86_64-unknown-linux-gnu
/view/peeterj_hc/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../include/c++/4.1.1/backward
/view/peeterj_hc/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.1.1/include
/usr/local/include
/vbs/bldsupp.linux1/linuxamd64/gcc4.1.1/include
/usr/include
End of search list.
GNU C++ version 4.1.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 3.3.3 (SuSE Linux).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
sample source code and command line:
gcc4.1.1/bin/g++ -fdiagnostics-show-options -c t.c
t.c:
int main(){}
--
Summary: doc reference to -fdiagnostics-show-options looks like
it should be -fdiagnostics-show-option
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peeterj at ca dot ibm dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28448
[Bug c++/31309] New: g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
Description:
Code includes two structures, a 6 byte struct of the following form:
struct 6bytes { char [2] ; char [4] }
and another that embeds this at the very end in the following form:
struct { bool ; bool ; 6bytes } ;f
compiler is generating code for assignment to the trailing 6byte struct using
an 8 byte read from that address, then merging in the value to be assigned, and
finally writing back 8 bytes.
If this structure is allocated from memory where this 8 byte sequence is not
accessable (ie: at the end of a shmat memory region for example), this results
in a trap. When the memory is accessable the compiler generated code does
happen to retain the value that follows the structure being accessed, but even
if the 2 bytes of memory trailing the structure is accessable, this generated
code that modified memory outside of the structure is not thread safe.
This has been observed with GCC 4.2 prerelease compilers, but not GCC 3.3.3. I
don't know if the issue applies to 4.1 or 4.0 compilers too.
host/target/build triplets provided above. Other info:
>Release: gcc (GCC) 4.2.0 20070317 (prerelease)
>Environment:
System: Linux hotel09 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005
x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64
configured with: ../gcc-4.2.0-20070316/configure
--prefix=/vbs/bldsupp.linux1/linuxamd64/gcc-4.2.0-20070316
--enable-threads=posix --enable-languages=c,c++ --enable-shared
--enable-__cxa_atexit
>How-To-Repeat:
Sample code will be attached. This forces the memory following the structure
to be unreadable by calling mprotect.
Build command of the form:
/view/peeterj_gcc-4.2.0-20070316-decfloat/vbs/bldsupp/linuxamd64/gcc-4.2.0/bin/g++
-O0 x.C
-Wl,-rpath,/view/peeterj_gcc-4.2.0-20070316-decfloat/vbs/bldsupp/linuxamd64/gcc-4.2.0/lib64
-o ./xx
(-rpath gunk is because I don't have the runtime locally installed)
The following gdb session demonstrates the issue (but will make more sense when
looking at the code).
hotel09:/vbs/engn/squ> gdb x
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...Using host libthread_db
library "/lib64/tls/libthread_db.so.1".
(gdb) run
Starting program: /vbs/engn/squ/x
[Thread debugging using libthread_db enabled]
[New Thread 183048206464 (LWP 18902)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 183048206464 (LWP 18902)]
0x00400edf in XXX::Initialize (this=0x7fbfff8ff8, iIndex=0) at x.C:51
51 pDictRidderInfo->dRID = INIT_6_BYTES_ZERO();
(gdb) disassemble $rip $rip+30
Dump of assembler code from 0x400edf to 0x400efd:
0x00400edf <_ZN3XXX10InitializeEi+71>: mov0xa(%rbx),%rcx
0x00400ee3 <_ZN3XXX10InitializeEi+75>: mov
%rcx,0xffd0(%rbp)
0x00400ee7 <_ZN3XXX10InitializeEi+79>: movzbq %dl,%rcx
0x00400eeb <_ZN3XXX10InitializeEi+83>: mov
0xffd0(%rbp),%rdx
0x00400eef <_ZN3XXX10InitializeEi+87>: mov$0x0,%dl
0x00400ef1 <_ZN3XXX10InitializeEi+89>: or %rcx,%rdx
0x00400ef4 <_ZN3XXX10InitializeEi+92>: mov
%rdx,0xffd0(%rbp)
0x00400ef8 <_ZN3XXX10InitializeEi+96>: mov
0xffd0(%rbp),%rdx
0x00400efc <_ZN3XXX10InitializeEi+100>: mov%rdx,0xa(%rbx)
End of assembler dump.
(gdb) p $rbx
$1 = 548682059760
(gdb) p (void*)$rbx+0xa+6
$2 = (void *) 0x7fbfffd000
>Fix:
Enabling optimization -O2 works around the issue, but the builds that we want
to do with gcc-4.2 are development (-g) builds so -O isn't a natural fit.
--
Summary: g++ 4.2.0 amd64 codegen issue with -O0. 6 byte
assignment at end of structure reads/writes past end of
structure causing SEGV when that memory is not
accessable.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peeterj at ca dot ibm dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug c++/31309] g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #1 from peeterj at ca dot ibm dot com 2007-03-22 04:28 --- Created an attachment (id=13251) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13251&action=view) source code that demonstrates the code generation issue described. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug c++/34859] New: g++ -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS causes error
Have a situation where some ugly make recursion is causing -D related cflags for compilation to be duplicated (only for one file out of thousands) When that duplication happens to include -D__STDC_LIMIT_MACROS the g++ 4.3 (using 20080111 snapshot) ends up with the following error: : error: "__STDC_LIMIT_MACROS" redefined : error: this is the location of the previous definition Can reproduce this as follows: rm -rf r.C touch r.C gcc-4.3-20080111/bin/g++ -c -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS r.C Other -D values do not appear to cause any sort of trouble. Example: gcc-4.3-20080111/bin/g++ -c -D__BLAH -D__BLAH r.C gcc-4.3-20080111/bin/g++ -c -DXXX -DXXX r.Cvim h But it appears that duplicate -D statements for anything that starts with -D__STDC_ causes this error (-D__STDC is okay). Any explaination for the special casing of the flags that start with __STDC_? This behaviour has not been observed with g++ 4.2 or lower. -- Summary: g++ -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS causes error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peeterj at ca dot ibm dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34859
[Bug c++/34862] New: operator new placement varient with reference arg not accepted by g++ 4.3
Have a class that defines a placement new like varient that updates a pointer
to raw storage via a reference argument. Here's a stripped down code fragment:
#include // size_t
class T
{
public:
void *operator new(size_t size, char *&p);
T( int &rc);
} ;
void *T::operator new(size_t size, char *&p)
{
void *o;
o = (void *) p;
p += size;
return(o);
}
T * f ( char *& cur_vardatap )
{
int rc ;
T * subTypep = new((char *&)cur_vardatap)
T( rc );
return subTypep ;
}
If I build this code with GCC4.3 it doesn't want to generate code that calls
it:
r2.C: In function 'T* f(char*&)':
r2.C:29: error: no matching function for call to 'T::operator new(long unsigned
int, char*)'
r2.C:13: note: candidates are: static void* T::operator new(size_t, char*&)
This code seems a bit fishy to me (casting the input parameter to a reference
type seems odd, and I'm wondering if that cast was added because some other
compiler wouldn't call this operator new either).
This can be worked around this easily enough by changing the code in question
to call global placement new and then increment cur_vardatap by sizeof(T)
afterwards (this specialized new operator is only called in two places so in
all honesty I don't know why the original developer bothered doing all this).
However, regardless of whether this is recoded, is GCC4.3 is correct rejecting
this, or is this a GCC 4.3 regression? GCC 4.2 and previous compilers accept
this syntax (as do a number of other compilers, IBM xlC, Sun WSPro, intel icpc,
msdev, ...)
--
Summary: operator new placement varient with reference arg not
accepted by g++ 4.3
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peeterj at ca dot ibm dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug c++/34859] g++ -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS causes error
--- Comment #1 from peeterj at ca dot ibm dot com 2008-01-18 23:06 ---
I see the two places in the code that look like they are related:
./libcpp/macro.c:1698: if (! ustrncmp (NODE_NAME (node), DSC ("__STDC_"))
./libcpp/macro.c:1699: && ustrcmp (NODE_NAME (node), (const uchar *)
"__STDC_FORMAT_MACROS"))
./libcpp/directives.c:2158: if (! ustrncmp (NODE_NAME (node), DSC
("__STDC_")))
The first of these excludes __STDC_FORMAT_MACROS (inttypes.h) so perhaps should
also do this for __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS of stdint.h
too? If that's the case, perhaps these same exclusions should be in
directives.h too (since I don't know the code I'm only guessing).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34859
[Bug c++/34859] g++ -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS causes error
--- Comment #4 from peeterj at ca dot ibm dot com 2008-01-19 05:19 --- My snapshot already has that fix. That one was only for __STDC_FORMAT_MACROS which is for . There's two more such macros for stdint.h (__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS) to access various bits of that file. I privately made the same sort of change to macro.c and directive.c for all three and it handled the issue ... however, given that other bug report it sounds like just the macro.c part of that change would be sufficient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34859
[Bug middle-end/31309] [4.1 regression] reads/writes past end of structure
--- Comment #26 from peeterj at ca dot ibm dot com 2008-01-21 20:00 --- (In reply to comment #25) > I don't plan to backport this to the 4.1 branch. > Thanks for both fixing this and backporting to 4.2! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug c++/31309] g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #4 from peeterj at ca dot ibm dot com 2007-06-27 14:49 --- removing Taavi from the CC list. Any update on getting this resolved? -- peeterj at ca dot ibm dot com changed: What|Removed |Added CC|taavib at ca dot ibm dot com| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug middle-end/31309] 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #11 from peeterj at ca dot ibm dot com 2008-01-02 23:09 --- I see that this bug fix is targetted for 4.1.3, but also see that such a release isn't planned: http://gcc.gnu.org/ml/gcc/2007-05/msg00669.html should the target release for this bug be updated to 4.2 or 4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug middle-end/31309] 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #13 from peeterj at ca dot ibm dot com 2008-01-03 15:26 --- It's a regression relative to gcc version 3.3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug middle-end/31309] [4.1/4.2 regression] reads/writes past end of structure
--- Comment #22 from peeterj at ca dot ibm dot com 2008-01-16 00:04 --- re: Fixed on the mainline. I'm not sure we want to put this on the other branches. Not knowing the gcc code in question, I can't comment on how much potential regression risk this fix will introduce. Assuming it's safe enough to apply without worry to other releases, I'd hope this would also be applied also to gcc-4.2 . The 4.2 version is what we were attempting to use when the bug was encountered, and switching to 4.3 at this point would likely be more destabilizing than the original bug (as well as potentially being a porting exersize as has traditionally been the case between major compiler revisions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
