[Bug target/19623] ICE: compiling SPECfp2000 benchmark fails in 191.fma3d with -ftree-vectorizer

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-02-13 09:29 
---
Actually, I misread the function I was supposed to be looking for loops in.
We do in fact vectorize 21 loops in beam_stress_integration.  So... WORKSFORME.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19623

[Bug target/19934] New: [4.0 regression] [alpha-linux] bootstrap error linking libgcj

[debian-gcc at lists dot debian dot org]

2005-02-12, the link error is known on mips{,el}-linux, first time I see it on
alpha-linux as well.

  Matthias

Creating list of files to link...
/bin/sh ./libtool --tag=CXX --mode=link
/build/buildd/gcc-snapshot-20050212/build/gcc/xgcc -shared-libgcc
-B/build/buildd/gcc-snapshot-20050212/build/gcc/ -nostdinc++
-L/build/buildd/gcc-snapshot-20050212/build/alpha-linux-gnu/libstdc++-v3/src
-L/build/buildd/gcc-snapshot-20050212/build/alpha-linux-gnu/libstdc++-v3/src/.libs
-B/usr/lib/gcc-snapshot/alpha-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/alpha-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/alpha-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/alpha-linux-gnu/sys-include
-L/build/buildd/gcc-snapshot-20050212/build/alpha-linux-gnu/libjava -mieee -g
-O2  -o libgcj.la -objectlist libgcj.objectlist \
external/sax/libsax_convenience.la external/w3c_dom/libw3c_convenience.la
../libffi/libffi_convenience.la  ../boehm-gc/libgcjgc_convenience.la
gnu/regexp/MessagesBundle.properties.lo
gnu/regexp/MessagesBundle_fr.properties.lo
org/ietf/jgss/MessagesBundle.properties.lo  \
-rpath /usr/lib/gcc-snapshot/lib -rpath /usr/lib/gcc-snapshot/lib  -lpthread
./libltdl/libltdlc.la -lz -version-info `grep -v '^#'
../../../src/libjava/libtool-version` 
creating reloadable object files...
creating a temporary reloadable object file: .libs/libgcj.la-2.o
ld -r -o .libs/libgcj.la-1.o .libs/prims.o .libs/jni.o .libs/exception.o
.libs/link.o .libs/defineclass.o .libs/interpret.o .libs/verify.o
gnu/gcj/.libs/natCore.o gnu/gcj/convert/.libs/JIS0208_to_Unicode.o
gnu/gcj/convert/.libs/JIS0212_to_Unicode.o 
[...]
gnu/xml/xpath/.libs/Predicate.o gnu/xml/xpath/.libs/Path.o
gnu/xml/xpath/.libs/OrExpr.o 
ld -r -o .libs/libgcj.la-2.o gnu/xml/xpath/.libs/LangFunction.o
gnu/xml/xpath/.libs/StartsWithFunction.o
gnu/xml/xpath/.libs/SubstringAfterFunction.o gnu/xml/xpath/.libs/FloorFunction.o
gnu/xml/xpath/.libs/NotFunction.o gnu/xml/xpath/.libs/Root.o
gnu/xml/xpath/.libs/PositionFunction.o gnu/xml/xpath/.libs/VariableReference.o
gnu/xml/xpath/.libs/DocumentOrderComparator.o
gnu/xml/xpath/.libs/LocalNameFunction.o
gnu/xml/xpath/.libs/NamespaceUriFunction.o
gnu/xml/xpath/.libs/TranslateFunction.o gnu/xml/xpath/.libs/FalseFunction.o
gnu/xml/xpath/.libs/AndExpr.o gnu/xml/xpath/.libs/XPathParser.o
gnu/xml/xpath/.libs/NamespaceTest.o gnu/xml/xpath/.libs/ConcatFunction.o
gnu/xml/xpath/.libs/NameTest.o gnu/xml/xpath/.libs/CountFunction.o
gnu/xml/xpath/.libs/IdFunction.o gnu/xml/xpath/.libs/LastFunction.o
gnu/xml/xpath/.libs/XPathTokenizer.o gnu/xml/xpath/.libs/Steps.o
gnu/xml/xpath/.libs/TrueFunction.o gnu/xml/xpath/.libs/BooleanFunction.o
gnu/xml/xpath/.libs/ParenthesizedExpr.o gnu/xml/xpath/.libs/XPathImpl.o
gnu/xml/xpath/.libs/Selector.o gnu/xml/xpath/.libs/RoundFunction.o
gnu/xml/xpath/.libs/SubstringBeforeFunction.o gnu/xml/xpath/.libs/Function.o
gnu/xml/xpath/.libs/CeilingFunction.o gnu/xml/xpath/.libs/RelationalExpr.o
gnu/xml/xpath/.libs/FunctionCall.o gnu/xml/xpath/.libs/NodeTypeTest.o
gnu/xml/xpath/.libs/ArithmeticExpr.o gnu/xml/xpath/.libs/Test.o
gnu/xml/xpath/.libs/ContainsFunction.o gnu/xml/pipeline/.libs/EventFilter.o
gnu/xml/pipeline/.libs/NSFilter.o gnu/xml/pipeline/.libs/XsltFilter.o
gnu/xml/pipeline/.libs/ValidationConsumer.o
gnu/xml/pipeline/.libs/PipelineFactory.o gnu/xml/pipeline/.libs/TextConsumer.o
gnu/xml/pipeline/.libs/LinkFilter.o gnu/xml/pipeline/.libs/TeeConsumer.o
gnu/xml/pipeline/.libs/DomConsumer.o gnu/xml/pipeline/.libs/EventConsumer.o
gnu/xml/pipeline/.libs/WellFormednessFilter.o
gnu/xml/pipeline/.libs/XIncludeFilter.o gnu/xml/pipeline/.libs/CallFilter.o
gnu/xml/aelfred2/.libs/XmlParser.o gnu/xml/aelfred2/.libs/XmlReader.o
gnu/xml/aelfred2/.libs/JAXPFactory.o gnu/xml/aelfred2/.libs/ContentHandler2.o
gnu/xml/aelfred2/.libs/SAXDriver.o gnu/xml/util/.libs/XCat.o
gnu/xml/util/.libs/DomParser.o gnu/xml/util/.libs/XMLWriter.o
gnu/xml/util/.libs/Resolver.o gnu/xml/util/.libs/DoParse.o
gnu/xml/util/.libs/XHTMLWriter.o gnu/xml/util/.libs/SAXNullTransformerFactory.o
gnu/xml/dom/.libs/DomCDATA.o gnu/xml/dom/.libs/DomXPathNSResolver.o
gnu/xml/dom/ls/.libs/DomLSEx.o gnu/xml/dom/ls/.libs/FilteredSAXEventSink.o
gnu/xml/dom/ls/.libs/DomLSSerializer.o gnu/xml/dom/ls/.libs/DomLSInput.o
gnu/xml/dom/ls/.libs/DomLSOutput.o gnu/xml/dom/ls/.libs/SAXEventSink.o
gnu/xml/dom/ls/.libs/DomLSParser.o gnu/xml/dom/ls/.libs/ReaderInputStream.o
gnu/xml/dom/ls/.libs/WriterOutputStream.o gnu/xml/dom/.libs/DomElement.o
gnu/xml/dom/.libs/DomNsNode.o gnu/xml/dom/.libs/DomAttr.o
gnu/xml/dom/.libs/DomPI.o gnu/xml/dom/.libs/DTDAttributeTypeInfo.o
gnu/xml/dom/.libs/DomDocumentBuilder.o gnu/xml/dom/.libs/DTDElementTypeInfo.o
gnu/xml/dom/.libs/DomEx.o gnu/xml/dom/.libs/DomDocument.o
gnu/xml/dom/.libs/DomXPathExpression.o
gnu/xml/dom/.libs/DomDocumentConfiguration.o gnu/xml/dom/.libs/Consumer.o
gnu/xml/dom/.libs/DomComment.o gnu/xml/dom/.libs/DomCharacterData.o
gnu/xml/dom/.libs/DomExtern.o gnu/xml/dom/.libs/DomEntityReference.o
gnu/xml/dom/.libs/DomNamedNodeMap.o gnu/xm

