--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-02 07:15 ---
Also fixed on the 4.3 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-02 07:16 ---
Subject: Bug 35431
Author: pinskia
Date: Wed Apr 2 07:15:19 2008
New Revision: 133822
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133822
Log:
2008-03-31 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #11 from herwig at gdsys dot de 2008-04-02 07:17 ---
(In reply to comment #10)
> Yes. Since the class declaration must be visible from the place where you
> call this function, and since then also the function's definition
> (=implementation) is visible, the template should
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-02 07:19 ---
Fixed also on the 4.3 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-02 07:19 ---
Subject: Bug 35429
Author: pinskia
Date: Wed Apr 2 07:19:01 2008
New Revision: 133823
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133823
Log:
2008-04-02 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
Note: This bug *can* be related to 35791 (they can have the same source).
procedure A is
type Base_1 is interface;
type Base_2 is interface;
type Middle is interface and Base_1 and Base_2;
type Derived is new Middle with null record;
function Make_Derived return Derived is
beg
--- Comment #27 from laurent at guerby dot net 2008-04-02 07:36 ---
My guess is that Initialize_TCB you wrote for RTEMS (s-taprop-rtems) does not
set success to True for some reason:
procedure Initialize_ATCB
...
STPO.Initialize_TCB (T, Success); --- here call into RTEMS specif
--- Comment #1 from george at gcc dot gnu dot org 2008-04-02 08:01 ---
Fixed in rev 133800 1 April 2008
--
george at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from george at gcc dot gnu dot org 2008-04-02 08:08 ---
Fixed in rev 133800, 1 April 2008
--
george at gcc dot gnu dot org changed:
What|Removed |Added
The gcc and g++ of trunk (svn r133789) has a problem with detecting faulty
warnings such was -Wno-this-does-not-exist.
E.g. it seems to pass on -Wno-long-double options down to, like with:
int main()
{
return 0;
}
DOES NOT fail with gcc -c -g -Wno-long-double main.c
but DOES fail with gcc -c -g
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-02 08:33 ---
I think this is expected behavior now, see PR 28322.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from Keller at hlrs dot de 2008-04-02 09:35 ---
(In reply to comment #1)
> I think this is expected behavior now, see PR 28322.
Thanks Andrew. So the fix to trigger another warning was correct and is the
preferred method for configure-scripts...
--
http://gcc.gnu.org
--- Comment #3 from hubicka at ucw dot cz 2008-04-02 09:35 ---
Subject: Re: New: [4.4 Regression] Revision 133787 breaks ia64
Hi,
I've added the assert to check that we don't initialize RTL world twice
without freeing it first (and thus that we don't leak memory). This
seems to be th
--- Comment #2 from bonzini at gnu dot org 2008-04-02 09:57 ---
Subject: Bug 35542
Author: bonzini
Date: Wed Apr 2 09:56:17 2008
New Revision: 133829
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133829
Log:
2008-04-02 Andy Hutchinson <[EMAIL PROTECTED]>
PR rtl-optim
--- Comment #14 from bonzini at gnu dot org 2008-04-02 09:57 ---
committed to trunk as 133828
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #3 from bonzini at gnu dot org 2008-04-02 09:57 ---
committed to trunk, will backport to 4.3 in due time (causes regressions for
AVR)
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #35 from bonzini at gnu dot org 2008-04-02 10:08 ---
the infinite loop is fixed, don't know if the second bug remains.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #36 from bonzini at gnu dot org 2008-04-02 10:08 ---
Subject: Bug 35752
Author: bonzini
Date: Wed Apr 2 10:07:58 2008
New Revision: 133832
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133832
Log:
2008-04-02 Paolo Bonzini <[EMAIL PROTECTED]>
PR bootstrap
--- Comment #15 from bonzini at gnu dot org 2008-04-02 11:24 ---
oops, still on 4.3
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-02 11:29 ---
Should be fixed now. Please re-open with the requested information if not.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #28 from laurent at guerby dot net 2008-04-02 11:44 ---
I did not notice that s-taprop for rtems was the posix version
procedure Initialize_TCB (Self_ID : Task_Id; Succeeded : out Boolean) is
Mutex_Attr : aliased pthread_mutexattr_t;
Result : Interfaces.C.
#include
#define N 50
void test(void) {
static char *array=NULL;
int i;
if (array==NULL) {
array=calloc(N, sizeof(char));
array[0]=0;
for(i=1;i0 -O1, -O2,
...:
> "C:\Dev-Cpp\bin\gcc.exe" "segfault.c" -o "segfault.exe" -O3
>
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-04-02 12:52 ---
Subject: Bug 14495
Author: rguenth
Date: Wed Apr 2 12:51:37 2008
New Revision: 133834
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133834
Log:
2008-04-02 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-04-02 12:54 ---
Subject: Bug 14495
Author: rguenth
Date: Wed Apr 2 12:54:08 2008
New Revision: 133835
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133835
Log:
2008-04-02 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-04-02 12:54
---
Subject: Bug 34793
Author: rguenth
Date: Wed Apr 2 12:54:08 2008
New Revision: 133835
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133835
Log:
2008-04-02 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-04-02 12:55
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-04-02 12:56
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-02 12:57 ---
Please try with a still maintained GCC version, which would be at least 4.2.3.
Thanks.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from bernds_cb1 at t-online dot de 2008-04-02 13:17 ---
We don't support a bfin-linux-gnu target. Does any of bfin-elf, bfin-uclinux
or bfin-linux-uclibc work for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35419
In the following code (condensed from a real example where Fnord was
boost::intrusive_ptr), the call to the Fnord constructor in function make_fnord
only succeeds because Aubergine is derived from Base. But GCC doesn't "know"
that Aubergine is derived from Base until after it's seen make_fnord. (An
--- Comment #12 from bangerth at math dot tamu dot edu 2008-04-02 13:31
---
Subject: Re: Pure virtual method body omitted from template
> No, it is not. And that's because this pure virtual method never gets called
> explicitly.
The point I meant to make but failed is: a pure virtua
Stage 1 compiler from revision 133835 failed to compile binutils:
[EMAIL PROTECTED] binutils]$
/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/xgcc
-B/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/
-B/usr/gcc-4.4/x86_64-unknown-linux-gnu/bin/ -DHAVE_CONFIG_H -I.
-I/export/gnu/src/too
--- Comment #1 from hjl dot tools at gmail dot com 2008-04-02 13:46 ---
Created an attachment (id=15410)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15410&action=view)
A testcase
[EMAIL PROTECTED] binutils]$
/export/build/gnu/tools/build-x86_64-linux/./prev-gcc/xgcc
-B/export/b
--- Comment #37 from oblivian at users dot sourceforge dot net 2008-04-02
13:47 ---
(In reply to comment #35)
> the infinite loop is fixed, don't know if the second bug remains.
>
Yes and no, It fixes the compilation so that ld no longer gets into a loop, but
the installed compiler is
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-02 13:50 ---
This is likely caused by http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00059.html.
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
At revision 133817, bootstrap fails at libstdc++-v3/src/strstream.cc on
powerpc-apple-darwin9:
...
libtool: compile: /opt/gcc/darwin_buildw/./gcc/xgcc -shared-libgcc
-B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/darwin_buildw
--- Comment #38 from bonzini at gnu dot org 2008-04-02 13:59 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap with --enable-shared
> I'll be opening a new bug on the sysroot problems I'm having with 4.3 since it
> appears no one has tried a
--- Comment #3 from hjl dot tools at gmail dot com 2008-04-02 14:00 ---
(In reply to comment #2)
> This is likely caused by http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00059.html.
>
> Reducing.
>
http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00059.html
is revision 133835. Revision 133834 pas
--- Comment #11 from bonzini at gnu dot org 2008-04-02 14:08 ---
Carlos, I think Greg has a point here:
> the problem is that xgcc thinks it is a relocated compiler when it
> runs from $objdir eg: when building libgcc* and other target libs, when in
> actual fact, it is not really a tr
I am getting a very strange ICE on a mips system when building with -mabi=n32
or -mabi=64:
testcase.i: In function ‘_IO_vfscanf_internal’:
testcase.i:2857: error: unable to find a register to spill in class
‘V1_REG’
testcase.i:2857: error: this is the insn:
(insn 1286 1241 1243 106 testcase.i:577
--- Comment #1 from aurelien at aurel32 dot net 2008-04-02 14:13 ---
Created an attachment (id=15411)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15411&action=view)
unreduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35802
--- Comment #2 from aurelien at aurel32 dot net 2008-04-02 14:13 ---
Created an attachment (id=15412)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15412&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35802
--- Comment #17 from ghazi at gcc dot gnu dot org 2008-04-02 14:18 ---
I see the same issue on x86_64 debian linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00085.html
Removing hppa tags since it's debian-specific, not hppa.
--
ghazi at gcc dot gnu dot org changed:
--- Comment #39 from oblivian at users dot sourceforge dot net 2008-04-02
14:19 ---
Created an attachment (id=15413)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15413&action=view)
Optional way to fix ld relink problems
Just for completeness, here is the fix the Ralf was suggest
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-02 14:25 ---
This is thunk related, most likely forgot a free function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35801
--- Comment #4 from dominiq at lps dot ens dot fr 2008-04-02 14:31 ---
I think PR35801 is the same problem on powerpc-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795
--- Comment #2 from dominiq at lps dot ens dot fr 2008-04-02 14:34 ---
I think it is another manifestation of PR35795.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35801
--- Comment #3 from aurelien at aurel32 dot net 2008-04-02 14:15 ---
Also please note that the same problem exists on mips
(mips64-unknown-linux-gnu).
--
aurelien at aurel32 dot net changed:
What|Removed |Added
-
--- Comment #4 from ghazi at gcc dot gnu dot org 2008-04-02 14:59 ---
Problem still occurs on 4.1 branch:
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00083.html
I'll try backporting the patch from 4.2.x and see if it still works.
--
ghazi at gcc dot gnu dot org changed:
--- Comment #29 from joel at gcc dot gnu dot org 2008-04-02 15:08 ---
I have spent the morning debugging at the assembly level and I am nearly 100%
positive %ebx is getting corrupted. It is correct before the call to
STPO.Initialize_TCB (T, Success);
at s-taskin.adb and 0x0 upo
--- Comment #4 from eric dot weddington at atmel dot com 2008-04-02 15:21
---
(In reply to comment #3)
> committed to trunk, will backport to 4.3 in due time (causes regressions for
> AVR)
>
Could you list what fails?
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35542
--- Comment #5 from bonzini at gnu dot org 2008-04-02 15:25 ---
I meant that this is a patch that is scheduled for backporting to 4.3, because
it fixes regressions on AVR.
The text between parentheses should have been "bug causes regressions for AVR".
Sorry.
--
http://gcc.gnu.org/
Gcc has traditionally used the concept of a compare operation that stores
a comparison result in CC0 or a register, and then can be used with arbitrary
comparison operators to compare it against zero to make a decision for
a branch, store flag, or conditional move instruction.
Since often the actua
--- Comment #6 from hutchinsonandy at aim dot com 2008-04-02 15:44 ---
Subject: Re: [4.3 Regression] fwprop only propagates
one operand
Eric,
it's difficult to give you a specfic example as the propagation is very
sensitive to generated code. I found this looking at other AVR bugs a
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-02 15:49 ---
Created an attachment (id=15414)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15414&action=view)
reduced testcase
Reduced testcase, fails with -O -ftree-vrp -fno-inline.
Program received signal SIGSEGV, Segm
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-02 15:53 ---
So we have
(addr_vec:DI [
(nil)
(label_ref:DI 26)
(label_ref:DI 26)
(label_ref:DI 26)
(label_ref:DI 26)
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35800
--- Comment #13 from herwig at gdsys dot de 2008-04-02 16:07 ---
(In reply to comment #12)
> The point I meant to make but failed is: a pure virtual method can *only*
> *ever* be called explicitly. It can't be called through the vtable because
> there can be no objects of the type of t
Hello,
This bug is a continuation from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532. It appears that native
retargeting of the compiler is not supported in the 4.3/4.4 series in favor of
the sysroot option. When trying to build a pass 1 c
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-02 16:20 ---
Heh, I was testing with -m32 and -m64 on 4.3 branch (but that was
--enable-checking=release default) and on the trunk just -m64. Can reproduce
now.
This seems to be NRV that is creating non-GIMPLE by replacing GIMPLE
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-02 16:23 ---
Sounds like you should be using --build-sysroot= and not set LDFLAGS_FOR_TARGET
and CPPFLAGS_FOR_TARGET .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from oblivian at users dot sourceforge dot net 2008-04-02
16:26 ---
(In reply to comment #1)
> Sounds like you should be using --build-sysroot= and not set
> LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .
>
You mean configure with just --with-build-sysroot and not --wit
--- Comment #5 from hjl dot tools at gmail dot com 2008-04-02 16:42 ---
(In reply to comment #3)
> Subject: Re: New: [4.4 Regression] Revision 133787 breaks ia64
>
> Hi,
> I've added the assert to check that we don't initialize RTL world twice
> without freeing it first (and thus that
--- Comment #30 from laurent at guerby dot net 2008-04-02 16:44 ---
Did you look at what happens in Initialize_TCB to the variable Success ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
Hi,
gcc 930523-1.c -c -fira -O1 -m32
fails with
930523-1.c: In function 'f':
930523-1.c:54: internal compiler error: in start_allocno_priorities, at
ira-color.c:1806
Please submit a full bug report,
rev: 133765
--
Summary: [ira] error in start_allocno_priorities, at ira-
--- Comment #2 from mstein dot lists at googlemail dot com 2008-04-02
16:55 ---
Fails in trunk (133803) too
--
mstein dot lists at googlemail dot com changed:
What|Removed |Added
--- Comment #2 from mstein dot lists at googlemail dot com 2008-04-02
17:02 ---
Seems to work again in rev 133774
--
mstein dot lists at googlemail dot com changed:
What|Removed |Added
--
--- Comment #14 from yuriry at gmail dot com 2008-04-02 17:15 ---
Hi Björn
My question is slightly off topic but I am really interested in the purpose of
defining a template class where a template parameter is not used. Why would
you need this?
Regards,
Yuri
template
class TBase
{
pu
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-02 17:17 ---
IMNSHO this is invalid.
[lib.support.types]/5 says the first argument must be a POD structure or POD
union, but struct A isn't POD structure because of the reference in it.
--
jakub at gcc dot gnu dot org changed:
--- Comment #2 from pogma at gcc dot gnu dot org 2008-04-02 17:37 ---
Subject: Bug 35216
Author: pogma
Date: Wed Apr 2 17:36:41 2008
New Revision: 133842
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133842
Log:
PR bootstrap/35216
* scripts/makemake.tcl: Replace org/omg build
--- Comment #15 from fang at csl dot cornell dot edu 2008-04-02 17:38
---
Unused template parameters can be used when you want to intentionally subtype a
base type with different flavors that are incompatible with each other, using
compile-time checking to prevent accidental cross-conta
--- Comment #3 from pogma at gcc dot gnu dot org 2008-04-02 17:44 ---
Fixed in r133842
--
pogma at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
Hi,
the code below compiles to 60 byte when using -Os
and 4 byte when using -O2.
This is just one example of many from the test suite:
extern void f(char *const *);
void g (char **o)
{
static const char *const multilib_exclusions_raw[] = { 0 };
const char *const *q = multilib_exclusions_raw;
--- Comment #3 from joseph at codesourcery dot com 2008-04-02 17:52 ---
Subject: Re: Bootstrap of combined gcc + binutils, with
--enable-shared, with sysroot fails
On Wed, 2 Apr 2008, pinskia at gcc dot gnu dot org wrote:
> Sounds like you should be using --build-sysroot= and not set
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |target
Target Milestone|--- |4.4.0
http:/
--- Comment #16 from yuriry at gmail dot com 2008-04-02 17:58 ---
Thanks for the reply, David! But now I have more questions than I had before
:-)
I'm not sure if this thread is the right place to go into details on this
topic. If you know any other place to move this discussion, plea
--- Comment #6 from hp at gcc dot gnu dot org 2008-04-02 18:06 ---
Created an attachment (id=15415)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15415&action=view)
another reduced testcase, -O2
I see attachment #2 there, but as long as I did a reduction too, here's
another, a wee
--- Comment #17 from bangerth at math dot tamu dot edu 2008-04-02 18:31
---
Subject: Re: Pure virtual method body omitted from template
On Wednesday 02 April 2008 12:15:53 yuriry at gmail dot com wrote:
> My question is slightly off topic but I am really interested in the purpose
> o
--- Comment #3 from dominiq at lps dot ens dot fr 2008-04-02 18:32 ---
Borrowed from pr35795, the following patch seems to work:
--- ../_gcc_clean/gcc/config/rs6000/rs6000.c2008-03-29 23:59:15.0
+0100
+++ ../gcc-4.4-work/gcc/config/rs6000/rs6000.c 2008-04-02 20:03:18.00
--- Comment #1 from vmakarov at redhat dot com 2008-04-02 18:34 ---
I've just fixed it on ira branch. The problem was in an assert requiring
nonzero number of references for an allocno. I permitted to have zero number
of references.
I've just realized that such situations are possible
--- Comment #18 from bangerth at math dot tamu dot edu 2008-04-02 18:34
---
Subject: Re: Pure virtual method body omitted from template
> You are absolutely right as long as there is no multithreading and no
> dangling pointer. Sure. The thing is: If it's called, something bad has
>
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #12 from carlos at codesourcery dot com 2008-04-02 19:20
---
Paolo,
What's the test-case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
--- Comment #7 from hp at gcc dot gnu dot org 2008-04-02 19:56 ---
It's not just about creating a properly filled (or handling the NULLs in the)
addr_vec after generating the tablejump or casesi: for machines with casesi,
passing a NULL default_label (operand[4]; fifth operand) is...unex
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-02 20:01 ---
spu-elf also fails the same way.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
G
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-04-02 20:17 ---
Hm, yeah. The trick of course is to not emit the jump to the default label.
For
the tablejump case it may be easiest to just use any other label. I'll see if
that works.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #9 from hjl dot tools at gmail dot com 2008-04-02 20:23 ---
(In reply to comment #8)
> Hm, yeah. The trick of course is to not emit the jump to the default label.
> For
> the tablejump case it may be easiest to just use any other label. I'll see if
> that works.
>
Can we
--- Comment #13 from bonzini at gnu dot org 2008-04-02 20:27 ---
Subject: Re: Native GCC no longer searches $prefix/lib for startfiles when run
from $objdir
> What's the test-case?
I'm talking of Greg's setting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-04-02 20:50
---
Ah, the following
/* Index jumptables from zero for suitable values of
minval to avoid a subtraction. */
if (! optimize_size
&& compare_tree_int (min
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-04-02 20:56
---
For now I have a compile-time testcase - I'll try to transform it into a
runtime one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35800
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-02 21:18 ---
This is because we don't run PRE at -Os, as PRE usually increases code-size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35806
--- Comment #12 from hp at gcc dot gnu dot org 2008-04-02 21:43 ---
In reply to comment #10)
> relies on the created hole be filled by the default_label - but that is
> NULL here. So, the following looks like the right fix here:
>
> Index: stmt.c
That's too late; it's not enough for c
--- Comment #14 from carlos at codesourcery dot com 2008-04-02 21:52
---
Using the sysroot flags is the solution for Greg's scenario. In fact I would
say it makes his job easier.
I'm looking for a test case that doesn't mangle GCC's configure files, and is
broken with no easy alternati
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-04-02 22:07
---
Created an attachment (id=15416)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15416&action=view)
patch
Patch in comment #10 passed bootstrap & regtest on x86_64-unknown-linux-gnu,
the
attached patch should
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-04-02 22:10
---
The fallback_label parm of try_casesi needs ATTRIBUTE_UNUSED for ! HAVE_casesi
targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35800
--- Comment #17 from janis at gcc dot gnu dot org 2008-04-02 22:11 ---
I tried the patch referenced in comment #16 on powerpc64-linux. It allows
tests pr11832.c and pr33009 to pass, but adding -frtl-abstract-sequences to all
tests causes several tests to timeout on compilation, and gcc.
When developing an OS for the smallest Atmels (ATtiny861/461/21)
i observed a strange effect. Sometimes, depending on the optimization
choosen by gcc, the compiler generates code which cannot be correct
(in my view). Most of the time the code is not functional too.
The problem is that use of the
--- Comment #1 from ruud at betaresearch dot nl 2008-04-02 22:28 ---
Other versions of gcc (like 4.2.1 or 4.3.0) display the
same behavior, but not on the same testcase. A separate
testcase can be made for each version if needed.
Since i cannot attach a zip file, and i don't know how ot
--- Comment #2 from ruud at betaresearch dot nl 2008-04-02 22:39 ---
>From Andy H <[EMAIL PROTECTED]>
[avr-gcc-list] Incorrect code by gcc?
Not a bug
According to the sources you posted,
privQueuRequestBody
void privQueuRequestBody(uint8_t uiSlot, int8_t siFreeFilling, uint16_t
uiTi
1 - 100 of 131 matches
Mail list logo
