[Bug middle-end/37026] New: GCC ICE in tree_to_gimple_tuple

[raj dot khem at gmail dot com]

I am seeing this error when compiling linux kernel 2.6.25 with gcc build from
latest 4_3 branch tip.

Here is test case



struct a {
 long a1;
 long a2;
};

struct b {
  struct a b1;
  struct a b2;
};
void bar (struct b *c)
{
 c->b1 = c->b2 = ((struct a) { foo(), 0 });
}



arm-none-linux-gnueabi-gcc test.c 



test.c: In function ‘bar’:
test.c:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: GCC ICE in tree_to_gimple_tuple
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: arm-none-linux-gnueabi


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

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rwild at gcc dot gnu dot org]

--- Comment #7 from rwild at gcc dot gnu dot org  2008-08-05 06:50 ---
Rob, please let's not play ping pong with the severity of this bug.
Also, I haven't confirmed this one yet because while I see a couple
of problems, I don't see yet whether any of them is a regression
(this report is about the 4.2 branch which is in regression mode,
not trunk).

GCC does not assume that all commands are GNU commands, and that will
not change either.  GCC configury mostly assumes that available commands
respect POSIX with known limitations and bugs either listed in
gcc/doc/install.texi and/or in


To your config.log diff: how exactly did you create the two differing
versions?  Asking because they were quite obviously called with a different
command line.  Did you call one of them directly, and the other was what a
'make' from the top level caused to use?  Or did you try to build one in
stage1 and one in a later stage?

Then, the differing 'uname -v' output has nothing whatsoever to do with sed
or grep.  It is created purely by a line like this:

  uname -v = `(uname -v) 2>/dev/null || echo unknown`

The reason that one configure run fails is that it determines the compiler
to use solaris threads rather than posix threads; this is a consequence of
one configure run being with gcc, and one with the previously built compiler.

IOW, I currently don't yet understand how any of the problems you have should
have to do with sed or grep or other tools at all.  Please stick to describing
the actual problems rather than what you perceive them to be caused by: If you
follow the installation instructions of GCC, then when and how does it fail,
and what is the first (not last!) error seen plus the commands that led to it?

Thanks,
Ralf


-- 


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

[Bug fortran/37025] New: ICE with TRANSFER to non-default-kind character: transfer(int(z'bde4'),4_'a')

[burnus at gcc dot gnu dot org]

f951: internal compiler error: in gfc_interpret_character, at
fortran/target-memory.c:402

  gcc_assert (result->ts.kind == gfc_default_character_kind);

character(len=20,kind=4) :: str
str = transfer(int(z'bde4'),4_'a')
end


-- 
   Summary: ICE with TRANSFER to non-default-kind character:
transfer(int(z'bde4'),4_'a')
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 31237
 nThis:


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

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

--- Comment #6 from rob1weld at aol dot com  2008-08-05 05:07 ---
The grep/sed problem occurs during the boehm-gc configury and in
libjava/classpath also. It is also missing iconv whereas the main configure
picks it up (due to: "--with-libiconv-prefix=/opt/csw"):


Adding multilib support to Makefile in /aux0/gcc-4.2.3/libjava
multidirs=
with_multisubdir=
configure: configuring in classpath
...
checking for ld used by GCC... /usr/ccs/bin/ld
checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
checking for shared library run path origin... /bin/bash:
/aux0/gcc-4.2.3/libjava/classpath/config.rpath: No such file or directory
done
checking for iconv... no, consider installing GNU libiconv
checking for X... libraries /usr/X11/lib, headers /usr/include/X11
checking whether -R must be followed by a space... no


Hopefully a new Autoconf is coming with a utility script (that will run through
all subdirectories searching for ".in" files and rebuild everything) -- that
anyone can run on any version of gcc or any GNU program (to save regressing
everything).


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[hjl dot tools at gmail dot com]

--- Comment #44 from hjl dot tools at gmail dot com  2008-08-05 04:34 
---
You can't compare gcc 4.3 with gcc 4.4 since gcc 4.3 can't align stack to
32byte. It is hard to tell where it went wrong. The assembly code is
quite different from Linux. If I have to guess, the problem may be in
unwind info, which can be a gcc or assembler bug. Unless we can reproduce
it on Linux, there is not much we can do.


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #43 from howarth at nitro dot med dot uc dot edu  2008-08-05 
03:33 ---
FYI, the gdb issue appears to be the same one reported here...

https://trac.macports.org/ticket/16102


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #42 from howarth at nitro dot med dot uc dot edu  2008-08-05 
03:13 ---
I not sure how valid this is, but if I manually create the missing symlinks to
point to the existing object files for libstdc++, I get...

Starting program: /Users/howarth/stackalign/eh-alloca-1.exe 
Reading symbols for shared libraries +++. done
terminate called after throwing an instance of 'A'

Program received signal SIGABRT, Aborted.
0x92986b9e in __kill ()
(gdb) bt 
#0  0x92986b9e in __kill ()
#1  0x92986b91 in kill$UNIX2003 ()
#2  0x929fdec2 in raise ()
#3  0x92a0d47f in abort ()
warning: .o file
"/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libsupc++convenience.a/vterminate.o"
more recent than executable timestamp
#4  0x001bed0b in __gnu_cxx::__verbose_terminate_handler () at
../../../../gcc-4.4-20080803/libstdc++-v3/libsupc++/vterminate.cc:98
warning: .o file
"/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libsupc++convenience.a/eh_terminate.o"
more recent than executable timestamp
#5  0x001bc83a in __cxxabiv1::__terminate (handler=0x1beba0
<__gnu_cxx::__verbose_terminate_handler()>) at
../../../../gcc-4.4-20080803/libstdc++-v3/libsupc++/eh_terminate.cc:43
#6  0x001bc87c in std::terminate () at
../../../../gcc-4.4-20080803/libstdc++-v3/libsupc++/eh_terminate.cc:53
warning: .o file
"/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libsupc++convenience.a/eh_throw.o"
more recent than executable timestamp
#7  0x001bc974 in __cxa_throw (obj=Could not find the frame base for
"__cxa_throw".
) at ../../../../gcc-4.4-20080803/libstdc++-v3/libsupc++/eh_throw.cc:76
#8  0x1eb1 in foo ()
#9  0x1ee5 in main ()


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #41 from howarth at nitro dot med dot uc dot edu  2008-08-05 
02:53 ---
When I run the binary in gdb, I get...

warning: Could not find object file
"/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o"
- no debug information available for
"../../../../gcc-4.4-20080803/libstdc++-v3/libmath/signbit.c".

etc. My build directory has a directory...

/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs

with object files but there is no libstdc++.lax subdirectory.


-- 


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

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

--- Comment #5 from rob1weld at aol dot com  2008-08-05 02:42 ---
Andrew Pinski  2008-08-04 18:53 wrote:
> Not if they want to call their OS a POSIX or UNIX OS really.  POSIX actually
> makes a standard about programs too.

If you want Posix conformant commands (not necessarily GNU programs) then the
Docs are here:

C(5)
http://docs.sun.com/app/docs/doc/819-2252/6n4i8rtov?l=en&a=view


It might be easier (for gcc) if we used GNU programs but if you would prefer
Posix and other Standards (certified by various groups) then here are a few
quotes from that Doc.


Solaris 10 supports IEEE Std 1003.1 and IEEE Std 1003.2, commonly known as
POSIX.1 and POSIX.2, respectively.


POSIX Standard  Description  Release
POSIX.1–2001POSIX.1-1990, POSIX.1b-1993, POSIX.1c-1996,
POSIX.2-1992, and POSIX.2a-1992 updatesSolaris 10 


Solaris 10 also supports the X/Open Common Applications Environment (CAE)
Portability Guide Issue 3 (XPG3) and Issue 4 (XPG4); Single UNIX Specification
(SUS, also known as XPG4v2); Single UNIX Specification, Version 2 (SUSv2); and
Single UNIX Specification, Version 3 (SUSv3). Both XPG4 and SUS include
Networking Services Issue 4 (XNS4). SUSv2 includes Networking Services Issue 5
(XNS5).


Utilities

  If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2
conflicts with historical Solaris utility behavior, the original Solaris
version of the utility is unchanged; a new version that is standard-conforming
has been provided in /usr/xpg4/bin. If the behavior required by POSIX.1–2001 or
SUSv3 conflicts with historical Solaris utility behavior, a new version that is
standard-conforming has been provided in /usr/xpg4/bin or in /usr/xpg6/bin. If
the behavior required by POSIX.1–2001 or SUSv3 conflicts with POSIX.2,
POSIX.2a, SUS, or SUSv2, a new version that is SUSv3 standard-conforming has
been provided in /usr/xpg6/bin.


We will need to check the "/usr/xpg4/bin" and "/usr/xpg6/bin" directories also
if you desire to use a program that meets a specific standard.

Or ...

We could just use GNU programs and require that the version number be greater
than X and less than Y and that all scripts work within those versions. Newer
series of gcc could permit newer version of the said utility program and old
versions of gcc could have patch sets made to permit some flexibility on the
range of versions permitted. This way we won't paint (program) ourselves into a
corner.


To me it seems easier to require GNU programs to compile GNU programs. This is
why I like to see the old compilers (gcc-3.4.3) working so we can bootstrap up
to the newer compilers (4.2.x series).