[Bug libstdc++/11706] std::pow(T, int) implementation pessimizes code

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-13 
10:25 ---
Subject: Bug 11706

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-13 10:25:02

Modified files:
libstdc++-v3   : ChangeLog 
libstdc++-v3/include/c_std: std_cmath.h 
Added files:
libstdc++-v3/testsuite/26_numerics/cmath: powi.cc 

Log message:
2005-02-13  Richard Guenther  <[EMAIL PROTECTED]>
Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/11706
* include/c_std/std_cmath.h (pow): Use __builtin_powi[lf]
for integer overloads.

* testsuite/26_numerics/cmath/powi.cc: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2893&r2=1.2894
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/c_std/std_cmath.h.diff?cvsroot=gcc&r1=1.17&r2=1.18
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/26_numerics/cmath/powi.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11706

[Bug libstdc++/11706] std::pow(T, int) implementation pessimizes code

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-02-13 10:26 
---
Fixed for 4.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11706

[Bug regression/19935] New: unexpected "bx lr" in arm mode.

[pluto at pld-linux dot org]

I have a simple testcase:   
   
void test()   
{   
}   
   
# arm-linux-gcc test.c -S -O2 produces:   
   
test:   
@ args = 0, pretend = 0, frame = 0   
@ frame_needed = 0, uses_anonymous_args = 0   
@ link register save eliminated.   
@ lr needed for prologue   
mov pc, lr   
   
   
# arm-linux-gcc test.c -S -O2 -mcpu=arm7tdmi-s produces:   
   
test:   
@ args = 0, pretend = 0, frame = 0   
@ frame_needed = 0, uses_anonymous_args = 0   
@ link register save eliminated.   
@ lr needed for prologue   
bx  lr   
   
-mthumb-interwork is disabled by default (vide man).   
why gcc4 produces "bx lr" ? (gcc34 works fine).  
  
# arm-linux-gcc -v 
Reading specs from /usr/lib/gcc/arm-linux/4.0.0/specs 
Configured with: ../configure --prefix=/usr 
--with-sysroot=/home/users/pluto/rpm/BUILD/gcc-4.0-20050130/fake-root 
--infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin 
--libdir=/usr/lib --libexecdir=/usr/lib --disable-shared --disable-threads 
--enable-languages=c,c++ --enable-c99 --enable-long-long --with-gnu-as 
--with-gnu-ld --with-system-zlib --with-multilib 
--with-sysroot=/home/users/pluto/rpm/BUILD/gcc-4.0-20050130/fake-root 
--without-x --target=arm-linux --host=i686-pld-linux --build=i686-pld-linux 
Thread model: single 
gcc version 4.0.0 20050130 (experimental)

-- 
   Summary: unexpected "bx lr" in arm mode.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-linux
  GCC host triplet: i686-linux
GCC target triplet: arm-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19935

[Bug fortran/19936] New: confused error message about implied do loop

[Thomas dot Koenig at online dot de]

$ cat implied_parameter.f90
program main
  integer, parameter :: i=4
  print *,(/(i,i=1,4)/)
end program main
$ gfortran implied_parameter.f90
 In file implied_parameter.f90:3

  print *,(/(i,i=1,4)/)
   1
Error: Syntax error in COMPLEX constant at (1)
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050212 (experimental)

-- 
   Summary: confused error message about implied do loop
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19936

[Bug target/17551] m68hc11: ICE: unrecognizable insn

[ciceron at gcc dot gnu dot org]

--- Additional Comments From ciceron at gcc dot gnu dot org  2005-02-13 
11:16 ---
The compiler crashes because the GCSE pass generates an invalid insn:

(insn 138 10 108 0 (nil) (set (reg:SI 61)
(reg/v:SI 55)) -1 (nil)
(nil))

and this is caused by handle_avail_exp()  which uses gen_rtx_SET () to
make the copy.  This is correct for QI and HI modes but fails with SI/DI modes
because the HC11 port needs a more complex move (with a PARALLEL and a scratch).
Jeff Law comment in gcse.c (arround lines 3472):

  /* ??? If the change fails, we return 0, even though we created
 an insn.  I think this is ok.  */

is wrong.  The change indeed failed but the insn remains and it's not valid
so it crashes later on.

Using gen_move_insn() fixed the problem.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ciceron at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17551

[Bug target/11519] When Building m68hc11: Internal compiler error: in print_operand_address

[ciceron at gcc dot gnu dot org]

--- Additional Comments From ciceron at gcc dot gnu dot org  2005-02-13 
11:42 ---
I'm not able to reproduce the problem neither on 3.3.5 nor on 3.4 branch.
 


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ciceron at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11519

[Bug pch/14940] PCH largefile test fails on various platforms

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-02-13 
11:52 ---
> This is now "fixed" on the PA.  You might look at pa-host.c to if the
> adopted work around might help other ports.

Alas, that doesn't work on SPARC/Solaris.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-13 
12:49 ---
Subject: Bug 19319

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-13 12:49:34

Modified files:
libmudflap : ChangeLog 
Added files:
libmudflap/testsuite/libmudflap.c++: pass55-frag.cxx 

Log message:
2005-02-13  Frank Ch. Eigler  <[EMAIL PROTECTED]>

PR mudflap/19319
* testsuite/libmudflap.c++/pass55-frag.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/ChangeLog.diff?cvsroot=gcc&r1=1.48&r2=1.49
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/testsuite/libmudflap.c++/pass55-frag.cxx.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

[fche at redhat dot com]

--- Additional Comments From fche at redhat dot com  2005-02-13 12:50 
---
Thank you, Jason!

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319

[Bug tree-optimization/19917] [4.0 regression] Weak const function mishandled inside loop

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-02-13 13:12 ---
I have successfully bootstrapped gcc and glibc with this patch. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19917

[Bug target/19933] Problem with define of HUGE_VAL in math_c99.

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|preprocessor|target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933

[Bug libgcj/19934] [4.0 regression] [alpha-linux] bootstrap error linking libgcj

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
13:55 ---
Confirmed.
See  for a possible 
patch and 
discussion.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |libgcj
 Ever Confirmed||1
   Keywords||build
   Last reconfirmed|-00-00 00:00:00 |2005-02-13 13:55:12
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19934

[Bug target/19935] [4.0 Regression] unexpected "bx lr" in arm mode.

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|regression  |target
Summary|unexpected "bx lr" in arm   |[4.0 Regression] unexpected
   |mode.   |"bx lr" in arm mode.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19935

[Bug fortran/19936] confused error message about implied do loop

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
14:11 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-02-13 14:11:10
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19936

[Bug tree-optimization/19792] Missed optimizations due to signedness in the way

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-02-13 14:17 
---
The testcase in this PR was reduced from ggc-page.c:ggc_alloc_typed_stat.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19792

