[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

[spark at gcc dot gnu dot org]

--- Comment #5 from spark at gcc dot gnu dot org  2007-06-15 06:33 ---
Subject: Bug 32339

Author: spark
Date: Fri Jun 15 06:33:24 2007
New Revision: 125736

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125736
Log:
2007-06-14  Seongbae Park  [EMAIL PROTECTED]

PR rtl-optimization/32339
* df-scan.c (df_uses_record): Don't modify flags but just add to it for
df_ref_record.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-scan.c


-- 


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

[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-06-15 07:31 ---
The testcase should go into the torture testsuite.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.3.0


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

[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||06/msg00973.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-06-12 10:05:44 |2007-06-15 08:50:04
   date||


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

[Bug libfortran/32345] Unconditional snprintf use breaks all gfortran exec tests on Tru64 UNIX V4.0F

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2007-06-15 10:26 ---
Subject: Bug 32345

Author: ro
Date: Fri Jun 15 10:26:16 2007
New Revision: 125739

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125739
Log:
PR libfortran/32345
* runtime/backtrace.c (show_backtrace): Only use snprintf if
available.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/backtrace.c


-- 


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

[Bug libfortran/32345] Unconditional snprintf use breaks all gfortran exec tests on Tru64 UNIX V4.0F

[ro at gcc dot gnu dot org]

--- Comment #3 from ro at gcc dot gnu dot org  2007-06-15 10:29 ---
Fixed.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/30493] [4.1 Regression] Unexpected compilation results: -O versus no optimization

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-06-15 11:27 ---
The choosepole/main miscompilation is a dup of PR32285.

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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2007-06-15 11:27 ---
*** Bug 30493 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at sambromley dot com


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

[Bug fortran/32352] New: Crash (out of bounds) with converting real to integer array index with -mrecip

[burnus at gcc dot gnu dot org]

http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01043.html

(This is with the SVN version of GCC and the -mrecip / rsqrt patch by Uros on
x86_64-unknown-linux-gnu.)

I don't know whether this a bug in the patch [for rsqrt] or only revealed by
the
patch, but the aermod.f90 benchmark from Polyhedron
[http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html] crashes here
at run time (segmentation fault) when compiled with

  gfortran -ffast-math -mrecip aermod.f90

Valgrind claims:
==16734== Conditional jump or move depends on uninitialised value(s)
==16734==at 0x4BA046: numrise_ (aermod.f90:35497)
==16734==by 0x4CBC05: prmdelh_ (aermod.f90:39786)
==16734==by 0x41D06F: prmcalc_ (aermod.f90:6787)
[...]

The program does not crash without -mrecip.

 - - -

Uros answered:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01044.html

gdb points to the top of:

Dump of assembler code from 0x808a193 to 0x808a293:
   0x0808a193 numrise_+8963: mov0xaf8c(%ebp,%edx,4),%eax
   0x0808a19a numrise_+8970: mov%eax,0xfffc(%ebx,%ecx,4)
   0x0808a19e numrise_+8974: mov0x616c(%ebp,%edx,4),%eax
   0x0808a1a5 numrise_+8981: mov0x2c(%ebp),%edx
   0x0808a1a8 numrise_+8984: mov%eax,0xfffc(%edx,%ecx,4)
   0x0808a1ac numrise_+8988: add$0x1,%ecx


where %ebp points to zt. It looks that %edx (that has value of 12324
at the point of crash) got out of bounds. Index into the array (JN
(int) = RN (float)) is calculated from DELN variable, that is computed
using rcpss. DELN is equal to 4107.55908 in rcpss case and RN is
12325.6777. Perhaps the problem is, that index is constructed from FP
variable?

 [...]

Hm, I was referring to this part of numrise function:

! ---   Use sliding step-size to sample nearfield more frequently
   DELN = 2.*FLOAT(NN-NTR)/FLOAT(NTR*(NTR-1))
   RN = 0.0
   DO IN = 1 , NTR - 1
  RN = RN + 1.0 + (IN-1)*DELN
  JN = RN
  XTR(IN) = XT(JN)
  YTR(IN) = YT(JN)
  ZTR(IN) = ZT(JN)
  RTR(IN) = RT(JN)
   ENDDO 

 - - -

Note: valgrind shows now error for the version without -mrecip

With -mrecip and -bounds-check, one has:

At line 35436 of file aermod.f90
Fortran runtime error: Array reference out of bounds for array 'xt', lower
bound of dimension 1 exceeded

This is SUBROUTINE NUMRISE:
 DO IN = NBEG , NEND
! ---   Define coordinates of plume relative to bldg.-defined origin
XBB = XT(IN-1) - XBADJ

No such error without bounds check.


-- 
   Summary: Crash (out of bounds) with converting real to integer
array index with -mrecip
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug tree-optimization/32353] New: [4.1/4.2 Regression] Miscompilation with RESULT_DECL

[jakub at gcc dot gnu dot org]

extern C void abort ();

struct A
{
  int f;
  A (int x) : f (x) {}
};

A
foo (const A x, const A y)
{
  A r (0);
  r = x.f == -111 ? y : (y.f == -111 || x.f  y.f) ? x : y;
  A s (0);
  r = r.f == -111 ? s : (r.f  s.f) ? r : s;
  return r;
}

int
main ()
{
  A a (A(0));
  int b[] = { 1, 2, 9 };
  for (int i = 0; i  3; i++)
{
  A c (b[i]);
  if (foo (a, c).f != b[i])
abort ();
  a = c;
}
}

is miscompiled on i?86-linux with -O2 -m32.  From quick glance at the dumps,
dce3 removes a needed statement:
retval.fD.2005 = SR.23D.2103_26;
but already *.alias1 seems to be wrong:
  # BLOCK 11
  # PRED: 10 (true)
L8:;
  iftmp.3D.2049_27 = retval;
  goto bb 13 (L10);
  # SUCC: 13 (fallthru)

  # BLOCK 12
  # PRED: 10 (false)
L9:;
  iftmp.3D.2049_28 = sD.2036;
  # SUCC: 13 (fallthru)

  # BLOCK 13
  # PRED: 11 (fallthru) 12 (fallthru)
  # iftmp.3D.2049_2 = PHI iftmp.3D.2049_27(11), iftmp.3D.2049_28(12);
L10:;
  iftmp.2D.2047_29 = iftmp.3D.2049_2;
  goto bb 15 (L12);
  # SUCC: 15 (fallthru)

  # BLOCK 14
  # PRED: 9 (false)
L11:;
  iftmp.2D.2047_30 = sD.2036;
  # SUCC: 15 (fallthru)

  # BLOCK 15
  # PRED: 13 (fallthru) 14 (fallthru)
  # iftmp.2D.2047_1 = PHI iftmp.2D.2047_29(13), iftmp.2D.2047_30(14);
L12:;
  #   D.2051_32 = V_MUST_DEF D.2051_31;
  #   VUSE SFT.6D.2086_23;
  D.2051 = *iftmp.2D.2047_1;

Note that iftmp.2D.2047_1 can be either sD.2036 (in that case it really VUSEs
SFT.6D.2086_23), but it can also be retval and that's not stored anywhere.


-- 
   Summary: [4.1/4.2 Regression] Miscompilation with RESULT_DECL
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i386-linux


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

[Bug fortran/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-06-15 12:54 ---
Uros writes:

I have fond the problem in following lines:

! --- Process new position
 S = S + DS
 IF ( FLOAT(NNP/NP).EQ.FLOAT(NNP)/XNP ) THEN   here
NN = NNP/NP

The problem is one ULP of the rcpss insn (+NR step), illustrated by
the following testcase:

--cut here--
float recip(float a)
{
 float xx = 1.0f/a;
 printf(%a\n, xx);

 return xx;
}

int NNP = 1;
int NP = 1;
float XNP = 1.0f;

int main()
{
 float a, b;
 int c;

 a = (float)(NNP/NP);
 b = (float)(NNP)*recip(XNP);

 printf(%a %a %i\n, a, b, a == b);

 return 0;
}
--cut here--

gcc -O2 -msse2 -mfpmath=sse -ffast-math equal.c
./a.out
0x1p+0
0x1p+0 0x1p+0 1

gcc -O2 -msse2 -mfpmath=sse -ffast-math -mrecip equal.c
./a.out
0x1.fep-1
0x1p+0 0x1.fep-1 0

Actually, the recip pass is OK, it is just a precision problem. This
is why -mrecip should stay separate option, not included in
-ffast-math...


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[mec at google dot com]

--- Comment #22 from mec at google dot com  2007-06-15 13:15 ---
With the test program, gcc 4.1.2 generates correct code and gcc 4.2.0 generates
wrong code.  Can someone increase the priority and severity of this PR?


-- 


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

[Bug middle-end/31723] Use reciprocal and reciprocal square root with -ffast-math

[burnus at gcc dot gnu dot org]

--- Comment #27 from burnus at gcc dot gnu dot org  2007-06-15 13:23 ---
Cross-pointer: see also PR 32352 (Polyhedron aermod.f90 crashes due
out-of-bounds problems to numerical differences using rsqrt/-mrecip).


-- 


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

[Bug fortran/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-06-15 13:31 ---
- Middle-end
- Wont Fix?!?


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |


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

[Bug middle-end/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-06-15 13:32 ---
- Middle-end
- WONTFIX - or can one do something about it?


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|fortran |middle-end
 Resolution||WONTFIX


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

[Bug middle-end/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2007-06-15 13:38 ---
(In reply to comment #3)
 - Middle-end

target, because middle end just throws conversion into target optabs.

 - WONTFIX - or can one do something about it?

Hardly... We can penalize everything with another NR-step (just for one last
ULP!), or we have in mind that (a == b) checks should be avoided, surely for
SFmode floats.


-- 


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

[Bug libstdc++/32354] New: libstdc++.so.6 missing RPATH

[stephan dot bergmann at sun dot com]

This seems to be relevant for all gcc versions, checked an old 3.4.1 and the
latest 4.3-20070608:  The libstdc++.so.6 in the installation's lib directory
has a recorded dependency on libgcc_s.so.1, also located in the installation's
lib directory, but lacks a corresponding RPATH ($ORIGIN).


-- 
   Summary: libstdc++.so.6 missing RPATH
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stephan dot bergmann at sun dot com
  GCC host triplet: i686-pc-linux


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-06-15 13:45 ---
Please remind us why exactly we want it and / or which specific problem you are
experiencing


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[dnovillo at gcc dot gnu dot org]

--- Comment #23 from dnovillo at gcc dot gnu dot org  2007-06-15 13:27 
---

Working on this today.


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dnovillo at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-06-15 13:27:21
   date||


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[stephan dot bergmann at sun dot com]

--- Comment #2 from stephan dot bergmann at sun dot com  2007-06-15 14:00 
---
see http://www.openoffice.org/issues/show_bug.cgi?id=78390


-- 


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

[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B

[rask at sygehus dot dk]

--- Comment #9 from rask at sygehus dot dk  2007-06-15 14:24 ---
Bug bootstrap/28949 is also similiar to this one.
Btw, this bug is the root cause of the error message 'Link tests are not
allowed after GCC_NO_EXECUTABLES' for newlib targets, so it should show up in
searches for that message, which it will now.


-- 


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

[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1

[jv244 at cam dot ac dot uk]

--- Comment #10 from jv244 at cam dot ac dot uk  2007-06-15 14:43 ---
The segfault is still happening with today's code. This is the simplest case I
find to trigger it. 

MODULE TEST
CONTAINS
FUNCTION s2a_3(s1) RESULT(a)
CHARACTER(LEN=*), INTENT(IN) :: s1
CHARACTER(LEN=1000) :: a(3)
a(1)=s1
END FUNCTION
END MODULE

USE TEST
character(LEN=1000) :: b(3)
b=s2a_3(REPEAT(1,101))
write(6,*) b(1)
END

The point where things segfault is the assignment a(1)=s1, and in particular
the  corresponding memset (which adds blanks to the rest of the string). This
memset much be getting a wrong pointer to start with, according to valgrind:

==23016== Invalid write of size 1
==23016==at 0x4A1AAF0: memset (mc_replace_strmem.c:490)
==23016==by 0x400A4D: __test_MOD_s2a_3 (test2.f90:6)
==23016==by 0x40098B: MAIN__ (test2.f90:12)
==23016==by 0x400A8B: main (fmain.c:22)
==23016==  Address 0x7FF017FA8 is not stack'd, malloc'd or (recently) free'd

the bug only happens if a is at the same time
1) a function result
2) an array
3) of character variables with a len known at compile time.

in the dump tree original, the corresponding memset line looks like:

__builtin_memset ((*__result.0)[NON_LVALUE_EXPR stride.0 + offset.1] + (char
*) (int8) D.1374, 32, 1000 - (int8) D.1374);

but I can't see how I could debug further pretty please, can somebody look
into that... I'd like to be able to test all the stuff that went in since the
bug was opened a few weeks ago.


-- 


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

[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-06-15 14:47 ---
--- gcc/tree-ssa-structalias.c.jj   2007-06-11 11:12:27.0 +0200
+++ gcc/tree-ssa-structalias.c  2007-06-15 16:40:29.0 +0200
@@ -4343,7 +4343,8 @@ set_uids_in_ptset (tree ptr, bitmap into
bitmap_set_bit (into, DECL_UID (sv-var));
}
   else if (TREE_CODE (vi-decl) == VAR_DECL
-  || TREE_CODE (vi-decl) == PARM_DECL)
+  || TREE_CODE (vi-decl) == PARM_DECL
+  || TREE_CODE (vi-decl) == RESULT_DECL)
{
  if (var_can_have_subvars (vi-decl)
   get_subvars_for_var (vi-decl))

seems to cure this, will try to bootstrap/regtest it now.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


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

[Bug other/32188] DFP instrinic document is out of date

[hjl at lucon dot org]

--- Comment #2 from hjl at lucon dot org  2007-06-15 14:48 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01062.html


-- 

hjl at lucon dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||06/msg01062.html
   Keywords||patch


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-06-15 14:41 ---
I'm not an expert of these matters, but I'm trying to understand this issue in
better detail. First, there is the info at the end of this page:

  http://gcc.gnu.org/onlinedocs/libstdc++/install.html

From that info, I suspect RPATH may be missing on purpose (for example, myself
I'm consistenly using LD_LIBRARY_PATH, while developing the library (note, I
was not active yet, when the info above has been added)), and Libtool is
expected to help people not willing to enter in such issues...


-- 


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

[Bug java/32247] -Wall enables -Wunused enables -Wunused-parameter

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2007-06-15 14:07 ---
(In reply to comment #7)
 Not really because this is a standard GCC option and having it different
 between java and other languages is wrong.
 
 http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Warning-Options.html
 
 Please read the documentation before really filing a bug, really an unused
 parameter is wrong because it usually means either you have conditional code
 (which case you).
 

Actually neither -Wunused nor -Wall should enable -Wunused-parameter according
to the documentation. -Wunused-parameter is only enabled by:

1) -Wunused-parameter [+ anything]
2) -Wall -Wextra
3) -Wunused -Wextra

So either Java is doing something wrong or the documentation does not reflect
the actual behaviour (very likely as well).


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug rtl-optimization/32355] New: [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924

[tbm at cyrius dot com]

Another dataflow problem.  This occurs on x86_64-linux, but not on ia64.

(sid)26281:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3
~/enlightenment-handlers.c
/home/tbm/enlightenment-handlers.c: In function 'doSignalsSetup':
/home/tbm/enlightenment-handlers.c:32: internal compiler error: in
df_lr_verify_transfer_functions, at df-problems.c:1924
Please submit a full bug report, [...]

Testcase:


typedef struct
{
}
__sigset_t;
typedef struct
{
char coredump;
}
EMode;
extern EMode Mode;
struct sigaction
{
  __sigset_t sa_mask;
  int sa_flags;
};
doSignalsSetup (void)
{
  static const int signals[] = {
1, 2 , 3, 4, 6, 8, 11, 13, 14, 15, 10, 12, 17, 7
  };
  unsigned int i, sig;
  struct sigaction sa;
  for (i = 0; i  sizeof (signals) / sizeof (int); i++)
{
  sig = signals[i];
  if (Mode.coredump  (sig == 4 || sig == 8))
continue;
  sa.sa_flags = (sig == 17);
  sigemptyset (sa.sa_mask);
}
}


-- 
   Summary: [4.3 Regression] ICE in df_lr_verify_transfer_functions,
at df-problems.c:1924
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC target triplet: x86_64-linux-gnu


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

[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1

[fxcoudert at gcc dot gnu dot org]

--- Comment #11 from fxcoudert at gcc dot gnu dot org  2007-06-15 15:12 
---
(In reply to comment #10)
 but I can't see how I could debug further pretty please, can somebody look
 into that... I'd like to be able to test all the stuff that went in since the
 bug was opened a few weeks ago.

I don't have much time right now, but here's what I saw and how I would debug
it further: by using -O1 and -fdump-tree-optimized, you can get a dump of the
optimized tree. The memset call is changed by the optimizer into:

__builtin_memset ((*__result.0)[_s1], 32, 1000 - _s1);

Compared to your original tree, where stride.0 = 1 and offset.1 = -stride.0,
and D.1374 = _s1, they look equivalent, except for the transformation of
(*array)[_s1] into (*array)[0] + (char *) _s1. I think that should not be a
problem, except if there is some type mismatch. Further debugging probably
needs to find the part of the front-end that generates this memset call (easily
done by grepping for BUILT_IN_MEMSET in the front-end files), setting a
break-point there and looking into the types of each operands. This last
operation can be done within gdb by calling the debug_tree() function on the
trees you're interested in.

When (and if) I get some time after my PhD defence (next monday), I'll try to
look into it; after all, I am interested in cp2k myself, even though it doesn't
yet work for what I need it to do ;-)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-06-12 15:47:40 |2007-06-15 15:12:01
   date||


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

[Bug libstdc++/32354] libstdc++.so.6 missing RPATH

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-15 15:14 ---
RPATH is evil.  Yes others say LD_LIBRARY_PATH is evil, but RPATH is worse.  It
forces that version of the library to be used and no other version can be used.
 So if you install libstdc++/libgcc_s.so in a different location than what
RPATH says, it will not work.

This is why it is not set for libstdc++ and other GCC libraries.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1

[pinskia at gmail dot com]

--- Comment #12 from pinskia at gmail dot com  2007-06-15 15:22 ---
Subject: Re:  [4.3 Regression] Miscompilation with -O1

On 15 Jun 2007 15:12:02 -, fxcoudert at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
 When (and if) I get some time after my PhD defence (next monday), I'll try to
 look into it; after all, I am interested in cp2k myself, even though it 
 doesn't
 yet work for what I need it to do ;-)

note this might get cleared up with pointer_plus.
I have not tried it there yet but i will be posting a patch and committing
soon.

--Pinski


-- 


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

[Bug rtl-optimization/32355] [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924

[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
   Target Milestone|--- |4.3.0


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

[Bug libgomp/28482] Cannot use libgomp in shared library

[tiago at forked dot de]

--- Comment #5 from tiago at forked dot de  2007-06-15 15:48 ---
The above changes still don't solve the problem for me, since I still can't
load a  python module which is dynamically linked to libgomp (from GCC 4.2.0).
Below, graph-tool is a python program and libgraph_tool.so is a dynamic library
linked with libgomp:

Traceback (most recent call last):
  File ./graph-tool, line 22, in ?
from libgraph_tool import *
ImportError: /home/count0/stuff/misc/src/gcc-root/lib/libgomp.so.1: cannot
allocate memory in static TLS block

Only when I also remove the line 
   XCFLAGS=${XCFLAGS} -ftls-model=initial-exec
from configure.tgt, does the module get loaded properly.


-- 


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

[Bug fortran/32357] bad result from mvbits in mips version of gfortran with -fdefault-integer-8

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2007-06-15 16:16 ---
Is mips a big endian cpu?  I can't reproduce this on 
i386 or x86_64 hardware.


-- 


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

[Bug fortran/32357] bad result from mvbits in mips version of gfortran with -fdefault-integer-8

[michael dot a dot richmond at nasa dot gov]

--- Comment #2 from michael dot a dot richmond at nasa dot gov  2007-06-15 
16:20 ---
(In reply to comment #1)
 Is mips a big endian cpu?  I can't reproduce this on 
 i386 or x86_64 hardware.

mips is big endian


-- 


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

[Bug fortran/32357] New: bad result from mvbits in mips version of gfortran with -fdefault-integer-8

[michael dot a dot richmond at nasa dot gov]

When I compile and run the program listed below under the mips version of
gfortran with -fdefault-integer-8 it prints i = 0. It should print i = 1.

PROGRAM test
i = 0
CALL MVBITS(1, 0, 16, i, 0)
WRITE(*, 10) i
10 FORMAT(i =,i2)
END PROGRAM test


-- 
   Summary: bad result from mvbits in mips version of gfortran with
-fdefault-integer-8
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug other/32358] Acovea finds bugs in GCC 4.3.0 and problems with default optimizations levels

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2007-06-15 16:53 ---
When I used Acovea-5.1.1 it found that -fipa-pta always causes an ICE with
-O  zero.


Here is the complete documentation for the feature:

# grep -B1 -A2 ipa-pta /usr/test/info/gcc.info
`-fipa-pta'
 Perform interprocedural pointer analysis.



Here is an example that also fails (not what I was testing):

# cat test_1.c 
main() {
  printf(Hello\n);
}



# /usr/test/bin/gcc -O0 -fipa-pta -o delete_this test_1.c
test_1.c: In function 'main':
test_1.c:2: warning: incompatible implicit declaration of built-in function
'printf'
#

# /usr/test/bin/gcc -O1 -fipa-pta -o delete_this test_1.c
test_1.c: In function 'main':
test_1.c:2: warning: incompatible implicit declaration of built-in function
'printf'
test_1.c:3: error: stmt (0xb7cd0084) marked modified after optimization pass: 
__builtin_puts (Hello[0]);
test_1.c:3: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
#

# /usr/test/bin/gcc -O2 -fipa-pta -o delete_this test_1.c
test_1.c: In function 'main':
test_1.c:2: warning: incompatible implicit declaration of built-in function
'printf'
test_1.c:3: error: stmt (0xb7ca6084) marked modified after optimization pass: 
__builtin_puts (Hello[0]);
test_1.c:3: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
#

etc.


-- 


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

[Bug other/32358] Acovea finds bugs in GCC 4.3.0 and problems with default optimizations levels

[rob1weld at aol dot com]

--- Comment #1 from rob1weld at aol dot com  2007-06-15 16:52 ---
Created an attachment (id=13708)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13708action=view)
Config - GCC 4.3.0 - Athlon-XP

Here is an Acovea configuration file for GCC 4.3.0 for an Athlon-XP.


-- 


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

[Bug other/32358] New: Acovea finds bugs in GCC 4.3.0 and problems with default optimizations levels

[rob1weld at aol dot com]

Acovea - Analysis of Compiler Options via Evolutionary Algorithm 
http://www.coyotegulch.com/products/acovea/index.html

Acovea implements a genetic algorithm to find the best options for compiling
programs with the GNU Compiler Collection (GCC) compiler. It has both command
line and GTK GUI.

Acovea can determine the GCC compiler flags and options neccesary to produce a
program with:

 * Fastest runtime
 * Smallest size
 * A specific return value

Traditional function-level profiling identifies the algorithms most influential
in a program's performance; Acovea is then applied to those algorithms to find
the compiler flags and options that generate the fastest code. Acovea is also
useful for finding pessimistic combinations of options, and for testing the
reliability of the compiler. 

Acovea is best for tiny programs but can also run whole makefiles.


After running (for a long time on a tiny program) it produces output such as
this (edited):


# runacovea -config gcc43_athlon_xp_nofm.acovea -input fftbench.c 21 | tee
runacovea_1_log.txt

Acovea 5.1.1 (compiled Jun 14 2007 22:58:24) - Evolving Better Software
Invented by Scott Robert Ladd ([EMAIL PROTECTED])
Coyote Gulch Productions  (http://www.coyotegulch.com)

   test application: fftbench.c
 config description: gcc 4.3.0 (20070609) Athlon-XP, no -ffast-math (version
1.0.0)
 test configuration: gcc43_athlon_xp_nofm.acovea
 acovea version: 5.1.1
evocosm version: 3.1.0
application version: /usr/test/bin/gcc 4.3.0
   # of populations: 5
population size: 40
  survival rate: 10% (4)
 migration rate: 5% (2)
  mutation rate: 1%
 crossover rate: 100%
fitness scaling: sigma
 generations to run: 20
 random number seed: 3742623689
   testing mode: speed

test start time: 2007 Jun 15 03:07:13

...(Lots of output)

generation 20 complete, average fitness: 3.65374

Acovea completed its analysis at 2007 Jun 15 07:51:19

Optimistic options:

   -fexpensive-optimizations  (1.599)
   -fstrict-aliasing  (3.027)
 -fgcse-after-reload  (1.678)

Pessimistic options:

 -fno-tree-loop-optimize  (-1.733)
   -fipa-pta  (-1.733)
  -funroll-all-loops  (-2.844)
   -ffloat-store  (-3.796)
   -fbranch-target-load-optimize  (-2.051)
 -m96bit-long-double  (-2.527)
-mfpmath=387  (-1.813)
-mfpmath=sse  (-1.733)
-mfpmath=sse,387  (-3.082)

Acovea's Best-of-the-Best:
/usr/test/bin/gcc -lrt -lm -std=gnu99 -O1 -march=athlon-xp -fno-defer-pop
-fno-delayed-branch -fno-cprop-registers -fno-if-conversion2 -fno-tree-dce
-fno-tree-dse -fno-tree-sra -fno-tree-ch -fno-merge-constants
-fno-move-loop-invariants -fno-tree-loop-optimize -fno-tree-copy-prop
-fno-tree-salias -fno-tree-vect-loop-version -foptimize-sibling-calls
-fcse-follow-jumps -fgcse -fgcse-lm -fcrossjumping -fexpensive-optimizations
-foptimize-register-move -fschedule-insns2 -fsched-interblock
-fsched2-use-traces -fcaller-saves -ftree-pre -ftree-vrp -fpeephole2
-freorder-blocks -fstrict-aliasing -funit-at-a-time -falign-loops
-finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload
-fkeep-inline-functions -fgcse-sm -funsafe-loop-optimizations -fcheck-data-deps
-ftree-loop-im -fvect-cost-model -ftracer -fprefetch-loop-arrays
-freorder-blocks-and-partition -frtl-abstract-sequences -fpeel-loops
-fbranch-target-load-optimize -fno-function-cse -mieee-fp -mno-fp-ret-in-387
-mno-push-args -mno-align-stringops -mfpmath=sse -D__NO_MATH_INLINES -o
/tmp/ACOVEA92B15424 fftbench.c 

Acovea's Common Options:
/usr/test/bin/gcc -lrt -lm -std=gnu99 -O1 -march=athlon-xp -fno-tree-sra
-fno-tree-salias -foptimize-sibling-calls -fcrossjumping -finline-functions
-funswitch-loops -fgcse-after-reload -frtl-abstract-sequences
-mno-fp-ret-in-387 -D__NO_MATH_INLINES -o /tmp/ACOVEA33D4CB8D fftbench.c 

-O1:
/usr/test/bin/gcc -lrt -lm -std=gnu99 -O1 -march=athlon-xp -o
/tmp/ACOVEA63EB983B fftbench.c 

-O2:
/usr/test/bin/gcc -lrt -lm -std=gnu99 -O2 -march=athlon-xp -o
/tmp/ACOVEA34683D10 fftbench.c 

-O3:
/usr/test/bin/gcc -lrt -lm -std=gnu99 -O3 -march=athlon-xp -o
/tmp/ACOVEAD10E9653 fftbench.c 

-O3 -ffast-math:
/usr/test/bin/gcc -lrt -lm -std=gnu99 -O3 -march=athlon-xp -ffast-math -o
/tmp/ACOVEA61BFDD78 fftbench.c 

-Os:
/usr/test/bin/gcc -lrt -lm -std=gnu99 -Os -march=athlon-xp -o
/tmp/ACOVEAC35D20E9 fftbench.c 


A relative graph of fitnesses:

 Acovea's Best-of-the-Best: *  
  (1.7221)
   Acovea's Common Options:    
  (2.36385)
   -O1: ** 
  (2.26057)
   -O2:    
  (1.89104)
   

[Bug fortran/32357] bad result from mvbits in mips version of gfortran with -fdefault-integer-8

[michael dot a dot richmond at nasa dot gov]

--- Comment #3 from michael dot a dot richmond at nasa dot gov  2007-06-15 
16:29 ---
(In reply to comment #1)
 Is mips a big endian cpu?  I can't reproduce this on 
 i386 or x86_64 hardware.

mips can be implemented as either big endian or little endian. I have an SGI
box, which is a big endian implementation. DEC built a line of mips
workstations that were little endian. There are separate versions of Linux for
each endianness. 


-- 


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

[Bug other/32358] Acovea finds bugs in GCC 4.3.0 and problems with default optimizations levels

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-06-15 17:06 ---
  When I used Acovea-5.1.1 it found that -fipa-pta always causes an ICE with 
 -O  zero.

Known issue, see PR 32305.  -fipa-pta does nothing for code generation anyways.
 It just analysis the program and nothing more.


-- 


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

[Bug fortran/31162] missing warning for real do-loops with implicit typed variables

[patchapp at dberlin dot org]

--- Comment #3 from patchapp at dberlin dot org  2007-06-15 18:20 ---
Subject: Bug number PR31162

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01077.html


-- 


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

[Bug fortran/32359] New: GFORTRAN MSG ERROR: THREADPRIVATE AT (1) ISN'T SAVED INCORRECT IN MAIN PGM

[longb at cray dot com]

Description:
For this test case the gfortran compiler is demanding that a threadprivate
variable declared and initialized in a main program must have the SAVE
attribute.  However, the variable already has a default SAVE attribute by
virtue of its declaration  initialization in the main program.

The error message is incorrect, since SAVE is on by F95 default in this
test case.

The following statement comes from p. 86 of the OpenMP API Version 2.5 May 2005
in the last bullet found in lines 27-28:

 * A variable that appears in a threadprivate directive and is not declared
in the scope of a module must have the SAVE attribute

However, the FORTRAN95 HANDBOOK states on p. 138:

Paragraph 3:

Any object that is data initialized (in a DATA statement or a type
 declaration statement) has the SAVE attribute by default.

Rules  Restrictions:

   2.  If SAVE appears in a main program as an attribute or a statement, it
   has no effect.

 gfortran -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../xt-gcc-4.2.0/configure --prefix=/opt/gcc/4.2.0/snos
--disable-nls --libdir=/opt/gcc/4.2.0/snos/lib --enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/4.2.0/snos/include/g++
--with-slibdir=/opt/gcc/4.2.0/snos/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit x86_64-suse-linux
Thread model: posix
gcc version 4.2.0 20070514 (rpm:4)


 cat bug2827.f90
! Derived from OpenMP test omp1/F2_6_2_8_5i.f90
  use omp_lib
  implicit none
  integer, parameter :: NT = 4
  integer :: a = 1
!$omp threadprivate(a)

!$call omp_set_num_threads(NT)
!$omp parallel
  print *, omp_get_thread_num(), a
!$omp end parallel

  END

 ftn -O3 -fopenmp -c bug2827.f90
/opt/xt-pe/2.1/bin/snos64/ftn: INFO: linux target is being used
bug2827.f90:5.18:

  integer :: a = 1
 1
Error: Threadprivate at (1) isn't SAVEd

--
Note: ftn is an alias for:

/opt/gcc/4.2.0/bin/../snos/bin/gfortran -static -v
-I/opt/xt-mpt/2.1/mpich2-64/GP/include -I/opt/xt-mpt/2.1/mpich2-64/GP/include
-L/opt/xt-mpt/2.1/mpich2-64/GP/lib -I/opt/acml/3.6.1/gnu64/include
-I/opt/xt-libsci/10.1.0/gnu/snos64/include
-I/opt/xt-libsci/10.1.0/gnu/snos64/include/superlu
-I/opt/xt-mpt/2.1/sma/P/include -L/opt/acml/3.6.1/gnu64/lib
-L/opt/xt-libsci/10.1.0/gnu/snos64/lib -L/opt/xt-mpt/2.1/sma/P/lib -lmpichf90
-lsci -lacml -lsma -lmpichf90 -lmpich -lrt -D__CRAYXT_COMPUTE_LINUX_TARGET
-D__TARGET_LINUX__ -fno-second-underscore
-I/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/include
-I/opt/xt-catamount/2.1/catamount/linux/include -I/opt/xt-service/2.1/include
-L/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/lib/snos64
-L/opt/xt-pe/2.1/cnos/linux/64/lib -L/opt/xt-mpt/2.1/lib/snos64
-L/opt/xt-service/2.1/lib/snos64 -Wl,--start -lpct -lalpslli -lalpsutil
-lportals -lpthread -Wl,--end -lgfortranbegin -lgfortran -lm


-- 
   Summary: GFORTRAN MSG ERROR: THREADPRIVATE AT (1) ISN'T SAVED
INCORRECT IN MAIN PGM
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug libfortran/32336] matmul: flag runtime- instead of assertation error

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-06-15 18:51 ---
Confirmed, a runtime error would be better.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-06-15 18:51:56
   date||


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

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

--- Comment #18 from tkoenig at gcc dot gnu dot org  2007-06-15 18:55 
---
Due to huge time constraints, I won't be able to
do anything with this for the next few weeks. Unassigning
myself for the time.

If anybody wants to look over my partial patch and fly with it,
he's welcome :-)


-- 


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

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|tkoenig 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=30694

[Bug libfortran/32336] matmul: flag runtime- instead of assertation error

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2007-06-15 19:09 ---
Unfortunately, I lost the example code and wasn't able to recreate one. I
will attach an example when I come across another one.


-- 


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

[Bug fortran/32357] bad result from mvbits in mips version of gfortran with -fdefault-integer-8

[tbm at cyrius dot com]

--- Comment #4 from tbm at cyrius dot com  2007-06-15 19:18 ---
I can confirm that on mips-linux-gnu (big-endian) 0 is printed while 1 is
printed on mipsel-linux-gnu (little-endian).  This happens both with 4.1
and current 4.3.


-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||tbm at cyrius dot com


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

[Bug fortran/32357] bad result from mvbits in mips version of gfortran with -fdefault-integer-8

[tbm at gcc dot gnu dot org]

-- 

tbm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet||mips-*
  Known to fail||4.1.0 4.2.0 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-06-15 19:19:03
   date||


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

[Bug fortran/32360] New: GFORTRAN WON'T COMPILE 'DATA PTR1 /NULL ()/' WHEN PTR1 HAS POINTER ATTRIBUTE

[longb at cray dot com]

Description:

This test case resulted from attempting to modify the way that the
initialization of pointers in a named common was done in some OpenMP tests.
This test case is syntatically correct, but the gfortran
compiler is not able to compile it.


 gfortran -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../xt-gcc-4.2.0/configure --prefix=/opt/gcc/4.2.0/snos
--disable-nls --libdir=/opt/gcc/4.2.0/snos/lib --enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/4.2.0/snos/include/g++
--with-slibdir=/opt/gcc/4.2.0/snos/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit x86_64-suse-linux
Thread model: posix
gcc version 4.2.0 20070514 (rpm:4)

 cat bug2829.f
  integer, pointer :: ptr1
  data ptr1 /NULL()/
  end
 ftn -c bug2829.f
/opt/xt-pe/2.1/bin/snos64/ftn: INFO: linux target is being used
bug2829.f:2.23:

  data ptr1 /NULL()/
  1
Error: NULL appears on right-hand side in assignment at (1)

- - -
NOTE:  Both the PGI  Pathscale compilers compile this test case without
errors.

--
Note: ftn is an alias for:

/opt/gcc/4.2.0/bin/../snos/bin/gfortran -static -v
-I/opt/xt-mpt/2.1/mpich2-64/GP/include -I/opt/xt-mpt/2.1/mpich2-64/GP/include
-L/opt/xt-mpt/2.1/mpich2-64/GP/lib -I/opt/acml/3.6.1/gnu64/include
-I/opt/xt-libsci/10.1.0/gnu/snos64/include
-I/opt/xt-libsci/10.1.0/gnu/snos64/include/superlu
-I/opt/xt-mpt/2.1/sma/P/include -L/opt/acml/3.6.1/gnu64/lib
-L/opt/xt-libsci/10.1.0/gnu/snos64/lib -L/opt/xt-mpt/2.1/sma/P/lib -lmpichf90
-lsci -lacml -lsma -lmpichf90 -lmpich -lrt -D__CRAYXT_COMPUTE_LINUX_TARGET
-D__TARGET_LINUX__ -fno-second-underscore
-I/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/include
-I/opt/xt-catamount/2.1/catamount/linux/include -I/opt/xt-service/2.1/include
-L/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/lib/snos64
-L/opt/xt-pe/2.1/cnos/linux/64/lib -L/opt/xt-mpt/2.1/lib/snos64
-L/opt/xt-service/2.1/lib/snos64 -Wl,--start -lpct -lalpslli -lalpsutil
-lportals -lpthread -Wl,--end -lgfortranbegin -lgfortran -lm


-- 
   Summary: GFORTRAN WON'T COMPILE 'DATA PTR1 /NULL ()/' WHEN PTR1
HAS POINTER ATTRIBUTE
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug fortran/32357] bad result from mvbits in mips version of gfortran with -fdefault-integer-8

[tbm at cyrius dot com]

--- Comment #5 from tbm at cyrius dot com  2007-06-15 19:31 ---
I don't see this problem on powerpc which is big-endian too.


-- 


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

[Bug fortran/32357] bad result from mvbits in mips version of gfortran with -fdefault-integer-8

[tbm at cyrius dot com]

--- Comment #6 from tbm at cyrius dot com  2007-06-15 19:37 ---
(In reply to comment #5)
 I don't see this problem on powerpc which is big-endian too.

Sorry, I *do* see the problem on powerpc.


(sid)832:[EMAIL PROTECTED]: ~/src] gfortran -fdefault-integer-8 t.f90 ; ./a.out
i = 0
(sid)833:[EMAIL PROTECTED]: ~/src] gfortran t.f90 ; ./a.out
i = 1


-- 


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

[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca  2007-06-15 
20:05 ---
Subject: Re:  [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

  We need to know that the return pointer (r2) is not used and that
  the function is a leaf function (i.e., that the incoming value in
  r2 is unchanged).  Calls clobber r2.
  
  Dave
 
 Sounds like the following patch would work:
 
 diff -r 149399c845b5 gcc/config/pa/pa.c
 --- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
 +++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
 @@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
  {
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
 -  df_hard_reg_used_count (2) == 1
 +  DF_REG_DEF_COUNT (2) == 0
! frame_pointer_needed);
  }
 
 
 This essentially checks if r2 is ever written within the function
 (including the calls since r2 is included in the CALL_USED_REGS).

Ok, I've found the problem.  The code that outputs trivial returns
in function.c has changed and just outputs the return when optimize
and HAVE_RETURN are true.  As a result, we are generating trivial
returns in cases when we shouldn't.

I think the solution is to rename the return pattern and let
the pa epilogue expander control the show.  This is what I currently
have:

Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 125747)
+++ config/pa/pa.md (working copy)
@@ -7345,11 +7345,11 @@

 ;; This can only be used in a leaf function, so we do
 ;; not need to use the PIC register when generating PIC code.
-(define_insn return
+(define_insn trivial_return
   [(return)
(use (reg:SI 2))
(const_int 0)]
-  hppa_can_use_return_insn_p ()
+  
   *
 {
   if (TARGET_PA_20)
@@ -7409,7 +7409,7 @@
   /* Try to use the trivial return first.  Else use the full
  epilogue.  */
   if (hppa_can_use_return_insn_p ())
-emit_jump_insn (gen_return ());
+emit_jump_insn (gen_trivial_return ());
   else
 {
   rtx x;
Index: config/pa/pa.c
===
--- config/pa/pa.c  (revision 125747)
+++ config/pa/pa.c  (working copy)
@@ -47,6 +47,7 @@
 #include tm_p.h
 #include target.h
 #include target-def.h
+#include df.h

 /* Return nonzero if there is a bypass for the output of 
OUT_INSN and the fp store IN_INSN.  */
@@ -4413,9 +4414,9 @@
 hppa_can_use_return_insn_p (void)
 {
   return (reload_completed
-  (compute_frame_size (get_frame_size (), 0) ? 0 : 1)
-  ! df_regs_ever_live_p (2)
-  ! frame_pointer_needed);
+  DF_REG_DEF_COUNT (2) == 0
+  !frame_pointer_needed
+  (compute_frame_size (get_frame_size (), 0) ? 0 : 1));
 }

 void

The code still seems to be generating trivial returns.  Full bootstrap
is in progress.

If this works, there's probably some minor cleanups that can be made.
hppa_can_use_return_insn_p() is only called by the epilogue expander
and it may be possible to move it there.  I also think we can do away
with one of trivial_return and return_internal in pa.md.

Dave


-- 


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

[Bug fortran/32361] New: GFORTRAN WON'T ACCEPT TYPE DECLARATION TO INITIALIZE DATA IN NAMED COMMON

[longb at cray dot com]

Description:
This test case resulted from attempting to modify the way that the
initialization of pointers in a named common was done in some OpenMP tests.  
This test case is syntatically correct, but the gfortran 
compiler is not able to compile it.

 gfortran -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../xt-gcc-4.2.0/configure --prefix=/opt/gcc/4.2.0/snos
--disable-nls --libdir=/opt/gcc/4.2.0/snos/lib --enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/4.2.0/snos/include/g++
--with-slibdir=/opt/gcc/4.2.0/snos/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit x86_64-suse-linux
Thread model: posix
gcc version 4.2.0 20070514 (rpm:4)


 cat bug2828.f90
  BLOCK DATA
   integer, pointer :: ptr1 = NULL()
   common / T / ptr1
  END
 ftn -c bug2828.f90
/opt/xt-pe/2.1/bin/snos64/ftn: INFO: linux target is being used
bug2828.f90:3.24:

   common / T / ptr1
   1
Error: Previously initialized symbol 'ptr1' in COMMON block 't' at (1)

- - -
Note: reversing the common and integer statements still results in an error.
--
Note: ftn is an alias for:

/opt/gcc/4.2.0/bin/../snos/bin/gfortran -static -v
-I/opt/xt-mpt/2.1/mpich2-64/GP/include -I/opt/xt-mpt/2.1/mpich2-64/GP/include
-L/opt/xt-mpt/2.1/mpich2-64/GP/lib -I/opt/acml/3.6.1/gnu64/include
-I/opt/xt-libsci/10.1.0/gnu/snos64/include
-I/opt/xt-libsci/10.1.0/gnu/snos64/include/superlu
-I/opt/xt-mpt/2.1/sma/P/include -L/opt/acml/3.6.1/gnu64/lib
-L/opt/xt-libsci/10.1.0/gnu/snos64/lib -L/opt/xt-mpt/2.1/sma/P/lib -lmpichf90
-lsci -lacml -lsma -lmpichf90 -lmpich -lrt -D__CRAYXT_COMPUTE_LINUX_TARGET
-D__TARGET_LINUX__ -fno-second-underscore
-I/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/include
-I/opt/xt-catamount/2.1/catamount/linux/include -I/opt/xt-service/2.1/include
-L/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/lib/snos64
-L/opt/xt-pe/2.1/cnos/linux/64/lib -L/opt/xt-mpt/2.1/lib/snos64
-L/opt/xt-service/2.1/lib/snos64 -Wl,--start -lpct -lalpslli -lalpsutil
-lportals -lpthread -Wl,--end -lgfortranbegin -lgfortran -lm


-- 
   Summary: GFORTRAN WON'T ACCEPT TYPE DECLARATION TO INITIALIZE
DATA IN NAMED COMMON
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)

[tkoenig at gcc dot gnu dot org]

--- Comment #18 from tkoenig at gcc dot gnu dot org  2007-06-15 20:35 
---
Too little time right now.

Unassigning myself.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|tkoenig 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=31067

[Bug fortran/32360] GFORTRAN WON'T COMPILE 'DATA PTR1 /NULL ()/' WHEN PTR1 HAS POINTER ATTRIBUTE

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2007-06-15 20:38 ---
 Error: NULL appears on right-hand side in assignment at (1)

Might be related to PR20888, comment #1 ?!


-- 


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

[Bug fortran/32359] incorrect error: Threadprivate isn't SAVEd (implicit save attribute undefined)

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2007-06-15 20:54 ---
In this code, the symbol's attribute SAVE is never set, i.e. neither
symbol.c(gfc_add_save) is called, nor is the attribute set manually:

  integer :: a = 1
  end

Thus, testing for sym-attr.save fails in resolve.c:6431 (if threadprivate is
set as shown above):
  if (sym-attr.threadprivate  !sym-attr.save
   (!sym-attr.in_common
   sym-module == NULL
   (sym-ns-proc_name == NULL
  || sym-ns-proc_name-attr.flavor != FL_MODULE)))
gfc_error (Threadprivate at %L isn't SAVEd, sym-declared_at);

If the SAVE parameter is explicitely specified, the attribute is set.
Intel and SUN compilers accept the reporter's testcase without problems.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-suse-linux   |
   GCC host triplet|x86_64-suse-linux   |
 GCC target triplet|x86_64-suse-linux   |
   Last reconfirmed|-00-00 00:00:00 |2007-06-15 20:54:06
   date||
Summary|GFORTRAN MSG ERROR:|incorrect error:
   |THREADPRIVATE AT (1) ISN'T  |Threadprivate isn't SAVEd
   |SAVED INCORRECT IN MAIN PGM|(implicit save attribute
   ||undefined)


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

[Bug target/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2007-06-15 21:18 ---
I don't understand how recip(1.0f) can return something different from 1.0f:
the twelve bit approximation should return 1.0f then the NR-step should involve
only integers, hence no round-off errors.

What am I missing?


-- 


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

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[rob1weld at aol dot com]

--- Comment #20 from rob1weld at aol dot com  2007-06-15 21:23 ---
Created an attachment (id=13709)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13709action=view)
Specific example where libm, libcrlibm, and mpfr differ

Here is a specific example of three different math libraries providing three
different answers to the same question. The number does not use very many
decimal places and thus __could__ come up in common use.

It is not really how likely the number would be used that is important but what
the result of using the answer would be. If your life is important don't be it
on this number.

This is just one number. How many more could there be, how will you prove you
are correct and deduce the actual correct answer in those instances. This is
what you must answer. This is why we need a fast, simple, library that is
accurate and comes with proof.


-- 


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

[Bug other/32358] Acovea finds bugs in GCC 4.3.0 and problems with default optimizations levels

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2007-06-15 21:32 ---
Thanks.

With Acovea I was able to discover the bug in a few hours with little effort
and provide a more trivial testcase with a better analysis.

Would someone run Acovea once a month on a few files to test gcc ?


I thought of another wonderful use for it. Alter Acovea or write a small
program so it can generate the .md's (and other such files) to produce
super-optimal code that runs as fast as possible and takes the least space for
each supported processor.


-- 


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

[Bug ada/32333] Ada gnatbind should utilize gcc's path and also check -B path

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2007-06-15 21:33 ---
It did end up building OK and scored equal on make check tests.


-- 


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

[Bug fortran/32362] New: ICE - gfortran in lookup_decl_in_outer_ctx, at omp-low.c:1508

[longb at cray dot com]

Description:
This test case derived from OpenMP test omp1/F2_2_9h.f90, involves nested
parallel loops.  The gfortran compiler currently aborts with an internal
error for this code.

 gfortran -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../xt-gcc-4.2.0/configure --prefix=/opt/gcc/4.2.0/snos
--disable-nls --libdir=/opt/gcc/4.2.0/snos/lib --enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/4.2.0/snos/include/g++
--with-slibdir=/opt/gcc/4.2.0/snos/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit x86_64-suse-linux
Thread model: posix
gcc version 4.2.0 20070514 (rpm:4)


 cat bug2830.f90
! Derived from OpenMP test omp1/F2_2_9h.f90
  use omp_lib
  implicit none
  integer, parameter :: NT = 4
  integer :: nThreads(NT)
  integer :: i, tmp = 1, itmp = 0
!$call omp_set_dynamic(.false.)
!$call omp_set_num_threads(NT)
  do i = 1, NT
  nThreads(i) = 0
  enddo
!$omp parallel private(itmp)
  itmp = omp_get_thread_num() + 1
!$omp parallel firstprivate(tmp)
  tmp = tmp + omp_get_thread_num() + 1
!$omp atomic
  nThreads(itmp) = nThreads(itmp)+tmp
!$omp end parallel
!$omp end parallel
  print *, nThreads
  END
 ftn -fopenmp -c bug2830.f90
/opt/xt-pe/2.1/bin/snos64/ftn: INFO: linux target is being used
bug2830.f90: In function 'MAIN__':
bug2830.f90:16: internal compiler error: in lookup_decl_in_outer_ctx, at
omp-low.c:1508
Please submit a full bug report,
with preprocessed source if appropriate.

--
Note: ftn is an alias for:

/opt/gcc/4.2.0/bin/../snos/bin/gfortran -static -v
-I/opt/xt-mpt/2.1/mpich2-64/GP/include -I/opt/xt-mpt/2.1/mpich2-64/GP/include
-L/opt/xt-mpt/2.1/mpich2-64/GP/lib -I/opt/acml/3.6.1/gnu64/include
-I/opt/xt-libsci/10.1.0/gnu/snos64/include
-I/opt/xt-libsci/10.1.0/gnu/snos64/include/superlu
-I/opt/xt-mpt/2.1/sma/P/include -L/opt/acml/3.6.1/gnu64/lib
-L/opt/xt-libsci/10.1.0/gnu/snos64/lib -L/opt/xt-mpt/2.1/sma/P/lib -lmpichf90
-lsci -lacml -lsma -lmpichf90 -lmpich -lrt -D__CRAYXT_COMPUTE_LINUX_TARGET
-D__TARGET_LINUX__ -fno-second-underscore
-I/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/include
-I/opt/xt-catamount/2.1/catamount/linux/include -I/opt/xt-service/2.1/include
-L/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/lib/snos64
-L/opt/xt-pe/2.1/cnos/linux/64/lib -L/opt/xt-mpt/2.1/lib/snos64
-L/opt/xt-service/2.1/lib/snos64 -Wl,--start -lpct -lalpslli -lalpsutil
-lportals -lpthread -Wl,--end -lgfortranbegin -lgfortran -lm


-- 
   Summary: ICE - gfortran in lookup_decl_in_outer_ctx, at omp-
low.c:1508
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug c++/31785] RFE: Possible to avoid emitting ctor sections for simple constructors of static objects ?

[pluto at agmk dot net]

--- Comment #2 from pluto at agmk dot net  2007-06-15 21:51 ---
(In reply to comment #1)
 This is not a trivial constructor (or at least what the standard defines as
 trivial :) ).

could you explain this?

as far i can see the MyOtherStruct hasn't virtual functions/base
and its data member has a trivial ctor, so MyOtherStruct() is a trivial ctor.


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[dnovillo at gcc dot gnu dot org]

--- Comment #24 from dnovillo at gcc dot gnu dot org  2007-06-15 22:10 
---
Subject: Bug 32327

Author: dnovillo
Date: Fri Jun 15 22:10:09 2007
New Revision: 125748

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125748
Log:

PR 32327
* tree-ssa-operands.c (build_ssa_operands): Initially assume
that the statement does not take any addresses.


testsuite/ChangeLog

PR 32327
* g++.dg/tree-ssa/pr32327-1.C: New test.
* g++.dg/tree-ssa/pr32327.C: New test.


Added:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/tree-ssa/pr32327-1.C
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/tree-ssa/pr32327.C
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
branches/gcc-4_2-branch/gcc/tree-ssa-operands.c


-- 


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

[Bug fortran/32359] incorrect error: Threadprivate isn't SAVEd (implicit save attribute undefined)

[dfranke at gcc dot gnu dot org]

-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dfranke at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-06-15 20:54:06 |2007-06-15 22:20:59
   date||


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

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[kargl at gcc dot gnu dot org]

--- Comment #21 from kargl at gcc dot gnu dot org  2007-06-15 22:22 ---
(In reply to comment #20)
 Created an attachment (id=13709)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13709action=view) [edit]
 Specific example where libm, libcrlibm, and mpfr differ
 
 Here is a specific example of three different math libraries providing three
 different answers to the same question. The number does not use very many
 decimal places and thus __could__ come up in common use.
 
 It is not really how likely the number would be used that is important but 
 what
 the result of using the answer would be. If your life is important don't be it
 on this number.
 
 This is just one number. How many more could there be, how will you prove you
 are correct and deduce the actual correct answer in those instances. This is
 what you must answer. This is why we need a fast, simple, library that is
 accurate and comes with proof.
 

What does this have to do with GCC developement?

GCC does not supply libm.  That's an OS vendor library.

GCC can't include crlibm at this time.  See Joseph's
comment.  Additionally, crlibm does not support float
or long double.

GCC does not supply mpfr.  It uses mpfr to do constant
folding.  AFAIK, sufficient guard digits are used to achieve
the desired accuracy.

Among all the noise that you've generated, I've become lost
in the waht exactly you think is broken.

On x86_64-*-*freebsd, dpara.f from netlib with gfortran 4.3,
I get 

 No failures, defects nor flaws have been discovered.
 Rounding appears to conform to the proposed IEEE standard  P754
 The arithmetic diagnosed appears to be Excellent!
 End of Test.

with 
gfc4x -o z dpara.f
gfc4x -o z -O  dpara.f
gfc4x -o z -O2 dpara.f

I get similar results with spara.f from netlib.

What, in 25 or fewer words, am I missing?


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


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

[Bug middle-end/31979] ICE compiling openssl-0.9.8e/apps/ocsp.c

[roederja at cs dot washington dot edu]

--- Comment #4 from roederja at cs dot washington dot edu  2007-06-15 22:31 
---
Created an attachment (id=13710)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13710action=view)
Testcase

Compile this file with -O2 or higher to trigger the bug, no other flags
necessary. With -O1 it compiles fine.


-- 


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

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

[joseph at codesourcery dot com]

--- Comment #22 from joseph at codesourcery dot com  2007-06-15 22:43 
---
Subject: Re:  Paranoia UCB GSL TestFloat libm tests fail
 - accuracy of recent gcc math poor

On Fri, 15 Jun 2007, rob1weld at aol dot com wrote:

 This is just one number. How many more could there be, how will you prove you
 are correct and deduce the actual correct answer in those instances. This is
 what you must answer. This is why we need a fast, simple, library that is
 accurate and comes with proof.

You are ascribing too much significance to the proofs.  The proofs are 
proofs of bounds on the accumulation of error during the calculation 
(round-off errors and errors arising from the approximation to the 
function being used in the algorithm), not of the actual implementations 
being correct.  To go from there to the functions being correct, the 
proofs rely on:

* The tables of values / polynomial coefficients / ... used in the 
approximations must have been computed correctly.  This relies on another 
implementation (such as Maple) being correct.

* The exhaustive searches for worst cases for approximation must also have 
used another correct implementation of the functions at higher precision.

* Where the exhaustive searches haven't been able to cover the whole 
domain of the function, there must be no particularly bad problem cases 
outside the area covered.

* The C code for the functions must accurately correspond to the algorithm 
whose error bounds are proved.  Proving things directly about C code is 
hard in practice.


-- 


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

[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c

[janis at gcc dot gnu dot org]

--- Comment #9 from janis at gcc dot gnu dot org  2007-06-15 23:40 ---
This makes no sense to me, but I'll report it in case it does to someone else. 
With compilers for powerpc64-linux, the test compiled with -c -O2 -mcpu=7450
(or -Os instead of -O2) passes with GCC 4.0 and fails with GCC 4.1 and later. 
A regression hunt of mainline between the branchpoints for 4.0 and 4.1
identified revision 106744.  That was a bit messy because r106743 introduced a
typo which was fixed in 106746.  A powerpc-linux cross compiler built from
r106741 plus the patch for r106744 also caused the test to fail.  The odd thing
is that the patch for 106744 is for dom, but the test fails even with
-fno-tree-dominator-opts.

I tried the test with a variety of revisions from before and after that patch
to see if the results were intermittent, but they consistently pass before the
patch and fail afterwards.

The testcase proved resistant to minimizing, but I'll attached the smallest I
managed to get it.  It's not preprocessed, still including altivec.h in case
changes to that file were related to the failure.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c

[janis at gcc dot gnu dot org]

--- Comment #10 from janis at gcc dot gnu dot org  2007-06-15 23:42 ---
Created an attachment (id=13711)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13711action=view)
smaller testcase


-- 


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

[Bug fortran/32362] ICE - gfortran in lookup_decl_in_outer_ctx, at omp-low.c:1508

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
   Keywords||openmp


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

[Bug target/30652] SSE expansion is missing for isinf() and other fpclassify functions

[ghazi at gcc dot gnu dot org]

--- Comment #5 from ghazi at gcc dot gnu dot org  2007-06-16 03:44 ---
(In reply to comment #2)
 The generic implementation, including for SSE, is 
   isgreater (abs(f), FLT_MAX)
 For isfinite, use islessequal instead.  For isnan, one can use 
   isunordered(f, f)
 For isnormal, it'd be
   isgreaterequal(abs(f), FLT_MIN)  islessequal(abs(f), FLT_MAX)
 which is less likely to be friendly to inline.

Generic isinf implementation here:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01103.html


-- 


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

[Bug c++/32364] New: Error from simple typedef/void combination

[skunk at iskunk dot org]

Came across this head-scratcher in building Qt with GCC 4.2.0. Heavily
simplified version:

foo.cxx:
typedef void (*funcptr)(void);

typedef void GLvoid;
typedef GLvoid (*_GLUfuncptr)(GLvoid);

int foo(void) { return 1; }

$ g++ -c foo.cxx
foo.cxx:4: error: 'anonymous' has incomplete type
foo.cxx:4: error: invalid use of 'GLvoid'

Compiles fine with 4.1.2 and 2.95.4.


-- 
   Summary: Error from simple typedef/void combination
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
 GCC build triplet: i386-unknown-freebsd4.8
  GCC host triplet: i386-unknown-freebsd4.8
GCC target triplet: i386-unknown-freebsd4.8


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

[Bug c++/32364] Error from simple typedef/void combination

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-06-16 04:53 ---
This is actually invalid C++ which we did not reject before 4.2.0.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/9278] Illegal use of typedef to void

[pinskia at gcc dot gnu dot org]

--- Comment #28 from pinskia at gcc dot gnu dot org  2007-06-16 04:53 
---
*** Bug 32364 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||skunk at iskunk dot org


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

[Bug tree-optimization/32015] pointer-plus ICE in extract_range_from_binary_expr, at tree-vrp.c:1755

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-06-16 05:43 ---
Subject: Bug 32015

Author: pinskia
Date: Sat Jun 16 05:42:36 2007
New Revision: 125755

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125755
Log:
2007-06-15  Andrew Pinski [EMAIL PROTECTED]
Zdenek Dvorak [EMAIL PROTECTED]
Richard Guenther  [EMAIL PROTECTED]
Kaz Kojima  [EMAIL PROTECTED]

* tree-vrp.c (compare_values_warnv): Convert val2 to
the type of val1.
(extract_range_from_assert): Create
POINTER_PLUS_EXPR for pointer types.
(extract_range_from_binary_expr): Handle
only POINTER_PLUS_EXPR, MIN_EXPR, and MAX_EXPR
for pointer types.
* doc/c-tree.texi (POINTER_PLUS_EXPR): Document.
* tree-ssa-loop-niter.c (split_to_var_and_offset): Handle
POINTER_PLUS_EXPR as PLUS_EXPR.
(number_of_iterations_lt_to_ne):
For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(assert_loop_rolls_lt): For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(number_of_iterations_le): Likewise.
(expand_simple_operations): POINTER_PLUS_EXPR are simple also.
(derive_constant_upper_bound): Handle POINTER_PLUS_EXPR just
like PLUS_EXPR and MINUS_EXPR.
* tree-pretty-print.c (dump_generic_node): Handle
POINTER_PLUS_EXPR.
(op_prio): Likewise.
(op_symbol_1): Likewise.
* optabs.c (optab_for_tree_code): Likewise.
* tree-ssa-loop-manip.c (create_iv): Handle pointer base
specially.
* tree-tailcall.c (process_assignment): Mention
POINTER_PLUS_EXPR in a TODO comment.
* tree.c (build2_stat): Assert when trying to use PLUS_EXPR or 
MINUS_EXPR with a pointer. Also assert for POINTER_PLUS_EXPR
not used with a pointer and an integer type.
* tree-scalar-evolution.c (add_to_evolution_1): Convert the
increment using chrec_convert_rhs instead of chrec_convert.
(follow_ssa_edge_in_rhs): Handle POINTER_PLUS_EXPR like
PLUS_EXPR except for the right hand side's type will be
sizetype.
(interpret_rhs_modify_stmt): Handle POINTER_PLUS_EXPR.
(fold_used_pointer_cast): Kill.
(pointer_offset_p): Kill.
(fold_used_pointer): Kill.
(pointer_used_p): Kill.
(analyze_scalar_evolution_1 case GIMPLE_MODIFY_STMT): Don't
call fold_used_pointer.
(instantiate_parameters_1): Convert the increment
using chrec_convert_rhs instead of chrec_convert.
Handle POINTER_PLUS_EXPR as PLUS_EXPR.
* builtins.c (get_pointer_alignment): Handle POINTER_PLUS_EXPR
instead of PLUS_EXPR.
(expand_builtin_strcat): Create a POINTER_PLUS_EXPR instead of
PLUS_EXPR for pointers.
(std_gimplify_va_arg_expr): Likewise.
(fold_builtin_memory_op): Likewise.
(fold_builtin_strstr): Likewise.
(fold_builtin_strchr): Likewise.
(fold_builtin_strrchr): Likewise.
(fold_builtin_strpbrk): Likewise.
(expand_builtin_memory_chk): Likewise.
(fold_builtin_memory_chk): Likewise.
(std_expand_builtin_va_start): Use
sizetype for the call to make_tree and then convert
to the pointer type.
(fold_builtin_memchr): Use POINTER_PLUS_EXPR
instead of PLUS_EXPR for adding to a pointer.
(std_gimplify_va_arg_expr): Use fold_build2 for
the creating of POINTER_PLUS_EXPR.  For the BIT_AND_EXPR, cast
the operands to sizetype first and then cast the BIT_AND_EXPR
back to the pointer type.
* fold-const.c (build_range_check): Handle pointer types
specially.
(extract_array_ref): Look for POINTER_PLUS_EXPR instead
of PLUS_EXPR's. Make sure the offset is converted to
sizetype.
(try_move_mult_to_index): Strip the NOPs from the offset.
Remove code argument and replace all uses with PLUS_EXPR.
(fold_to_nonsharp_ineq_using_bound): Handle pointer types
specially. Don't use a pointer type for MINUS_EXPR.
(fold_unary): Handle for (T1)(X op Y),
only p+ as that is the only as that can be handled for
binary operators now.
(fold_binary case POINTER_PLUS_EXPR): Add folding of
POINTER_PLUS_EXPR.
case PLUS_EXPR: Add folding of PTR+INT into
PTR p+ INT.
Don't call try_move_mult_to_index.
case MINUS_EXPR: Fold (PTR0 p+ A) - (PTR1 p+ B)
into (PTR0 - PTR1) + (A - B). Fold (PTR0 p+ A) - PTR1 into
(PTR0 - PTR1) + A iff (PTR0 - PTR1) simplifies.
Don't call try_move_mult_to_index.
(tree_expr_nonnegative_warnv_p): Handle POINTER_PLUS_EXPR.
(tree_expr_nonzero_p): Likewise.
(fold_indirect_ref_1): Look at POINTER_PLUS_EXPR instead
of PLUS_EXPR for the complex expression folding.
* tree-chrec.c 

[Bug tree-optimization/32225] [PTR-PLUS] ICE in alias.c with INDIRECT_REF to a INTEGER_TYPE

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-06-16 05:43 ---
Subject: Bug 32225

Author: pinskia
Date: Sat Jun 16 05:42:36 2007
New Revision: 125755

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125755
Log:
2007-06-15  Andrew Pinski [EMAIL PROTECTED]
Zdenek Dvorak [EMAIL PROTECTED]
Richard Guenther  [EMAIL PROTECTED]
Kaz Kojima  [EMAIL PROTECTED]

* tree-vrp.c (compare_values_warnv): Convert val2 to
the type of val1.
(extract_range_from_assert): Create
POINTER_PLUS_EXPR for pointer types.
(extract_range_from_binary_expr): Handle
only POINTER_PLUS_EXPR, MIN_EXPR, and MAX_EXPR
for pointer types.
* doc/c-tree.texi (POINTER_PLUS_EXPR): Document.
* tree-ssa-loop-niter.c (split_to_var_and_offset): Handle
POINTER_PLUS_EXPR as PLUS_EXPR.
(number_of_iterations_lt_to_ne):
For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(assert_loop_rolls_lt): For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(number_of_iterations_le): Likewise.
(expand_simple_operations): POINTER_PLUS_EXPR are simple also.
(derive_constant_upper_bound): Handle POINTER_PLUS_EXPR just
like PLUS_EXPR and MINUS_EXPR.
* tree-pretty-print.c (dump_generic_node): Handle
POINTER_PLUS_EXPR.
(op_prio): Likewise.
(op_symbol_1): Likewise.
* optabs.c (optab_for_tree_code): Likewise.
* tree-ssa-loop-manip.c (create_iv): Handle pointer base
specially.
* tree-tailcall.c (process_assignment): Mention
POINTER_PLUS_EXPR in a TODO comment.
* tree.c (build2_stat): Assert when trying to use PLUS_EXPR or 
MINUS_EXPR with a pointer. Also assert for POINTER_PLUS_EXPR
not used with a pointer and an integer type.
* tree-scalar-evolution.c (add_to_evolution_1): Convert the
increment using chrec_convert_rhs instead of chrec_convert.
(follow_ssa_edge_in_rhs): Handle POINTER_PLUS_EXPR like
PLUS_EXPR except for the right hand side's type will be
sizetype.
(interpret_rhs_modify_stmt): Handle POINTER_PLUS_EXPR.
(fold_used_pointer_cast): Kill.
(pointer_offset_p): Kill.
(fold_used_pointer): Kill.
(pointer_used_p): Kill.
(analyze_scalar_evolution_1 case GIMPLE_MODIFY_STMT): Don't
call fold_used_pointer.
(instantiate_parameters_1): Convert the increment
using chrec_convert_rhs instead of chrec_convert.
Handle POINTER_PLUS_EXPR as PLUS_EXPR.
* builtins.c (get_pointer_alignment): Handle POINTER_PLUS_EXPR
instead of PLUS_EXPR.
(expand_builtin_strcat): Create a POINTER_PLUS_EXPR instead of
PLUS_EXPR for pointers.
(std_gimplify_va_arg_expr): Likewise.
(fold_builtin_memory_op): Likewise.
(fold_builtin_strstr): Likewise.
(fold_builtin_strchr): Likewise.
(fold_builtin_strrchr): Likewise.
(fold_builtin_strpbrk): Likewise.
(expand_builtin_memory_chk): Likewise.
(fold_builtin_memory_chk): Likewise.
(std_expand_builtin_va_start): Use
sizetype for the call to make_tree and then convert
to the pointer type.
(fold_builtin_memchr): Use POINTER_PLUS_EXPR
instead of PLUS_EXPR for adding to a pointer.
(std_gimplify_va_arg_expr): Use fold_build2 for
the creating of POINTER_PLUS_EXPR.  For the BIT_AND_EXPR, cast
the operands to sizetype first and then cast the BIT_AND_EXPR
back to the pointer type.
* fold-const.c (build_range_check): Handle pointer types
specially.
(extract_array_ref): Look for POINTER_PLUS_EXPR instead
of PLUS_EXPR's. Make sure the offset is converted to
sizetype.
(try_move_mult_to_index): Strip the NOPs from the offset.
Remove code argument and replace all uses with PLUS_EXPR.
(fold_to_nonsharp_ineq_using_bound): Handle pointer types
specially. Don't use a pointer type for MINUS_EXPR.
(fold_unary): Handle for (T1)(X op Y),
only p+ as that is the only as that can be handled for
binary operators now.
(fold_binary case POINTER_PLUS_EXPR): Add folding of
POINTER_PLUS_EXPR.
case PLUS_EXPR: Add folding of PTR+INT into
PTR p+ INT.
Don't call try_move_mult_to_index.
case MINUS_EXPR: Fold (PTR0 p+ A) - (PTR1 p+ B)
into (PTR0 - PTR1) + (A - B). Fold (PTR0 p+ A) - PTR1 into
(PTR0 - PTR1) + A iff (PTR0 - PTR1) simplifies.
Don't call try_move_mult_to_index.
(tree_expr_nonnegative_warnv_p): Handle POINTER_PLUS_EXPR.
(tree_expr_nonzero_p): Likewise.
(fold_indirect_ref_1): Look at POINTER_PLUS_EXPR instead
of PLUS_EXPR for the complex expression folding.
* tree-chrec.c 

[Bug tree-optimization/32145] [pointer_plus] Ice in build2_stat, at tree.c:3074

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-06-16 05:43 ---
Subject: Bug 32145

Author: pinskia
Date: Sat Jun 16 05:42:36 2007
New Revision: 125755

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125755
Log:
2007-06-15  Andrew Pinski [EMAIL PROTECTED]
Zdenek Dvorak [EMAIL PROTECTED]
Richard Guenther  [EMAIL PROTECTED]
Kaz Kojima  [EMAIL PROTECTED]

* tree-vrp.c (compare_values_warnv): Convert val2 to
the type of val1.
(extract_range_from_assert): Create
POINTER_PLUS_EXPR for pointer types.
(extract_range_from_binary_expr): Handle
only POINTER_PLUS_EXPR, MIN_EXPR, and MAX_EXPR
for pointer types.
* doc/c-tree.texi (POINTER_PLUS_EXPR): Document.
* tree-ssa-loop-niter.c (split_to_var_and_offset): Handle
POINTER_PLUS_EXPR as PLUS_EXPR.
(number_of_iterations_lt_to_ne):
For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(assert_loop_rolls_lt): For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(number_of_iterations_le): Likewise.
(expand_simple_operations): POINTER_PLUS_EXPR are simple also.
(derive_constant_upper_bound): Handle POINTER_PLUS_EXPR just
like PLUS_EXPR and MINUS_EXPR.
* tree-pretty-print.c (dump_generic_node): Handle
POINTER_PLUS_EXPR.
(op_prio): Likewise.
(op_symbol_1): Likewise.
* optabs.c (optab_for_tree_code): Likewise.
* tree-ssa-loop-manip.c (create_iv): Handle pointer base
specially.
* tree-tailcall.c (process_assignment): Mention
POINTER_PLUS_EXPR in a TODO comment.
* tree.c (build2_stat): Assert when trying to use PLUS_EXPR or 
MINUS_EXPR with a pointer. Also assert for POINTER_PLUS_EXPR
not used with a pointer and an integer type.
* tree-scalar-evolution.c (add_to_evolution_1): Convert the
increment using chrec_convert_rhs instead of chrec_convert.
(follow_ssa_edge_in_rhs): Handle POINTER_PLUS_EXPR like
PLUS_EXPR except for the right hand side's type will be
sizetype.
(interpret_rhs_modify_stmt): Handle POINTER_PLUS_EXPR.
(fold_used_pointer_cast): Kill.
(pointer_offset_p): Kill.
(fold_used_pointer): Kill.
(pointer_used_p): Kill.
(analyze_scalar_evolution_1 case GIMPLE_MODIFY_STMT): Don't
call fold_used_pointer.
(instantiate_parameters_1): Convert the increment
using chrec_convert_rhs instead of chrec_convert.
Handle POINTER_PLUS_EXPR as PLUS_EXPR.
* builtins.c (get_pointer_alignment): Handle POINTER_PLUS_EXPR
instead of PLUS_EXPR.
(expand_builtin_strcat): Create a POINTER_PLUS_EXPR instead of
PLUS_EXPR for pointers.
(std_gimplify_va_arg_expr): Likewise.
(fold_builtin_memory_op): Likewise.
(fold_builtin_strstr): Likewise.
(fold_builtin_strchr): Likewise.
(fold_builtin_strrchr): Likewise.
(fold_builtin_strpbrk): Likewise.
(expand_builtin_memory_chk): Likewise.
(fold_builtin_memory_chk): Likewise.
(std_expand_builtin_va_start): Use
sizetype for the call to make_tree and then convert
to the pointer type.
(fold_builtin_memchr): Use POINTER_PLUS_EXPR
instead of PLUS_EXPR for adding to a pointer.
(std_gimplify_va_arg_expr): Use fold_build2 for
the creating of POINTER_PLUS_EXPR.  For the BIT_AND_EXPR, cast
the operands to sizetype first and then cast the BIT_AND_EXPR
back to the pointer type.
* fold-const.c (build_range_check): Handle pointer types
specially.
(extract_array_ref): Look for POINTER_PLUS_EXPR instead
of PLUS_EXPR's. Make sure the offset is converted to
sizetype.
(try_move_mult_to_index): Strip the NOPs from the offset.
Remove code argument and replace all uses with PLUS_EXPR.
(fold_to_nonsharp_ineq_using_bound): Handle pointer types
specially. Don't use a pointer type for MINUS_EXPR.
(fold_unary): Handle for (T1)(X op Y),
only p+ as that is the only as that can be handled for
binary operators now.
(fold_binary case POINTER_PLUS_EXPR): Add folding of
POINTER_PLUS_EXPR.
case PLUS_EXPR: Add folding of PTR+INT into
PTR p+ INT.
Don't call try_move_mult_to_index.
case MINUS_EXPR: Fold (PTR0 p+ A) - (PTR1 p+ B)
into (PTR0 - PTR1) + (A - B). Fold (PTR0 p+ A) - PTR1 into
(PTR0 - PTR1) + A iff (PTR0 - PTR1) simplifies.
Don't call try_move_mult_to_index.
(tree_expr_nonnegative_warnv_p): Handle POINTER_PLUS_EXPR.
(tree_expr_nonzero_p): Likewise.
(fold_indirect_ref_1): Look at POINTER_PLUS_EXPR instead
of PLUS_EXPR for the complex expression folding.
* tree-chrec.c 

[Bug tree-optimization/32144] [pointer_plus] Ice in chrec_fold_plus_poly_poly, at tree-chrec.c:110

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2007-06-16 05:43 ---
Subject: Bug 32144

Author: pinskia
Date: Sat Jun 16 05:42:36 2007
New Revision: 125755

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125755
Log:
2007-06-15  Andrew Pinski [EMAIL PROTECTED]
Zdenek Dvorak [EMAIL PROTECTED]
Richard Guenther  [EMAIL PROTECTED]
Kaz Kojima  [EMAIL PROTECTED]

* tree-vrp.c (compare_values_warnv): Convert val2 to
the type of val1.
(extract_range_from_assert): Create
POINTER_PLUS_EXPR for pointer types.
(extract_range_from_binary_expr): Handle
only POINTER_PLUS_EXPR, MIN_EXPR, and MAX_EXPR
for pointer types.
* doc/c-tree.texi (POINTER_PLUS_EXPR): Document.
* tree-ssa-loop-niter.c (split_to_var_and_offset): Handle
POINTER_PLUS_EXPR as PLUS_EXPR.
(number_of_iterations_lt_to_ne):
For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(assert_loop_rolls_lt): For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(number_of_iterations_le): Likewise.
(expand_simple_operations): POINTER_PLUS_EXPR are simple also.
(derive_constant_upper_bound): Handle POINTER_PLUS_EXPR just
like PLUS_EXPR and MINUS_EXPR.
* tree-pretty-print.c (dump_generic_node): Handle
POINTER_PLUS_EXPR.
(op_prio): Likewise.
(op_symbol_1): Likewise.
* optabs.c (optab_for_tree_code): Likewise.
* tree-ssa-loop-manip.c (create_iv): Handle pointer base
specially.
* tree-tailcall.c (process_assignment): Mention
POINTER_PLUS_EXPR in a TODO comment.
* tree.c (build2_stat): Assert when trying to use PLUS_EXPR or 
MINUS_EXPR with a pointer. Also assert for POINTER_PLUS_EXPR
not used with a pointer and an integer type.
* tree-scalar-evolution.c (add_to_evolution_1): Convert the
increment using chrec_convert_rhs instead of chrec_convert.
(follow_ssa_edge_in_rhs): Handle POINTER_PLUS_EXPR like
PLUS_EXPR except for the right hand side's type will be
sizetype.
(interpret_rhs_modify_stmt): Handle POINTER_PLUS_EXPR.
(fold_used_pointer_cast): Kill.
(pointer_offset_p): Kill.
(fold_used_pointer): Kill.
(pointer_used_p): Kill.
(analyze_scalar_evolution_1 case GIMPLE_MODIFY_STMT): Don't
call fold_used_pointer.
(instantiate_parameters_1): Convert the increment
using chrec_convert_rhs instead of chrec_convert.
Handle POINTER_PLUS_EXPR as PLUS_EXPR.
* builtins.c (get_pointer_alignment): Handle POINTER_PLUS_EXPR
instead of PLUS_EXPR.
(expand_builtin_strcat): Create a POINTER_PLUS_EXPR instead of
PLUS_EXPR for pointers.
(std_gimplify_va_arg_expr): Likewise.
(fold_builtin_memory_op): Likewise.
(fold_builtin_strstr): Likewise.
(fold_builtin_strchr): Likewise.
(fold_builtin_strrchr): Likewise.
(fold_builtin_strpbrk): Likewise.
(expand_builtin_memory_chk): Likewise.
(fold_builtin_memory_chk): Likewise.
(std_expand_builtin_va_start): Use
sizetype for the call to make_tree and then convert
to the pointer type.
(fold_builtin_memchr): Use POINTER_PLUS_EXPR
instead of PLUS_EXPR for adding to a pointer.
(std_gimplify_va_arg_expr): Use fold_build2 for
the creating of POINTER_PLUS_EXPR.  For the BIT_AND_EXPR, cast
the operands to sizetype first and then cast the BIT_AND_EXPR
back to the pointer type.
* fold-const.c (build_range_check): Handle pointer types
specially.
(extract_array_ref): Look for POINTER_PLUS_EXPR instead
of PLUS_EXPR's. Make sure the offset is converted to
sizetype.
(try_move_mult_to_index): Strip the NOPs from the offset.
Remove code argument and replace all uses with PLUS_EXPR.
(fold_to_nonsharp_ineq_using_bound): Handle pointer types
specially. Don't use a pointer type for MINUS_EXPR.
(fold_unary): Handle for (T1)(X op Y),
only p+ as that is the only as that can be handled for
binary operators now.
(fold_binary case POINTER_PLUS_EXPR): Add folding of
POINTER_PLUS_EXPR.
case PLUS_EXPR: Add folding of PTR+INT into
PTR p+ INT.
Don't call try_move_mult_to_index.
case MINUS_EXPR: Fold (PTR0 p+ A) - (PTR1 p+ B)
into (PTR0 - PTR1) + (A - B). Fold (PTR0 p+ A) - PTR1 into
(PTR0 - PTR1) + A iff (PTR0 - PTR1) simplifies.
Don't call try_move_mult_to_index.
(tree_expr_nonnegative_warnv_p): Handle POINTER_PLUS_EXPR.
(tree_expr_nonzero_p): Likewise.
(fold_indirect_ref_1): Look at POINTER_PLUS_EXPR instead
of PLUS_EXPR for the complex expression folding.
* tree-chrec.c 

[Bug tree-optimization/32167] [pointer_plus] Ice in compare_values_warnv, at tree-vrp.c:760

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2007-06-16 05:43 ---
Subject: Bug 32167

Author: pinskia
Date: Sat Jun 16 05:42:36 2007
New Revision: 125755

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125755
Log:
2007-06-15  Andrew Pinski [EMAIL PROTECTED]
Zdenek Dvorak [EMAIL PROTECTED]
Richard Guenther  [EMAIL PROTECTED]
Kaz Kojima  [EMAIL PROTECTED]

* tree-vrp.c (compare_values_warnv): Convert val2 to
the type of val1.
(extract_range_from_assert): Create
POINTER_PLUS_EXPR for pointer types.
(extract_range_from_binary_expr): Handle
only POINTER_PLUS_EXPR, MIN_EXPR, and MAX_EXPR
for pointer types.
* doc/c-tree.texi (POINTER_PLUS_EXPR): Document.
* tree-ssa-loop-niter.c (split_to_var_and_offset): Handle
POINTER_PLUS_EXPR as PLUS_EXPR.
(number_of_iterations_lt_to_ne):
For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(assert_loop_rolls_lt): For pointer types, use sizetype when
creating MINUS_EXPR/PLUS_EXPRs.
(number_of_iterations_le): Likewise.
(expand_simple_operations): POINTER_PLUS_EXPR are simple also.
(derive_constant_upper_bound): Handle POINTER_PLUS_EXPR just
like PLUS_EXPR and MINUS_EXPR.
* tree-pretty-print.c (dump_generic_node): Handle
POINTER_PLUS_EXPR.
(op_prio): Likewise.
(op_symbol_1): Likewise.
* optabs.c (optab_for_tree_code): Likewise.
* tree-ssa-loop-manip.c (create_iv): Handle pointer base
specially.
* tree-tailcall.c (process_assignment): Mention
POINTER_PLUS_EXPR in a TODO comment.
* tree.c (build2_stat): Assert when trying to use PLUS_EXPR or 
MINUS_EXPR with a pointer. Also assert for POINTER_PLUS_EXPR
not used with a pointer and an integer type.
* tree-scalar-evolution.c (add_to_evolution_1): Convert the
increment using chrec_convert_rhs instead of chrec_convert.
(follow_ssa_edge_in_rhs): Handle POINTER_PLUS_EXPR like
PLUS_EXPR except for the right hand side's type will be
sizetype.
(interpret_rhs_modify_stmt): Handle POINTER_PLUS_EXPR.
(fold_used_pointer_cast): Kill.
(pointer_offset_p): Kill.
(fold_used_pointer): Kill.
(pointer_used_p): Kill.
(analyze_scalar_evolution_1 case GIMPLE_MODIFY_STMT): Don't
call fold_used_pointer.
(instantiate_parameters_1): Convert the increment
using chrec_convert_rhs instead of chrec_convert.
Handle POINTER_PLUS_EXPR as PLUS_EXPR.
* builtins.c (get_pointer_alignment): Handle POINTER_PLUS_EXPR
instead of PLUS_EXPR.
(expand_builtin_strcat): Create a POINTER_PLUS_EXPR instead of
PLUS_EXPR for pointers.
(std_gimplify_va_arg_expr): Likewise.
(fold_builtin_memory_op): Likewise.
(fold_builtin_strstr): Likewise.
(fold_builtin_strchr): Likewise.
(fold_builtin_strrchr): Likewise.
(fold_builtin_strpbrk): Likewise.
(expand_builtin_memory_chk): Likewise.
(fold_builtin_memory_chk): Likewise.
(std_expand_builtin_va_start): Use
sizetype for the call to make_tree and then convert
to the pointer type.
(fold_builtin_memchr): Use POINTER_PLUS_EXPR
instead of PLUS_EXPR for adding to a pointer.
(std_gimplify_va_arg_expr): Use fold_build2 for
the creating of POINTER_PLUS_EXPR.  For the BIT_AND_EXPR, cast
the operands to sizetype first and then cast the BIT_AND_EXPR
back to the pointer type.
* fold-const.c (build_range_check): Handle pointer types
specially.
(extract_array_ref): Look for POINTER_PLUS_EXPR instead
of PLUS_EXPR's. Make sure the offset is converted to
sizetype.
(try_move_mult_to_index): Strip the NOPs from the offset.
Remove code argument and replace all uses with PLUS_EXPR.
(fold_to_nonsharp_ineq_using_bound): Handle pointer types
specially. Don't use a pointer type for MINUS_EXPR.
(fold_unary): Handle for (T1)(X op Y),
only p+ as that is the only as that can be handled for
binary operators now.
(fold_binary case POINTER_PLUS_EXPR): Add folding of
POINTER_PLUS_EXPR.
case PLUS_EXPR: Add folding of PTR+INT into
PTR p+ INT.
Don't call try_move_mult_to_index.
case MINUS_EXPR: Fold (PTR0 p+ A) - (PTR1 p+ B)
into (PTR0 - PTR1) + (A - B). Fold (PTR0 p+ A) - PTR1 into
(PTR0 - PTR1) + A iff (PTR0 - PTR1) simplifies.
Don't call try_move_mult_to_index.
(tree_expr_nonnegative_warnv_p): Handle POINTER_PLUS_EXPR.
(tree_expr_nonzero_p): Likewise.
(fold_indirect_ref_1): Look at POINTER_PLUS_EXPR instead
of PLUS_EXPR for the complex expression folding.
* tree-chrec.c 

[Bug tree-optimization/32273] 'restrict' is forgotten after loop unrolling

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-06-16 05:49 ---
Fixed at revision 125755 on the trunk by the merge of the pointer_plus.  Though
this is now a TREE level missed optimization so unassigning me.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
  Component|middle-end  |tree-optimization
   Keywords||TREE


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

[Bug tree-optimization/29708] Alias can go funny with pointer addition

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-06-16 05:50 ---
Fixed at revision 125755.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/18412] missed vectorization opportunity due to aliasing issue

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-06-16 05:51 ---
Fixed on the trunk at revision 125755.
Note gcc.dg/vect/vect-106.c is already testing this case so I don't need to add
another testcase.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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