[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include

2018-06-19 Thread sjackman at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

Shaun Jackman  changed:

   What|Removed |Added

 CC||sjackman at gmail dot com

--- Comment #7 from Shaun Jackman  ---
Thanks for reporting and trouble shooting this issue, Markus. This issue also
affects the Linuxbrew package manager. See the downstream issue at
https://github.com/Linuxbrew/brew/issues/724. It'd be great if this issue were
addressed by GCC. Thanks to the trouble shooting here, we can work around the
issue in the mean time.

Cheers,
Shaun

[Bug c++/43545] New: OpenMP ICE (segfault) in conditional break

2010-03-26 Thread sjackman at gmail dot com 
The following test case causes g++ 4.4.0 to crash.

$ g++ --version
g++ (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6)

#include vector

int main()
{
std::vectorint m;
std::vectorint::const_iterator it = m.begin();
#pragma omp parallel
for (;;) {
if (it == m.end())
break;
}
return 0;
}


-- 
   Summary: OpenMP ICE (segfault) in conditional break
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty

2010-03-09 Thread sjackman at gmail dot com 


--- Comment #19 from sjackman at gmail dot com  2010-03-09 19:15 ---
How does the Dinkumware implementation avoid the performance hit of erase
returning an iterator?


-- 


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

[Bug libstdc++/41975] unordered_set::erase performs worse when nearly empty

2009-11-28 Thread sjackman at gmail dot com 


--- Comment #8 from sjackman at gmail dot com  2009-11-29 00:44 ---
I wouldn't depend on the number of buckets shrinking. Shrinking (and growing) a
hash table is an expensive operation that requires rehashing all the elements
in the hash table. Even if the implementation does provide the ability to
shrink the hash table, a number of applications would disable it. Google
sparsehash provides min_load_factor for this purpose.


-- 


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

[Bug c/42210] New: avr: optimizing assignment to a bit field

2009-11-28 Thread sjackman at gmail dot com 
When assigning a bool to a single bit of a bitfield located in the
bit-addressable region of memory, better code is produced by
   if (flag)
   bitfield.bit = true;
   else
   bitfield.bit = false;
than
   bitfield.bit = flag;

I've included a short test and the assembler output by both forms.
Should I file a bug suggesting a possible improvement here?

Cheers,
Shaun

#include stdbool.h
#include stdint.h

struct byte { uint8_t x0:1; uint8_t x1:1; uint8_t x2:1; uint8_t x3:1;
   uint8_t x4:1; uint8_t x5:1; uint8_t x6:1; uint8_t x7:1; };

volatile struct byte *const porte = (void*)0x23;

void set_flag_good(bool flag)
{
   if (flag)
   porte-x6 = true;
   else
   porte-x6 = false;
}

void set_flag_bad(bool flag)
{
   porte-x6 = flag;
}


 set_flag_good:
  0:   88 23   and r24, r24
  2:   01 f4   brne.+0 ; 0x4 set_flag_good+0x4
   2: R_AVR_7_PCREL.text+0x8
  4:   1e 98   cbi 0x03, 6 ; 3
  6:   08 95   ret
  8:   1e 9a   sbi 0x03, 6 ; 3
  a:   08 95   ret

000c set_flag_bad:
  c:   81 70   andir24, 0x01   ; 1
  e:   82 95   swapr24
 10:   88 0f   add r24, r24
 12:   88 0f   add r24, r24
 14:   80 7c   andir24, 0xC0   ; 192
 16:   93 b1   in  r25, 0x03   ; 3
 18:   9f 7b   andir25, 0xBF   ; 191
 1a:   98 2b   or  r25, r24
 1c:   93 b9   out 0x03, r25   ; 3
 1e:   08 95   ret


-- 
   Summary: avr: optimizing assignment to a bit field
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
GCC target triplet: avr-unknown-none


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

[Bug c/34412] New: ICE in extract_insn, at recog.c:1990

2007-12-09 Thread sjackman at gmail dot com 
$ avr-gcc -mmcu=at90pwm316 -g -O2 -Wall -Wextra -Werror -Os -mtiny-stack
-I../.. -I.. -MMD -DBOOTLOADER -DF_CPU=1600  -c -o serial.o ../../serial.c
../../serial.c: In function ‘serial_read’:
../../serial.c:13: error: unrecognizable insn:
(insn/f 52 51 53 2 ../../serial.c:9 (set (reg:QI 28 r28)
(plus:QI (reg/f:HI 28 r28)
(const_int -4 [0xfffc]))) -1 (nil))
../../serial.c:13: internal compiler error: in extract_insn, at recog.c:1990


-- 
   Summary: ICE in extract_insn, at recog.c:1990
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
GCC target triplet: avr


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

[Bug target/34412] ICE in extract_insn, at recog.c:1990

2007-12-09 Thread sjackman at gmail dot com 


--- Comment #1 from sjackman at gmail dot com  2007-12-09 21:08 ---
Created an attachment (id=14714)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14714action=view)
Test case