[Bug fortran/19928] Reference of constant derived type component causes failure

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-02-13 
14:24 ---
No derived type is necessary:
$ cat pr19928.f90
subroutine pr19928
  character :: signal_names(10)*16
  signal_names = ''
  write (*,*) signal_names(:)(1:4)
end subroutine pr19928
$ gfortran pr19928.f90
pr19928.f90: In function 'pr19928':
pr19928.f90:4: internal compiler error: in gfc_conv_constant, at
fortran/trans-const.c:344
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050212 (experimental)


-- 
   What|Removed |Added

OtherBugsDependingO||19276
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19928

[Bug c++/19317] [4.0 Regression] removing a temporary return value when we cannot

[mueller at kde dot org]

--- Additional Comments From mueller at kde dot org  2005-02-13 14:59 
---
bug has been fixed by  
  
2005-02-13  Jason Merrill  <[EMAIL PROTECTED]>  
  
PR mudflap/19319  
* gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return  
slot explicit.  
  
PR c++/16405  
* fold-const.c (fold_indirect_ref_1): Split out from...  
(build_fold_indirect_ref): Here.  
(fold_indirect_ref): New fn.  
* tree.h: Declare it.  
* gimplify.c (gimplify_compound_lval): Call fold_indirect_ref.  
(gimplify_modify_expr_rhs): Likewise.  
(gimplify_expr): Likewise.  
  
can anyone add the testcase to the regression testsuite please? 
 
it seems to me however the above commit caused another regression, I get 
other miscompilations now.  
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317

