[Bug c/40191] New: fails to build a cross-compiler in-tree

2009-05-18 Thread rmh at gcc dot gnu dot org 
I found this when building a i586-mingw32 cross-compiler directly in srcdir. 
Build fails with:

make[2]: Entering directory `/tmp/trunk/i586-mingw32msvc/libgcc'
Makefile:143: ../.././gcc/libgcc.mvars: No such file or directory
make[2]: *** No rule to make target `../.././gcc/libgcc.mvars'.  Stop.

This happens because ${host_subdir} gets the wrong path (fallbacks to "."). 
The check in acx.m4 doesn't take into account that ${host_noncanonical} changes
its meaning when we switched from gcc/ to libgcc/.

Patch attached.


-- 
   Summary: fails to build a cross-compiler in-tree
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: build, patch
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rmh at gcc dot gnu dot org


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

[Bug target/40191] fails to build a cross-compiler in-tree

2009-05-18 Thread rmh at gcc dot gnu dot org 


--- Comment #2 from rmh at gcc dot gnu dot org  2009-05-18 20:45 ---
Created an attachment (id=17889)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17889&action=view)
patch

2009-05-18  Robert Millan 

* acx.m4: Fix ${host_subdir} initialization for libgcc.


-- 


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

[Bug target/40191] fails to build a cross-compiler in-tree

2009-07-28 Thread rmh at gcc dot gnu dot org 


--- Comment #3 from rmh at gcc dot gnu dot org  2009-07-28 22:11 ---
ping


-- 


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

[Bug c/41246] New: %ecx corruption when combining -regparm=3 with nested functions

2009-09-03 Thread rmh at gcc dot gnu dot org 
On i386, combining -regparm=3 with nested functions results in %ecx (holding
the third function parameter because of -regparm=3) being overwritten with a
temporary pointer used by GCC to implement the nested function call.

GNU GRUB has had a workaround (disabling -regparm in a case-by-case basis) to
this bug for a long while.  It's only been brought up to me recently that we
had this problem (I'm one of the GRUB maintainers).

One of the GRUB developers (Bean) produced a test case.  I'm attaching it here.


-- 
   Summary: %ecx corruption when combining -regparm=3 with nested
functions
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: rmh at gcc dot gnu dot org


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

[Bug c/41246] %ecx corruption when combining -regparm=3 with nested functions

2009-09-03 Thread rmh at gcc dot gnu dot org 


--- Comment #1 from rmh at gcc dot gnu dot org  2009-09-03 15:34 ---
Created an attachment (id=18477)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18477&action=view)
test case

$ gcc -m32 regparm_nested.c && ./a.out
10 31 31

$ gcc -m32 -mregparm=3 regparm_nested.c && ./a.out
10 31 -3957600


-- 


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

[Bug target/41246] %ecx corruption when combining -regparm=3 with nested functions

2009-09-03 Thread rmh at gcc dot gnu dot org 


--- Comment #4 from rmh at gcc dot gnu dot org  2009-09-03 16:47 ---
(In reply to comment #2)
> So, perhaps we should just
> error out whenever we see in -m32 mode on i?86/x86_64 a nested function in
> -mregparm=3 mode.

Error out is much nicer.  I can recall nasty memory corruption bugs that
could've been solved in a blast if GCC rejected our code :-)


-- 


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

[Bug c/41299] New: code size regression (from 4.3) with -Os and -mregparm=3

2009-09-07 Thread rmh at gcc dot gnu dot org 
$ gcc-4.3 -c -Os -mregparm=3 -m32 test.c && objcopy -O binary test.o test.raw
&&  du -b test.raw
66  test.raw

$ gcc-4.4 -c -Os -mregparm=3 -m32 test.c && objcopy -O binary test.o test.raw
&&  du -b test.raw
70  test.raw


-- 
   Summary: code size regression (from 4.3) with -Os and -mregparm=3
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rmh at gcc dot gnu dot org


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

[Bug c/41299] code size regression (from 4.3) with -Os and -mregparm=3

2009-09-07 Thread rmh at gcc dot gnu dot org 


--- Comment #1 from rmh at gcc dot gnu dot org  2009-09-07 18:40 ---
Created an attachment (id=18531)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18531&action=view)
test case


-- 


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

[Bug lto/42392] New: ICE when combining LTO with asm()

2009-12-16 Thread rmh at gcc dot gnu dot org 
I got this error when trying to compile GRUB (latest bzr) on amd64 with -flto:

lto1: internal compiler error: compressed stream: buffer error

The culprit was an acinclude check, which can be reduced to the following test
case:

asm (".globl start; start: nop");
int
main ()
{
}

I'm not sure this can be considered valid C (or at least valid GNU C). I'm
tentatively setting ice-on-invalid-code keyword. If I understand correctly, it
is equivalent to:

void start ()
{
  asm ("nop");
}
int
main ()
{
}

In any case I suppose if the code isn't valid, GCC ought to fail more
gracefully than this, so I report anyway in case you'd like to know :-)


-- 
   Summary: ICE when combining LTO with asm()
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, lto
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rmh at gcc dot gnu dot org


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

[Bug c/42537] New: [PATCH] misc spelling fixes

2009-12-29 Thread rmh at gcc dot gnu dot org 
Misc spelling fixes (found when running the debian lintian tool)


-- 
   Summary: [PATCH] misc spelling fixes
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: trivial
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmh at gcc dot gnu dot org


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

[Bug c/42537] [PATCH] misc spelling fixes

2009-12-29 Thread rmh at gcc dot gnu dot org 


--- Comment #1 from rmh at gcc dot gnu dot org  2009-12-29 12:46 ---
Created an attachment (id=19412)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19412&action=view)
misc spelling fixes


-- 


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

[Bug c/33901] New: assumes target of a const pointer is read-only

2007-10-25 Thread rmh at gcc dot gnu dot org 
Given the following code:

main ()
{
  const char *foo = 0;
  *foo = 0;
}

gcc will refuse to compile it with:

$ echo "main () { const char *foo = 0; *foo = 0; }" | gcc -x c -c - -o
/dev/null
: In function ‘main’:
:1: error: assignment of read-only location

Sure, foo is read-only, but *foo is just a memory location; one should be able
to write to it.


-- 
   Summary: assumes target of a const pointer is read-only
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmh at gcc dot gnu dot org


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