--- Comment #9 from jason at gcc dot gnu dot org 2006-08-29 07:10 ---
Subject: Bug 26670
Author: jason
Date: Tue Aug 29 07:10:38 2006
New Revision: 116556
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116556
Log:
PR c++/26670
* class.c (check_field_decls): Unset
--
Summary: TARGET_FUNCTION_VALUE not documented
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gc
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-08-29
07:55 ---
Harald,
In fixing PR28873, I have fixed this PR. Will
CALL ice(23.0) ! { dg-error "no specific subroutine" }
1
Error: There is no specif
Description of the problem:
I create module.cpp; which has a function labeled
__attribute__((constructor)).
If I link module.o directly; the function gets called.
If I make module.o into libmodule.a and then link libmodule.a, the
function does not get called.
Attached is the test c
This ICE arises:
bug2.f90: In function MAIN__:
bug2.f90:30: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:1665
when compiling the following code:
module modA
implicit none
private
public :: sub
interface sub
module procedure subA
module procedure subB
--- Comment #8 from aph at gcc dot gnu dot org 2006-08-29 10:08 ---
OK, I'm working on this. It looks like a regression from 4.1.1 -> 4.1.2.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-29
10:22 ---
I have just posted the fix to the fortran list.
Thanks for the report.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28873
--
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 #2 from bkoz at gcc dot gnu dot org 2006-08-29 10:36 ---
More info.
I was able to take mainline libstdc++ sources, modify limits,
--disable-visibility and then run check-compile on the same machine/os/sources
with both 4_1-branch and mainline (20060827).
The time just to c
--- Comment #9 from aph at gcc dot gnu dot org 2006-08-29 10:37 ---
OK, here it is:
old:
14: invokevirtual
17: checkcast
20: areturn
new:
14: invokevirtual
17: areturn
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-08-29 10:44 ---
Actually, this is -S, so not just compile only. Hmm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
The following IMHO valid testcase is rejected on mainline and the 4.1
branch since a couple of days:
template struct A;
template struct A {};
template struct A {};
A a;
bug
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
Alleged bug goes away if ommitting -fprefetch-loop-arrays.
Trying to compile binutils-2.17.50.0.3 (gdb-6.4 also exhibits this alleged bug)
with gcc-trunk from 20060828, i get errors of the form:
make[3]: Entering directory
`/root/src/buildroot/build_x86_64/binutils-2.17.50.0.3-target/libiberty'
i
--- Comment #1 from aldot at gcc dot gnu dot org 2006-08-29 12:46 ---
Created an attachment (id=12147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12147&action=view)
original unreduced testcase
Initial args used for unreduced testcase were:
gcc -O2 -fPIC -ftree-loop-optimize -f
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-08-29
13:05 ---
(In reply to comment #0)
Drew,
You are really uncovering them! A simplified version of your testcase that
produces the same fault is:
program test
type t
integer :: i
integer :: j
end type
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-08-29
13:09 ---
Created an attachment (id=12148)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12148&action=view)
Provisional fix for the problem
This is regtesting as I write but I have little doubt that this is
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-29
13:12 ---
(In reply to comment #2)
> Created an attachment (id=12148)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12148&action=view) [edit]
> Provisional fix for the problem
> This is regtesting as I write
Dnia wtorek, 29 sierpnia 2006 10:37, TongKe Xue napisał:
>If I make module.o into libmodule.a and then link libmodule.a, the
> function does not get called.
use -Wl,-whole-archive (man ld)
$ make
g++ module.cpp -c -O2
ar cq libmodule.a module.o
g++ test.cpp module.o -o from-object
g++ test.cpp -Wl,--whole-archive libmodule.a -Wl,--no-whole-archive \
-o from-lib
$ ./from-object
Yay life is good.
$ ./from-lib
Yay life is good.
#include "module.hpp"
#include
using namespace std;
--- Comment #10 from aph at gcc dot gnu dot org 2006-08-29 14:05 ---
class Psupersuper
{
}
class Psuper extends Psupersuper
{
}
class P extends Psuper
{
Psupersuper barf()
{
return new P();
}
}
class PR28663
{
static Psuper arse ()
{
return (P)new P().barf();
}
}
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #6 from luke dot powell at bjservices dot com 2006-08-29 14:21
---
(In reply to comment #5)
> Not reproducible.
>
> I built a m68k-elf toolchain on x86_64-pc-linux-gnu and compiled the testcase.
> No ICE was observed.
>
I am also seeing this bug with v4.1.1. My configure l
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-08-29 14:34 ---
Subject: Bug 28139
Author: amylaar
Date: Tue Aug 29 14:34:36 2006
New Revision: 116561
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116561
Log:
cp:
PR c++/28139
* except.c (expand_start_cat
--- Comment #4 from jakub at gcc dot gnu dot org 2006-08-29 14:35 ---
Playing with fold_builtin_mem*.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-08-29 14:41
---
The only reason for keeping the old predication-based code is that it can
handle an important case that the generic code cannot. Specifically, it can
conditionally skip a call to a function: this is not normally p
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-08-29 14:43 ---
I cannot reproduce the problem with neither of the testcases, neither on i686
nor from x86_64 crosscompiler. Could you please check whether it did not get
fixed in the meantime?
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from anlauf at gmx dot de 2006-08-29 14:46 ---
(In reply to comment #2)
> Error: There is no specific subroutine for the generic 'ice' at (1)
The new error message is rather terse but OK.
-Harald
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20067
--- Comment #7 from tbm at cyrius dot com 2006-08-29 14:53 ---
Yes, seems so - fails with 4.2.0 20060721, works with 4.2.0 20060819 on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27474
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-08-29 14:59 ---
SCCVN comes up with
Value numbers:
d_2 = c_1
c_7 = b_6
d_8 = b_6
c_10 = a_9
d_11 = a_9
where
# PRED: 3 (fallthru,exec) 4 (fallthru,exec)
# dD.1526_2 = PHI ;
# cD.1525_1 = PHI ;
...
As a result, once integr
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-08-29 15:02
---
Fixed on mainline; however, the problem was already present in 4.1, so we need
to decide if we want the patch in the 4.1 branch.
--
amylaar at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from aph at gcc dot gnu dot org 2006-08-29 15:06 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01085.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
I get a tree check error with -ftree-vectorize. It works with 4.0 but fails
with 4.1 and 4.2.
(sid)345:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -ftree-vectorize
-Os -c
oo2c-allocate.c
oo2c-allocate.c: In function 'Allocate__WriteStats':
oo2c-allocate.c:4: internal compiler error: tree
--- Comment #1 from tbm at cyrius dot com 2006-08-29 15:11 ---
Created an attachment (id=12149)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12149&action=view)
test case
Testcase from application "oo2c".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #15 from amylaar at gcc dot gnu dot org 2006-08-29 15:30
---
(In reply to comment #14)
> This works for me with a cross (and sysroot) to powerpc-linux-gnu from a
> i686-linux-gnu.
>
Is that a unified tree build with newlib?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #4 from pault at gcc dot gnu dot org 2006-08-29 15:49 ---
Since I just posted a patch for it, I might as well assign it to myself!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from pault at gcc dot gnu dot org 2006-08-29 15:50 ---
I believe that does it.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from hosking at cs dot purdue dot edu 2006-08-29 15:52
---
Sorry, my information was in error last time. It seems I got the src/dest
information wrong for the edge being split. The edge is between blocks 32 and
33 in the dump below:
;; Function TrestleGoo__PutProp (Tr
--- Comment #28 from amylaar at gcc dot gnu dot org 2006-08-29 15:53
---
Subject: Bug 17506
Author: amylaar
Date: Tue Aug 29 15:52:54 2006
New Revision: 116564
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116564
Log:
gcc:
2006-08-29 Nathan Sidwell <[EMAIL PROTECTED]>
The current implementation of -fstack-check-register doesn't work on m68k.
With -fstack-check-register=N, the m68k inserts stack checking code like
cmp.l %dN,%sp
trapcs
However, %dN isn't reserved in FIXED_REGISTER.
So the compiler would use %dN as an available regiter elsewhere.
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-29 16:29 ---
All the issues with dot product have been sorted, as far as I know.
Paul
--
pault 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
|
Compiler blows up on this function.
$ cat test.f
integer*4 function test(charr, charrlen)
character (len=*) :: charr
integer*4 charrlen, i
do i=1, charrlen
write (*,*) i, charr(i)
end do
end
$ gfortran -c test.f
test.f: In function 'test':
test.f:5: in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|x86_64-linux-gnu|
GCC host triplet|x86_64-linux-gnu|
Keywords
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-29 17:04 ---
*** This bug has been marked as a duplicate of 26197 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-08-29 17:04
---
*** Bug 27474 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
seen with current trunk and on the redhat/gcc-4_1-branch; works with the
gcc-4_1-branch. The files are rather large, please find them at
http://people.debian.org/~doko/tmp/help.tar.bz2
The code is taken from OOo 2.0.3.
Matthias
$ make
HelpCompiler.java HelpLinker.java HelpContentIdentifier.java
--- Comment #29 from nathan at gcc dot gnu dot org 2006-08-29 17:20 ---
(In reply to comment #28)
> 2006-08-29 Nathan Sidwell <[EMAIL PROTECTED]>
> J"orn Rennecke <[EMAIL PROTECTED]>
>
> PR tree-optimization/17506
> * tree-ssa.c (warn_uninit): If warning
--- Comment #12 from tromey at gcc dot gnu dot org 2006-08-29 17:27 ---
PR 28067 blocks this -- when merging the gcj-eclipse branch to trunk,
we should remove the workaround patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
Currently we error out if there is an assignment to a static final field
(in a .class file) which is not in the class' static initializer.
This constraint is apparently not enforced by the JDK -- meaning that
we reject class files which run on the JDK. Class files like this are
generated by retrow
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #2 from aldot at gcc dot gnu dot org 2006-08-29 18:11 ---
Also fails for native i686-linux-gnu with
gcc-4.2-20060829 -march=i686 -msse -O1 -fprefetch-loop-arrays
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from jason at gcc dot gnu dot org 2006-08-29 18:15 ---
Subject: Bug 26577
Author: jason
Date: Tue Aug 29 18:15:20 2006
New Revision: 116568
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116568
Log:
PR c++/26577
* cvt.c (convert_to_void): Don't au
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-29 19:02
---
This doesn't ICE for me with current mainline - I get the following error
messages:
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc:6: error: type/value mismatch at argument 1
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-08-29 19:07
---
This doesn't ICE for me with current mainline:
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
void bar()
bug.cc:2: error: no matching function for call to 'foo()'
Can anyone else
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-29 19:11
---
This doesn't ICE for me on current mainline:
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc:3: error: templates may not be 'virtual'
bug.cc:7: error: '' is not a valid type f
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #21 from guenter at roeck-us dot net 2006-08-29 19:12 ---
This bug fix causes severe problems with all e500 double precision floating
point code. It generates code such as :
...
evldd 9,104(31)
stw 9,112(31)
stw 10,116(31)
...
i.e., t
--- Comment #22 from dje at watson dot ibm dot com 2006-08-29 19:26 ---
Subject: Re: [4.1 Regression] returning constant double
One of the patterns probably needs a r->m case as well, but we
need a testcase to figure out which one.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #3 from kargl at gcc dot gnu dot org 2006-08-29 19:47 ---
Subject: Bug 28866
Author: kargl
Date: Tue Aug 29 19:47:31 2006
New Revision: 116570
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116570
Log:
2006-08-29 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #4 from kargl at gcc dot gnu dot org 2006-08-29 19:49 ---
Patch committed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from steven at gcc dot gnu dot org 2006-08-29 19:52 ---
I seem to have accepted this bug instead of confirming it. That wasn't my
intention.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #23 from guenter at roeck-us dot net 2006-08-29 20:23 ---
Here is a test case:
double calc(double val, double *result)
{
double f = val - (double)((int)val);
*result = val - f;
if (!val)
return val - *result;
else
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #24 from dje at gcc dot gnu dot org 2006-08-29 20:49 ---
new codegen problem
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|RES
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-08-29 20:51
---
(In reply to comment #23)
> Here is a test case:
Thanks for the small testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #26 from dje at gcc dot gnu dot org 2006-08-29 21:09 ---
The RTL looks like:
(code_label 34 33 35 2 "" [0 uses])
(note 35 34 0 NOTE_INSN_BASIC_BLOCK)
;; return val
(insn 36 35 37 (set (subreg:DF (reg:DI 136) 0)
(reg:DF 122 [ val ])) -1 (nil)
(nil))
(insn 37 36
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-29 21:26 ---
Confirmed: changing the substring reference to the unambiguous
write (*,*) i, charr(i:i)
gets rid of the problem. Apparently, vene though charr is scalar, the
reference is being interpreted as an array refere
--- Comment #3 from kargl at gcc dot gnu dot org 2006-08-29 21:39 ---
We no longer get an ICE with
GNU F95 version 4.2.0 20060828 (experimental) (x86_64-unknown-freebsd7.0)
gfortran -o z ji.f90
In file ji.f90:6
MODULE PROCEDURE sreal, schar, sint => sreal
internal compiler error: in ix86_secondary_memory_needed, at
config/i386/i386.c:15963
is triggered by my (invalid) attempt at x86-64 inline assembly:
static inline void* CMPXCHG_PTR( void* volatile * dest,
void* newValue, void* comp ) {
void
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-08-29 21:58
---
*** Bug 28893 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 2006-08-29 21:58 ---
It is the same as PR 26655, the "a" is causing it.
*** This bug has been marked as a duplicate of 26655 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Attached code file is compiled.
Here is the critical passage:
inline void taskSignal(void)
{
unsigned char i;
PORTB |= _BV(PB4);
PORTB |= _BV(PB5);
PORTB |= _BV(PB6);
i=0;
do
{
i+=2;
}
while( i<245 );
i=0;
do
{
i+=3;
}
while( i<245 );
POR
--- Comment #1 from ralf-engels at gmx dot de 2006-08-29 22:30 ---
Created an attachment (id=12150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12150&action=view)
source code which is compiled strangely.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28894
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|tree-optimization |target
http:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-29 22:34 ---
264: 8a 5f subir24, 0xFA ; 250
That looks fine for me since it is r24 = r24 - -2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28894
template
class final
{
struct workaround { typedef T type; };
friend class workaround::type;
final() { };
final( final const& ) { };
};
struct Foo : virtual public final {};
void test() { Foo foo; }
$7.1.5.3/2 prohibits such code and Comeau compiler reports an error:
error: typedef
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-29 23:21 ---
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1520.pdf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28895
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-29 23:22 ---
Related to PR 22047.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28895
--- Comment #3 from fang at csl dot cornell dot edu 2006-08-29 23:23
---
Hi, see PR 21498.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28895
--- Comment #21 from jason at gcc dot gnu dot org 2006-08-30 02:59 ---
Subject: Bug 26577
Author: jason
Date: Wed Aug 30 02:59:14 2006
New Revision: 116576
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116576
Log:
PR c++/26577
* cvt.c (convert_to_void): Don't au
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-30 03:28 ---
Devang,
Why did you remove your self, you caused this regression.
Yes you might not work on GCC any more for Apple but that does not take you
away from fixing the regression you caused. I am a bit upset at this be
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-08-30 03:32
---
(In reply to comment #15)
> (In reply to comment #14)
> > This works for me with a cross (and sysroot) to powerpc-linux-gnu from a
> > i686-linux-gnu.
> >
> Is that a unified tree build with newlib?
No it is not,
--- Comment #30 from pinskia at gcc dot gnu dot org 2006-08-30 03:33
---
I will file tomorrow the bug reports about the cases I mentioned to the patches
list.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 03:36 ---
Seems like you should also be doing -ffixed-reg=N. Maybe that should be
mentioned in the docs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28889
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 03:38 ---
Been fixed since at least "4.2.0 20060826".
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-30 03:39 ---
Been fixed since at least "4.2.0 20060826".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 03:41 ---
Fixed since at least "4.2.0 20060826".
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-08-30 03:42
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENE
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-30 03:54
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 04:01 ---
A NON_LVALUE_EXPR is getting into the way:
(gdb) p debug_tree(max)
unit size
align 32 symtab 0 alias set -1 precision 32 min max
pointer_to_this >
readonly constant invariant
arg
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-30 04:33 ---
Subject: Bug 28349
Author: pinskia
Date: Wed Aug 30 04:33:10 2006
New Revision: 116577
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116577
Log:
2006-08-29 Andrew Pinski <[EMAIL PROTECTED]>
PR c+
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-30 04:33 ---
Fixed on the mainline, will most likely Apply this patch to the 4.1 branch this
long weekend.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from pault at gcc dot gnu dot org 2006-08-30 04:37 ---
Fixed on trunk and 4.1 again
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-30 04:41 ---
I had meant to close this as fixed the last time.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 04:43 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-30 04:44 ---
(In reply to comment #6)
> As a result, once integrated into PRE/FRE, it will eliminate uses of the d_2
> phi with the c_1 phi, which is what you want.
Thanks, I was expecting that the new VN would fix this.
--
--- Comment #2 from pault at gcc dot gnu dot org 2006-08-30 04:46 ---
(In reply to comment #1)
> Confirmed: changing the substring reference to the unambiguous
> write (*,*) i, charr(i:i)
> gets rid of the problem. Apparently, vene though charr is scalar, the
> reference is bei
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 05:01 ---
Confirmed, this was added on the mainline but an easy search of ChangeLog could
not find it because the changeLog was incomplete:
* target-def.h: New target hook function_value.
Note I think it is the same
1 - 100 of 123 matches
Mail list logo