[Bug c++/19317] [4.0 Regression] removing a temporary return value when we cannot

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
15:40 ---
(In reply to comment #7)
> it seems to me however the above commit caused another regression, I get 
> other miscompilations now.  

More than just that it causes a bootstrap to fail (I think you must have just 
did a build and not a full 
bootstrap).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317

[Bug c/19937] New: [4.0 regression] Wrong loop exit

[schwab at suse dot de]

$ cat loop.c   
typedef __SIZE_TYPE__ size_t;   
extern void abort (void);   
extern size_t strlen (const char *);   
extern int strncmp (const char *, const char *, size_t);   
int foo (const char *name)   
{   
  static const char *debug_sec_names [] =   
{   
  ".debug",   
  ".gnu.linkonce.wi.",   
  ".line",   
  ".stab"   
};   
  int i;   
  int flags = 0;   
   
  for (i = sizeof (debug_sec_names) / sizeof (debug_sec_names[0]); i--;)   
if (strncmp (name, debug_sec_names[i], strlen (debug_sec_names[i])) == 0)   
  break;   
   
  if (i >= 0)   
flags |= 0x1;   
  return flags;   
}   
   
int main (void)   
{   
  if (foo (".interp") == 0x1)   
abort ();   
  return 0;   
}   
$ gcc -O2 loop.c   
$ ./a.out   
Aborted

-- 
   Summary: [4.0 regression] Wrong loop exit
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

[Bug c/19937] [4.0 regression] Wrong loop exit

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
16:25 ---
Confirmed, looking for where it is miscompiled.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-13 16:25:13
   date||
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
16:44 ---
Reduced testcase:
void abort (void);
int g(void)
{
  return 1;
}
int main (void)
{   
  int i;
  for (i = 4; i--;)   
if (g () == 0)   
  break;
  if (i >= 0)   
abort ();   
  return 0;   
}


-- 
   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
  Component|c   |tree-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

[Bug tree-optimization/14303] [tree-ssa] gcc.c-torture/execute/20020720-1.c is not fully folded

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2005-02-13 
16:45 ---
 Fixed in the last patch.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14303

[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
16:52 ---
I think this is an ivopt bug:
  if (i_3 != 4294967295) goto ; else goto ;


i_3 is signed but the expression (I think), 4294967295, is unsigned, maybe we 
are missing a 
fold_convert.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-02-13 
17:25 ---
Andy, the patch needs a ChangeLog and needs to be posted to gcc-patches. I 
suggest you to explicitly CC the AVR maintainers when you post the patch. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251

Re: aren't specialized templates templates?

[Martin Sebor]

Tim Janik wrote:
hi all.
the code snippet below is extracted from a much more
complicated piece of code. basically the problem is that
g++ (3.3 and 3.4) demand different typedef syntax inside
template bodies, depending on whether full or partial
specialization is used.
is this really the correct behaviour and standard conform?
(to me it seems, line20 should still be considered part of
a template and thus accept the "typename")
Unfortunately, it is the correct behavior. But because it makes
typename hard to use, a relaxation of the rule that would make
your code well-formed is now being considered. For the status
of this proposed change see:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#382
Martin
snip-
template
struct Base {
  typedef C* Iterator;
};
template
struct Derived : Base {
  typedef typename Base::Iterator Iterator;
};
#define BASE_ITER(BASE) typename BASE :: Iterator
template
struct Derived : Base {
  typedef BASE_ITER (Base) Iterator; // line15
};
template<>
struct Derived : Base {
  typedef BASE_ITER (Base) Iterator;   // line20
};
// test.cc:20: error: using `typename' outside of template
snip-
---
ciaoTJ

[Bug fortran/19928] Reference of constant derived type component causes failure

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-02-13 
17:50 ---
Looking at PR 17123 a bit more closely, I think that
this is a duplicate.

Thomas

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19928

[Bug tree-optimization/19938] New: Missed jump threading opportunity due to signedness difference

[kazu at cs dot umass dot edu]

Consider:

void
foo (int length, int *array)
{
  int i;

  for (i = 0; i < length; i++)
{
  if (array[i] != 0)
{
  int j;

  for (j = 0; j < length; j++)
;

  if (j != length)
array[i] = 0;
}
}
}

A part of the last tree SSA form looks like so:

:;
  j_16 = j_15 + 1;
  D.1187_17 = (unsigned int) length_4;
  if (j_16 != D.1187_17) goto ; else goto ;

:;
  if (length_4 != j_16) goto ; else goto ;

Note that when we take edge from  to , we know that we leave 
for  because length_4 == D.1187_17 == j_16, but we don't notice that
because a sign-changing cast is in the way.

CSE pickes up this optimization oportunity.

Reduced from reload.c:find_reloads.

-- 
   Summary: Missed jump threading opportunity due to signedness
difference
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 19721,19794
 nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938

[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

  BugsThisDependsOn||19938


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

  BugsThisDependsOn||19938


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794

[Bug fortran/19936] confused error message about implied do loop

[sgk at troutmask dot apl dot washington dot edu]

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2005-02-13 18:00 ---
For a long winded explanation and patch, see

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00643.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19936

[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
18:04 ---
Confirmed, but note the following in the tree level is really invalid:
  D.1187_17 = (unsigned int) length_4;
  if (j_16 != D.1187_17) goto ; else goto ;

as j_16 is signed and we are comparing against an unsigned type.

In which case this is an IV-OPT problem, very closely related to PR 19937 
(which by the way is a wrong-
code regression).

If someone would add more checking we would have caught this earlier.

-- 
   What|Removed |Added

  BugsThisDependsOn||19937
   Severity|enhancement |normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-13 18:04:35
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938

[Bug tree-optimization/19939] New: -finline-functions inhibits tail recursion accumulation optimization

[falk at debian dot org]

[EMAIL PROTECTED]:/tmp% cat test.c
unsigned long ipow(unsigned long a, unsigned long b) {
if (b == 0)
return 1;
else
return a * ipow(a, b - 1);
}

[EMAIL PROTECTED]:/tmp% gcc -c -O2 test.c && objdump -d test.o  

test.o: file format elf64-alpha

Disassembly of section .text:

 :
   0:   01 00 1f 20 lda v0,1
   4:   05 00 20 e6 beq a1,1c 
   8:   1f 04 ff 47 nop
   c:   00 00 fe 2f unop
  10:   ff ff 31 22 lda a1,-1(a1)
  14:   00 04 10 4c mulqv0,a0,v0
  18:   fd ff 3f f6 bne a1,10 
  1c:   01 80 fa 6b ret

The recursion was nicely transformed to a branch.

[EMAIL PROTECTED]:/tmp% gcc -c -O2 test.c -finline-functions && objdump -d 
test.o

test.o: file format elf64-alpha

Disassembly of section .text:

 :
   0:   00 00 bb 27 ldahgp,0(t12)
   4:   00 00 bd 23 lda gp,0(gp)
   8:   f0 ff de 23 lda sp,-16(sp)
   c:   01 00 1f 20 lda v0,1
  10:   08 00 3e b5 stq s0,8(sp)
  14:   00 00 5e b7 stq ra,0(sp)
  18:   09 04 f0 47 mov a0,s0
  1c:   1c 00 20 e6 beq a1,90 
  20:   a1 35 20 42 cmpeq   a1,0x1,t0
  24:   19 00 20 f4 bne t0,8c 
  28:   a1 55 20 42 cmpeq   a1,0x2,t0
  2c:   01 00 5f 20 lda t1,1
  30:   15 00 20 f4 bne t0,88 
  34:   a1 75 20 42 cmpeq   a1,0x3,t0
  38:   12 00 20 f4 bne t0,84 
  3c:   a1 95 20 42 cmpeq   a1,0x4,t0
  40:   0f 00 20 f4 bne t0,80 
  44:   a1 b5 20 42 cmpeq   a1,0x5,t0
  48:   0c 00 20 f4 bne t0,7c 
  4c:   a1 d5 20 42 cmpeq   a1,0x6,t0
  50:   09 00 20 f4 bne t0,78 
  54:   a1 f5 20 42 cmpeq   a1,0x7,t0
  58:   06 00 20 f4 bne t0,74 
  5c:   a1 15 21 42 cmpeq   a1,0x8,t0
  60:   03 00 20 f4 bne t0,70 
  64:   f7 ff 31 22 lda a1,-9(a1)
  68:   00 00 40 d3 bsr ra,6c 
  6c:   02 04 20 4d mulqs0,v0,t1
  70:   02 04 49 4c mulqt1,s0,t1
  74:   02 04 49 4c mulqt1,s0,t1
  78:   02 04 49 4c mulqt1,s0,t1
  7c:   02 04 49 4c mulqt1,s0,t1
  80:   02 04 49 4c mulqt1,s0,t1
  84:   02 04 49 4c mulqt1,s0,t1
  88:   00 04 49 4c mulqt1,s0,v0
  8c:   00 04 09 4c mulqv0,s0,v0
  90:   00 00 5e a7 ldq ra,0(sp)
  94:   08 00 3e a5 ldq s0,8(sp)
  98:   10 00 de 23 lda sp,16(sp)
  9c:   01 80 fa 6b ret

But here the recursion is back. It looks like the function was inlined into
itself too early.

-- 
   Summary: -finline-functions inhibits tail recursion accumulation
optimization
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: alphaev68-unknown-linux-gnu
  GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19939

[Bug tree-optimization/19939] -finline-functions inhibits tail recursion accumulation optimization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
18:17 ---
This is a dup of bug 1046, yes the function is slightly different but the 
problem is the same:
"Well at -O3 -fno-inline this is fixed but at -O3 -finline this is not fixed, 
the problem is that 
fib is being inlined into itself why I do not know.  Jan why is this happening?"

*** This bug has been marked as a duplicate of 1046 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19939

[Bug tree-optimization/1046] gcc less efficient than jdk for recursion!

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
18:17 ---
*** Bug 19939 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||falk at debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1046

[Bug tree-optimization/19835] [4.0 Regression] [AVR] Loop variable gets widened to LONG instead of int

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-02-13 18:30 
---
(In reply to comment #1)
> There has to be a reason why we want to use long int instead of the integer
> type which is the same size 

There's no doubt that someone may have thought so, but it's wrong;
as there's no valid reason to effectively transform (int)j into a temp of
any greater rank unsigned type. (as there is no valid reason to ever
require an unsigned index to memory of greater rank than a pointer). 

Further, given that GCC knows the bounds of the variable (i.e. 0 >= j <= 19)
temp should most correctly have been typed as an (unsigned char) QI mode.
(which undoubtedly could only likely help subsequent optimizations to know)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19835

[Bug tree-optimization/19940] New: Missed jump threading opportunity due to |.

[kazu at cs dot umass dot edu]

Consider:

void bar (void);

int global;

void
foo (unsigned char pedwarned, unsigned char warned)
{
  unsigned char tem = warned | pedwarned;

  if (tem == 0)
{
  if (global)
warned = 1;
}

  tem = warned | pedwarned;
  if (tem != 0)
bar ();
}

Notice that if we get to "warned = 1;", we know we are going to call bar.
However, the tree optimizers do not notice this.

The RTL optimizers do find this optimization opportunity.

Reduced from c-decl.c:duplicate_decls.

-- 
   Summary: Missed jump threading opportunity due to |.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 19794
 nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19940

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

  BugsThisDependsOn||19940


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794

[Bug c++/19941] New: No warning emitted for nested switch statements.

[dhruvbird at yahoo dot com]

When there are many nested switch statements, then the compiler does not
recognize bogus labels such as spelling mistakes like 'delault' instead of
'default', and goes on to generate code. Even with -Wall, no warning is
generated. However these stupidities(spelling mistakes) are recognized and
warnings to that effect are emitted in programs such as these:


#include 
int
main()
{
  int r = rand();
  int s = 0;

  switch (s)
{
case 0:
  switch(r)
{
case 1:
  s = 2;
  break;
  
case 2:
  s = 7;
  break;
  
defauft:
  s = 9;
}
default:
  r = 9;
}
}

swtest.cpp: In function `int main()':
swtest.cpp:21: warning: label `defauft' defined but not used

-Dhruv.

-- 
   Summary: No warning emitted for nested switch statements.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dhruvbird at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19941

[Bug c++/19941] No warning emitted for nested switch statements.

[dhruvbird at yahoo dot com]

--- Additional Comments From dhruvbird at yahoo dot com  2005-02-13 18:40 
---
Created an attachment (id=8190)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8190&action=view)
The files required for reproducing the bug, and a short description.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19941

[Bug c++/19941] No warning emitted for nested switch statements.

[dhruvbird at yahoo dot com]

--- Additional Comments From dhruvbird at yahoo dot com  2005-02-13 18:44 
---
(In reply to comment #1)
> Created an attachment (id=8190)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8190&action=view)
> The files required for reproducing the bug, and a short description.
> 

Actually, it is not the spelling mistake that is recognized, but the lack of any
control reaching that part of the code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19941

[Bug c++/19941] No warning emitted for nested switch statements.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
18:50 ---
Labels inside a switch statement is legal code and it is hard to dect that you 
had ment to use default 
instead of what you put in the label.  (default is just a special label really).


Use -Wunreachable-code if you want to dect unreachable code.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19941

[Bug tree-optimization/19940] Missed jump threading opportunity due to |.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
18:59 ---
Confirmed, related to PR 18832.

Note on PPC at least we don't really thread the jumps that well on the rtl 
level:
_foo:
or. r0,r4,r3
bne- cr0,L2
lis r2,ha16(_global)
ori r0,r3,1
lwz r2,lo16(_global)(r2)
cmpwi cr6,r0,0
cmpwi cr7,r2,0
beqlr- cr7
beqlr- cr6
L2:
b _bar

Now if we change all the unsigned char to _Bool we get the threaded jump:
_foo:
or. r0,r4,r3
bne- cr0,L2
lis r2,ha16(_global)
lwz r2,lo16(_global)(r2)
cmpwi cr7,r2,0
beqlr- cr7
L2:
b _bar

-- 
   What|Removed |Added

  BugsThisDependsOn||18832
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-13 18:59:10
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19940

[Bug ada/19942] New: Stage 2 compilation of ali.adb causes GNAT bug box

[awreynolds at mac dot com]

Error occurs with GCC head updated as of 13 Feb 2005 at 12:00 EST

Build compiler:

pbg4:~/Developer/Compiler/fsf-gcc-head/build drew$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20040913 (GNAT for Mac OS X build 1650)

Configured with the following command:

../configure   --prefix=/usr/local/ada --disable-nls --enable-shared 
--enable-languages=c,ada

Reported message:

stage1/xgcc -Bstage1/ -B/usr/local/ada/powerpc-apple-darwin7.8.0/bin/ -c -g -O2 
-mdynamic-no-
pic  -gnatpg -gnata -I- -I. -Iada -I../../gcc/ada ../../gcc/ada/ali.adb -o 
ada/ali.o
+===GNAT BUG 
DETECTED==+
| 4.0.0 20050213 (experimental) (powerpc-apple-darwin7.8.0) GCC error: |
| in gnat_type_for_mode, at ada/utils.c:1838   |
| Error detected at ali.adb:2097:1 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==
+

Please include these source files with error report
Note that list may not be accurate in some cases, 
so please double check that the problem can still 
be reproduced with the set of files listed.

../../gcc/ada/ali.adb
../../gcc/ada/ali.ads
../../gcc/ada/casing.ads
../../gcc/ada/types.ads
../../gcc/ada/gnatvsn.ads
../../gcc/ada/rident.ads
../../gcc/ada/table.ads
../../gcc/ada/butil.ads
../../gcc/ada/debug.ads
../../gcc/ada/fname.ads
../../gcc/ada/namet.ads
../../gcc/ada/alloc.ads
../../gcc/ada/opt.ads
../../gcc/ada/hostparm.ads
../../gcc/ada/osint.ads
../../gcc/ada/output.ads
../../gcc/ada/table.adb
../../gcc/ada/tree_io.ads



Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [ada/ali.o] Error 1
make[1]: *** [stage2_build] Error 2
make: *** [bootstrap] Error 2

-- 
   Summary: Stage 2 compilation of ali.adb causes GNAT bug box
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: awreynolds at mac dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: (powerpc-apple-darwin7.8.0
  GCC host triplet: (powerpc-apple-darwin7.8.0
GCC target triplet: (powerpc-apple-darwin7.8.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19942

[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-02-13 19:17 ---
Broken by this patch: 
 
2005-02-06  Zdenek Dvorak  <[EMAIL PROTECTED]> 
 
* tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Do not add 
unnecessary cast to original induction variable increments. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

[Bug ada/19942] Stage 2 compilation of ali.adb causes GNAT bug box

[awreynolds at mac dot com]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19942

[Bug ada/19942] Stage 2 compilation of ali.adb causes GNAT bug box

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
19:24 ---
Mine, I am about to submit the patch to fix this bug.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Keywords||build
   Last reconfirmed|-00-00 00:00:00 |2005-02-13 19:24:47
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19942

[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit

[rakdver at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

[Bug ada/19942] [4.0 Regression] Stage 2 compilation of ali.adb causes GNAT bug box

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
19:38 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch
Summary|Stage 2 compilation of  |[4.0 Regression] Stage 2
   |ali.adb causes GNAT bug box |compilation of ali.adb
   ||causes GNAT bug box


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19942

[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-02-13 
19:50 ---
Function that may trap is not pure; in particular func_pure_2 cannot
be considered pure.  The remaining testcases are real bugs, however.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828

[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory

[drow at gcc dot gnu dot org]

--- Additional Comments From drow at gcc dot gnu dot org  2005-02-13 20:05 
---
That's a pretty useless definition of pure functions - they may read global
memory, but not dereference any pointers which are invalid at any point in
the life of the program?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828

[Bug ada/19942] [4.0 Regression] Stage 2 compilation of ali.adb causes GNAT bug box

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-13 
20:08 ---
Subject: Bug 19942

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-13 20:08:29

Modified files:
gcc/ada: ChangeLog utils.c 

Log message:
2005-02-13  Andrew Pinski  <[EMAIL PROTECTED]>

PR ada/19942
* utils.c (gnat_type_for_mode): Return null instead of ICE because we 
asked
for an unknown mode.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.637&r2=1.638
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/utils.c.diff?cvsroot=gcc&r1=1.91&r2=1.92



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19942

[Bug ada/19942] [4.0 Regression] Stage 2 compilation of ali.adb causes GNAT bug box

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
20:09 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19942

[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-02-13 20:11 ---
Subject: Re:  [4.0 Regression] LIM is pulling out a pure function even though 
there is something which can modify global memory

> That's a pretty useless definition of pure functions - they may read global
> memory, but not dereference any pointers which are invalid at any point in
> the life of the program?

sorry, but allowing pure functions to trap would make them even more
useless.  For example it would be forbidden to remove calls to them
(no dce), possibilities for code motion would be severely limited,
etc.  Hopefully with interprocedural alias analysis pure specifier
will become less needed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828

[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory

[drow at gcc dot gnu dot org]

--- Additional Comments From drow at gcc dot gnu dot org  2005-02-13 20:13 
---
I've suggested when talking to someone else about this that they should be
assumed not to trap at the points where they are called.  That would allow
calls to them to be removed, although still limit code motion.

It's a pity there's no rigorous definition of the current meaning of pure.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828

[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory

[ian at airs dot com]

--- Additional Comments From ian at airs dot com  2005-02-13 20:27 ---
The definition of pure states that such a function may depend upon global
variables.  I guess you are saying that func_pure_2 is not pure because the
global variable a may not be a valid memory address?

I disagree.  If the programmer declares that func_pure_2 is pure, then the
programmer is promising the compiler that the variable a holds a valid memory
address.  The attribute is not a statement of something which the compiler can
deduce for itself; it is a promise by the programmer.

Given that promise, the compiler is fully entitled and expected to hoist
function calls out of loops which do not modify global variables, etc.  If that
causes a bug, it is a bug in the code, not in the compiler.

I agree that it would be nice if the compiler could do a better job of analyzing
whether a function is const/pure, but until then we should trust the programmer.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828

[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-02-13 
20:38 ---
Subject: Re:  [4.0 Regression] LIM is pulling
 out a pure function even though there is something which can modify global
 memory

On Sun, 13 Feb 2005, drow at gcc dot gnu dot org wrote:

> I've suggested when talking to someone else about this that they should be
> assumed not to trap at the points where they are called.  That would allow
> calls to them to be removed, although still limit code motion.
> 
> It's a pity there's no rigorous definition of the current meaning of pure.

I would say that a pure function is a pure but not necessarily total 
function of its arguments and those parts of the state of the machine 
visible to it: you can move or remove calls to pure functions as long as 
in the abstract machine the function would have been called with the 
particular machine state with which it does get called.  So strlen is pure 
and "if (s) strlen(s);" is valid and the strlen call can't be moved before 
the test for NULL.  Similarly a const function is a pure but not 
necessarily total function of the values of its arguments only: so a 
square root function which doesn't set errno or floating point exception 
flags could be "const" and a call to it should not be moved before a test 
that the argument is nonnegative.

Where there are optimizations depending on the function being total - not 
trapping even if you call it with arguments with which the program never 
calls it in the abstract machine model - perhaps an additional attribute 
"total" should be added which can be used in conjunction with "const" or 
"pure".  (Though I'm not sure how many real functions are going to be 
"pure" and "total" but not "const".)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828

[Bug rtl-optimization/19943] New: missed optimization: memcpy is invoked with small size known upfront if invoked through inlined function(s)

[yuri at tsoft dot com]

code below produces "memcpy" invocation for wrong_1 and wrong_2 procedures, only
ok procedure hets "memcpy" optimized properly.

Both wrong_1 and wrong_2 should compile to identical code equal to code of "ok".

--begin code--
include 
char *b;

struct W {
  inline static void wr(char *buf, int sz) {
::memcpy(b, buf, sz);
b += sz;
  }
  inline static void wr(char c) { wr(&c, sizeof(c)); }
};

int wrong_1(char c) { W::wr(&c, 1); }
int wrong_2(char c) { W::wr(c); }
int ok(char c) { ::memcpy(b, &c, 1); }
--end code--

-- 
   Summary: missed optimization: memcpy is invoked with small size
known upfront if invoked through inlined function(s)
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19943

[Bug rtl-optimization/19943] missed optimization: memcpy is invoked with small size known upfront if invoked through inlined function(s)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
20:56 ---
Fixed in 4.0 by doing some const progation before expanding to RTL.
A way to get around this before 4.0 you can declare sz as constant aka:
  inline static void wr(char *buf, const int sz)

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||missed-optimization
 Resolution||FIXED
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19943

[Bug other/19525] [4.0 Regression] In-build-directory multilib testing broken

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-02-13 
20:56 ---
Patch posted here:

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00653.html

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19525

[Bug middle-end/19698] [3.4/4.0 Regression] Infinite loop in update_life_info

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-02-13 
21:24 ---
...and the hammer branch does not fail this test case because it has Zdenek's 
patch on it.  Well, that explains - and gives me some more confidence to 
submit it for GCC 4.0 too. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19698

[Bug target/19019] GCC ldouble format incompatibility with XLC long double

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-13 
21:31 ---
Subject: Bug 19019

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-13 21:31:37

Modified files:
gcc: ChangeLog 
gcc/config/rs6000: aix.h beos.h rs6000.c rs6000.h rs6000.md 
gcc/doc: invoke.texi 

Log message:
PR target/19019
* config/rs6000/aix.h ({TARGET,MASK}_XL_CALL): Rename to
{TARGET,MASK}_XL_COMPAT.
(SUBTARGET_SWITCHES): Rename xl-call to xl-compat.  Use
MASK_XL_COMPAT.
* config/rs6000/beos.h ({TARGET,MASK}_XL_CALL): Remove.
* config/rs6000/rs6000.c (function_arg): Change TARGET_XL_CALL to
TARGET_XL_COMPAT.
(rs6000_arg_partial_bytes): Same.
(rs6000_generate_compare): Generate PARALLEL for compare if TFmode
and XL compatibility enabled.
* config/rs6000/rs6000.h (TARGET_XL_CALL): Rename to TARGET_XL_COMPAT.
* config/rs6000/rs6000.md (cmptf_internal1): Add !TARGET_XL_COMPAT
test to final condition.
(cmptf_internal2): New.
* doc/invoke.texi (RS/6000 Subtarget Options): Change xl-call to
xl-compat.  Add TFmode information to description.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7464&r2=2.7465
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/aix.h.diff?cvsroot=gcc&r1=1.49&r2=1.50
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/beos.h.diff?cvsroot=gcc&r1=1.12&r2=1.13
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.784&r2=1.785
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.h.diff?cvsroot=gcc&r1=1.353&r2=1.354
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcc&r1=1.346&r2=1.347
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.577&r2=1.578



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19019

[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-02-13 
22:20 ---
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00657.html

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

[Bug bootstrap/16787] NAN constant "(0.0/0.0)" cannot be compiled by Tru64 cc

[w dot northcott at unsw dot edu dot au]

--- Additional Comments From w dot northcott at unsw dot edu dot au  
2005-02-13 22:55 ---
This is a documentation problem.The current host specific docs at 
http://gcc.gnu.org/install/
specific.html#alpha*-*-* read:
*
In Tru64 UNIX V5.1, Compaq introduced a new assembler that does not currently 
(2001-06-13) work 
with mips-tfile. As a workaround, we need to use the old assembler, invoked via 
the barely documented 
-oldas option. To bootstrap GCC, you either need to use the Compaq C Compiler:
% CC=cc srcdir/configure [options] [target]
or you can use a copy of GCC 2.95.3 or higher built on Tru64 UNIX V4.0:
% CC=gcc -Wa,-oldas srcdir/configure [options] [target]
*
This is misleading and unhelpful:
1.  The only effect most people will observe from the assembler change is that 
gcc binaries built on 
older (pre 5.1) versions of Tru64 will not run on 5.1.
2.  The -oldas seems to be unecessary.
3.  The -ieee flag is vital to bootstrap using the DEC compiler.  So the 
configure suggestion should 
read: 'To bootstrap GCC, you either need to use the Compaq C Compiler:
% CC="cc -ieee" srcdir/configure [options] [target]'

Could someone please please fix the documentation.
Bill Northcott


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16787

[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
23:03 ---
In fact I just tested the patch for PR 19937 and it fixes this bug also.

-- 
   What|Removed |Added

Version|unknown |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938

[Bug tree-optimization/18595] [4.0 Regression] IV-OPTS is O(N^3)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-13 
23:14 ---
Moving to 4.1 as I don't care much if this gets fixed.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18595

[Bug middle-end/19698] [3.4/4.0 Regression] Infinite loop in update_life_info

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-02-13 
23:44 ---
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00655.html 

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19698

[Bug tree-optimization/19944] New: [4.0 regression] cris-elf testsuite failures: gcc.dg/pr15784-1.c, gcc.dg/pr15784-2.c

[hp at gcc dot gnu dot org]

Between LAST_UPDATED "" and "" these tests were introduced,
failing from the start for cris-elf:
FAIL: gcc.dg/pr15784-1.c scan-tree-dump-times ABS_EXPR 0
FAIL: gcc.dg/pr15784-2.c scan-tree-dump-times ABS_EXPR 0

The top of pr15784-1.c.t03.generic is:
a (x)
{
  int D.1055;
  int D.1056;
  
  D.1056 = ABS_EXPR ;
  D.1055 = D.1056 >= 0;
  return D.1055;
}

-- 
   Summary: [4.0 regression] cris-elf testsuite failures:
gcc.dg/pr15784-1.c, gcc.dg/pr15784-2.c
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: cris-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19944

[Bug tree-optimization/19944] cris-elf testsuite failures: gcc.dg/pr15784-1.c, gcc.dg/pr15784-2.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-02-14 00:17 
---
Title change as it's not actually a regression; I haven't seem the tests pass.

-- 
   What|Removed |Added

 CC||phython at gcc dot gnu dot
   ||org
Summary|[4.0 regression] cris-elf   |cris-elf testsuite failures:
   |testsuite failures: |gcc.dg/pr15784-1.c,
   |gcc.dg/pr15784-1.c, |gcc.dg/pr15784-2.c
   |gcc.dg/pr15784-2.c  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19944

[Bug c/19945] New: [4.0 Regression] inefficient store of constant into a global register

[giovannibajo at libero dot it]

int a;
void foo(void)
{
  a = 10;
}


when compiled with GCC 4.0 20050118, with -O2 -fomit-frame-pointer, generates 
the following code:

foo:
movl$10, %eax
movl%eax, a
ret

Notice the unnecessary which wastes a register.  With 3.4, we get the expected 
code:

foo:
movl$10, a
ret

-- 
   Summary: [4.0 Regression] inefficient store of constant into a
global register
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giovannibajo at libero dot it
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: x86-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug c/19945] [4.0 Regression] inefficient store of constant into a global register

[giovannibajo at libero dot it]

-- 
   What|Removed |Added

   Severity|normal  |critical
  Known to fail||4.0.0
  Known to work||3.4.3
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug tree-optimization/19944] cris-elf testsuite failures: gcc.dg/pr15784-1.c, gcc.dg/pr15784-2.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
00:19 ---
Looks like Jason accidently reverted the patch which fixed these.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-14 00:19:23
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19944

[Bug target/19945] [4.0 Regression] inefficient store of constant into a global register

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug target/19945] [4.0 Regression] inefficient store of constant into a global register

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
00:25 ---
Fixed since at least 20050127.

-- 
   What|Removed |Added

   Severity|critical|minor


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug target/19945] [4.0 Regression] inefficient store of constant into a global register

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
00:26 ---
Confirmed with yesterday's compiler (why it works with a cross to x86_64 and 
-m32 I don't know).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-14 00:26:38
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug libstdc++/19946] New: [4.0 regression] cris-elf testsuite failure: demangle/abi_examples/01.cc and 02

[hp at gcc dot gnu dot org]

Between LAST_UPDATED "Sat Feb 12 01:23:34 UTC 2005" and
"Sun Feb 13 17:33:07 UTC 2005" I see testsuite regressions for
cris-elf:
FAIL: demangle/abi_examples/01.cc execution test
FAIL: demangle/abi_examples/02.cc execution test

There was a demangler cp_demangle.c change in this time-frame
(author CC:ed) and it seems the testsuite wasn't updated to match.

-- 
   Summary: [4.0 regression] cris-elf testsuite failure:
demangle/abi_examples/01.cc and 02
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,jason at redhat dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: cris-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19946

[Bug target/19945] inefficient store of constant into a global register

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
00:35 ---
This is not a regression at all, in fact on i686 it is cheaper to do the moves 
instead of doing it in one 
move.

So really this is not a bug at all.  In fact my testing shows that this is not 
really a regression either and 
not it looks like the 3.4.3 you used was not compiled for i686 by default.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.0.0   |3.4.0 4.0.0 3.0.4 3.2.3
  Known to work|3.4.3   |
 Resolution||INVALID
Summary|[4.0 Regression] inefficient|inefficient store of
   |store of constant into a|constant into a global
   |global register |register
   Target Milestone|4.0.0   |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug target/19945] Inefficient store of constant into a global register

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-02-14 
00:36 ---
Seems deliberate, -march=i486 fixes it, so it is not a regression (my 3.4 was 
configured to default to -march=i486). I don't see how wasting a register can 
make the code faster on i686 though.

-- 
   What|Removed |Added

  Known to fail|3.4.0 4.0.0 3.0.4 3.2.3 |
Summary|inefficient store of|Inefficient store of
   |constant into a global  |constant into a global
   |register|register
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug target/19945] Inefficient store of constant into a global register

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-02-14 
00:37 ---
It is easy to devise a testcase where we run slower because of the additional 
wasted register. 

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug target/19945] Inefficient store of constant into a global register

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
00:43 ---
Then open one with that testcase as this as this is intentional as:
const int x86_split_long_moves = m_PPRO;

and PPRO is the same as i686 and pentiumpro.

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug target/19945] Inefficient store of constant into a global register

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-02-14 
00:49 ---
This is not wasting a register at all, don't make unfounded claims like that 
if you don't know why exactly the code looks like it does. 
 
In this case the code comes from a peephole2 splitting the immediate move.  
Those peepholes run after register allocation, so the peephole can only apply 
if a register is available.  If there are no available registers, the peephole 
simply does not match. 
 
So in fact this peephole makes gcc use the registers more efficiently! 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945

[Bug libstdc++/19946] [4.0 regression] cris-elf testsuite failure: demangle/abi_examples/01.cc and 02

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
01:58 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|cris-elf|
   Last reconfirmed|-00-00 00:00:00 |2005-02-14 01:58:37
   date||
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19946

[Bug tree-optimization/19944] cris-elf testsuite failures: gcc.dg/pr15784-1.c, gcc.dg/pr15784-2.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-02-14 02:00 
---
Oops, forgot to fill in actual dates on the first line.  Here for reference:
Between LAST_UPDATED "Sat Feb 12 01:23:34 UTC 2005" and
"Sun Feb 13 17:33:07 UTC 2005" these tests were introduced

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19944

[Bug c/18500] Gcc outputs sizeof calculation code that uses unitialized memory

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
02:21 ---
Fixed on the mainline now.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18500

[Bug tree-optimization/14844] [tree-ssa] narrow types if wide result is not needed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
02:23 ---
Note the code from build_binop from the C and C++ front-ends need to be moved 
to fold and then 
when that happens my tree combiner will just work.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14844

[Bug c++/18497] Not rejecting non template call to template (non-dependent) function until instaination time

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Last reconfirmed|2004-11-15 14:10:52 |2005-02-14 02:27:30
   date||
Summary|error in parsing function   |Not rejecting non template
   |template|call to template (non-
   ||dependent) function until
   ||instaination time


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18497

[Bug tree-optimization/19944] cris-elf testsuite failures: gcc.dg/pr15784-1.c, gcc.dg/pr15784-2.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-14 
02:27 ---
Subject: Bug 19944

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-14 02:27:33

Modified files:
gcc: fold-const.c ChangeLog 

Log message:
2005-02-13  James A. Morrison  <[EMAIL PROTECTED]>

PR tree-optimization/19944
* fold-const.c (fold): Re-add ABS_EXPR folding.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.509&r2=1.510
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7465&r2=2.7466



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19944

[Bug tree-optimization/19944] cris-elf testsuite failures: gcc.dg/pr15784-1.c, gcc.dg/pr15784-2.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
02:33 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19944

[Bug fortran/17142] assertion "POINTER_TYPE_P (TREE_TYPE (se->expr))" failed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
02:42 ---
We hit a different ICE now:
  gcc_assert (TREE_TYPE (rhs) == TREE_TYPE (lhs)
  || AGGREGATE_TYPE_P (TREE_TYPE (lhs)));

in gfc_add_modify_expr

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17142

[Bug c++/19947] New: __attribute__ ((__always_inline__)) fails for no apparent reason

[yuri at tsoft dot com]

I have some functions marked with this attribute, on most it works ok,
but sometimes I get:
"sorry, unimplemented: inlining failed in call to 'my_func': function not 
inlinable"
"sorry, unimplemented: called from here"
And the second line doesn't seem to point to the use of this function at all.
Also statement "unimplemented" seems to be strange.

I can't get sample code since it works fine on all my simple examples.

-- 
   Summary: __attribute__ ((__always_inline__)) fails for no
apparent reason
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19947

[Bug c++/19947] __attribute__ ((__always_inline__)) fails for no apparent reason

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
05:16 ---
A more complex example is fine for right now, it might be a duplicate of bug 
14950 or PR 17248.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19947

[Bug tree-optimization/14844] [tree-ssa] narrow types if wide result is not needed

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-02-14 05:47 
---
(In reply to comment #7)
> Note the code from build_binop from the C and C++ front-ends need to be moved 
> to fold and then 
> when that happens my tree combiner will just work.

Sorry, but a little confused, as it's perfectly correct to shorten these 
operands to the width
of the operation's assignment, and in fact should be done? (so there's nothing 
to correct
and arguably should have been identifyed as such by the front-ends to begin 
with it would seem)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14844

[Bug tree-optimization/14844] [tree-ssa] narrow types if wide result is not needed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-14 
05:57 ---
(In reply to comment #8)
> Sorry, but a little confused, as it's perfectly correct to shorten these 
> operands to the width
> of the operation's assignment, and in fact should be done? (so there's 
> nothing to correct
> and arguably should have been identifyed as such by the front-ends to begin 
> with it would seem)

What I was trying to say, is that this should not be done in the front-end as 
the front-end has almost 
no business to deal with optimizations.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14844

[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-02-14 06:04 
---
(In reply to comment #5)
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00657.html

it may be worth noting that compare for equivelence/non-equivelence,
is insensitive to the sign of equivelent rank integers, although relative
(< >) compares are, but it does'nt seem that it's recognized when
comparision operations are constructed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-02-14 07:03 ---
Subject: Re:  [4.0 regression] Wrong loop exit

> (In reply to comment #5)
> > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00657.html
> 
> it may be worth noting that compare for equivelence/non-equivelence,
> is insensitive to the sign of equivelent rank integers, although relative
> (< >) compares are, but it does'nt seem that it's recognized when
> comparision operations are constructed?

I don't understand the comment.  Comparisons constructed due to
may_eliminate_iv are always either EQ_EXPRs or NE_EXPRs.  Comparing
directly with a value in a different type (regardless of what comparison
operator is used) is however always an invalid gimple.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

[Bug target/19150] [3.3/3.4/4.0 Regression] suboptimal fp division with -ffast-math

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2005-02-14 07:03 
---
The patch for the problem described in description of this bug is actually at
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01928.html. There is an
inconsistency in simplify_binary_operation(), as decribed in b).

Index: simplify-rtx.c
===
RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.204
diff -u -p -r1.204 simplify-rtx.c
--- simplify-rtx.c  9 Sep 2004 17:19:16 -   1.204
+++ simplify-rtx.c  20 Sep 2004 14:03:51 -
@@ -1309,7 +1309,10 @@ simplify_binary_operation (enum rtx_code
  REAL_ARITHMETIC (value, rtx_to_tree_code (code), f0, f1);
 
  value = real_value_truncate (mode, value);
- return CONST_DOUBLE_FROM_REAL_VALUE (value, mode);
+ tem = CONST_DOUBLE_FROM_REAL_VALUE (value, mode);
+ if (MEM_P (op0) || MEM_P (op1))
+   tem = validize_mem (force_const_mem (mode, tem));
+ return tem;
}
 }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19150

[Bug c++/19948] New: ICE: tree check: expected class 'declaration', have 'exceptional' (error_mark) in pushtag, at cp/name-lookup.c:4658

[fang at csl dot cornell dot edu]

ICE: tree check: expected class 'declaration', have 'exceptional' (error_mark) 
in pushtag, at cp/name-
lookup.c:4658

g++ is very confused about forward-declared classes and friend classes.  
--
GCC version info:

Using built-in specs.
Configured with: ../configure --prefix=/sw --prefix=/sw/lib/gcc4 --enable-
languages=c,c++,objc,f95,java --infodir=/share/info --with-gmp=/sw 
--with-as=/sw/lib/odcctools/
bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-included-gettext 
--host=powerpc-apple-darwin
Thread model: posix
gcc version 4.0.0 20050130 (experimental)
 /sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin/4.0.0/cc1plus -E -quiet -v 
-D__DYNAMIC__ 
-D__APPLE_CC__=1 gcc4death.cc -fPIC -fpch-preprocess -o gcc4death.ii
ignoring nonexistent directory 
"/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/../../../../powerpc-
apple-darwin/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/../../../../include/c++/4.0.0
 
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/../../../../include/c++/4.0.0/powerpc-apple-
darwin
 
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/../../../../include/c++/4.0.0/backward
 /usr/local/include
 /sw/lib/gcc4/include
 /sw/lib/gcc4/lib/gcc/powerpc-apple-darwin/4.0.0/include
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
 /sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin/4.0.0/cc1plus -fpreprocessed 
gcc4death.ii -fPIC 
-quiet -dumpbase gcc4death.cc -auxbase gcc4death -version -o gcc4death.s
GNU C++ version 4.0.0 20050130 (experimental) (powerpc-apple-darwin)
compiled by GNU C version 3.3 20030304 (Apple Computer, Inc. build 
1640).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

--
command to reproduce:

g++-4.0 -c gcc4death.cc -o gcc4death.o

--
gcc error feedback:

util/persistent_object_manager_gcc4death.h: In instantiation of 
'util::persistent_traits':
gcc4death.cc:7:   instantiated from here
util/persistent_object_manager_gcc4death.h:480: error: use of 
'persistent_object_manager' is 
ambiguous
util/persistent_object_manager_gcc4death.h:67: error:   first declared as 
'class util::
persistent_object_manager' here
util/persistent_object_manager_gcc4death.h:28: error:   also declared as 
'struct util::memory::
persistent_object_manager' here
util/persistent_object_manager_gcc4death.h:480: error: conflicting declaration 
'struct util::
persistent_object_manager'
util/persistent_object_manager_gcc4death.h:67: error: 'class 
util::persistent_object_manager' has a 
previous declaration as 'class util::persistent_object_manager'
util/persistent_object_manager_gcc4death.h:480: internal compiler error: tree 
check: expected class 
'declaration', have 'exceptional' (error_mark) in pushtag, at 
cp/name-lookup.c:4658
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


=== "gcc4death.ii" 
# 1 "gcc4death.cc"
# 1 ""
# 1 ""
# 1 "gcc4death.cc"

# 1 "util/persistent_object_manager_gcc4death.h" 1
# 24 "util/persistent_object_manager_gcc4death.h"
namespace util {
class persistent_object_manager;
namespace memory {
class pointer_manipulator {
friend class persistent_object_manager;
};
}
}
# 45 "util/persistent_object_manager_gcc4death.h"
namespace util {
# 58 "util/persistent_object_manager_gcc4death.h"
using namespace memory;
# 67 "util/persistent_object_manager_gcc4death.h"
class persistent_object_manager {
# 467 "util/persistent_object_manager_gcc4death.h"
};
# 479 "util/persistent_object_manager_gcc4death.h"
template 
class persistent_traits {
friend class persistent_object_manager;
# 525 "util/persistent_object_manager_gcc4death.h"
};


}
# 3 "gcc4death.cc" 2

class whatever { };

static const
util::persistent_traits __blah__;
=== end-of-file =

other comments:
The above code should produce the following error as reported by gcc-3.3 and 
gcc-3.4.

gcc4death.cc:7: error: uninitialized const `__blah__'

-- 
   Summary: ICE: tree check: expected class 'declaration', have
'exceptional' (error_mark) in pushtag, at cp/name-
lookup.c:4658
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fang at csl dot cornell dot edu
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19948