-- 


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

[Bug middle-end/24221] ICE in first_insn_after_basic_block_note on HPPA

2007-11-26 Thread sjackman at gmail dot com 


--- Comment #7 from sjackman at gmail dot com  2007-11-26 19:54 ---
Subject: Re:  ICE in first_insn_after_basic_block_note on HPPA

This package (swingwt) no longer exists in Debian, so I don't have any
further information. If you would like to close the bug, that's fine
by me.

Cheers,
Shaun

On 26 Nov 2007 14:12:20 -, steven at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
 --- Comment #6 from steven at gcc dot gnu dot org  2007-11-26 14:12 
 ---
 No test case, no progress.  If this problem still exists, we need more than a
 pointer to a build log to investigate the problem.


-- 


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

[Bug c/34210] ffs builtin calls undefined __ffshi2

2007-11-23 Thread sjackman at gmail dot com 


--- Comment #1 from sjackman at gmail dot com  2007-11-23 20:01 ---
It's worth noting that __ffsi2 generates terrible code on the AVR: a 194 byte
function. avr-libc also provides ffs (16-bit, not 32-bit as in __ffssi2) which
is written in assembler and 24 bytes long. As a workaround, you can force the
use of avr-libc's ffs by providing the -fno-builtin-ffs.

Cheers,
Shaun


-- 

sjackman at gmail dot com changed:

   What|Removed |Added

 CC||sjackman at gmail dot com


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

[Bug c/34210] New: ffs builtin calls undefined __ffshi2

