--- Comment #19 from aaronavay62 at aaronwl dot com 2008-05-04 07:32
---
On i386-pc-mingw32, these are the tests that fail on 4.3.0.
Hanging idle (at 0% CPU):
c74004a
c940010
c94002f
c94002g
c94008a
c953001
Hanging busy (at 100% CPU):
c960004
c974001
c974002
c974013
--
aaronavay62
--- Comment #1 from irar at il dot ibm dot com 2008-05-04 08:00 ---
I don't get the ICE: revision 134926, x86_64-linux, same flags. The loop in
line 14 gets vectorized.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
I just tried to compile the GNU C compiler version 4.4 snapshot 20080502
with the Intel C compiler.
The Intel C compiler said
../../src/gcc-4.4-20080502/gcc/config/i386/i386.c(20878): warning #175:
subscript out of range
The source code is
pat = GEN_FCN (icode) (target, args[0].op, args[1
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-05-04 08:06 ---
Subject: Bug 35990
Author: tkoenig
Date: Sun May 4 08:06:02 2008
New Revision: 134927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134927
Log:
2008-05-04 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-05-04 09:03 ---
Fixed on trunk.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|
--- Comment #7 from dominiq at lps dot ens dot fr 2008-05-04 09:59 ---
If I am not mistaken, the patch for libgfortran/intrinsics/pack_generic.c has
not been commited yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35990
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-04 10:47 ---
I can reproduce this on i686 with -O3 -mfpmath=sse -msse2 (r134902):
#1 0x086d592d in vectorizable_assignment (stmt=0xb7c9dcb0, bsi=0xbff3b824,
vec_stmt=0xbff3b7c0, slp_node=0xab9ca08)
at /home/richard/src
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-05-04 10:15 ---
Subject: Bug 35990
Author: tkoenig
Date: Sun May 4 10:14:49 2008
New Revision: 134928
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134928
Log:
2008-05-04 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #9 from tkoenig at netcologne dot de 2008-05-04 10:15 ---
Subject: Re: run-time abort for PACK of run-time zero
sized array
On Sun, 2008-05-04 at 09:59 +, dominiq at lps dot ens dot fr wrote:
>
> --- Comment #7 from dominiq at lps dot ens dot fr 2008-05-0
--- Comment #3 from irar at il dot ibm dot com 2008-05-04 11:13 ---
In my dump this stmt is vectorized ok:
bug.F:14: note: -->vectorizing statement: D.1055_23 = ((D.1054_22))
bug.F:14: note: transform statement.
bug.F:14: note: vect_is_simple_use: operand ((D.1054_22))
bug.F:14: not
--- Comment #4 from irar at il dot ibm dot com 2008-05-04 11:21 ---
If it is really a try to SLP, I think this patch will fix the ICE:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 134926)
+++ t
--- Comment #5 from d at domob dot eu 2008-05-04 11:23 ---
Now I believe I found out where the problem might be; as far as I can tell,
gfc_array_ctor_strlen in trans-array.c is the point where we determine the
length of the elements of a character array constructor; in the loop over all
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-04 11:24 ---
Created an attachment (id=15574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574&action=view)
vectorizer dump
Attached. The last line indeed hints at SLP:
t.f90:14: note: -->vectorizing SLP node star
--- Comment #6 from irar at il dot ibm dot com 2008-05-04 11:49 ---
(In reply to comment #5)
> Created an attachment (id=15574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574&action=view) [edit]
> vectorizer dump
>
> Attached.
Thanks!
> The last line indeed hints at SLP:
--- Comment #7 from rguenther at suse dot de 2008-05-04 11:53 ---
Subject: Re: [4.4 regression] internal compiler
error: in vectorizable_assignment, at tree-vect-transform.c:3671
On Sun, 4 May 2008, irar at il dot ibm dot com wrote:
> --- Comment #6 from irar at il dot ibm dot co
--- Comment #8 from irar at il dot ibm dot com 2008-05-04 12:07 ---
(In reply to comment #7)
> It does - and the loop is vectorized. But it looks like a hack ;)
It is not. We actually do this in all vectorizable_...() that support SLP.
SLP currently does not support multiple types (I
--- Comment #9 from rguenther at suse dot de 2008-05-04 12:22 ---
Subject: Re: [4.4 regression] internal compiler
error: in vectorizable_assignment, at tree-vect-transform.c:3671
On Sun, 4 May 2008, irar at il dot ibm dot com wrote:
> --- Comment #8 from irar at il dot ibm dot co
--- Comment #10 from irar at il dot ibm dot com 2008-05-04 12:26 ---
(In reply to comment #9)
> Can you give the patch bootstrap & test? I'll pre-approve
> it here.
Sure, for both trunk and 4.3.1, I guess.
Ira
>
> Thanks,
> Richard.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cg
The program shows a problem where the compiler
seems to do 16-bit arithmetic on a 15-bit field.
In the program below,
None of the 'false' conditions within a 'doRead'
should be generated by the arguments passed but
when compiled with -O2 the tests yield false
but when compiled with -O work fine.
--- Comment #11 from rguenther at suse dot de 2008-05-04 12:41 ---
Subject: Re: [4.4 regression] internal compiler
error: in vectorizable_assignment, at tree-vect-transform.c:3671
On Sun, 4 May 2008, irar at il dot ibm dot com wrote:
>
>
> --- Comment #10 from irar at il dot ib
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-05-04 12:58
---
A testcase is difficult since it cannot be isolate from other optimisations.
The the problem is "obvious". It can be seen by doing RTL dump and looking at
preferred register classes.
Any source operand that
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-05-04 14:46 ---
Created an attachment (id=15575)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15575&action=view)
proposed patch
Testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35995
--- Comment #1 from hjl at gcc dot gnu dot org 2008-05-04 15:22 ---
Subject: Bug 36121
Author: hjl
Date: Sun May 4 15:22:05 2008
New Revision: 134932
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134932
Log:
2008-05-04 H.J. Lu <[EMAIL PROTECTED]>
PR target/36121
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-04 15:27 ---
Fixed by
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00206.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-04 15:35 ---
*** This bug has been marked as a duplicate of 36100 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #9 from hjl dot tools at gmail dot com 2008-05-04 15:35 ---
*** Bug 36118 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
gcc dislikes this prefix to a program depending on C99 integer division:
$ cat bug.c
#if 1/-2 || (-1)/2
# error "integer division rounding away from zero not supported"
#endif
$ gcc-4.2.2 -fsyntax-only bug.c
bug.c:1:12: warning: integer overflow in preprocessor expression
bug.c:1:21: warning: inte
Hi,
It seems to have some regression in gcc 4.3, visible on arm targets as well as
x86_64.
I originally already reported it to Debian bugtracking system
[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472867]
I tested it against the latest gcc snapshot:
gcc (GCC) 4.3.1 20080501 (prerelease)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-04 16:34 ---
Pointers types overflow is undefined which is what you are seeing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-04 16:45 ---
(In reply to comment #2)
> shouldn't gcc report a warning in this case ?
Maybe, but really depending on undefined behavior is bad too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
--- Comment #2 from cyprien+gccbug at cypou dot net 2008-05-04 16:41
---
shouldn't gcc report a warning in this case ?
because silently entering an infinite loop is not very kind...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
--- Comment #4 from kargl at gcc dot gnu dot org 2008-05-04 17:01 ---
(In reply to comment #2)
> shouldn't gcc report a warning in this case ?
>
> because silently entering an infinite loop is not very kind...
>
If your code invokes undefined behavior, how is gcc going
to read your mi
--- Comment #5 from cyprien+gccbug at cypou dot net 2008-05-04 17:03
---
Now, this code should not rely on undefined behaviour:
extern void func(int,void*);
void test()
{
register long *foo = (long*) (4*sizeof(*foo)) - 1;
register int index;
for(index=0;index<4;index++)
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-05-04 17:09 ---
>Now, this code should not rely on undefined behaviour:
It does because incrementing or decrementing to a NULL Pointer is undefined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++
-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/o
pt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/g
--- Comment #1 from danglin at gcc dot gnu dot org 2008-05-04 17:15 ---
27_io/basic_istream/extractors_arithmetic/char/9555-ia.cc and
27_io/basic_istream/extractors_arithmetic/wchar_t/9555-ia.cc
also fail with the same error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
--- Comment #7 from cyprien+gccbug at cypou dot net 2008-05-04 17:31
---
it's right, using --foo unstead of foo-- gives a better result.
But it does not make me happy (about the possibility of a bug)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
--- Comment #2 from danglin at gcc dot gnu dot org 2008-05-04 18:03 ---
Breakpoint 1, verify_gimple_expr (expr=0x7ae94318)
at ../../gcc/gcc/tree-cfg.c:3962
3962 gcc_unreachable ();
(gdb) bt
#0 verify_gimple_expr (expr=0x7ae94318) at ../../gcc/gcc/tree-cfg.c:3962
#1 0x003cf
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-05-04 18:11 ---
sum, product etc are also affected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35995
--- Comment #1 from tromey at gcc dot gnu dot org 2008-05-04 18:43 ---
Note that this was fixed by:
2007-05-02 Eric Christopher <[EMAIL PROTECTED]>
* expr.c (num_div_op): Don't overflow if the result is
zero.
This is in 4.3.
--
tromey at gcc dot gnu dot org chang
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-04 18:47 ---
Closing as fixed then.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-05-04 19:08 ---
Subject: Bug 35995
Author: tkoenig
Date: Sun May 4 19:07:28 2008
New Revision: 134934
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134934
Log:
2008-05-04 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-05-04 19:08 ---
Fixed on trunk.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|
--- Comment #26 from jakub at gcc dot gnu dot org 2008-05-04 19:47 ---
Created an attachment (id=15576)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15576&action=view)
gcc44-pr36090.patch
Patch I've bootstrapped on 4.3 branch on {i386,x86_64,ppc,ppc64}-linux, no
regressions.
Not
--- Comment #27 from dje at gcc dot gnu dot org 2008-05-04 20:08 ---
I was planning to add asserts in print_operand_address ensuring that the
operand was the TOC SYMBOL_REF.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #8 from cyprien+gccbug at cypou dot net 2008-05-04 20:13
---
On some embedded machines, the SDRAM lays on 0x address. So it is not
so meaningless to increment or decrement from/to NULL pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124
--- Comment #33 from tkoenig at gcc dot gnu dot org 2008-05-04 20:57
---
Subject: Bug 32770
Author: tkoenig
Date: Sun May 4 20:56:30 2008
New Revision: 134936
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134936
Log:
2008-05-04 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-05-04 21:29 ---
The problem is that we set ila1 to a null pointer if its
size is zero:
D.647 = size.6 * 4;
if (D.647 < 0)
{
_gfortran_runtime_error (&"Attempt to allocate a negative amount of
memory."[1]{lb: 1
--- Comment #3 from danglin at gcc dot gnu dot org 2008-05-04 21:43 ---
(gdb) p debug_tree (rhs)
unit size
align 64 symtab 20 alias set 29 canonical type 60340e80 precision 128
pointer_to_this reference_to_this
>
addressable used TF file
/test/gnu/gcc/gcc/
--- Comment #5 from sam at gcc dot gnu dot org 2008-05-04 23:03 ---
Yes, I've seen this, but I expect an answer to another one very soon, which
would make the test case pass (I think the test case has the error message at
the right place), that's why I haven't fixed it yet.
--
http:
$ gcc -O1 -c -o vc1.o vc1.i
In file included from E:/msys/1.0/usrc/ffmpeg/src/libavcodec/mpegvideo.h:33,
from E:/msys/1.0/usrc/ffmpeg/src/libavcodec/vc1.c:31:
E:/msys/1.0/usrc/ffmpeg/src/libavcodec/bitstream.h: In function 'decode012':
E:/msys/1.0/usrc/ffmpeg/src/libavcodec/bitstre
--- Comment #1 from nightstrike at gmail dot com 2008-05-04 23:35 ---
Created an attachment (id=15577)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15577&action=view)
Preprocessed source
This is the preprocessed source that is used in the compilations mentioned in
the PR.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 00:12 ---
Both a and a.143 are marked as addressable. Interesting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
--- Comment #8 from hutchinsonandy at gcc dot gnu dot org 2008-05-05 01:15
---
The following information from Kenny Zadeck, shows why the solution does not
work. This limitation is not avoidable at the present time without causing
compilation time/memory regressions on other targets. S
> /usr/local/gcc44/bin/gcc -v
[..]
gcc version 4.4.0 20080503 (experimental) (GCC)
> gcc -O3 -mfpmath=sse -fno-pic -fno-tree-vectorize -S himenoBMTxps.c
With -O2/-O3, the inner loop in jacobi() in this program ends containing a lot
of this:
movss _p-4(%edi,%edx,4), %xmm0
movl
--- Comment #1 from astrange at ithinksw dot com 2008-05-05 02:12 ---
Created an attachment (id=15578)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15578&action=view)
source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
--
astrange at ithinksw dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
--- Comment #2 from astrange at ithinksw dot com 2008-05-05 02:12 ---
Created an attachment (id=15579)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15579&action=view)
compiled at -O3 on darwin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
--- Comment #3 from astrange at ithinksw dot com 2008-05-05 02:13 ---
Created an attachment (id=15580)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15580&action=view)
and at -Os
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36127
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Target Milestone|--- |4.4.0
http:/
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 04:50 ---
This is most likely a dup of bug 33887 and has been fixed for GCC 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36122
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 04:59 ---
Here is a further reduced testcase:
typedef struct {
int lock;
int pad0_;
} mutex_t;
static mutex_t main_arena;
void __malloc_check_init()
{
for(;;)
__asm__ __volatile__ ("": "+m"(main_arena.lock) );
}
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:03 ---
If we had put the size in pointer to the array type, then this gets foldded.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36084
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.4
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-05 05:05 ---
*** This bug has been marked as a duplicate of 36111 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-05 05:05 ---
*** Bug 36092 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:10 ---
Even if the code assembled for 3.3.6 or 3.4.x, the weak reference was not being
emitted. So this is not a regression really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35999
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:13 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:20 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36011
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 05:22 ---
This is not a bug, the names are in the reserved implementation namespace.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
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-05-05 05:27 ---
The std:: namespace is supposed to be exposed and is marked as such in the
libstdc++ headers.
So I don't think this is a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-05 05:28 ---
> ERF, ERFC, GAMMA, and LOG_GAMMA returned NaN for REAL*10 inputs in
> my test. EXPONENT returned garbage for REAL*10 and FRACTION
There is another thing which has to be addressed. On Windows there seems to be
no "l
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-05-05 05:28 ---
As mentioned in the other bug report, it is hard to handle the -fabi-version=2
version of the mangled string. We handle correctly the correctly mangled
already.
So closing as won't fix.
--
pinskia at gcc dot gn
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36053
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36009
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3/4.4 regression]Used|[4.3/4.4 regression] Used
|function interface bug
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36007
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36095
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:36 ---
This is expected behavior. We no longer error out about an unkown warning
option unless there is an error/warning already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:38 ---
The warning looks fine for me, it is saying selog_on(&sel) will never be
executed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35973
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 05:40 ---
Sorry I mean:
[t.c : 24] D.1191_5 = sel.enabled;
[t.c : 24] iftmp.1_6 = D.1191_5 != 42;
As far as I can tell this warning is correct.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:42 ---
IIRC -fobjc-gc is only useful for the NeXT runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35996
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-05 05:46 ---
(In reply to comment #2)
> The problem is that we set ila1 to a null pointer if its
> size is zero: [...]
> It isn't clear to me why we do this (maybe as a debugging aid?).
Well, if we don't assign anything, the memo
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:49 ---
*** Bug 35893 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 05:49 ---
We have a predict_expr.
*** This bug has been marked as a duplicate of 35736 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 05:50 ---
I don't think this is true any more. The tuples branch should now be able to
bootstrap without any issues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnosti
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:51 ---
Actually it does not make sense to have any other value than 3 here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35501
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 05:54 ---
I don't think this is a real bug. Also patches should be off of the trunk and
submitted to [EMAIL PROTECTED]
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 05:55 ---
The assembler is crashing and not GCC. So this is best to file this bug to
binutils project.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35547
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-05 06:06 ---
(In reply to comment #1)
> > ERF, ERFC, GAMMA, and LOG_GAMMA returned NaN for REAL*10 inputs in
> > my test. EXPONENT returned garbage for REAL*10 and FRACTION
>
> There is another thing which has to be addressed. On
1 - 100 of 107 matches
Mail list logo
