>
> If the initializer is constant, but the member value that's being
> initialized has a
> non-trivial constructor with a side effect, your patch will inhibit the
> warning
> but the program will not behave the same as if reordering had not happened.
>
> Peter
>
Yes. It sounds unlikely. But not
Quoting Daniel Marjamäki :
Yes. It sounds unlikely. But not impossible of course. I could also
make sure the member variables are POD types before I inhibit the
warning. I just have no idea how I check if a member is POD. But I
could investigate this.
You could check if it has a constructor, u
On Fri, 15 Jul 2011, Ian Lance Taylor wrote:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1. This means that the gcc i
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
Joern,
Thanks for your valuable feedback! This is only a RFC, and I will send out
formal patch along with ChangLog later on.
Basically, my patch is only to add new dependence in scheduler, and it only
blocks some instruction movements, so it is NO RISK to compiler correctness.
For whatever st
Hello All,
I compiled a simple 1.c file with -mpcu=e500mc64 option and while
trying to create a relocatable, i am getting the following error:
$powerpc-elf-ld.exe -static -r 1.o
powerpc-elf-ld.exe: Relocatable linking with relocations from format
elf64-powerpc (1.o) to format elf32-powerpc (a.out