But when I'm running Solaris (and not Linux) I can use the "/usr/xpg4/bin" and
"/usr/xpg6/bin" programs (and the wonders of ZFS) too.


-- 

rob1weld at aol dot com changed:

   What|Removed |Added

   Severity|normal  |major


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[hjl dot tools at gmail dot com]

--- Comment #40 from hjl dot tools at gmail dot com  2008-08-05 02:41 
---
(In reply to comment #39)
> #0  0x92986b9e in __kill ()
> Starting program: /Users/howarth/stackalign/eh-alloca-1.exe 
> Reading symbols for shared libraries +++. done
> terminate called after throwing an instance of 'A'
> 
> Program received signal SIGABRT, Aborted.
> 0x92986b9e in __kill ()
> (gdb) bt
> #1  0x92986b91 in kill$UNIX2003 ()
> #2  0x929fdec2 in raise ()
> #3  0x92a0d47f in abort ()
> #4  0x001bed0b in __gnu_cxx::__verbose_terminate_handler ()

Why aren't there filename and line number?

> #5  0x001bc83a in __cxxabiv1::__terminate ()

Why aren't there filename and line number?

> #6  0x001bc87c in std::terminate ()

Why aren't there filename and line number?

> #7  0x001bc974 in __cxa_throw ()

Why aren't there filename and line number?

> #8  0x1e61 in foo (size=5) at eh-alloca-1.C:47
> #9  0x1e95 in main () at eh-alloca-1.C:53
> 


-- 


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

[Bug libgcj/31890] Java Namespace error - javaprims.h out of sync

[tromey at gcc dot gnu dot org]

--- Comment #5 from tromey at gcc dot gnu dot org  2008-08-05 01:29 ---
Subject: Bug 31890

Author: tromey
Date: Tue Aug  5 01:28:26 2008
New Revision: 138664

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138664
Log:
PR libgcj/31890:
* gcj/javaprims.h: Regenerate class list.

Modified:
trunk/libjava/ChangeLog
trunk/libjava/gcj/javaprims.h


-- 


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

[Bug target/37010] -mno-accumulate-outgoing-args doesn't work with stack alignment

[Joey dot ye at intel dot com]

--- Comment #15 from Joey dot ye at intel dot com  2008-08-05 01:01 ---
(In reply to comment #12)
> I think the problem is in
>   /* Set offset to aligned because the realigned frame tarts from here.  */
>   if (stack_realign_fp)
> offset = (offset + stack_alignment_needed -1) & -stack_alignment_needed;
> This code assumes that offset 0 is properly aligned to any alignment,
> which isn't true. It happens to work with -maccumulate-outgoing-args.
I still believe #8 is the right reason.


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #39 from howarth at nitro dot med dot uc dot edu  2008-08-05 
00:56 ---
#0  0x92986b9e in __kill ()
Starting program: /Users/howarth/stackalign/eh-alloca-1.exe 
Reading symbols for shared libraries +++. done
terminate called after throwing an instance of 'A'

Program received signal SIGABRT, Aborted.
0x92986b9e in __kill ()
(gdb) bt
#1  0x92986b91 in kill$UNIX2003 ()
#2  0x929fdec2 in raise ()
#3  0x92a0d47f in abort ()
#4  0x001bed0b in __gnu_cxx::__verbose_terminate_handler ()
#5  0x001bc83a in __cxxabiv1::__terminate ()
#6  0x001bc87c in std::terminate ()
#7  0x001bc974 in __cxa_throw ()
#8  0x1e61 in foo (size=5) at eh-alloca-1.C:47
#9  0x1e95 in main () at eh-alloca-1.C:53


-- 


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

[Bug tree-optimization/37024] [4.4 Regression] bad tail call from tuples merge

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-08-05 00:22 ---
Note the reason why this "works" on x86 and not rs6000 or really any other
backend is that the x86 back-end assumes that the middle-end asks about some
calls that could return in different locations:
  /* Check that the return value locations are the same.  Like
...
This is also the place we notice 
 differences in the return value ABI.  Note that it is ok for one
 of the functions to have void return type as long as the return
 value of the other is passed in a register.  */

  if (STACK_REG_P (a) || STACK_REG_P (b))
{ 
  if (!rtx_equal_p (a, b))
return false;
}
  else if (VOID_TYPE_P (TREE_TYPE (DECL_RESULT (cfun->decl
;
  else if (!rtx_equal_p (a, b))
return false;


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[hjl dot tools at gmail dot com]

--- Comment #38 from hjl dot tools at gmail dot com  2008-08-05 00:17 
---
(In reply to comment #37)
> I haven't been able to reduce the eh-alloca-1.C testcase. However I have
> verified that it passes as expected when compiled with g++ from gcc 4.3.1 on
> i686-apple-darwin9 using...
> 

Please show stack backtrace when abort happens.


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #37 from howarth at nitro dot med dot uc dot edu  2008-08-04 
23:36 ---
I haven't been able to reduce the eh-alloca-1.C testcase. However I have
verified that it passes as expected when compiled with g++ from gcc 4.3.1 on
i686-apple-darwin9 using...

g++-4 ./eh-alloca-1.C -nostdinc++ -fmessage-length=0 -O3 -g -mstackrealign
-mpreferred-stack-boundary=5 -multiply_defined suppress --save-temps -lm -o
./eh-alloca-1.exe

I have attached the preprocessed source, assembly and object files from a
compilation under gcc 4.3.1 and current gcc trunk (4.4.0). Hopefully a side by
side comparison will reveal the origin of the problem.


-- 


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

[Bug tree-optimization/37024] [4.4 Regression] bad tail call from tuples merge

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-08-04 23:35 ---
Simple testcase:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-tailc-details" } */
/* PR tree-opt/37024 */

double doubleValue();

long
longValue ()
{
 return (long) doubleValue ();
}

/* We should not tail call doubleValue in longValue as the mode changes. */
/* { dg-final { scan-tree-dump-times "Found tail call" 0 "tailc"} } */
/* { dg-final { cleanup-tree-dump "tailc" } } */

--- CUT ---
I can test this after all, doing so on ppc64-linux-gnu even though this is a
generic issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #36 from howarth at nitro dot med dot uc dot edu  2008-08-04 
23:33 ---
Created an attachment (id=16023)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16023&action=view)
assembly file for g++.dg/torture/stackalign/eh-alloca-1.C on gcc 4.4.0


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #35 from howarth at nitro dot med dot uc dot edu  2008-08-04 
23:32 ---
Created an attachment (id=16022)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16022&action=view)
assembly file for g++.dg/torture/stackalign/eh-alloca-1.C on gcc 4.3.1


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #34 from howarth at nitro dot med dot uc dot edu  2008-08-04 
23:31 ---
Created an attachment (id=16021)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16021&action=view)
object file for g++.dg/torture/stackalign/eh-alloca-1.C using gcc 4.4.0


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #33 from howarth at nitro dot med dot uc dot edu  2008-08-04 
23:31 ---
Created an attachment (id=16020)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16020&action=view)
object file for g++.dg/torture/stackalign/eh-alloca-1.C using gcc 4.3.1


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #32 from howarth at nitro dot med dot uc dot edu  2008-08-04 
23:30 ---
Created an attachment (id=16019)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16019&action=view)
preprocessed source file for g++.dg/torture/stackalign/eh-alloca-1.C on gcc
4.4.0


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #31 from howarth at nitro dot med dot uc dot edu  2008-08-04 
23:29 ---
Created an attachment (id=16018)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16018&action=view)
preprocessed source file for g++.dg/torture/stackalign/eh-alloca-1.C on gcc
4.3.1


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #30 from howarth at nitro dot med dot uc dot edu  2008-08-04 
23:18 ---
One other stackalign compile failure I forget to mention was...

/fink.build/gcc44-4.3.999-20080803/gcc-4.4-20080803/gcc/testsuite/gcc.target/i386/stackalign/return-3.c
 -mstackrealign -msse -std=gnu99 -mpreferred-stack
-boundary=2 -fno-show-column -S  -o return-3.s(timeout = 300)
/sw/src/fink.build/gcc44-4.3.999-20080803/gcc-4.4-20080803/gcc/testsuite/gcc.target/i386/stackalign/return-3.c:7:
error: decimal floating point not suppor
ted for this target
compiler exited with status 1
output is:
/sw/src/fink.build/gcc44-4.3.999-20080803/gcc-4.4-20080803/gcc/testsuite/gcc.target/i386/stackalign/return-3.c:7:
error: decimal floating point not supported for this target

FAIL: gcc.target/i386/stackalign/return-3.c -mstackrealign (test for excess
errors)
Excess errors:
/sw/src/fink.build/gcc44-4.3.999-20080803/gcc-4.4-20080803/gcc/testsuite/gcc.target/i386/stackalign/return-3.c:7:
error: decimal floating point not supported for this target

Should this test be marked as XFAIL on darwin?


-- 


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

[Bug tree-optimization/36922] [4.4 Regression] ICE in tree-data-ref.c with -ftree-loop-linear

[dje at gcc dot gnu dot org]

--- Comment #3 from dje at gcc dot gnu dot org  2008-08-04 21:57 ---
Copying from the duplicate PR...

The failure starts with this patch:

   http://gcc.gnu.org/viewcvs?view=rev&rev=135116

r135116 | spop | 2008-05-09 16:17:47 + (Fri, 09 May 2008)


-- 


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

[Bug tree-optimization/37024] [4.4 Regression] bad tail call from tuples merge

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-04 21:48 ---
Patch which I don't have time to test:
Index: tree-tailcall.c
===
--- tree-tailcall.c (revision 138567)
+++ tree-tailcall.c (working copy)
@@ -283,7 +283,7 @@ process_assignment (gimple stmt, gimple_
 {
   /* Reject a tailcall if the type conversion might need
 additional code.  */
-  if (IS_CONVERT_EXPR_CODE_P (code)
+  if (gimple_assign_cast_p (stmt)
  && TYPE_MODE (TREE_TYPE (dest)) != TYPE_MODE (TREE_TYPE (src_var)))
return false;


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Severity|normal  |blocker
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-04 21:48:05
   date||
Summary|bad tail call from tuples   |[4.4 Regression] bad tail
   |merge   |call from tuples merge
   Target Milestone|--- |4.4.0


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

[Bug target/37010] -mno-accumulate-outgoing-args doesn't work with stack alignment

[hjl dot tools at gmail dot com]

--- Comment #14 from hjl dot tools at gmail dot com  2008-08-04 21:43 
---
With stack alignment, we have different stack frame layouts. We
need to handle them properly.


-- 


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

[Bug tree-optimization/37024] New: bad tail call from tuples merge

[janis at gcc dot gnu dot org]

Since the gimple-tuples branch was merged, test omnetpp from SPEC CPU2006 hangs
when compiled with -O2 for powerpc-linux.  Here's a minimized testcase of the
code with the problem:

extern void foo (void);

class cPar
{
public:
  double dblval;
  long longValue ();
  double doubleValue ();
};

long
cPar::longValue ()
{
  return (long) doubleValue ();
}

double
cPar::doubleValue ()
{
  foo ();
  return dblval;
}

and code to invoke it from a separate file:

void foo (void) { }

class cPar
{
public:
  double dblval;
  long longValue ();
  double doubleValue ();
};

int
main ()
{
  cPar x;
  long i;

  x.dblval = 42.;

  i = x.longValue ();
  if (i != 42)
__builtin_abort ();
}

The failure starts on the tuples branch with this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=138188

r138188 | rguenth | 2008-07-27 14:38:30 + (Sun, 27 Jul 2008)


-- 
   Summary: bad tail call from tuples merge
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug target/37010] -mno-accumulate-outgoing-args doesn't work with stack alignment

[hjl dot tools at gmail dot com]

--- Comment #13 from hjl dot tools at gmail dot com  2008-08-04 21:29 
---
The previous ix86_compute_frame_layout uses

  /* Align start of frame for local function.  */
  frame->padding1 = ((offset + stack_alignment_needed - 1)
 & -stack_alignment_needed) - offset;

to align the stack offset. That was correct since before stack alignment
merge, the outgoing stack alignment is no bigger than the incoming stack
alignment. That is no longer true after stack alignment merge.


-- 


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[rguenther at suse dot de]

--- Comment #14 from rguenther at suse dot de  2008-08-04 21:13 ---
Subject: Re:  [4.3/4.4 Regression] member function pointer
 failure with optimization

On Mon, 4 Aug 2008, rguenther at suse dot de wrote:

> --- Comment #13 from rguenther at suse dot de  2008-08-04 21:11 ---
> Subject: Re:  [4.3/4.4 Regression] member function pointer
>  failure with optimization
> 
>  So I would prefer if
> you add those to the AGGREGATE_TYPE_P case instead of letting
> it fall-through to the "default" case - we should probably add
> some gcc_unreachable () to make sure we handled all cases.

On a second thought this is probably not so good, but a
/* Fallthrough.  */ comment would be nice for the AGGREGATE_TYPE_P case.

Thanks,
Richard.


-- 


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[rguenther at suse dot de]

--- Comment #13 from rguenther at suse dot de  2008-08-04 21:11 ---
Subject: Re:  [4.3/4.4 Regression] member function pointer
 failure with optimization

On Mon, 4 Aug 2008, jason at gcc dot gnu dot org wrote:

> --- Comment #12 from jason at gcc dot gnu dot org  2008-08-04 21:03 
> ---
> Well, that's the problem then: we have two POINTER_TYPE to METHOD_TYPE which
> are considered equivalent in the front end, but not equivalent in the tree-ssa
> types_compatible_p.
> 
> The specific bug seems to be that useless_type_conversion_1 doesn't expect to
> need to do structural comparison of non-aggregate types.  That's an invalid
> assumption; it should check TYPE_STRUCTURAL_EQUALITY_P.  Does the attached
> patch seem appropriate to you?  It fixes the bug for me, though I haven't
> regression tested it.

Duh, if TYPE_STRUCTURAL_EQUALITY_P is used on non-aggregates then yes,
this is a correct patch (the code currently makes FUNCTION_TYPEs and
METHOD_TYPEs distinct if they are not pointer-equivalent or linked
via TYPE_CANONICAL / TYPE_MAIN_VARIANT).  So I would prefer if
you add those to the AGGREGATE_TYPE_P case instead of letting
it fall-through to the "default" case - we should probably add
some gcc_unreachable () to make sure we handled all cases.

Thanks,
Richard.


-- 


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2008-08-04 21:03 ---
Well, that's the problem then: we have two POINTER_TYPE to METHOD_TYPE which
are considered equivalent in the front end, but not equivalent in the tree-ssa
types_compatible_p.

The specific bug seems to be that useless_type_conversion_1 doesn't expect to
need to do structural comparison of non-aggregate types.  That's an invalid
assumption; it should check TYPE_STRUCTURAL_EQUALITY_P.  Does the attached
patch seem appropriate to you?  It fixes the bug for me, though I haven't
regression tested it.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-04 09:18:24 |2008-08-04 21:03:50
   date||


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2008-08-04 21:02 ---
Created an attachment (id=16017)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16017&action=view)
Patch to check TYPE_STRUCTURAL_EQUALITY_P in useless_type_conversion


-- 


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

[Bug c/37023] Macro replacement not working if file is preprocessed then compiler

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-08-04 20:46 ---
This was fixed by:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01145.html


-- 


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

[Bug c/37023] Macro replacement not working if file is preprocessed then compiler

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-04 20:41 ---
This works for me on the trunk ...


-- 


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

[Bug c/37023] New: Macro replacement not working if file is preprocessed then compiler

[geir at cray dot com]

The following program shows two cases where macro replacement works if the
program is compiled, but does NOT work if the program is preprocessed and then
compiled.  Either the preprocessed program should be able to be compiled, or
gcc should return an error when the non-preprocessed code is compiled.


$ cat ISU3006.c

/*  derived from ISU's RTED_OpenMP/C/Col7_Imp_Dep_Errs/c_G_1_1_a.c  */
/*  Trying c99 _Pragma possibility  */
#include 
#include 
#include 
#define NT 4
#define N 17

#ifdef TEST3
#define NTM(x) #x
#define PRAGMA(x) NTM(omp parallel default(none) shared(vara,
actual_num_threads) num_threads(x) )
#define LISTING(x) _Pragma(x)
#endif

