[Bug c/57862] New: invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 Bug ID: 57862 Summary: invalid read struct uint32_t member (ARMV5) Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mendola at gmail dot com Created attachment 30481 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30481&action=edit The preprocessed file # uname -a Linux tqma28 2.6.35.3 #1 PREEMPT Sun Sep 11 17:38:39 CEST 2011 armv5tejl GNU/Linux # gcc-4.7 -v -save-temps main.c -march=armv5t Using built-in specs. COLLECT_GCC=gcc-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.7/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv4t --with-float=soft --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-march=armv5t' '-mfloat-abi=soft' '-mtls-dialect=gnu' /usr/lib/gcc/arm-linux-gnueabi/4.7/cc1 -E -quiet -v -imultilib . -imultiarch arm-linux-gnueabi main.c -march=armv5t -mfloat-abi=soft -mtls-dialect=gnu -fpch-preprocess -o main.i ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabi" ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/arm-linux-gnueabi/4.7/include /usr/local/include /usr/lib/gcc/arm-linux-gnueabi/4.7/include-fixed /usr/include/arm-linux-gnueabi /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-march=armv5t' '-mfloat-abi=soft' '-mtls-dialect=gnu' /usr/lib/gcc/arm-linux-gnueabi/4.7/cc1 -fpreprocessed main.i -quiet -dumpbase main.c -march=armv5t -mfloat-abi=soft -mtls-dialect=gnu -auxbase main -version -o main.s GNU C (Debian 4.7.2-5) version 4.7.2 (arm-linux-gnueabi) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=15631 GNU C (Debian 4.7.2-5) version 4.7.2 (arm-linux-gnueabi) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=15631 Compiler executable checksum: da7c3c2f0b4be4af23076cf3c1dfbf58 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-march=armv5t' '-mfloat-abi=soft' '-mtls-dialect=gnu' as -v -march=armv5t -mfloat-abi=soft -meabi=5 -o main.o main.s GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Debian) 2.22 COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.7/:/usr/lib/gcc/arm-linux-gnueabi/4.7/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.7/:/usr/lib/gcc/arm-linux-gnueabi/ LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.7/:/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../:/lib/arm-linux-gnueabi/:/lib/:/usr/lib/arm-linux-gnueabi/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-march=armv5t' '-mfloat-abi=soft' '-mtls-dialect=gnu' /usr/lib/gcc/arm-linux-gnueabi/4.7/collect2 --sysroot=/ --build-id --no-add-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.3 -X --hash-style=both -m armelf_linux_eabi /usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi/crt1.o /usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi/crti.o /usr/lib/gcc/arm-linux-gnueabi/4.7/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabi/4.7 -L/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi -L/usr/lib/gcc/arm-linux-gnueabi/4.7/../../.. -L/lib/arm-linux-gnueabi -L/usr/lib/arm-linux-gnueabi main.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabi/4.7/crtend.o /usr/lib/gcc/arm-linux-gnueabi/4.7/../../../arm-linux-gnueabi/crtn.o This is the following output executing it: # ./a.out myInAddr.s_addr: 513 theIpHeader->daddr: 513 1.2.3.4 1.2.0.0 and that 1.2.
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #2 from Gaetano Mendola --- I had 0. Putting 2 or 3 fixed the problem. Now my question is: who is faulty? Kernel configuration on this platform, the architecture, the compiler or even me ? BTW, compiling that code with clang even with 0 in /proc/cpu/alignment gives the right "result".
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #4 from Gaetano Mendola --- At this point I'm very puzzled. The fact I have to use memcpy instead of an assignment for sake of portability is plain wrong. Consider that only looking at: struct in_addr myInAddr; myInAddr.s_addr = theIpHeader->daddr; I have no idea if the theIpHeader pointer was the result of a malloc or the result of an assignment with a not aligned offset. Unless of course I inspect the pointer value. The entire application (my application) suppose, as I think it should, that an assignment of a value retrieved from a structure member is correctly done, note that I'm not relying if this is done with 1 bus access, 2 or whatever. I'm going to put 2 in /proc/cpu/alignment and considering it as a kernel configuration problem. btw clang behaves correctly even with a "kernel not well configured".
[Bug c/57862] invalid read struct uint32_t member (ARMV5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57862 --- Comment #6 from Gaetano Mendola --- That's clear to me. I'm writing in C not in assembler, what I'm trying to understand is if I have to threat the following code: struct in_addr myInAddr; myInAddr.s_addr = theIpHeader->daddr; as not portable, where myInAddr.s_addr and theIpHeader->daddr are of the same type. I'm not a c-standard lawyer but I'm hard believing that in the standard that assignment is marked as: "undefined behaviour" unless you use memcpy. And again printf-ing the two values, both are reported on screen as the same number but the bytes behind that area of memory do not contain the same values.
[Bug c++/58333] New: "performance" regression when using -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58333
Bug ID: 58333
Summary: "performance" regression when using -std=c++0x
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mendola at gmail dot com
Created attachment 30753
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30753&action=edit
Preprocessed files (with and without -std=c++0x)
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
I'm attaching the preprocessed file, using or not the -std=c++0x, what you can
see in the following test case that if compiled with -std=c++0x the
"benchmarked" piece of code runs 1.5 seconds slower (8.9 seconds vs 10.4
seconds).
If in the code the "chrono" call is removed then with or without -std=c++0x the
running time are the same.
#include
#include
#include
#include
int main() {
cpu_set_t myAffinityMask;
CPU_ZERO( &myAffinityMask );
CPU_SET(0, &myAffinityMask );
sched_setaffinity(0, sizeof(myAffinityMask), &myAffinityMask);
volatile float* myMemoryA = new float[(1<<24)];
volatile float* myMemoryB = new float[(1<<24)];
struct timeval myStart;
struct timeval myStop;
struct timeval myResult;
gettimeofday(&myStart, 0);
for (size_t i = 0; i < (1<<24); ++i) {
myMemoryA[i] = i;
myMemoryB[i] = i+1;
}
delete []myMemoryA;
delete []myMemoryB;
for (size_t j = 0; j < 100; ++j) {
volatile float* myMemoryA = new float[(1<<24)];
volatile float* myMemoryB = new float[(1<<24)];
for (size_t i = 0; i < (1<<24); ++i) {
myMemoryA[i] *= sqrtf(myMemoryB[i]);
}
delete []myMemoryA;
delete []myMemoryB;
}
gettimeofday(&myStop, 0);
timersub(&myStop,&myStart,&myResult);
std::cout << "Time: " << myResult.tv_sec*1000 + myResult.tv_usec/1000.0 <<
std::endl;
boost::chrono::time_point t1 =
boost::chrono::high_resolution_clock::now();
std::cout << "t1: " << t1 << std::endl;
}
[Bug c++/55449] New: [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449
Bug #: 55449
Summary: [4.4.3] pure virtual call only with -O1/2/3
(boost::optional)
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mend...@gmail.com
Created attachment 28765
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28765
test case + preprocessor output
The following code generates a pure virtual method call only when compiled with
-O1/O2/O3, the same code seems working without error with gcc 4.7.3.
The code is inlined in here and I have attached an archive containing the
preprocessor output as well.
Consider that it doesn't crash if:
- Remove the noncopyable from B
or
- Remove one of the two segments in the extra scope in main
or
- Remove the try { } catch
I have tried with boost 1.40, 1.50 and 1.52
#include
#include
class B : boost::noncopyable { //if the noncopyable is removed works
public:
virtual size_t bar() const = 0;
};
class D : public B {
public:
D()
:theBar(foo(10))
{ }
virtual size_t bar() const {
return theBar;
}
private:
static size_t foo(const boost::optional a) {
if (a) { //if this is a.is_initialized() then it works
return a.get();
}
return 2;
}
const size_t theBar;
};
class Foo {
public:
Foo(const B& b)
:theBar(b.bar() * b.bar())
{ }
private:
const size_t theBar;
};
int main()
{
{ //if this section is removed works
D d;
try {
Foo myCompound(d);
} catch(...) {}
}
{
D d;
try {
Foo myCompound(d);
} catch(...) {}
}
}
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #3 from Gaetano Mendola 2012-11-24 06:27:06 UTC --- Time to adopt ICC.
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #5 from Gaetano Mendola 2012-11-24 06:57:16 UTC --- I have no problem to pay someone, I'm a bit disappointed seeing a bug closed because "new version works" without investigate if the problem is still there in new versions but not triggered by my test case. Also if 4.4.3 is not supported why while submitting the bug I was able to target the 4.4.3?
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #8 from Gaetano Mendola 2012-11-24 12:25:35 UTC --- Jonathan, I have nothing against you personaly, what you wrote is: "GCC 4.4 is no longer supported, and the problem *seems* to be already fixed in current releases." and doesn't exactly show that you have investigate, I have also stated that with 4.7.3 works. Actualy the code I have submitted was tailored already I couldn't shrink more than I did. To be honest with the real code instead to have a "pure virtual call" I had a simple core with gdb finding bogus data in the core, that was the smallest test I was able to make it reproducible. About the fact I didn't post the g++ -v output you are right, I have issued the command "g++ -v -save-temps ..." but somehow the output get lost in the archive attached. If you are interested in the output I will provide it. About the fact to pay you to find the patch/commit correcting it just send me a commercial proposal to my email address. Thank you for your time. Regards Gaetano Mendola
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #10 from Gaetano Mendola 2012-11-24 17:49:41 UTC --- (In reply to comment #9) > (In reply to comment #8) > > Jonathan, I have nothing against you personaly, what you wrote is: > > > > "GCC 4.4 is no longer supported, and the problem *seems* to be already > > fixed in > > current releases." > > > > and doesn't exactly show that you have investigate, I have also stated that > > with 4.7.3 works. > > I investigated and couldn't find anything conclusive, so I said "seems" > because > I wasn't certain. > > If you assume I didn't investigate and reply with "time to adopt ICC" then > feel > free to do so, I don't volunteer my time to GCC for people with that attitude. Well, I have to admit that was a poor and over reacted reply from my side, but as you spent your time to investigate the issue I have spent my time to understand why it was happening and some hours, no kidding, to shrink it as much I could to create the test case I have submitted, as you can see that code is useful to nothing. I was frustrated to see a short "it work/fixed in current release" after having work half noon to submit it, the fast it was working with a new gcc release was an information I already knew it, I'd expect something on the line: "o yes, it was an old bug we have already corrected", that's why I have submitted the bug not to drive someone else trying the same I did. As you can see from my first post I have tried to shrink more than that, and each piece I was removing was then making the test "passing". > I'm not interested, the point is you provided an incomplete bug report but are > then happy to complain about the effort put in by people who look at it. I'm not happy to complain, why would I? I'm happy when stuff works and when a submitted bug was a real bug helping to improve gcc quality. When I submitted it, for me the bug report was not incomplete otherwise I wouldn't have submitted it, I did follow the guide and the only piece missing, my fault, was the output of g++ -v -save-temps because I forgot to redirect the output to a file. I would have provided it immediately if you would have pointed it out earlier. > The bug was fixed by http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html so is > fixed in 4.5.0 and later Thank you for it. May I say now then: "time to upgrade gcc" ? I'm sorry it was not my intention to hurt anyone.
[Bug c++/45385] New: -Wconversion fails to detect a real conversion loss
Hi,
compiling the following code with -Wconversion doesn't give a warning while
with compiler version 4.3.2 does. As you can verify the posted code has a real
conversion loss at runtime giving:
expected: 80
obtained: 3705032704
=
#include
void foo(unsigned int a) { std::cout << "obtained: " << a << std::endl; }
class Test {
public:
void eval() {
foo(bar());
}
private:
unsigned long long bar() const {
unsigned long long ret = 80;
std::cout << "expected: " << ret << std::endl;
return ret;
}
};
int main () {
Test t;
t.eval();
return 1;
}
=
--
Summary: -Wconversion fails to detect a real conversion loss
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mendola at gmail dot com
GCC build triplet: 4.4.3
GCC host triplet: 4.4.3
GCC target triplet: 4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45385