2007-11-23 Thread sjackman at gmail dot com 
ffs((uint8_t)x) and ffs((uint16_t)x) generate a call to __ffshi2, but this
function does not exist in libgcc.a, giving the error
undefined reference to `__ffshi2'.

Test case:

int main(int argc)
{
return ffs(argc);
}


-- 
   Summary: ffs builtin calls undefined __ffshi2
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
GCC target triplet: avr


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

[Bug c/32122] indirect goto to an integer accepted

2007-11-23 Thread sjackman at gmail dot com 


--- Comment #2 from sjackman at gmail dot com  2007-11-23 17:30 ---
I've always used `goto *123;' on embedded targets as a feature to be able to
jump to a constant address. This particularly useful feature should not be
removed. Is a simple change of syntax being suggested, such as `goto *(void
*)123;'? Dereferencing a void pointer looks strange to me, but I guess no
stranger than dereferencing an integer.


-- 

sjackman at gmail dot com changed:

   What|Removed |Added

 CC||sjackman at gmail dot com


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

[Bug c/28193] New: config/arm/arm.c:3140 ICE

2006-06-28 Thread sjackman at gmail dot com 
Compiling crtstuff.c with arm-elf-gcc 4.0.3 for -mthumb -fPIC
-msingle-pic-base fails. I had no trouble compiling GCC 4.1.1.

Cheers,
Shaun

make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc'
make GCC_FOR_TARGET=/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc
-B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/
-B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/ -isystem
/usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include \
 AR_FOR_TARGET=arm-elf-ar \
 AR_CREATE_FOR_TARGET=arm-elf-ar  rc \
 AR_EXTRACT_FOR_TARGET=arm-elf-ar  x \
 AR_FLAGS_FOR_TARGET= \
 CC=gcc CFLAGS=-g -O2  -W -Wall -Wwrite-strings
-Wstrict-prototypes-Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition   \
 BUILD_PREFIX= \
 BUILD_PREFIX_1=loser- \
 LANGUAGES= \
 LIBGCC2_CFLAGS=-O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -Dinhibit_libc -fno-inline
-g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -mthumb -fPIC
-msingle-pic-base   \
 MULTILIB_CFLAGS= -mthumb -fPIC -msingle-pic-base
T=thumb/pic/xip/ thumb/pic/xip/crtbegin.o thumb/pic/xip/crtend.o
thumb/pic/xip/crti.o thumb/pic/xip/crtn.o
make[3]: Entering directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc'
/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/xgcc
-B/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc/
-B/usr/local/arm-elf/bin/ -B/usr/local/arm-elf/lib/-isystem
/usr/local/arm-elf/include -isystem /usr/local/arm-elf/sys-include
-O2-DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include  -I. -Ithumb/pic/xip -I../../gcc
-I../../gcc/thumb/pic/xip -I../../gcc/../include
-I../../gcc/../libcpp/include  -mthumb -fPIC -msingle-pic-base -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-unit-at-a-time  \
 -Dinhibit_libc -c ../../gcc/crtstuff.c -DCRT_BEGIN \
 -o thumb/pic/xip/crtbegin.o
../../gcc/crtstuff.c: In function 'frame_dummy':
../../gcc/crtstuff.c:325: internal compiler error: in
thumb_find_work_register,at config/arm/arm.c:3140
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [thumb/pic/xip/crtbegin.o] Error 1
make[3]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc'
make[2]: *** [extrathumb_pic_xip] Error 2
make[2]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/home/sjackman/src/toolchain/gcc-4.0.3/_build/gcc'
make: *** [all-gcc] Error 2


-- 
   Summary: config/arm/arm.c:3140 ICE
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-elf


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

[Bug c/28194] New: R_ARM_GOTOFF32 breaks execute-in-place

2006-06-28 Thread sjackman at gmail dot com 
Execute-in-place (XIP) code, commonly used with uClinux, places the .text
section in flash and the .data section in RAM. GCC 4.1 emits R_ARM_GOTOFF32
relocations for symbols in the .text segment relative to the GOT, which is in
the .data segment. This new behaviours breaks XIP. See the following diff,
which illustrates this new behaviour.

Cheers,
Shaun

$ cat f.c
void g(void (*h)(void)) {}
static void f(void) { g(f); }
$ diff -u f.s-4.0.3 f.s-4.1.1
--- f.s-4.0.3   2006-06-28 09:32:54.044964568 -0600
+++ f.s-4.1.1   2006-06-28 08:55:49.880089024 -0600
@@ -8,11 +8,12 @@
.type   g, %function
 g:
push{r7, lr}
-   mov r7, sp
sub sp, sp, #4
-   sub r3, r7, #4
+   add r7, sp, #0
+   mov r3, r7
str r0, [r3]
mov sp, r7
+   add sp, sp, #4
@ sp needed for prologue
pop {r7, pc}
.size   g, .-g
@@ -22,10 +23,9 @@
.type   f, %function
 f:
push{r7, lr}
-   mov r7, sp
+   add r7, sp, #0
ldr r3, .L5
add r3, r3, sl
-   ldr r3, [r3]
mov r0, r3
bl  g
mov sp, r7
@@ -34,6 +34,6 @@
 .L6:
.align  2
 .L5:
-   .word   f(GOT)
+   .word   f(GOTOFF)
.size   f, .-f
-   .ident  GCC: (GNU) 4.0.3
+   .ident  GCC: (GNU) 4.1.1


-- 
   Summary: R_ARM_GOTOFF32 breaks execute-in-place
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-elf


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

[Bug c/28193] config/arm/arm.c:3140 ICE

2006-06-28 Thread sjackman at gmail dot com 


--- Comment #1 from sjackman at gmail dot com  2006-06-28 17:36 ---
Created an attachment (id=11772)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11772action=view)
Backport thumb_find_work_register from 4.1.1

2005-03-01  Nick Clifton  [EMAIL PROTECTED]

* config/arm/arm.c (thumb_find_work_register): Check all of the
argument registers to see if they are free, and a couple of
special cases where the last argument register but can be proved
to be available during the function's prologue.


-- 


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

[Bug target/28193] config/arm/arm.c:3140 ICE

2006-06-28 Thread sjackman at gmail dot com 


--- Comment #2 from sjackman at gmail dot com  2006-06-28 20:18 ---
This proposed patch does help. At the very least, it prevents the ICE on
compiling crtstuff.c while compiling the toolchain. However, with this patch
applied, I saw the same bug later while compiling newlib. As the comment in
thumb_find_work_register suggests, the real bug is probably in
thumb_compute_save_reg_mask.

make[8]: Entering directory
`/home/sjackman/src/toolchain/src/_build/arm-elf/thumb/pic/xip/newlib/libc/stdio'
arm-elf-gcc -B/home/sjackman/src/toolchain/src/_build/arm-elf/newlib/ -isystem
/home/sjackman/src/toolchain/src/_build/arm-elf/newlib/targ-include -isystem
/home/sjackman/src/toolchain/src/newlib/libc/include -DPACKAGE_NAME=\newlib\
-DPACKAGE_TARNAME=\newlib\ -DPACKAGE_VERSION=\1.14.0\
-DPACKAGE_STRING=\newlib\1.14.0\ -DPACKAGE_BUGREPORT=\\  -I.
-I../../../../../../../../newlib/libc/stdio -O2 -D__NO_SYSCALLS__
-DNO_FLOATING_POINT -DHAVE_FCNTL -DHAVE_NANOSLEEP -fno-builtin  -O2 -g -O2 
 -mthumb -fPIC -msingle-pic-base -c -o lib_a-findfp.o `test -f 'findfp.c' ||
echo '../../../../../../../../newlib/libc/stdio/'`findfp.c
../../../../../../../../newlib/libc/stdio/findfp.c: In function 'std':
../../../../../../../../newlib/libc/stdio/findfp.c:61: internal compiler
error:in thumb_find_work_register, at config/arm/arm.c:3173
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[8]: *** [lib_a-findfp.o] Error 1
make[8]: Leaving directory
`/home/sjackman/src/toolchain/src/_build/arm-elf/thumb/pic/xip/newlib/libc/stdio'


-- 


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

[Bug target/28193] config/arm/arm.c:3140 ICE

2006-06-28 Thread sjackman at gmail dot com 


--- Comment #3 from sjackman at gmail dot com  2006-06-28 20:51 ---
I tried backporting thumb_compute_save_reg_mask from GCC 4.1.1 to GCC 4.0.3
without success. I'll try backporting this entire patch from svn.

2005-03-01  Nick Clifton  [EMAIL PROTECTED]

* config/arm/arm.c (thumb_find_work_register): Check all of the
argument registers to see if they are free, and a couple of
special cases where the last argument register but can be proved
to be available during the function's prologue.
(print_multi_reg, arm_compute_save_reg0_reg12_mask,
output_return_instruction, emit_multi_reg_push, thumb_pushpop,
thumb_unexpanded_epilogue): Use unsigned long as the type for the
register bit-mask.
(thumb_compute_save_reg_mask): Likewise.  Also use
thumb_find_work_register() to ensure that there is agreement about
which work register is going to be used in the prologue.
(thumb_output_function_prologue): Use unsigned long as the type
for the register bit-mask.  Also delay pushing the link register if
other high registers are going to be pushed.
(thumb_compute_save_reg_mask, emit_multi_reg_push,
print_multi-reg, number_of_first_bit_set, thumb_pushpop): Remove
redundant prototypes.


-- 


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

[Bug target/28193] config/arm/arm.c:3140 ICE

2006-06-28 Thread sjackman at gmail dot com 


--- Comment #4 from sjackman at gmail dot com  2006-06-28 22:30 ---
I tried applying r95736 (2005-03-01 Nick Clifton) and r103151 (2005-08-16
Richard Earnshaw) against GCC 4.0.3. Both these patches apply cleanly (with
offsets), but don't fix the problem compiling newlib.


-- 


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

[Bug target/28193] [4.0 only] config/arm/arm.c:3140 ICE

2006-06-28 Thread sjackman at gmail dot com 


--- Comment #6 from sjackman at gmail dot com  2006-06-29 00:01 ---
Applying the patch from r103277 fixes this bug. I also had r95736 and r103151
applied against my 4.0.3 tree at the time. So, I don't know if r103277 alone is
sufficient. r103277 was meant to close PR target/23473, so this bug may be a
duplicate of #23473.


-- 


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

[Bug target/28193] [4.0 only] config/arm/arm.c:3140 ICE

2006-06-28 Thread sjackman at gmail dot com 


--- Comment #7 from sjackman at gmail dot com  2006-06-29 00:10 ---
Subject: Re:  [4.0 only] config/arm/arm.c:3140 ICE

On 28 Jun 2006 23:31:22 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
 --- Comment #5 from pinskia at gcc dot gnu dot org  2006-06-28 23:31 
 ---
 Is this a regression?
...
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28193

I haven't tested any version of GCC earlier than 4.0.3 for this bug,
so I don't know if it's a regression. I was testing svn versions after
4.0.3 and before 4.1.0 to discover when this bug was fixed. It appears
it was fixed in r103277.

Cheers,
Shaun


-- 


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

[Bug java/26720] New: Can't find method 'access$1(I)'

2006-03-16 Thread sjackman at gmail dot com 
In the following test, gcj fails to generate an access method for the private
static members of type char, byte, and short, although it does generate the
access method for the private static members of type int and Object.

class AccessTest {
   public interface Foo {
   public void foo();
   }

   private static char buggy_char;
   private static byte buggy_byte;
   private static short buggy_short;
   private static int i;
   private static Object o;

   static {
   new Foo() {
   public void foo() {
   buggy_char = 0;
   buggy_byte = 0;
   buggy_short = 0;
   i = 0;
   o = null;
   }
   };
   }
}


-- 
   Summary: Can't find method 'access$1(I)'
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/26702] New: Size of static variables always zero on arm-elf

2006-03-15 Thread sjackman at gmail dot com 
When an object file is compiled by arm-elf-gcc 4.1.0, nm -S 2.16.*
always shows zero as the size of a static variable.

Thanks,
Shaun

$ cat foo.c
int foo;
static int static_foo;
$ arm-elf-gcc -c foo.c
$ arm-elf-readelf -s foo.o | grep foo
 1:  0 FILELOCAL  DEFAULT  ABS foo.c
 6:  0 NOTYPE  LOCAL  DEFAULT3 static_foo
 8: 0004 4 OBJECT  GLOBAL DEFAULT  COM foo
$ gcc -c foo.c
$ readelf -s foo.o | grep foo
 1:  0 FILELOCAL  DEFAULT  ABS foo.c
 5:  4 OBJECT  LOCAL  DEFAULT3 static_foo
 8: 0004 4 OBJECT  GLOBAL DEFAULT  COM foo
$ arm-elf-gcc --version | head -1
arm-elf-gcc (GCC) 4.1.0
$ arm-elf-readelf --version | head -1
GNU readelf 2.16.91 20060309
$ gcc --version | head -1
gcc (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)
$ readelf --version | head -1
GNU readelf 2.16.91-multiarch 20060118 Debian GNU/Linux


-- 
   Summary: Size of static variables always zero on arm-elf
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-elf


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

[Bug target/26702] Size of static variables always zero on arm-elf

2006-03-15 Thread sjackman at gmail dot com 


--- Comment #2 from sjackman at gmail dot com  2006-03-15 18:51 ---
Subject: Re:  Size of static variables always zero on arm-elf

On 15 Mar 2006 18:38:46 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
 What does the output of -S show?  I bet it is just putting static_foo in a BSS
 using lcomm but I could be wrong.  This might not be a gcc bug.

$ arm-elf-readelf -S foo.o
There are 8 section headers, starting at offset 0x7c:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf
Al
  [ 0]   NULL 00 00 00  0   0 
0
  [ 1] .text PROGBITS 34 00 00  AX  0   0 
1
  [ 2] .data PROGBITS 34 00 00  WA  0   0 
1
  [ 3] .bss  NOBITS   34 04 00  WA  0   0 
4
  [ 4] .comment  PROGBITS 34 12 00  0   0 
1
  [ 5] .shstrtab STRTAB   46 35 00  0   0 
1
  [ 6] .symtab   SYMTAB   0001bc 90 10  7   8 
4
  [ 7] .strtab   STRTAB   00024c 19 00  0   0 
1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


-- 


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

[Bug target/26702] Size of static variables always zero on arm-elf

2006-03-15 Thread sjackman at gmail dot com 


--- Comment #4 from sjackman at gmail dot com  2006-03-15 19:03 ---
Subject: Re:  Size of static variables always zero on arm-elf

On 15 Mar 2006 18:53:53 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
 No I mean what is the assembly output from GCC which you get by invoking gcc
 with -S.

It does not appear to use lcomm for static_foo. If it's not a gcc bug,
is it a gas bug or a binutils bug?

-- sdj

$ arm-elf-gcc -S foo.c
$ cat foo.s
.file   foo.c
.bss
.align  2
static_foo:
.space  4
.comm   foo,4,4
.ident  GCC: (GNU) 4.1.0


-- 


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

[Bug target/26702] Size of static variables always zero on arm-elf

2006-03-15 Thread sjackman at gmail dot com 


--- Comment #6 from sjackman at gmail dot com  2006-03-15 20:01 ---
Subject: Re:  Size of static variables always zero on arm-elf

On 15 Mar 2006 19:07:12 -, pinskia at gcc dot gnu dot org  Can
you try one more thing:
 static int static_foo = 1;

 And then use readelf -s on the object file?

$ cat foo.c
int foo;
static int static_foo = 1;
$ arm-elf-gcc -c foo.c
$ arm-elf-readelf -s foo.o | grep foo
 1:  0 FILELOCAL  DEFAULT  ABS foo.c
 5:  4 OBJECT  LOCAL  DEFAULT2 static_foo
 8: 0004 4 OBJECT  GLOBAL DEFAULT  COM foo
$ arm-elf-gcc -S foo.c
$ cat foo.s
.file   foo.c
.data
.align  2
.type   static_foo, %object
.size   static_foo, 4
static_foo:
.word   1
.comm   foo,4,4
.ident  GCC: (GNU) 4.1.0


-- 


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

[Bug target/26702] Size of static variables always zero on arm-elf

2006-03-15 Thread sjackman at gmail dot com 


--- Comment #8 from sjackman at gmail dot com  2006-03-15 20:10 ---
Subject: Re:  Size of static variables always zero on arm-elf

GCC is not emitting the type or size information for static bss symbols.

-- sdj

$ echo 'static int foo = 1;' foo.c
$ arm-elf-gcc -S foo.c -odata.s
$ echo 'static int foo;' foo.c
$ arm-elf-gcc -S foo.c -obss.s
$ diff -u data.s bss.s
--- data.s  2006-03-15 13:08:17.0 -0700
+++ bss.s   2006-03-15 13:08:17.0 -0700
@@ -1,8 +1,6 @@
.file   foo.c
-   .data
+   .bss
.align  2
-   .type   foo, %object
-   .size   foo, 4
 foo:
-   .word   1
+   .space  4
.ident  GCC: (GNU) 4.1.0


-- 


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

[Bug java/24221] New: ICE in first_insn_after_basic_block_note on HPPA

2005-10-05 Thread sjackman at gmail dot com 
The Debian HPPA buildd is failing with an ICE when building SwingWT
for the HPPA.

Here's the full build log:
http://buildd.debian.org/fetch.php?pkg=swingwtver=0.87-2arch=hppastamp=1126289145file=logas=raw

Here's the interesting line:
swingwtx/swing/JOptionPane.java:325: internal compiler error: in
first_insn_after_basic_block_note, at flow.c:349

GCJ 4.0.1 is being used.

Cheers,
Shaun


-- 
   Summary: ICE in first_insn_after_basic_block_note on HPPA
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjackman at gmail dot com
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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