int actual_num_threads;

int main(){
int vara=0;

#ifdef TEST3
  LISTING(PRAGMA(NT))
#elif TEST2
  _Pragma ( "omp parallel default(none) shared(vara, actual_num_threads)
num_threads(NT)" )
#else /*TEST1*/
 #pragma omp parallel default(none) shared(vara, actual_num_threads)
num_threads(NT)
#endif
{
#pragma omp master
{
actual_num_threads = omp_get_num_threads();
vara = 10 + actual_num_threads;
}
}
printf("calculate vara: %d\n",vara);
return 0;
}

$ gcc --version
gcc (GCC) 4.3.1 20080606 (rpm:5)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -fopenmp ISU3006.c
$ gcc -DTEST2 -fopenmp ISU3006.c
$ gcc -E -fopenmp ISU3006.c >i1.i
$ gcc -fopenmp i1.i
ISU3006.c: In function 'main':
ISU3006.c:26: error: 'NT' undeclared (first use in this function)
ISU3006.c:26: error: (Each undeclared identifier is reported only once
ISU3006.c:26: error: for each function it appears in.)
ISU3006.c:26: error: expected integer expression before end of line
$ grep parallel i1.i
extern int omp_in_parallel (void) __attribute__((__nothrow__));
#pragma omp parallel default(none) shared(vara, actual_num_threads)
num_threads(NT)
$ gcc -DTEST2 -E -fopenmp ISU3006.c >i2.i
$ gcc -fopenmp i2.i
ISU3006.c: In function 'main':
ISU3006.c:24: error: 'NT' undeclared (first use in this function)
ISU3006.c:24: error: (Each undeclared identifier is reported only once
ISU3006.c:24: error: for each function it appears in.)
ISU3006.c:24: error: expected integer expression before end of line
$ grep parallel i2.i
extern int omp_in_parallel (void) __attribute__((__nothrow__));
#pragma omp parallel default(none) shared(vara, actual_num_threads)
num_threads(NT)
$

   Here is code that allows the program to be compiled when first running it
through the preprocessor:

$ gcc -DTEST3 -fopenmp ISU3006.c
$ gcc -DTEST3 -E -fopenmp ISU3006.c >i3.i
$ gcc -fopenmp i3.i
$ grep parallel i3.i
extern int omp_in_parallel (void) __attribute__((__nothrow__));
#pragma omp parallel default(none) shared(vara, actual_num_threads)
num_threads(4)
$


-- 
   Summary: Macro replacement not working if file is preprocessed
then compiler
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-08-04 20:27 
---
The middle-end expects that if there is variable of record type T that for
a component-reference it can walk its fields and find the one used as
operand 1 in the component-reference.

If you look at the tree in commend #4 as it reaches the middle-end then
this is not the case.  SRA tries to deal with this by doing

case FIELD_DECL:
  /* Fields are unique within a record, but not between
 compatible records.  */
  if (DECL_FIELD_CONTEXT (ae) == DECL_FIELD_CONTEXT (be))
return false;
  return fields_compatible_p (ae, be);

but fields_compatible_p returns false because

  if (!types_compatible_p (TREE_TYPE (f1), TREE_TYPE (f2)))
return false;

returns false.


-- 


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2008-08-04 20:17 ---
However, it's not clear to me that pointers to member functions need to have
TYPE_STRUCTURAL_EQUALITY_P in general; I'm testing a patch to set
TYPE_CANONICAL appropriately.


-- 


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

[Bug debug/37022] libffi test suite failures

[andreast at gcc dot gnu dot org]

--- Comment #1 from andreast at gcc dot gnu dot org  2008-08-04 19:59 
---
Created an attachment (id=16016)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16016&action=view)
preprocessed source closure_fn1

