--- Additional Comments From pault at gcc dot gnu dot org 2005-08-05 06:08
---
This is amusing.
integer o(4), b, c
COMMON /IBM/ o
EQUIVALENCE (o(1),b),(C,o(4))
o(3)=1
CALL MYSUB1
CALL MYSUB2
END
subroutine MYSUB1
integer o (4
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-05 05:47
---
> I am a little busy, but I might be able to try some more.
> However, I have no real experience programming compilers,
> and I don't think I understand the
Join the club!
> intended logic of the algorithm
--- Additional Comments From adah at netstd dot com 2005-08-05 05:41
---
(In reply to comment #44)
> | However, I still believe it is the problem of the compilers.
> Please take ti to the C++ standard committee. The behaviour is that
> described by the standard. If you don't like it, h
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-05 05:36
---
I think that 4.0 opened and closed more than once since I promised to complete
this!
Fixed on mainline and 4.02
--
What|Removed |Added
---
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
05:32 ---
Subject: Bug 22010
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-05 05:31:44
Modified files:
gcc/fortran: module
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
05:13 ---
Confirmed:
t.cc:14: error: types mismatch in comparsion
long intD.5
intD.2
D.1753 != -1;
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
05:11 ---
Confirmed;
t.cc:10: error: statement types mismatch
# VUSE ;
# VUSE ;
iftmp.0D.1797_19 = *D.1804_18;
sD.1725:: * const
intD.2 (*__vtbl_ptr_typeD.1484) (void)
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
05:10 ---
Confirmed.
There is also another fortran front bug/tree-opt:
store-ccp does not remove the extra load:
# j.0_2 = V_MUST_DEF ;
j.0 = -1;
# j.1_4 = V_MUST_DEF ;
j.1 = &__label_001000;
# SFT.5_
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:50 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:47 ---
Confirmed, -O1 -ftree-loop-linear is needed to reproduce the bug.
The full error:
t.c: In function 'foo':
t.c:3: error: statement types mismatch
lletmp.33D.1335_13 = 0;
unsigned intD.3
intD.0
t.c:3: error:
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-08-05
04:46 ---
> Just a note for fullness, this was caused by the patch which fixed PR 19296.
Right. The annoying thing is that it is in 3.3.6 too so I think someone should
fix the typo on the 3.3 branch too.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:46 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:46 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:25 ---
Fixed. Thanks Ira.
--
What|Removed |Added
Status|ASSIGNED|R
--
Bug 22368 depends on bug 22526, which changed state.
Bug 22526 Summary: vectorizer produces mis-match types in conditionals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22526
What|Old Value |New Value
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:24 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:22 ---
(In reply to comment #1)
> DOM seems to be innocent here.
Hmm, VRP gets it correct, in that there are no warnings for the following code:
void __show_backtrace(void *rw)
{
if (rw == 0) return;
L0:;
i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:10 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:02 ---
I don't think this is a bug as A will be tried to be instantiating while
trying to convert it from float.
ICC gives the same result as GCC, an error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2322
--- Additional Comments From mark at codesourcery dot com 2005-08-05 03:49
---
Subject: Re: error: '' is/uses anonymous type'
sethml at google dot com wrote:
> --- Additional Comments From sethml at google dot com 2005-08-05 03:43
> ---
> The C++ working group examined this i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:48 ---
To suspend it as the DR is still in drafting.
--
What|Removed |Added
Status|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:48 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From sethml at google dot com 2005-08-05 03:43
---
The C++ working group examined this issue in April as core language issue 488:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#488
They tentatively concluded that type deduction should fail in this
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:43 ---
Fixed by:
2005-08-04 Jan Hubicka <[EMAIL PROTECTED]>
* profile.c (branch_prob): Split edges with goto locus on them
to get proper line counts.
* tree-cfg.c (make_cond_expr_edges):
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:40 ---
Just a note for fullness, this was caused by the patch which fixed PR 19296.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:35 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:32 ---
*** Bug 23243 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 03:14
---
No, because you still need to use "Q" to get a register that may be used
with a low-part. Even on i486.
--
What|Removed |Added
--
--- Additional Comments From jzampier at gmail dot com 2005-08-05 02:58
---
Created an attachment (id=9434)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9434&action=view)
The offending code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23244
The iterators over hash_map behave in a manner inconsistent with the other
std::map, std::list, etc... data structures. This can cause segfaults which are
hard to root-cause. Sample Code Included with additional information:
Specifically, the iterators over hash_map require the 'first' datamember
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
02:42 ---
Subject: Bug 21529
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-05 02:42:07
Modified files:
gcc: ChangeLog params.def params.h tree-sr
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 02:34
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
02:33 ---
Subject: Bug 21291
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-05 02:33:11
Modified files:
gcc: Change
--- Additional Comments From ianw at gelato dot unsw dot edu dot au
2005-08-05 02:17 ---
Subject: Re: Invalid %sil register chosen when dereferenced pointer used in
inline asm with -O0
On Fri, Aug 05, 2005 at 01:35:51AM -, pinskia at physics dot uc dot edu
wrote:
> On Aug 4, 2005
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-05
01:35 ---
Subject: Re: New: Invalid %sil register chosen when dereferenced pointer used
in inline asm with -O0
On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au
wrote:
> /* this one doesn't
On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au
wrote:
/* this one doesn't */
__asm__ __volatile__("xchgb %0, %1"
: "=r"(old), "=m"(*newp)
: "0"(0xff), "m"(*newp) : "memory");
This is not a bug.
r is selecting %sil which is a valid register for x86_64.
"r" is
Hi,
See the following snippet
[EMAIL PROTECTED]:~$ gcc-snap -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,obj-c++,ada,treelang
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls
--enable-__
--- Additional Comments From jconner at apple dot com 2005-08-05 00:17
---
I believe I have tracked down the root of this behavior to an invalid
transformation in simplify_comparison
(from combine.c). See email thread starting here:
http://gcc.gnu.org/ml/gcc/2005-08/msg00159.html
-
--
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
The following test code incorrectly generates an assertion failure on gcc
mainline and 4.0.1:
#include
struct fbs {
unsigned char uc8;
} fbs1 = {255};
void testfn ( struct fbs *fbs_ptr )
{
if ((fbs_ptr->uc8 != 255) && (fbs_ptr->uc8 != 0))
assert(0);
}
int main (int argc, char *argv[])
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04
23:55 ---
Known.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Eve
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-04
23:37 ---
Subject: Bug 21291
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-04 23:37:00
Modified files:
gcc: ChangeLog tree-outof-ssa.c
Added fil
--
Bug 20126 depends on bug 22425, which changed state.
Bug 22425 Summary: [4.1 regression] ICE in loop_givs_rescan, at loop.c:5521
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425
What|Old Value |New Value
-
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-08-04 23:09 ---
Fixed by this patch:
2005-07-14 Alexandre Oliva <[EMAIL PROTECTED]>
Ulrich Weigand <[EMAIL PROTECTED]>
PR target/20126
* loop.c (loop_givs_rescan): Do
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
22:49 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
22:41 ---
This works in "4.1.0 20050802".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
22:11 ---
TER will not work at -O0 though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 22:03
---
I'm testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gree
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-04 22:03
---
Andrew, can you have a look at why this isn't being TER'ed back into the
asm_expr? It's not a 100% ideal solution to this problem, but I'll guess
that it'll handle at least some of the cases including this one.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:57 ---
This looks like a target issue.
--
What|Removed |Added
Component|tree-optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:56 ---
This looks like a target issue.
--
What|Removed |Added
Component|tree-optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:45 ---
This is a classpath issue
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:41 ---
I think the easy fix would change Makefile.am.
The following line:
JAVAC = $(srcdir)/split-for-gcj.sh && $(MAKE) -f $(srcdir)/Makefile.gcj \
GCJ='$(GCJ)' compile_classpath='$(top_builddir):$(compile_clas
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:38 ---
CC tromey.
--
What|Removed |Added
CC||tromey at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:38 ---
Oh, this is truely part of classpath.
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:32 ---
Confirmed, reduced testcase:
static __attribute__ ((__section__ (".init.data"))) char *message;
static __attribute__ ((__section__ (".init.data"))) int (*actions[])(void) = {};
void unpack_to_rootfs(void)
{
FAIL: gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997
transformation on insn
(a new test) appeared on mainline on 20050802 on hppa2.0w-hpux and hppa64-hpux.
gcc-testresults shows it also failing on hppa-linux.
--
Summary: gcc.dg/tree-prof/val-prof-5.c scan-tr
FAIL: gcc.c-torture/execute/pr23135.c execution, -Os
(a new test) have appeared on mainline on 20050804 on ia64-hp-hpux11.23, both
-mlp64 and -milp32.
--
Summary: gcc.c-torture/execute/pr23135.c execution fails
Product: gcc
Version: 4.1.0
Status
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
20:58 ---
Reducing.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-04 20:48
---
The reason that we're rejecting the "m" alternative is that we've expanded
"+mr"(blen) to
(set (reg/v:SI 60 [ blen.25 ])
(asm_operands:SI ("") ("=mr") 2 [
--- Additional Comments From pluto at agmk dot net 2005-08-04 20:40 ---
Created an attachment (id=9433)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9433&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
$ gcc initramfs.i -O2 -c -funit-at-a-time
(...)
init/initramfs.c: At top level:
init/initramfs.c:10: error: message causes a section type conflict
init/initramfs.c:33: error: head causes a section type conflict
init/initramfs.c:80: error: ino causes a section type conflict
init/initramfs.c:
--- Additional Comments From dnovillo at redhat dot com 2005-08-04 19:24
---
Subject: Re: [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
On Thu, Aug 04, 2005 at 07:18:13PM -, dank at kegel dot com wrote:
> In general, once a ten-line testcase is found, do these get add
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
19:23 ---
(In reply to comment #8)
> In general, once a ten-line testcase is found, do these get added
> to the gcc regression testsuite as a matter of course?
In general once the fix is found, it will be added to th
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-04
19:22 ---
When the patch that fixes a bug is put into GCC the testcases go in as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
--- Additional Comments From dank at kegel dot com 2005-08-04 19:18 ---
In general, once a ten-line testcase is found, do these get added
to the gcc regression testsuite as a matter of course?
We would be happy to submit patches to add these to the test suite, but
we don't have copyrigh
--- Additional Comments From danalis at cis dot udel dot edu 2005-08-04
19:16 ---
For the record the reduced test case was derived from h07.cpp of bench++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
18:43 ---
Reduced testcase:
enum eumtype { ENUM1, ENUM2 };
void g(const eumtype kind );
void f(long i);
void g(const eumtype kind)
{
if ((kind != ENUM1) && (kind != ENUM2))
f(kind);
}
--- the tree before VRP:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
18:31 ---
Confirmed, reducing a little further.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-04
18:17 ---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00283.html.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-04
18:16 ---
Subject: Bug 22037
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-04 18:16:41
Modified files:
gcc: ChangeLog passes.c tree-cfg.c
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-08-04 18:04 ---
Subject: Re: PCH largefile test fails on various platforms
> My patch added the largefile test to the 3.4 branch. I don't think that
> failing
> a new test can be called a regression. I expect t
--- Additional Comments From uttamp at us dot ibm dot com 2005-08-04 17:57
---
(In reply to comment #1)
> Confirmed, reduced testcase:
> double func ( double a, double b, double c)
> {
> double y0;
> if(a==0.0) {
> y0 = -c/b;
> return y0;
> }
> y0 = -c/b;
> return
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
17:55 ---
Confirmed, reduced testcase:
double func ( double a, double b, double c)
{
double y0;
if(a==0.0) {
y0 = -c/b;
return y0;
}
y0 = -c/b;
return y0;
}
--
What|Removed
--- Additional Comments From ian at airs dot com 2005-08-04 17:54 ---
My patch added the largefile test to the 3.4 branch. I don't think that failing
a new test can be called a regression. I expect that the compiler would have
failed the test before, too, it's just that nobody knew abou
Following test program causes an internal compiler error,
$ cat y.c
double func ( double a, double b, double c)
{
double x0, x1, y0, y1;
int type = 0;
double ar;
if(b==0.0){
x0 = -c/a;
return( x0 > 1.0? 1.0 : ( x0 < 0.0 ? 0.0: x0));
}
if(a==0.0) {
y0 = -c/b;
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-08-04 17:41 ---
Subject: Re: PCH largefile test fails on various platforms
> Log message:
> ./
> PR pch/14400
> Backport from mainline:
With this change largefile.c now fails on hppa2.0w-hp-hpux
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-04 17:06 ---
(In reply to comment #3)
> Try killing the peephole2 for this. Somebody elses cost-metric should force
> the constant into a register for the move ...
Killing the peephole2 would just produce the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
16:15 ---
Confirmed, I wish loop.c would go away.
--
What|Removed |Added
Known to fail|
--
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |200
This testcase causes an ICE at -O2:
void foo (volatile long long *x)
{
while (*x)
{
*x = 0;
*((volatile char *) 0) = 0;
}
}
with:
error: unrecognizable insn:
(insn:HI 25 21 27 2 (set (mem/v:QI (subreg:SI (reg:DI 124) 4) [0 S1 A8])
(subreg:QI (reg:DI 124) 7)) -1 (ni
--- Additional Comments From rofi at ya dot com 2005-08-04 15:59 ---
Created an attachment (id=9431)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9431&action=view)
Failing case with an optional commented checking part
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
gcc version 4.1.0 20050730 (experimental)
The following two DATA statements are rejected by gfortran because "J" is not
considered a valid primary in those expressions although it is the variable of
another enclosing data-implied-do.
PROGRAM p
REAL :: ONE_ARRAY(100, 100)
INTEGER :: K, J
D
when cross compiling the gcc 4.0.2 on a i686-pc-linux-gnu with
intel: binutils 2.16.1 - compiled with gcc 4.1.0
mips: binutils 2.16.1 - compiled with gcc 4.1.0
the following error occures:
/home/pfl/gnu/mips-sgi-irix6.5/bin/ld: unrecognized option '-_SYSTYPE_SVR4'
/home/pfl/gnu/mips-sgi-irix6.5/
--- Additional Comments From jlquinn at gcc dot gnu dot org 2005-08-04
15:34 ---
Unfortunately, I no longer have access to the test box, so I can't verify if
it's
working now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 15:26
---
The relevant part of the JLS is section 15.12.1 @
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#20448
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
15:23 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 15:07
---
Backtrace:
#0 0x08066846 in java_complete_lhs (node=0x0) at
/var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11665
#1 0x08066757 in java_complete_tree (node=0x0) at
/var/tmp/porta
--
What|Removed |Added
OtherBugsDependingO||18131, 23220
nThis||
Keywords||
The following file is miscompiled by gcj -C:
public class Outer extends Thread {
public class Inner extends Thread {
private Inner () {
start ();
}
}
}
It uses the wrong "this" to call start():
Outer$Inner(Outer);
Code:
0: aload_0
1: aload_1
2: putfield
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-08-04
13:36 ---
(In reply to comment #13)
> Strength reduction already happens before loop unrolling, but I guess
> there could still be new opportunities after loop unrolling. Not sure
> how significant that would be.
--- Additional Comments From gdr at integrable-solutions dot net
2005-08-04 13:26 ---
Subject: Re: SFINAE bug
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| IIRC SFINAE does not mean not instantiating the template class.
That is true. However, the real issue has noth
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
13:14 ---
*** Bug 23222 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15247
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
13:14 ---
fmovdne %fcc1, %f50, %f8
Yep this is still a dup of bug 15247.
*** This bug has been marked as a duplicate of 15247 ***
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04
13:10 ---
Strength reduction already happens before loop unrolling, but I guess
there could still be new opportunities after loop unrolling. Not sure
how significant that would be.
For the number of loop iteratio
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
13:07 ---
IIRC SFINAE does not mean not instantiating the template class.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
13:04 ---
Confirmed, a regression from 3.0.4 and 2.95.3.
--
What|Removed |Added
Status|UNC
1 - 100 of 118 matches
Mail list logo
