[Bug target/52187] armeb-unknown-eabi not recognized as big-endian

2013-02-15 Thread sethml at google dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52187



Seth LaForge sethml at google dot com changed:



   What|Removed |Added



 CC||sethml at google dot com



--- Comment #5 from Seth LaForge sethml at google dot com 2013-02-15 18:34:41 
UTC ---

Patch submitted:

http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00785.html


[Bug target/56351] New: ARM Big-Endian: storing local double to packed variable causes corruption

2013-02-15 Thread sethml at google dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56351

 Bug #: 56351
   Summary: ARM Big-Endian: storing local double to packed
variable causes corruption
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: set...@google.com


Created attachment 29478
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29478
Test case which demonstrates incorrect codegen

The attached code behaves incorrectly on my platform with gcc 4.7.2.  In
particular, the output is:

val is: 1.234567 (0x3FF3C0C9:539B8887)
Calling PrintAndStoreUnaligned:
57432423068808260924249171392224224725059031612325630140261797720764832869069412330679690067968.00
(0x539B8887:3FF3C0C9)
unaligned_double.val is:
57432423068808260924249171392224224725059031612325630140261797720764832869069412330679690067968.00
(0x539B8887:3FF3C0C9)

It appears that storing a double parameter into an unaligned variable can cause
all accesses to that parameter within the function to have the upper and lower
32 bits swapped.

This code is being built for a TI TMS570-series processor, although I suspect
the problem would occur with any big-endian ARM target with VFPv3
floating-point support.  Here's compiler info.  To build the compiler with
these flags requires a minor patch:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00791.html

% third_party/car/embedded/toolchains/gcc_tms570/bin/armeb-unknown-eabi-gcc -v
-save-temps -O1 -c gcc_bug.c -o gcc_bug.o -Wa,-adhlsn=gcc_bug.lst
Using built-in specs.
COLLECT_GCC=third_party/car/embedded/toolchains/gcc_tms570/bin/armeb-unknown-eabi-gcc
Target: armeb-unknown-eabi
Configured with: ../gcc-4.7.2/configure
--prefix=/usr/local/google/armeb/toolchain --build=x86_64-cross-linux-gnu
--target=armeb-unknown-eabi --host=x86_64-cross-linux-gnu
--with-sysroot=/usr/local/google/armeb/sysroot --with-newlib
--with-headers=../newlib-1.19.0/newlib/libc/include --disable-nls
--enable-languages=c,c++ --enable-c99 --enable-long-long
--with-mpfr=/usr/local/google/armeb/toolchain
--with-gmp=/usr/local/google/armeb/toolchain
--with-mpc=/usr/local/google/armeb/toolchain --disable-multilib
--with-abi=aapcs --with-arch=armv7-r --with-mode=thumb --with-float=hard
--with-fpu=vfpv3-d16 --disable-threads --disable-shared --disable-libgomp
--disable-libmudflap --disable-libssp
Thread model: single
gcc version 4.7.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-c' '-o' 'gcc_bug.o'
'-march=armv7-r' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mabi=aapcs' '-mthumb'

/google/src/cloud/sethml/head2/google3/third_party/car/embedded/toolchains/gcc_tms570/bin/../libexec/gcc/armeb-unknown-eabi/4.7.2/cc1
-E -quiet -v -iprefix
/google/src/cloud/sethml/head2/google3/third_party/car/embedded/toolchains/gcc_tms570/bin/../lib/gcc/armeb-unknown-eabi/4.7.2/
-D__USES_INITFINI__ gcc_bug.c -march=armv7-r -mfloat-abi=hard -mfpu=vfpv3-d16
-mabi=aapcs -mthumb -O1 -fpch-preprocess -o gcc_bug.i
ignoring duplicate directory
/google/src/cloud/sethml/head2/google3/third_party/car/embedded/toolchains/gcc_tms570/bin/../lib/gcc/../../lib/gcc/armeb-unknown-eabi/4.7.2/include
ignoring nonexistent directory
/usr/local/google/armeb/sysroot/usr/local/include
ignoring duplicate directory
/google/src/cloud/sethml/head2/google3/third_party/car/embedded/toolchains/gcc_tms570/bin/../lib/gcc/../../lib/gcc/armeb-unknown-eabi/4.7.2/include-fixed
ignoring duplicate directory
/google/src/cloud/sethml/head2/google3/third_party/car/embedded/toolchains/gcc_tms570/bin/../lib/gcc/../../lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/include
#include ... search starts here:
#include ... search starts here:

