--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-31 08:17 ---
Fixed on the trunk, thanks.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #24 from ubizjak at gmail dot com 2008-01-31 08:21 ---
Author: hubicka
Date: Wed Jan 30 23:25:35 2008
New Revision: 131969
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131969
Log:
* gcc.c-torture/execute/pr34982.c: Add forgotten return 0.
Modified:
tru
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-31 08:30 ---
(In reply to comment #4)
> Reply to comment two:
>
> There is front-endery code to do "cond ? a : b" in the handling of missing
> optional dummy arguments. You can borrow from that.
>
I know about the TREE_SSA expre
--- Comment #4 from rsandifo at gcc dot gnu dot org 2008-01-31 09:26
---
Subject: Bug 34995
Author: rsandifo
Date: Thu Jan 31 09:25:52 2008
New Revision: 131976
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131976
Log:
gcc/
PR rtl-optimization/34995
* reload.c
--- Comment #5 from rsandifo at gcc dot gnu dot org 2008-01-31 09:28
---
Patch applied. Thanks to Ian for the review.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #39 from rguenther at suse dot de 2008-01-31 09:39 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression]
performance loss (not inlining as much??)
On Wed, 30 Jan 2008, stevenb dot gcc at gmail dot com wrote:
>
>
> --- Comment #37 from stevenb dot gcc at gmail dot com 2008-
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-31 09:49 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
Hello,
I'd like to report that there is the ICE happened when the linux-2.6.23 NFS
code is compiled using gcc-4.0.0:
CC fs/nfs/nfs4proc.o
fs/nfs/nfs4proc.c: In function 'nfs4_proc_readdir':
fs/nfs/nfs4proc.c:2237: error: unrecognizable insn:
(insn:HI 205 202 207 12 (set (reg:SI 126 [ D.22481 ])
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-31 10:11 ---
Created an attachment (id=15062)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15062&action=view)
patch
"final" patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-31 10:12 ---
Testing on ppc-darwin appreciated ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
--- Comment #4 from dominiq at lps dot ens dot fr 2008-01-31 10:01 ---
After applying the patch in comment #2 on top of rev. 131968, I am not having
hanging so far, but apparently all the executables are timed out (?) after
having taken ~40s:
...
Executing on host: /opt/gcc/darwin_build
--- Comment #1 from yur at emcraft dot com 2008-01-31 09:59 ---
Created an attachment (id=15060)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15060&action=view)
This is the file, which produces the ICE described
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35039
--- Comment #2 from yur at emcraft dot com 2008-01-31 10:00 ---
Created an attachment (id=15061)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15061&action=view)
This is the dump of GCC-4.0.0 iterations when compiles the file which produce
the ICE
--
http://gcc.gnu.org/bugzill
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-31 10:35 ---
I suppose the static function
static const unsigned char *
read_uleb128 (const unsigned char *p, _uleb128_t *val)
{
in unwind-pe.h should be marked 'inline', otherwise it will be emitted
multiple times to the asm f
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-31 10:39 ---
Coverage and shared libraries do not mix easily.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35038
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-31 10:44 ---
The static size_of_encoded_value's are supposed to be mangled when --combine,
like size_of_encoded_value.12521 and on a simple testcase with --combine
on x86_64-linux/trunk they are.
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-31 10:35 ---
> After applying the patch in comment #2 on top of rev. 131968,
After a check, I realized that I applied the patch in the wrong directory, so
the behavior reported in comment #4 is for the unpatched rev. 131968.
--
REAL, DIMENSION(2,2), PARAMETER :: xyz = RESHAPE((/ 1,2,3,4 /), SHAPE(xyz))
END
This is accepted by gfortran and all other compilers Tobias tested. However,
neither of us is sure whether it's valid or not.
For any invalid example, see also: PR34495.
--
Summary: usage of init express
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2008-01-31 10:38
---
(In reply to comment #8)
> I'll respond to Jakub's latest comments before trying DJ's more recent patch.
> Running "getconf ARG_MAX" on my IRIX box, returns 20480, which is 20K.
> I believe this is the default, o
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-31 10:40 ---
Regressions should have a target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-31 10:43 ---
We need preprocessed source of nfs4proc.c which you'll get as nfs4proc.i if you
add -save-temps to the gcc command-line. Also please try 4.0.4 or a still
maintained release like 4.2.2.
--
rguenth at gcc dot gnu
--- Comment #4 from yur at emcraft dot com 2008-01-31 10:54 ---
Richard,
The gcc 4.2.2 successfully compiles this code without ICEs (see the item (c) in
my description of the ICE). As far as the preprocessed source of nfs4proc.c is
concerned, here it is...
Regards, Yuri
--
http://
--- Comment #5 from yur at emcraft dot com 2008-01-31 10:55 ---
Created an attachment (id=15063)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15063&action=view)
The preprocessed source of file which produces the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35039
--- Comment #8 from andreast at gcc dot gnu dot org 2008-01-31 11:12
---
bootstrap started on ppc-darwin.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-31 12:22 ---
I think this is valid. One has to read carefully what specification-part and
entity-decl means. I think after "integer(8)" the kind is known and in the next
specification part (e.g. for the dimension) one may use it;
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-31 12:28 ---
> bootstrap started on ppc-darwin.
After having applied the patch in the right directory and an incremental make
on Darwin9, I still ahve the same failures:
FAIL: PR9577 run
FAIL: longfield run
FAIL: shortfield run
--- Comment #10 from burnus at gcc dot gnu dot org 2008-01-31 12:46 ---
(In reply to comment #9)
> Sun f95 gives:
> Error 1078: scale factor out of range
> ifort gives:
>
g95 and openf95 give the same result as ifort:
While NAG f95 follows sunf95 by giving the run-
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-31 12:39 ---
I asked at comp.lang.fortran:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a05b8b177f2eb7b1/
--
burnus at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-31 12:39 ---
Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00373.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34910
--- Comment #10 from andreast at gcc dot gnu dot org 2008-01-31 12:51
---
You'd need at least a fresh build of libstdc++ and libjava. An incremental
build failed for me as well. So I have rm -rf'ed the two libraries. And I saved
a complete bootstrap :) That was for yesterdays trial.
Rig
--- Comment #11 from andreast at gcc dot gnu dot org 2008-01-31 13:30
---
Applying the patch from #5 on r131976
Results here:
/Volumes/development/gcc/head/gcc/libjava/jni.cc: In function 'T
extract_from_jvalue(const jvalue&) [with T = jboolean]':
/Volumes/development/gcc/head/gcc/lib
Andexpertness in wars or.
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-31 14:19
---
I guess this should be P1, ppc-darwin is still a secondary platform and we
shouldn't break its libjava ABI.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-31 13:59 ---
trans-decl has:
if (sym->attr.volatile_)
{
TREE_THIS_VOLATILE (decl) = 1;
new = build_qualified_type (TREE_TYPE (decl), TYPE_QUAL_VOLATILE);
TREE_TYPE (decl) = new;
}
However, variables w
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-31 14:14
---
Created an attachment (id=15064)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15064&action=view)
patch
D*mn. Try this one.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from bangerth at dealii dot org 2008-01-31 14:53 ---
This way you make the compiler believe that all the functions
are in a namespace when the compiler that compiled these functions
into a .dll assumed that they are not. This can't work.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-31 14:47 ---
Eh, how is this a regression? Was struct-reorg in 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35041
The following testcase fails for me when compiled with -O3 -fwhole-program
-fdump-ipa-all -combine -fipa-type-escape -fipa-struct-reorg
#include
typedef struct test_struct
{
int a;
int b;
} type_struct;
typedef type_struct **struct_pointer2;
struct_pointer2 str1;
int main()
{
int i, j;
--- Comment #5 from aldot at gcc dot gnu dot org 2008-01-31 15:05 ---
Works with gcc-4.1.2 (if one prunes the 'static' of the weakref; They were
required to be public back then):
$ gcc-4.1 pr35034-1.c pr35034-2.c -O0 -S -o - -combine -pipe
.file "pr35034-1.c"
.text
.gl
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-31 14:39 ---
Confirmed. ICEs with -O -fwhole-program -fipa-type-escape -fipa-struct-reorg
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
oded_value, .-size_of_encoded_value
.weakref__gthrw_pthread_once,pthread_once
.ident "GCC: (GNU) 4.3.0 20080131 (experimental)"
.section.note.GNU-stack,"",@progbits
--
aldot at gcc dot gnu dot org changed:
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-31 15:10 ---
Fails with 4.1.2 for me as well, with the static. w/o 4.1 complains
t1.c:5: error: '__gthrw_pthread_once' defined both normally and as an alias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
--- Comment #4 from olga at gcc dot gnu dot org 2008-01-31 15:18 ---
The following test fixes the problem. Under the testing now.
Index: ipa-struct-reorg.c
===
--- ipa-struct-reorg.c (revision 131976)
+++ ipa-struct-reorg.
--- Comment #9 from aldot at gcc dot gnu dot org 2008-01-31 15:18 ---
(In reply to comment #7)
> Fails with 4.1.2 for me as well, with the static. w/o 4.1 complains
>
> t1.c:5: error: '__gthrw_pthread_once' defined both normally and as an alias
>
Works flawlessly for me (without the
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-31 15:20
---
That's a accepts-invalid problem on 4.1, try the same thing with the reduced
testcase from comment #6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
--- Comment #3 from olga at gcc dot gnu dot org 2008-01-31 15:11 ---
(In reply to comment #2)
> Eh, how is this a regression? Was struct-reorg in 4.2?
Of course not.
Olga
--
olga at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-31 15:08 ---
Confirmed. The following also fails with optimization:
t1.c:
static void __attribute__((used))
size_of_encoded_value (void)
{
};
static int __gthrw_pthread_once __attribute__ ((__weakref__("pthread_once")));
t2.c:
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-31 15:11 ---
(In reply to comment #2)
> I suppose the static function
>
> static const unsigned char *
> read_uleb128 (const unsigned char *p, _uleb128_t *val)
> {
>
> in unwind-pe.h should be marked 'inline', otherwise it will b
Documentation states that the default value of -finline-limit is 600. However,
if -finline-limit=600 is actually used with -O3, the code size is much bigger
than if it weren't used with -O3. The real default value seems to be closer to
180.
Default values specified for max-inline-insns-single (450
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-31 15:54 ---
-finline-limit=N should be deprecated. It is an alias for --param
max-inline-insns-single=N/2 --param max-inline-insns-auto=N/2.
There is no real default, instead the defaults for max-inline-insns-single is
450, t
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-01-31 15:36
---
That one is not a regression. It happens because, when the a argument is an
assumed-shape array, gfc_return_by_reference() return 0 because
sym->attr.always_explicit is set for the function.
There are two interes
--- Comment #5 from ddenisen at altera dot com 2008-01-31 16:13 ---
> @emph{Note:} there may be no value to @option{-finline-limit} that results
> in default behavior.
That's also not user-friendly. When it is changed, it is not clear what is
"more aggressive" inlining and what is not.
--- Comment #6 from rguenther at suse dot de 2008-01-31 16:22 ---
Subject: Re: Documentation for -finline-limit is incorrect
On Thu, 31 Jan 2008, ddenisen at altera dot com wrote:
> --- Comment #4 from ddenisen at altera dot com 2008-01-31 16:12 ---
> > @emph{Note:} there may
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-31 16:05 ---
I agree, just the switch will have different effects with different releases.
I will correct the documentation to something like
@item [EMAIL PROTECTED]
@opindex finline-limit
By default, GCC limits the size of func
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #2 from ddenisen at altera dot com 2008-01-31 15:59 ---
(In reply to comment #1)
> -finline-limit=N should be deprecated. It is an alias for --param
> max-inline-insns-single=N/2 --param max-inline-insns-auto=N/2.
>
> There is no real default, instead the defaults for max-
--- Comment #4 from ddenisen at altera dot com 2008-01-31 16:12 ---
> @emph{Note:} there may be no value to @option{-finline-limit} that results
> in default behavior.
That's also not user-friendly. When it is changed, it is not clear what is
"more aggressive" inlining and what is not.
--- Comment #12 from rth at gcc dot gnu dot org 2008-01-31 16:34 ---
Looks like a bad REG_EQUAL note -- it's got a wrong (or confusing) mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #7 from ddenisen at altera dot com 2008-01-31 16:40 ---
If the default behaviour has to stay, then I think the option should be
removed. Having no option is better than having an option with an
unreproducible default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-31 17:23 ---
Reduced testcase:
typedef long unsigned int size_t;
typedef struct {
long double dat[2];
} gsl_complex_long_double;
typedef struct {
size_t size;
size_t stride;
long double *data;
} gsl_vector_co
--- Comment #13 from rth at gcc dot gnu dot org 2008-01-31 17:23 ---
Created an attachment (id=15066)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15066&action=view)
proposed fix
There's two things we can do. First, we could modify loop-iv.c to cope with
a CCmode REG_EQUAL note
1510 type = signed_type_for_types (TREE_TYPE (chrec_a), TREE_TYPE
(chrec_b));
1511 chrec_a = chrec_convert (type, chrec_a, NULL_TREE);
(gdb) p type
$4 = (tree) 0x0
and we then ICE in
#0 0x0064bc08 in fold_convert (type=0x0, arg=0x2aad7d1bb570)
at /space/rguenther/src/svn/t
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-31 17:15 ---
Created an attachment (id=15065)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15065&action=view)
testcase
-O -ftree-vectorize
a cross from x86_64 is enough to trigger the ICE.
reducing.
--
http://gcc.g
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-31 17:30 ---
Mine. I have a patch, defered for 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #61 from alond at il dot ibm dot com 2008-01-31 18:07 ---
> Done. Still have same fails on hppa2.0w-hp-hpux11.11.
Dave,
can you please perform an initial debugging?
I think it will make it easier to loacte the bug if we had some debugging
information, like where is the
fa
find_dead_or_set_registers uses mark_set_resources to determine if a register
is set, and if it is, it concludes that the register is before that set.
A register is also considered set when the set is inside a COND_EXEC, thus
delay slot scheduling can clobber values in registers that are supposed
t
--- Comment #1 from amylaar at gcc dot gnu dot org 2008-01-31 18:45 ---
Created an attachment (id=15067)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15067&action=view)
Test case
This is a test case, extracted from an ARC linux kernel.
--
http://gcc.gnu.org/bugzilla/show_bug
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #14 from andreast at gcc dot gnu dot org 2008-01-31 18:39
---
With the patch from #12:
=== libjava Summary ===
# of expected passes2550
Thanks again!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
--- Comment #6 from rth at gcc dot gnu dot org 2008-01-31 19:06 ---
Yes, closing as not-a-bug for 32-bit i386.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rsandifo at gcc dot gnu dot org 2008-01-31 19:27
---
Created an attachment (id=15068)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15068&action=view)
Patch that I intend to commit
Thanks for the testing. I went ahead and made the changes
I mentioned in comme
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-31 19:51 ---
Hi, namespace has nothing to do with the issue,
The problem can be summarized as follows:
if you have a declaration of the template function without always_inline and
the definition with, the instationation does not
--- Comment #4 from rsandifo at gcc dot gnu dot org 2008-01-31 19:28
---
Subject: Bug 34900
Author: rsandifo
Date: Thu Jan 31 19:28:03 2008
New Revision: 131983
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131983
Log:
gcc/
PR target/34900
* config/mips/mips.c
--- Comment #5 from rsandifo at gcc dot gnu dot org 2008-01-31 19:36
---
For the record, the patch logged by the previous comment
was to 4.3.0. It adds the missing mode I mentioned in
comment #2.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-31 20:07 ---
Subject: Bug 34936
Author: dgregor
Date: Thu Jan 31 20:06:33 2008
New Revision: 131984
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131984
Log:
2008-01-31 Douglas Gregor <[EMAIL PROTECTED]>
Ja
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-31 20:07 ---
Subject: Bug 34935
Author: dgregor
Date: Thu Jan 31 20:06:33 2008
New Revision: 131984
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131984
Log:
2008-01-31 Douglas Gregor <[EMAIL PROTECTED]>
Ja
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-31 20:07 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-31 20:08 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-31 21:10 ---
A patch for when trunk reopens.
Index: m4/shape.m4
===
--- m4/shape.m4 (revision 131915)
+++ m4/shape.m4 (working copy)
@@ -46,6 +46,7 @@ shape_'rtype_
--- Comment #2 from thomas at maier-komor dot de 2008-01-31 21:20 ---
Subject: Re: mipsel-elf fails to build on Solaris 10
rsandifo at gcc dot gnu dot org schrieb:
> --- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-25 10:08
> ---
> I'm not sure how we can make prog
--- Comment #3 from thomas at maier-komor dot de 2008-01-31 22:18 ---
Subject: Re: mipsel-elf fails to build on Solaris 10
rsandifo at gcc dot gnu dot org schrieb:
> --- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-25 10:08
> ---
> I'm not sure how we can make prog
--- Comment #64 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-31
22:18 ---
Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in
find_new_var_of_type, at ipa-struct-reorg.c:605
> Then, in the second loop, we load p[968].a and convert it to a float
> value of 3. We do
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-31 22:21 ---
Subject: Bug 34910
Author: pault
Date: Thu Jan 31 22:20:47 2008
New Revision: 131985
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131985
Log:
2008-01-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-31 22:23 ---
Fixed on trunk. Thanks for the hint, Daniel!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-31 22:25 ---
Answer (see link): All these are wrong per answer to an interpretation request:
6. INTEGER :: B = BIT_SIZE(B)
7. INTEGER :: B(BIT_SIZE(B))
8. INTEGER :: D = DIGITS(D)
9. INTEGER :: D(DIGITS(D))
10. REAL :: X = EP
--- Comment #62 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-31
22:00 ---
Subject: Re: wo_prof_two_strs.c:56: internal
compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
On Thu, 31 Jan 2008, alond at il dot ibm dot com wrote:
>
>
> --- Comment #61
--- Comment #7 from dfranke at gcc dot gnu dot org 2008-01-31 22:29 ---
Thanks for fixing :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34910
--- Comment #4 from rsandifo at gcc dot gnu dot org 2008-01-31 22:35
---
"thomas at maier-komor dot de" <[EMAIL PROTECTED]> writes:
> --- Comment #3 from thomas at maier-komor dot de 2008-01-31 22:18 ---
> Subject: Re: mipsel-elf fails to build on Solaris 10
>
> rsandifo at gc
--- Comment #5 from thomas at maier-komor dot de 2008-01-31 22:38 ---
Subject: Re: mipsel-elf fails to build on Solaris 10
rsandifo at gcc dot gnu dot org schrieb:
> --- Comment #4 from rsandifo at gcc dot gnu dot org 2008-01-31 22:35
> ---
> "thomas at maier-komor dot de" <[
The attached code, coming from the GNU libc (test-ifloat.c and
s_cacoshf.c) gives wrong results when compiled with gcc-4.3 and -O3. The
results are correct with gcc-4.3 and lower optimizations, or with gcc-4.2.
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --
--- Comment #1 from aurelien at aurel32 dot net 2008-01-31 22:52 ---
Created an attachment (id=15070)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15070&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
--- Comment #6 from rsandifo at nildram dot co dot uk 2008-01-31 22:55
---
Subject: Re: mipsel-elf fails to build on Solaris 10
"thomas at maier-komor dot de" <[EMAIL PROTECTED]> writes:
> One final question: can you tell me, what libssp is?
It's the run-time support for the stack-sm
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-31 22:55 ---
Does -fno-gcse-after-reload fix the miscompiling?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from thomas at maier-komor dot de 2008-01-31 22:56 ---
Subject: Re: mipsel-elf fails to build on Solaris 10
rsandifo at nildram dot co dot uk schrieb:
> --- Comment #6 from rsandifo at nildram dot co dot uk 2008-01-31 22:55
> ---
> Subject: Re: mipsel-elf fail
--- Comment #3 from aurelien at aurel32 dot net 2008-01-31 22:58 ---
Oops, the bug actually exist on *i386*, not on x86_64. I used the value from my
main installation and not from my i386 chroot.
Here are the correct specs:
Using built-in specs.
Target: i486-linux-gnu
Configured with:
--- Comment #4 from aurelien at aurel32 dot net 2008-01-31 22:59 ---
(In reply to comment #2)
> Does -fno-gcse-after-reload fix the miscompiling?
>
Yes that fixes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
--- Comment #26 from pault at gcc dot gnu dot org 2008-01-31 22:59 ---
Created an attachment (id=15071)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15071&action=view)
A fix for the PR
This is regtesting as I write. It fixes the first three PRs but not that of
comment #25. I be
# ls -l compile
-rw-r--r-- 1 bin bin 3707 Jul 13 2005 compile
Causes gcc configure tests to fail.
--
Summary: Toplevel compile script is not executable
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
1 - 100 of 129 matches
Mail list logo