Preprocessed source.


-- 


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

[Bug debug/37022] New: libffi test suite failures

[andreast at gcc dot gnu dot org]

FAIL: libffi.call/closure_fn1.c -Os (test for excess errors)
FAIL: libffi.call/closure_fn2.c -Os (test for excess errors)
FAIL: libffi.call/closure_fn6.c -Os (test for excess errors)
FAIL: libffi.call/cls_6_1_byte.c -Os (test for excess errors)
FAIL: libffi.call/cls_7_1_byte.c -Os (test for excess errors)

/Volumes/development/gcc/head/gcc/libffi/testsuite/libffi.call/closure_fn1.c:
In function 'main':^M
/Volumes/development/gcc/head/gcc/libffi/testsuite/libffi.call/closure_fn1.c:89:
internal compiler error: in compute_barrier_args_size, at dwarf2out.c:1279^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M

FAIL: libffi.call/closure_fn1.c -Os (test for excess errors)


Revision 138427 introduces these failures.


-- 
   Summary: libffi test suite failures
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andreast at gcc dot gnu dot org
 GCC build triplet: x86_64-apple-darwin9
  GCC host triplet: x86_64-apple-darwin9
GCC target triplet: x86_64-apple-darwin9


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

[Bug c++/36963] [4.4 Regression] Bogus narrowing conversion error in initializer list.

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2008-08-04 19:55 ---
Subject: Bug 36963

Author: jason
Date: Mon Aug  4 19:53:57 2008
New Revision: 138652

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138652
Log:
PR c++/36963
* typeck2.c (check_narrowing): Allow narrowing conversion
from an explicit floating-point constant.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/g++.dg/cpp0x/initlist5.C


-- 


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