/google/src/cloud/sethml/head2/google3/third_party/car/embedded/toolchains/gcc_tms570/bin/../lib/gcc/armeb-unknown-eabi/4.7.2/include

/google/src/cloud/sethml/head2/google3/third_party/car/embedded/toolchains/gcc_tms570/bin/../lib/gcc/armeb-unknown-eabi/4.7.2/include-fixed

/google/src/cloud/sethml/head2/google3/third_party/car/embedded/toolchains/gcc_tms570/bin/../lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/include
 /usr/local/google/armeb/sysroot/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-c' '-o' 'gcc_bug.o'
'-march=armv7-r' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mabi=aapcs' '-mthumb'

/google/src/cloud/sethml/head2/google3/third_party/car/embedded/toolchains/gcc_tms570/bin/../libexec/gcc/armeb-unknown-eabi/4.7.2/cc1
-fpreprocessed gcc_bug.i -quiet -dumpbase gcc_bug.c -march=armv7-r
-mfloat-abi=hard -mfpu=vfpv3-d16 -mabi=aapcs -mthumb -auxbase-strip gcc_bug.o
-O1 -version -o gcc_bug.s
GNU C (GCC) version 4.7.2 (armeb-unknown-eabi)
compiled by GNU C version 4.6.x-google 20120601 (prerelease), GMP
version 5.0.5, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param 

[Bug target/56351] ARM Big-Endian: storing local double to packed variable causes corruption

2013-02-15 Thread sethml at google dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56351



--- Comment #1 from Seth LaForge sethml at google dot com 2013-02-15 20:16:43 
UTC ---

Ugh, my attachment was a bit mangled.  Here's the source to stimulate the issue

- gcc_bug.c:



#include stdio.h



void PrintDouble(double v) __attribute__((noinline));

void PrintDouble(double v) {

  union { double d; int i[2]; } u = { v };

  printf(%f (0x%08X:%08X), v, u.i[0], u.i[1]);

}



struct { double val; } __attribute__((packed)) unaligned_double;



void PrintAndStoreUnaligned(double v) __attribute__((noinline));

void PrintAndStoreUnaligned(double v) {

  PrintDouble(v);

  unaligned_double.val = v;

}



int main() {

  double val = 1.234567;

  printf(val is: );

  PrintDouble(val);

  printf(\nCalling PrintAndStoreUnaligned: );

  PrintAndStoreUnaligned(val);

  printf(\nunaligned_double.val is: );

  PrintDouble(unaligned_double.val);

  printf(\n);

  return 0;

}


[Bug target/56351] ARM Big-Endian: storing local double to packed variable causes corruption

2013-02-15 Thread sethml at google dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56351



Seth LaForge sethml at google dot com changed:



   What|Removed |Added



 CC||sethml at google dot com



--- Comment #3 from Seth LaForge sethml at google dot com 2013-02-15 22:43:56 
UTC ---

Thank you Andrew, super useful pointer!  Yes, that patch does appear to fix my

problem.  I've backported it to gcc 4.7 and posted a patch:

http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00800.html



With gcc 4.7.2 with my/Julian's patch, I get correct code:



  43PrintAndStoreUnaligned:

  46 0020 B538push  {r3, r4, r5, lr}

  47 0022 EC523B10fmrrd r3, r2, d0

  48 0026 4614mov r4, r2

  49 0028 461Dmov r5, r3

  50 002a 4622mov r2, r4

  51 002c EC423B10fmdrr d0, r3, r2

  52 0030 F7FEbl  PrintDouble

  53 0034 F2400300movw  r3, #:lower16:unaligned_double

  54 0038 F2C00300movt  r3, #:upper16:unaligned_double

  55 003c 605Dstr r5, [r3, #4]

  56 003e 601Cstr r4, [r3, #0]  

  57 0040 BD38pop {r3, r4, r5, pc}


[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'

2005-08-04 Thread sethml at google dot com

--- Additional Comments From sethml at google dot com  2005-08-05 03:43 
---
The C++ working group examined this issue in April as core language issue 488:
  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#488

They tentatively concluded that type deduction should fail in this case, leaving
the built-in operator==(int,int) version as the only viable candidate and thus
the code attached to this bug report would compile.

It seems likely that this decision will hold, that the standard will be
clarified, making this code valid.

Can we get this bug re-opened, and perhaps change GCC 4 to accept this code in
anticipation of the C++ standard changing to explicitly allow it?

-- 
   What|Removed |Added

 CC||sethml at google dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589