[Bug target/37010] -mno-accumulate-outgoing-args doesn't work with stack alignment

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2008-08-04 19:38 
---
(In reply to comment #11)
> (In reply to comment #10)
> > Did you mean we needed 2 "additional 'and $-16, sp" insns to align the
> > stack? I don't think so.
> Definitely not. 
> Solution 1: Just ignore it. __m128 parameter shouldn't be passed with
> -mpreferred-stack-boundary=2, or

That will defeat the whole purpose for stack alignment. How do you
align __m1256 when -mpreferred-stack-boundary=4?

> Solution 2. Record max alignment of all outgoing parameter, and
> crtl->preferred_stack_boundary >= max_parameter_alignment

crtl->preferred_stack_boundary is correct.

I think the problem is in

  /* Set offset to aligned because the realigned frame tarts from here.  */
  if (stack_realign_fp)
offset = (offset + stack_alignment_needed -1) & -stack_alignment_needed;

This code assumes that offset 0 is properly aligned to any alignment,
which isn't true. It happens to work with -maccumulate-outgoing-args.


-- 


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2008-08-04 19:37 ---
In general, it seems like SRA needs to be more conservative with
TYPE_STRUCTURAL_EQUALITY_P types such as these.


-- 


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

[Bug c++/16663] Poor error recovery

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-08-04 19:22 ---
Created an attachment (id=16015)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16015&action=view)
testcase

Testcase


-- 


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

[Bug c++/16663] Poor error recovery

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-08-04 19:21 ---
In GCC 4.4 we have:

pr16663.C:2: error: variable or field ‘Foo’ declared void
pr16663.C:2: error: ‘misspelled’ was not declared in this scope
pr16663.C:2: error: expected primary-expression before ‘char’
pr16663.C:2: error: expected primary-expression before ‘bool’
pr16663.C:2: error: expected primary-expression before ‘float’

This is not easy to fix since that statement can be a function declaration but
also a variable declaration and initialization. We try to parse tentatively the
first case, fail, then we parse the second case and see that 'void' is not
allowed and that 'misspelled' is not declared.

If we have 

int Bar(misspelled a, char b, bool c, float f);

then we get the full list of error messages:

pr16663.C:4: error: ‘misspelled’ was not declared in this scope
pr16663.C:4: error: expected primary-expression before ‘char’
pr16663.C:4: error: expected primary-expression before ‘bool’
pr16663.C:4: error: expected primary-expression before ‘float’
pr16663.C:4: error: initializer expression list treated as compound expression


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2005-07-23 05:28:50 |2008-08-04 19:21:19
   date||


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

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|major   |normal


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

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-08-04 18:53 ---
>The creator of the Operating System can name any command any name they want
> (EG: Ralph can be spelled Ralf or Rolf etc). Similarly grep can be called sed
> and sed can be called diff -- I'm not suggested that is a good idea, just that
> it is possible.

Not if they want to call their OS a POSIX or UNIX OS really.  POSIX actually
makes a standard about programs too.


-- 


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

[Bug libgcj/31890] Java Namespace error - javaprims.h out of sync

[tromey at gcc dot gnu dot org]

--- Comment #4 from tromey at gcc dot gnu dot org  2008-08-04 18:52 ---
Testing a patch.


-- 

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 |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-05-14 20:57:32 |2008-08-04 18:52:09
   date||


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

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2008-08-04 18:44 ---
> I wrote:
> It would be nice if the main configure script caught this instead of the build
failing just as it was about to finish.

But then I would not have to try fixing this ...

The boehm-gc directory built correctly and the build continues until we get to
the libjava directory that fails with this error:

...
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for garbage collector to use... boehm
checking for thread model used by GCC... solaris
configure: error: thread package solaris not yet supported
gmake[2]: *** [config.status] Error 1
gmake[2]: Leaving directory `/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/aux0/gcc-4.2.3_build'
gmake: *** [all] Error 2


The _matching_ portions of the "gcc-4.2.3/boehm-gc/configure" and the
"gcc-4.2.3/libjava/configure" can be fixed the same way.


The libjava configure has a few problems:

1. Libjava can be configured to use the Boehm Garbage Collection - so the
configuring should matchup the threading types and options more closely.

2. Another huge bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

3. Various parts in "libjava/configure" make assumtions that are not true
and are not the same as those made in "boehm-gc/configure":

EG: 

In the "case "$THREADS" in" section (line 5354 in "boehm-gc/configure" and line
9109 in libjava/configure) the boehm configury separates the various Operating
Systems in a more fine-grained manner than is done in the libjava configury.


The libjava configury checks for these thread types (with only ONE case
statement used for "*-*-linux*" and (much later) a few more OS types are
checked):

no | none | single)
posix | posix95 | pthreads)
case "$host" in
 *-*-linux*)
cat >>confdefs.h <<\_ACEOF
#define LINUX_THREADS 1
_ACEOF
;;
esac
win32)
decosf1 | irix | mach | os2 | solaris | dce | vxworks)
...
case "$THREADS" in
 posix)
case "$host" in
 *-*-cygwin*)
# Don't set THREADLIBS here.  Cygwin doesn't have -lpthread.
;;
 *-*-freebsd[1234]*)
# Before FreeBSD 5, it didn't have -lpthread (or any library which
# merely adds pthread_* functions) but it does have a -pthread switch
# which is required at link-time to select -lc_r *instead* of -lc.
THREADLDFLAGS=-pthread
# Don't set THREADSPEC here as might be expected since -pthread is
# not processed when found within a spec file, it must come from
# the command line.  For now, the user must provide the -pthread
# switch to link code compiled with gcj.  In future, consider adding
# support for weak references to pthread_* functions ala gthr.h API.
THREADSPEC='%{!pthread: %{!shared: %eUnder this configuration, the user
must provide -pthread when linking.}}'
;;
 *-*-freebsd*)
# FreeBSD >=5.3 implements a model much closer to other modern UNIX
# systems which support threads and -lpthread.
THREADLDFLAGS=-pthread
THREADSPEC=-lpthread
;;
 alpha*-dec-osf* | hppa*-hp-hpux*)
THREADCXXFLAGS=-pthread
# boehm-gc needs some functions from librt, so link that too.
THREADLIBS='-lpthread -lrt'
THREADSPEC='-lpthread -lrt'
;;
 *)
THREADLIBS=-lpthread
THREADSPEC=-lpthread
;;
esac
THREADH=posix-threads.h
# MIT pthreads doesn't seem to have the mutexattr functions.
# But for now we don't check for it.  We just assume you aren't
# using MIT pthreads.
cat >>confdefs.h <<\_ACEOF
#define HAVE_PTHREAD_MUTEXATTR_INIT 1
_ACEOF
# If we're using the Boehm GC, then we happen to know that it
# defines _REENTRANT, so we don't bother.  Eww.
if test "$GC" != boehm; then
cat >>confdefs.h <<\_ACEOF
#define _REENTRANT 1
_ACEOF
fi
cat >>confdefs.h <<\_ACEOF
#define _POSIX_PTHREAD_SEMANTICS 1
_ACEOF
;;
 win32)
THREADH=win32-threads.h
THREADCXXFLAGS=-mthreads
# We need thread-safe exception handling so _CRT_MT should be set to 1.
# But we do not want the executables created to be dependent on
# mingwm10.dll which provides a __mingwthr_key_dtor() that cleans up
# exception handling contexts.  The following kludge achieves this effect
# and causes a dummy __mingwthr_key_dtor() to be linked in from
# libmingw32.a.  This causes a memory leak of about 24 bytes per thread.
# A workaround is to explicitly use -mthreads while linking Java programs.
# See PR libgcj/28263.
#
# FIXME: In Java we are able to detect thread death at the end of
# Thread.run() so we should be able to clean up the exception handling
# contexts ourselves.
THREADSTARTFILESPEC='crtmt%O%s'
;;
 none)
THREADH=no-threads.h
;;
esac
  ac_config_links="$ac_config_links
include/java-threads.

[Bug c++/37006] explicitly deleted inline function gives warning "used but never defined"

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-08-04 18:40 ---
Subject: Bug 37006

Author: jason
Date: Mon Aug  4 18:39:16 2008
New Revision: 138648

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138648
Log:
PR c++/37006
* pt.c (tsubst_decl): Leave DECL_INITIAL set on deleted
instantiations.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c


-- 


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

[Bug c++/36959] [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
   Priority|P3  |P2


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

[Bug tree-optimization/36905] [4.2/4.3/4.4 Regression] IV-opts needs a little help with a[i+1]

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-04 18:38 ---
I believe we have a dup for this issue - it looks very familiar.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)

[tromey at gcc dot gnu dot org]

--- Comment #8 from tromey at gcc dot gnu dot org  2008-08-04 18:32 ---
Hmm, I could not get bugzilla to change the product.


-- 


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

[Bug middle-end/36691] [4.2 Regression] wrong value left in induction variable

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-08-04 18:32 
---
Subject: Bug 36691

Author: rguenth
Date: Mon Aug  4 18:30:59 2008
New Revision: 138646

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138646
Log:
2008-08-04  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36691
* tree-ssa-loop-niter.c (number_of_iterations_lt_to_ne): Correctly
check for no_overflow.

* gcc.c-torture/execute/pr36691.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr36691.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-loop-niter.c


--- Comment #11 from rguenth at gcc dot gnu dot org  2008-08-04 18:32 
---
Fixed on the trunk and the 4.3 branch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
  Known to work|4.1.0   |4.1.0 4.3.2 4.4.0
Summary|[4.2/4.3/4.4 Regression]|[4.2 Regression] wrong value
   |wrong value left in |left in induction variable
   |induction variable  |


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

[Bug middle-end/36691] [4.2/4.3/4.4 Regression] wrong value left in induction variable

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-08-04 18:32 
---
Subject: Bug 36691

Author: rguenth
Date: Mon Aug  4 18:30:59 2008
New Revision: 138646

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138646
Log:
2008-08-04  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36691
* tree-ssa-loop-niter.c (number_of_iterations_lt_to_ne): Correctly
check for no_overflow.

* gcc.c-torture/execute/pr36691.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr36691.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-loop-niter.c


-- 


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

[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)

[tromey at gcc dot gnu dot org]

--- Comment #7 from tromey at gcc dot gnu dot org  2008-08-04 18:31 ---
I didn't fix anything.
AFAIK the classpath configury still does not check versions.

I'm moving this to the classpath product.
It should be fixed there.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-04 18:31:27
   date||


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

[Bug middle-end/36691] [4.2/4.3/4.4 Regression] wrong value left in induction variable

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-08-04 18:30 ---
Subject: Bug 36691

Author: rguenth
Date: Mon Aug  4 18:29:08 2008
New Revision: 138645

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138645
Log:
2008-08-04  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36691
* tree-ssa-loop-niter.c (number_of_iterations_lt_to_ne): Correctly
check for no_overflow.

* gcc.c-torture/execute/pr36691.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr36691.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c


-- 


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

[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-04 17:58 ---
Patch for 1) http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00221.html
Patch for 2) http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00226.html

I didn't yet start on 3), so 4) is unknown yet (as is 5, 6, ... ;))


-- 


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

[Bug tree-optimization/37021] New: Fortran Complex reduction / multiplication not vectorized

[rguenth at gcc dot gnu dot org]

subroutine to_product_of(self,a,b,a1,a2)
  complex(kind=8) :: self (:)
  complex(kind=8), intent(in) :: a(:,:)
  complex(kind=8), intent(in) :: b(:)
  integer a1,a2
  self = ZERO
  do i = 1,a1
do j = 1,a2
  self(i) = self(i) + a(i,j)*b(j)
end do
  end do
end subroutine

There are numerous reasons this is not vectorized at the moment:
 1) aliasing doesn't tell apart the data of self, a and b
 2) the reduction is obfuscated by extra SSA_NAME copies from store-motion
(after you fix 1)
 3) REALPART_EXPR < (*ptr)[i] > is not handled by data dependency analysis
 4) ... ?


-- 
   Summary: Fortran Complex reduction / multiplication not
vectorized
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization, alias
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug middle-end/37009] No need to align stack when incoming stack is aligned

[hjl at gcc dot gnu dot org]

--- Comment #3 from hjl at gcc dot gnu dot org  2008-08-04 17:48 ---
Subject: Bug 37009

Author: hjl
Date: Mon Aug  4 17:47:02 2008
New Revision: 138644

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138644
Log:
2008-08-04  H.J. Lu  <[EMAIL PROTECTED]>

PR middle-end/37009
* gcc.dg/torture/stackalign/alloca-4.c: New.
* gcc.target/i386/incoming-5.c: Likewise.

* gcc.target/i386/incoming-1.c: Update scan.
* gcc.target/i386/incoming-4.c: Likewise.

Added:
branches/stack/gcc/testsuite/gcc.dg/torture/stackalign/alloca-4.c
branches/stack/gcc/testsuite/gcc.target/i386/incoming-5.c
Modified:
branches/stack/gcc/testsuite/ChangeLog.stackalign
branches/stack/gcc/testsuite/gcc.target/i386/incoming-1.c
branches/stack/gcc/testsuite/gcc.target/i386/incoming-4.c


-- 


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

[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64

[sje at cup dot hp dot com]

--- Comment #24 from sje at cup dot hp dot com  2008-08-04 17:34 ---
I bootstrapped the 3 patches on mainline and 4.3 branch and verified that they
fix the problem that is reported on the 4.3 branch with the patches.


-- 


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

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2008-08-04 17:21 ---
Created an attachment (id=16014)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16014&action=view)
gdiff of Origonal gcc-4.2.3/libjava/configure vs. repaired version

gdiff -Naur config_Origonal_configure.log config_Modified-1_configure.log >
diff_of_logs.gdiff


-- 


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

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2008-08-04 17:18 ---
>Ralf Wildenhues  2008-08-04 08:57 wrote:
>I see the egrep issue.

Would you click the "CONFIRMED" button please.


> Can you please specify for which grep and sed commands you see errors?

I need to build some dependencies (that will take a few days) before I can run
the _entire_ script, but I do have an initial report (see below) ...


> The assumption is that all systems do have sed and grep available, but
> that the vendor versions of these tools have some quirks that make it
> unsuitable for some (but not all) uses.  Wrt. egrep and fgrep, there
> are systems for which 'grep -E' and 'grep -F' have to be used.

> If any of these assumptions are not valid, then I would like to know
> details, so that the Autoconf manual can be updated to reflect this.


> > If any of these assumptions are not valid ...
> > have some quirks that make it unsuitable for some (but not all) uses

Assume that _ALL_ commands (grep, make, egrep, diff, _everything_) are not
"valid" _GNU_ commands. 

The creator of the Operating System can name any command any name they want
(EG: Ralph can be spelled Ralf or Rolf etc). Similarly grep can be called sed
and sed can be called diff -- I'm not suggested that is a good idea, just that
it is possible.


>From a practical point of view it makes sense to run the command with
"--version" (or "-v" or "-V") and check that it is indeed a GNU program and
that the version is "new enough" that _ALL_ following uses of the command will
operate correctly.

Yes, that would be a rewrite of a lot of scripts but if you want to make sure
that everything works you need the sanity tests to run at the beginning of each
script. If you don't check that you are sane then how can you decide anything ?

---

The Solaris 11 OS that I am using is only a couple of months old.

When I do a directory listing to find my "g-prefixed" commands I get a list
like this (I edited out some obvious commands that are not "g-prefixed"
versions and hopefully was not too heavy-handed):

# ls -l /usr/bin/g*
-r-xr-xr-x   1 root bin30432 Jun 26 18:26 /usr/bin/gcmp
...
-r-xr-xr-x   1 root bin   151740 Jun 26 18:26 /usr/bin/gdiff
-r-xr-xr-x   1 root bin36712 Jun 26 18:26 /usr/bin/gdiff3
...
-r-xr-xr-x   3 root bin   116268 Jun 26 17:02 /usr/bin/gegrep
...
-r-xr-xr-x   3 root bin   116268 Jun 26 17:02 /usr/bin/gfgrep
-r-xr-xr-x   1 root bin23568 Jun 26 19:58 /usr/bin/ggettext
-r-xr-xr-x   3 root bin   116268 Jun 26 17:02 /usr/bin/ggrep
...
-r-xr-xr-x   1 root bin   151780 Jun 26 18:00 /usr/bin/gm4
-r-xr-xr-x   1 root bin   153036 Jun 26 18:01 /usr/bin/gmake
...
-r-xr-xr-x   1 root bin   315084 Jun 26 19:58 /usr/bin/gmsgfmt
...
-r-xr-xr-x   1 root bin88376 Jun 26 16:48 /usr/bin/gpatch
...
-r-xr-xr-x   1 root bin34728 Jun 26 18:26 /usr/bin/gsdiff
...
-r-xr-xr-x   1 root bin   312884 Jun 26 17:02 /usr/bin/gtar


That is about all I can spot from eye / memory / knowledge about GNUisms.


That list is, again: gcmp, gdiff, gdiff3, gegrep, gfgrep, ggettext, ggrep, gm4,
gmake, gmsgfmt, gpatch, gsdiff, gtar, (etc, possibly I missed one).

This means that any attempt to use these programs (on Solaris and _some_ other
OSes) will fail.


Here is the output for each program and for Solaris 11's "g-prefixed" version:

---
# cmp --version
cmp: illegal option -- version
usage: cmp [-l | -s] file1 file2 [skip1] [skip2]

# gcmp --version
cmp (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Written by Torbjorn Granlund and David MacKenzie.
---
# diff --version
diff: illegal option -- version
usage: diff [-bitw] [-c | -e | -f | -h | -n | -u] file1 file2
   diff [-bitw] [-C number | -U number] file1 file2
   diff [-bitw] [-D string] file1 file2
   diff [-bitw] [-c | -e | -f | -h | -n | -u] [-l] [-r] [-s] [-S name]
directory1 directory2

# gdiff --version
diff (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Written by Paul Eggert, Mike Haertel, David Hayes,
Richard Stallman, and Len Tower.
---
# diff3 --version
usage: diff3 file1 file2 file3

# gdiff3 --version
diff3 (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters,

[Bug debug/37020] New: [4.4 Regression] [AVR] FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline

[eric dot weddington at atmel dot com]

>From test suite for the AVR target:
FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline

This test case has failed recently:
4.4.0 20080729 (experimental) [trunk revision 138276]
http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02938.html
(and in the most recent trunk).

But the test case passed on:
4.4.0 20080728 (experimental) [trunk revision 138218]
http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02823.html


-- 
   Summary: [4.4 Regression] [AVR] FAIL: gcc.dg/debug/dwarf2/dwarf-
die3.c scan-assembler-not DW_AT_inline
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot weddington at atmel dot com
GCC target triplet: avr-*-*


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

I-N-G-Y-E-N - S.e.X

[ingyentini]

Szia

Szeretnék figyelmedbe ajánlani egy INGYENES SEX OLDALT!!!

IME A CIME: http://freesex.rapidsms.eu

[Bug c++/36999] Erroneous "declaration 'class ...' does not declare anything" warnings possible

[simonb at gcc dot gnu dot org]

--- Comment #1 from simonb at gcc dot gnu dot org  2008-08-04 15:11 ---
Subject: Bug 36999

Author: simonb
Date: Mon Aug  4 15:09:56 2008
New Revision: 138633

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138633
Log:
PR c++/36999
* parser.c (cp_parser_elaborated_type_specifier): Warn only when
the declaration's id is followed by a semicolon.

* g++.dg/warn/pr36999.C: New.


Added:
trunk/gcc/testsuite/g++.dg/warn/pr36999.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[hjl at gcc dot gnu dot org]

--- Comment #29 from hjl at gcc dot gnu dot org  2008-08-04 14:57 ---
Subject: Bug 37012

Author: hjl
Date: Mon Aug  4 14:56:12 2008
New Revision: 138631

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138631
Log:
2008-08-04  H.J. Lu  <[EMAIL PROTECTED]>

PR target/37012
* config/i386/i386.c (ix86_expand_prologue): Use UNITS_PER_WORD
instead of STACK_BOUNDARY / BITS_PER_UNIT to align stack.
(ix86_expand_epilogue): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c


-- 


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

[Bug target/37010] -mno-accumulate-outgoing-args doesn't work with stack alignment

[Joey dot ye at intel dot com]

--- Comment #11 from Joey dot ye at intel dot com  2008-08-04 14:11 ---
(In reply to comment #10)
> Did you mean we needed 2 "additional 'and $-16, sp" insns to align the
> stack? I don't think so.
Definitely not. 
Solution 1: Just ignore it. __m128 parameter shouldn't be passed with
-mpreferred-stack-boundary=2, or
Solution 2. Record max alignment of all outgoing parameter, and
crtl->preferred_stack_boundary >= max_parameter_alignment


-- 


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-08-04 14:00 ---
Causes

FAIL: g++.dg/template/ptrmem8.C  (test for errors, line 18)
FAIL: g++.dg/template/ptrmem8.C  (test for errors, line 19)

Jason - can you help here?  Thanks.


-- 


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

[Bug middle-end/37009] No need to align stack when incoming stack is aligned

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2008-08-04 13:53 ---
Subject: Bug 37009

Author: hjl
Date: Mon Aug  4 13:51:36 2008
New Revision: 138621

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138621
Log:
gcc/

2008-08-04  H.J. Lu  <[EMAIL PROTECTED]>

PR middle-end/37009
* cfgexpand.c (expand_stack_alignment): Check parm_stack_boundary
for incoming stack boundary.

* function.c (assign_parm_find_entry_rtl): Update
parm_stack_boundary.

* function.h (rtl_data): Add parm_stack_boundary.

* config/i386/i386.c (ix86_finalize_stack_realign_flags): Check
parm_stack_boundary for incoming stack boundary.

gcc/testsuite/

2008-08-04  H.J. Lu  <[EMAIL PROTECTED]>

PR middle-end/37009
* gcc.dg/torture/stackalign/alloca-2.c: New.
* gcc.dg/torture/stackalign/alloca-3.c: Likewise.
* gcc.dg/torture/stackalign/vararg-3.c: Likewise.
* gcc.target/i386/incoming-1.c: Likewise.
* gcc.target/i386/incoming-2.c: Likewise.
* gcc.target/i386/incoming-3.c: Likewise.
* gcc.target/i386/incoming-4.c: Likewise.

Added:
branches/stack/gcc/testsuite/gcc.dg/torture/stackalign/alloca-2.c
branches/stack/gcc/testsuite/gcc.dg/torture/stackalign/alloca-3.c
branches/stack/gcc/testsuite/gcc.dg/torture/stackalign/vararg-3.c
branches/stack/gcc/testsuite/gcc.target/i386/incoming-1.c
branches/stack/gcc/testsuite/gcc.target/i386/incoming-2.c
branches/stack/gcc/testsuite/gcc.target/i386/incoming-3.c
branches/stack/gcc/testsuite/gcc.target/i386/incoming-4.c
Modified:
branches/stack/gcc/ChangeLog.stackalign
branches/stack/gcc/cfgexpand.c
branches/stack/gcc/config/i386/i386.c
branches/stack/gcc/function.c
branches/stack/gcc/function.h
branches/stack/gcc/testsuite/ChangeLog.stackalign


-- 


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

[Bug libgcj/31890] Java Namespace error - javaprims.h out of sync

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2008-08-04 13:50 ---
Changed severity back up to normal (from minor) since this bug has sat open for
a year with no reply, and there is something to fix.


-- 

rob1weld at aol dot com changed:

   What|Removed |Added

   Severity|minor   |normal


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

[Bug libgcj/32028] Make fails at gjdoc - gnu.classpath.tools.gjdoc.ParseException: unmatched input in line 1: @Retention(SOURCE) @Target(METHOD)

[rob1weld at aol dot com]

--- Comment #6 from rob1weld at aol dot com  2008-08-04 13:44 ---
> Andrew John Hughes 2008-06-20 14:34:
> What is this bug waiting on?

> Tom Tromey 2007-05-24 17:18:
> I think gjdoc only recently got support for generics and annotations.
> So an older gjdoc is expected to fail.  I haven't been keeping track
> of gjdoc version numbers but I expect if you install a newer version
> this will work.  Can you try that?


It is at this point that Tom changed the status to WAITING.


> Rob 2007-05-25 19:12:
> Tom, here are the results you requested:


The next post is yours ("Andrew John Hughes 2008-06-20 14:34") asking why is
there the WAITING status. 

Tom _was_ waiting for me to fufill his request, which I did.

I am waiting for this to be fixed and for Tom to click on "Resolve bug,
changing resolution to FIXED".

I had switched platforms so I can not test if Tom has fixed this and change the
status myself.


-- 


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-08-04 13:41 ---
Of course it didn't work.  The following seems to

Index: gcc/cp/class.c
===
--- gcc/cp/class.c  (revision 138611)
+++ gcc/cp/class.c  (working copy)
@@ -6197,7 +6197,12 @@ resolve_address_of_overloaded_function (
 }

   if (TYPE_PTRFN_P (target_type) || TYPE_PTRMEMFUNC_P (target_type))
-return cp_build_unary_op (ADDR_EXPR, fn, 0, flags);
+{
+  tree tem = cp_build_unary_op (ADDR_EXPR, fn, 0, flags);
+  if (TREE_CODE (tem) == PTRMEM_CST)
+   return make_ptrmem_cst (target_type, fn);
+  return tem;
+}
   else
 {
   /* The target must be a REFERENCE_TYPE.  Above, cp_build_unary_op


we might be able to unconditionally do return make_ptrmem_cst (target_type,
fn);
for TYPE_PTRMEMFUNC_P (target_type) though.


-- 


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

[Bug middle-end/36691] [4.2/4.3/4.4 Regression] wrong value left in induction variable

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-08-04 13:36 ---
Because somehow we get into

  /* If we can determine the final value of the control iv exactly, we can
 transform the condition to != comparison.  In particular, this will be
 the case if DELTA is constant.  */
  if (number_of_iterations_lt_to_ne (type, iv0, iv1, niter, &delta, step,
 bnds))
{
  affine_iv zps;

and that figures it can just use [0, 5] - but number_of_iterations_lt_to_ne
didn't add any assumptions...  why does it take the "absolute value of
the step", and why do we compute that (unconditionally) by negating the
step?

It looks like at least

  /* The final value of the iv is iv0->base - MOD, assuming that this
 computation does not overflow, and that
 iv0->base - MOD <= iv1->base. */
  if (!iv0->no_overflow && !integer_zerop (mod))

is wrong, as iv0 is just { 3, 0, true } (mod == 4), so certainly the
assumption computed (if we would compute it) is false.

So, with

Index: tree-ssa-loop-niter.c
===
--- tree-ssa-loop-niter.c   (revision 138620)
+++ tree-ssa-loop-niter.c   (working copy)
@@ -677,7 +677,7 @@ number_of_iterations_lt_to_ne (tree type
   tree tmod;
   mpz_t mmod;
   tree assumption = boolean_true_node, bound, noloop;
-  bool ret = false;
+  bool no_overflow, ret = false;
   tree type1 = type;
   if (POINTER_TYPE_P (type))
 type1 = sizetype;
@@ -692,12 +692,13 @@ number_of_iterations_lt_to_ne (tree type
   mpz_set_double_int (mmod, tree_to_double_int (mod), true);
   mpz_neg (mmod, mmod);

+  no_overflow = iv0->no_overflow && iv1->no_overflow;
   if (integer_nonzerop (iv0->step))
 {
   /* The final value of the iv is iv1->base + MOD, assuming that this
 computation does not overflow, and that
 iv0->base <= iv1->base + MOD.  */
-  if (!iv1->no_overflow && !integer_zerop (mod))
+  if (!no_overflow && !integer_zerop (mod))
{
  bound = fold_build2 (MINUS_EXPR, type,
   TYPE_MAX_VALUE (type1), tmod);
@@ -719,7 +720,7 @@ number_of_iterations_lt_to_ne (tree type
   /* The final value of the iv is iv0->base - MOD, assuming that this
 computation does not overflow, and that
 iv0->base - MOD <= iv1->base. */
-  if (!iv0->no_overflow && !integer_zerop (mod))
+  if (!no_overflow && !integer_zerop (mod))
{
  bound = fold_build2 (PLUS_EXPR, type1,
   TYPE_MIN_VALUE (type1), tmod);


we make the testcase work.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #28 from howarth at nitro dot med dot uc dot edu  2008-08-04 
13:24 ---
I can't provide an .o until tonight but the last eh-alloca-1.s and the previous
eh-alloca-1.ii should be okay for a test case. I'll see if I can prune that
into
a smaller testcase later tonight.


-- 


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

[Bug middle-end/36691] [4.2/4.3/4.4 Regression] wrong value left in induction variable

[cnstar9988 at gmail dot com]

--- Comment #7 from cnstar9988 at gmail dot com  2008-08-04 13:12 ---
confirmed gcc 4.2.4, -O3.

gcc test.c -O3


-- 


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

[Bug middle-end/36691] [4.2/4.3/4.4 Regression] wrong value left in induction variable

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-08-04 13:00 ---
Slightly differently "worded" the testcase is

unsigned int g_5;

void func_1 (void)
{
  for (g_5 = 9; g_5 >= 4; g_5 -= 5)
;
}

extern void abort (void);
int main (void)
{
  func_1 ();
  if (g_5 != 0)
abort ();
  return 0;
}

so the loop wraps once (9, 4, UINT_MAX, ..., 5, 0).

>From the scev-cprop dump we see that the number of iterations is wrong:

Analyzing # of iterations of loop 1
  exit condition 3 < [4, + , 4294967291]
  bounds on difference of bases: 1 ... 1
  result:
# of iterations 1, bounded by 1
  (set_nb_iterations_in_loop = 1))


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[hjl dot tools at gmail dot com]

--- Comment #27 from hjl dot tools at gmail dot com  2008-08-04 12:52 
---
(In reply to comment #12)
> HJ,
>Your proposed patch eliminated all the stackalign failures in 'make -k
> check-gcc' reducing the total gcc failures down to 14 unexpected. I will do a
> 'make -k check-g++' next but this fix looks good so far.
> Jack
> 

The same patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00200.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||08/msg00200.html


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[hjl dot tools at gmail dot com]

--- Comment #26 from hjl dot tools at gmail dot com  2008-08-04 12:50 
---
(In reply to comment #24)
> I can comment out every abort in the eh-alloca-1.ii (renamed eh-alloca-1.C) 
> and
> the resulting executable still does...
> 
> terminate called after throwing an instance of 'A'
> Abort
> 
> The abort must be coming from within libstdc++, no?

That means DWARF2 unwind info is wrong. Please

1. Try to create a smallest testcase and provide the .ii file.
2. Provide the complete command line used to compile it.
3. Provide the .o file.
4. Provide the .s file.


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[hjl dot tools at gmail dot com]

--- Comment #25 from hjl dot tools at gmail dot com  2008-08-04 12:46 
---
(In reply to comment #19)
> I'll check eh-alloca-1.C shortly. Do you think we should also have...
> 
> --- i386.c.org  2008-08-03 22:55:01.0 -0400
> +++ i386.c  2008-08-03 22:56:07.0 -0400
> @@ -7242,7 +7242,7 @@
>preferred_alignment = crtl->preferred_stack_boundary / BITS_PER_UNIT;
> 
>gcc_assert (!size || stack_alignment_needed);
> -  gcc_assert (preferred_alignment >= STACK_BOUNDARY / BITS_PER_UNIT);

That is correct. Since STACK_BOUNDARY is required by MacOS, you
don't want to set stack alignment less than the one specified by
ABI.

> +  gcc_assert (preferred_alignment >= UNITS_PER_WORD);

That is wrong.

>gcc_assert (preferred_alignment <= stack_alignment_needed);
> 
>/* During reload iteration the amount of registers saved can change.
> 
> It didn't fix the issue but seems to be of identical form as the other 
> changes.
> Also,
> what about instances of the same construct in the gcc/gcc subdirectory 
> (outside
> of
> gcc/gcc/config/i386)?
> 

I think they are OK.


-- 


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

[Bug middle-end/36691] [4.2/4.3/4.4 Regression] wrong value left in induction variable

[cnstar9988 at gmail dot com]

--- Comment #5 from cnstar9988 at gmail dot com  2008-08-04 12:42 ---
ping...


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #24 from howarth at nitro dot med dot uc dot edu  2008-08-04 
12:32 ---
I can comment out every abort in the eh-alloca-1.ii (renamed eh-alloca-1.C) and
the resulting executable still does...

terminate called after throwing an instance of 'A'
Abort

The abort must be coming from within libstdc++, no?


-- 


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

[Bug target/37010] -mno-accumulate-outgoing-args doesn't work with stack alignment

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2008-08-04 12:26 
---
(In reply to comment #8)
> Root cause is that outgoing parameter frame is aligned based on stack pointer.
> Namely, address_of_stack_param = SP + offset + fixed_padding.
> 
> With -mpreferred-stack-boundary=2, alignment of SP is only 4 bytes. Outgoing
> frame won't be possibly aligned with 16 bytes without additional 'and $-16,
> sp'.

Did you mean we needed 2 "additional 'and $-16, sp" insns to align the
stack? I don't think so.


-- 


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

[Bug target/37010] -mno-accumulate-outgoing-args doesn't work with stack alignment

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2008-08-04 12:24 ---
(In reply to comment #7)
> This problem is associated with -mpreferred-stack-boundary=2, rather than with
> stack alignment. Following case fails on trunk before merging with stack
> branch:

Of course, before stack alignment merge, we can only align stack
variable to PREFERRED boundary, which is 1 << 2 == 4 bytes. 


-- 


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

[Bug bootstrap/35752] [4.3 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared

[bonzini at gnu dot org]

--- Comment #62 from bonzini at gnu dot org  2008-08-04 12:24 ---
committed.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[hjl dot tools at gmail dot com]

--- Comment #23 from hjl dot tools at gmail dot com  2008-08-04 12:21 
---
(In reply to comment #21)
> The eh-allocca-1.ii file generated is identical to that created before
> (although the compiled executable no longer segfaults but just aborts).
> 

There are ,many aborts. Please tell us which one.


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #22 from howarth at nitro dot med dot uc dot edu  2008-08-04 
12:08 ---
Created an attachment (id=16013)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16013&action=view)
assembly file for g++.dg/torture/stackalign/eh-alloca-1.C with proposed patch


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #21 from howarth at nitro dot med dot uc dot edu  2008-08-04 
12:07 ---
The eh-allocca-1.ii file generated is identical to that created before
(although the compiled executable no longer segfaults but just aborts).


-- 


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #20 from howarth at nitro dot med dot uc dot edu  2008-08-04 
12:04 ---
The failure of eh-alloca-1.C at -O3 is no longer a segfault but a normal abort
now.


-- 


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-08-04 11:56 ---
I'm testing that patch, but I'm sure some side-effects of cp_build_unary_op
are necessary...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
   Priority|P3  |P1


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

[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #19 from howarth at nitro dot med dot uc dot edu  2008-08-04 
11:56 ---
I'll check eh-alloca-1.C shortly. Do you think we should also have...

--- i386.c.org  2008-08-03 22:55:01.0 -0400
+++ i386.c  2008-08-03 22:56:07.0 -0400
@@ -7242,7 +7242,7 @@
   preferred_alignment = crtl->preferred_stack_boundary / BITS_PER_UNIT;

   gcc_assert (!size || stack_alignment_needed);
-  gcc_assert (preferred_alignment >= STACK_BOUNDARY / BITS_PER_UNIT);
+  gcc_assert (preferred_alignment >= UNITS_PER_WORD);
   gcc_assert (preferred_alignment <= stack_alignment_needed);

   /* During reload iteration the amount of registers saved can change.

It didn't fix the issue but seems to be of identical form as the other changes.
Also,
what about instances of the same construct in the gcc/gcc subdirectory (outside
of
gcc/gcc/config/i386)?


-- 


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

[Bug tree-optimization/28632] VRP should understand bitwise OR and AND

[vda dot linux at googlemail dot com]

--- Comment #10 from vda dot linux at googlemail dot com  2008-08-04 11:55 
---
Created an attachment (id=16012)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16012&action=view)
Testcase to be added to testsuite

This program is artificially made to not compile if VRP fails
to predict a range:

  if (a < 0x1000) return;
  if (a > 0x1000) return;
  if (b < 0x0110) return;
  if (!__builtin_constant_p ((a|b) >= 0x01000))
asm("the.bug.is.here");

Before this patch, gcc will fail to see that (a|b) >= 0x01000 is known at
compile time, after it it will see that.

I don't know how to conditionally check for -O (not -O2 or -Os, just -O).
#if defined __OPTIMIZE__ means "-O", I need to check for
"-O but not bare -O". Help.
Currently gcc -O -c pr28632.c fails (-O level is not high enough to trigger
VRP).


-- 


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

[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-08-04 11:54 ---
This is yet another case of the C++ frontend using two different record types
for the same PFN structure.

For example we have

 
...
bit offset  context 

where you can see the type of the variable indexed is not of the same type
as the field context type of the field we index it by ...

Because TYPE_GET_PTRMEMFUNC_TYPE for itemfun is a different type than the
type of itemfunptr, so we build a "wrong" PTRMEM_CST object.

The following "fixes" this, but I'd like to have a C++ maintainer have a look
here... (there doesn't seem to exist an easy way to fix or workaround this
in SRA, but eventually gimplification of the CONSTRUCTOR could insert a
conversion)

Index: cp/class.c
===
--- cp/class.c  (revision 138552)
+++ cp/class.c  (working copy)
@@ -6197,7 +6197,7 @@ resolve_address_of_overloaded_function (
 }

   if (TYPE_PTRFN_P (target_type) || TYPE_PTRMEMFUNC_P (target_type))
-return cp_build_unary_op (ADDR_EXPR, fn, 0, flags);
+return make_ptrmem_cst (target_type, fn);
   else
 {
   /* The target must be a REFERENCE_TYPE.  Above, cp_build_unary_op


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/30211] model missing vec_extract_even/odd idioms for ia64

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-08-04 11:53 ---
vec_extract_odd/vec_extract_even expanders for x86_64 and i686 were added for
4.4 in http://gcc.gnu.org/viewcvs?view=rev&revision=138553

Updating Summary and Target fields.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 GCC target triplet|ia64-*-*, x86_64-*-*, i?86- |ia64-*-*
   |*-* |
Summary|model missing   |model missing
   |vec_extract_even/odd idioms |vec_extract_even/odd idioms
   |for ia64 and x86_64 |for ia64


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

[Bug tree-optimization/35252] No vectorization for complex arrays

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2008-08-04 11:43 ---
Hm, following testcase doesn't vectorize due to vect cost model
(-O2 -msse3 -ftree-vectorize -ffast-math) on i686 target:

--cut here--
void testf(void)
{
  int i;

  for (i = 0; i < 16; i++)
cf[i] = af[i] + bf[i];
}
--cut here--


Compilation reports:

pr30211.c:8: note: vectorization_factor = 2, niters = 16
pr30211.c:8: note: === vect_update_slp_costs_according_to_vf ===
pr30211.c:8: note: cost model: vector iteration cost = 16 is divisible by
scalar iteration cost = 8 by a factor greater than or equal to the
vectorization factor = 2 .
pr30211.c:8: note: not vectorized: vectorization not profitable.
pr30211.c:8: note: not vectorized: vector version will never be profitable.

However, without cost model the loop in this testcase compiles to:

.L2:
movaps  bf(%eax), %xmm0
addps   af(%eax), %xmm0
movaps  %xmm0, cf(%eax)
addl$16, %eax
cmpl$128, %eax
jne .L2

which is IMO faster than equivalent scalar version:

.L2:
movss   bf+4(,%eax,8), %xmm1
addss   af+4(,%eax,8), %xmm1
movss   bf(,%eax,8), %xmm0
addss   af(,%eax,8), %xmm0
movss   %xmm0, cf(,%eax,8)
movss   %xmm1, cf+4(,%eax,8)
addl$1, %eax
cmpl$16, %eax
jne .L2


-- 


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

[Bug tree-optimization/28632] VRP should understand bitwise OR and AND

[vda dot linux at googlemail dot com]

--- Comment #9 from vda dot linux at googlemail dot com  2008-08-04 11:34 
---
Created an attachment (id=16011)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16011&action=view)
The instrumented version of the patch

Set $VDA_DEBUG to the name of a file and gcc will append debug printouts to it
showing how it deduced value ranges for (a | b) and (a & b).

// extract_range_from_binary_expr(OR)[u32]
// a integer_nonnegative_range(unsigned int __bid_IDEC_glbflags.40_536)=0
// b integer_nonnegative_range(_IDEC_flags[u32],[16,16])=1
 if (a | b) < (16) || (a | b) > (4294967295)) err();

[gcc inferred that since b = 16, (a | b) is always >= 16,
despite the fact we do not know value range of a]

// extract_range_from_binary_expr(AND)[u32]
// a integer_nonnegative_range(unsigned int[u32],[0,4294967295])=1
// b integer_nonnegative_range(_IDEC_round[u32],[1,1])=1
// bits_always_set(0,4294967295)=[u32]0
// bits_always_set(1,1)=[u32]1
// bits_maybe_set(0,4294967295)=[u32]4294967295
// bits_maybe_set(1,1)=[u32]1
 if (a & b) < 0 || (a & b) > 1 err();

[a case where both operands had known positive range]


-- 


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

[Bug tree-optimization/28632] VRP should understand bitwise OR and AND

[vda dot linux at googlemail dot com]

--- Comment #8 from vda dot linux at googlemail dot com  2008-08-04 11:28 
---
Created an attachment (id=16010)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16010&action=view)
Example program which is compiled differently with this patch.

The difference is here:

movl(%edx), %eax#,
callbb_simple_perror_msg#
 .L40:
-   orl $1, 12(%esp)#, errs
+   movl$1, 12(%esp)#, errs
 .L19:
addl$4, 24(%esp)#, argv.78
movl24(%esp), %eax  # argv.78,

With improved VRP on (a | b), gcc now can deduce that in this program, errs |=
1 is always equivalent to errs = 1.


-- 


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

[Bug tree-optimization/28632] VRP should understand bitwise OR and AND

[vda dot linux at googlemail dot com]

--- Comment #7 from vda dot linux at googlemail dot com  2008-08-04 11:25 
---
Created an attachment (id=16009)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16009&action=view)
Updated patch against current svn

This patch is bootstrapping successfully on current gcc svn.


-- 

vda dot linux at googlemail dot com changed:

   What|Removed |Added

  Attachment #12067|0   |1
is obsolete||


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

[Bug target/36840] Fortran complex array multiply missed optimization

[victork at gcc dot gnu dot org]

--- Comment #5 from victork at gcc dot gnu dot org  2008-08-04 11:15 ---
Closing as duplicate of PR30211 (and PR35252).

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


-- 

victork at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/30211] model missing vec_extract_even/odd idioms for ia64 and x86_64

[victork at gcc dot gnu dot org]

--- Comment #2 from victork at gcc dot gnu dot org  2008-08-04 11:15 ---
*** Bug 36840 has been marked as a duplicate of this bug. ***


-- 

victork at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rajiv dot adhikary at amd
   ||dot com


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