[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap

[tbm at cyrius dot com]

--- Comment #7 from tbm at cyrius dot com  2007-05-20 08:47 ---
And finally, I can confirm that it works when I specify --disable-static.


-- 


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

[Bug libstdc++/31777] GLIBCXX_FORCE_NEW doesn't always work in pool_allocator

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-05-20 09:26 ---
Better fixing in mainline only, only GLIBCXX_FORCE_NEW has problems (in an
extension allocator)


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

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


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

[Bug libstdc++/31908] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[pcarlini at suse dot de]

--- Comment #6 from pcarlini at suse dot de  2007-05-20 09:29 ---
May I suggest recategorizing? In my experience, libstdc++ reports don't get
much attention from the compiler people...


-- 


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

[Bug tree-optimization/31995] can't determine dependence between p->a[x+i] and p->a[x+i+1]

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-05-20 09:40 ---
Created an attachment (id=13587)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13587&action=view)
Patch which fixes the problem

I think this patch is correct, the issue is two fold, one we don't consider
invariants when we are dealing with evolution_function_is_affine_multivariate_p
and then we don't see if index == index in build_classic_dist_vector_1 which
causes us to reject the distance vector.  This patch has not been bootstrapped
or tested at all, it only has been tested on the testcase in the bug report.


-- 

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|UNCONFIRMED |ASSIGNED


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

[Bug libfortran/31933] Uninitialized memory when writing real(10) as unformatted

[jb at gcc dot gnu dot org]

--- Comment #3 from jb at gcc dot gnu dot org  2007-05-20 09:46 ---
I see. With that in mind, I think the patch for PR31915 that went in as r124741
is incorrect (and I share some of the blame since I approved it). We should use
the size argument the frontend provides to the unformatted_(read|write)
functions instead of calling the size_from_real_kind function.


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jb at gcc dot gnu dot org


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

[Bug libfortran/31933] Uninitialized memory when writing real(10) as unformatted

[jb at gcc dot gnu dot org]

--- Comment #4 from jb at gcc dot gnu dot org  2007-05-20 09:50 ---
(In reply to comment #3)
> I see. With that in mind, I think the patch for PR31915 that went in as 
> r124741
> is incorrect (and I share some of the blame since I approved it). We should 
> use
> the size argument the frontend provides to the unformatted_(read|write)
> functions instead of calling the size_from_real_kind function.

Actually, shouldn't there be another libgfortran which is used when compiling
with -m32? Sorry, I don't have a 64-bit box to test on. I have a hard time
imagining that the 64-bit libgfortran would be ABI-compatible with the 32-bit
one except for size_from_real_kind.


-- 


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

[Bug middle-end/32006] New: [Regression 4.3] ICE (segv) with

[tobias dot burnus at physik dot fu-berlin dot de]

Using test_fpu.f90 of the Polyhedron testsuite,
http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html, fails since
2007-05-15 (r124736) on x86_64-unknown-linux-gnu, 2007-05-14 (r124708) was
still ok. Last tested: 2007-05-20 (r124860).

The ICE occures with:
gfortran -O3 -ftree-vectorize -ffast-math -funroll-loops test_fpu.f90
With -m32 the ICE does not occure.

Running GCC through valgrind shows:

==30881== Conditional jump or move depends on uninitialised value(s)
==30881==at 0x7A2E38: vrp_evaluate_conditional_warnv (tree-vrp.c:4803)
==30881==by 0x7A34D9: vrp_evaluate_conditional (tree-vrp.c:4935)
==30881==by 0x76488B: substitute_and_fold (tree-ssa-propagate.c:1131)
==30881==by 0x79E418: vrp_finalize (tree-vrp.c:5914)
==30881==by 0x7A006A: execute_vrp (tree-vrp.c:6000)
==30881==by 0x609540: execute_one_pass (passes.c:1065)
==30881==by 0x6096FB: execute_pass_list (passes.c:1117)
==30881==by 0x60970D: execute_pass_list (passes.c:1118)
==30881==by 0x6D3337: tree_rest_of_compilation (tree-optimize.c:406)
==30881==by 0x810D9F: cgraph_expand_function (cgraphunit.c:1086)
==30881==by 0x813241: cgraph_optimize (cgraphunit.c:1155)
==30881==by 0x466F5C: gfc_be_parse_file (f95-lang.c:307)


-- 
   Summary: [Regression 4.3] ICE (segv) with
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de


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

[Bug middle-end/31935] [Regression 4.3] ICE with -O3 -ftree-loop-linear -ftree-vectorize

[tobias dot burnus at physik dot fu-berlin dot de]

--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de  
2007-05-20 10:03 ---
The problem disappeared meanwhile: 4.3.0 20070519 is no longer crashing :-)


-- 


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

[Bug tree-optimization/31995] can't determine dependence between p->a[x+i] and p->a[x+i+1]

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-05-20 10:28 ---
There were no regressions in the vect.exp testsuite on powerpc-darwin.  Plus a
quick s/x+i+1/y+i+1/ on this testcase gives the correct answer of
t.c:19: note: not vectorized: can't determine dependence between
p_8(D)->a[D.2030_7] and p_8(D)->a[D.2028_4]
affine dependence test not usable: access function not affine or constant.


-- 


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

[Bug libstdc++/31621] libstdc++ uses -xc++ which can cause exceptions to show up which causes __gxx_personality_v0 to be referenced

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-20 10:29:52
   date||


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

[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap

[tbm at cyrius dot com]

--- Comment #8 from tbm at cyrius dot com  2007-05-20 10:44 ---
(In reply to comment #6)
> (In reply to comment #5)
> > With:
> >/home/tbm/scratch/gcc/configure -v --enable-languages=c,c++ 
> > --disable-werror
> > mipsel-linux-gnu
> > I get the same segfault in gcc/libstdc++-v3/src/fstream-inst.cc
> > 
> 
> Can you reproduce with a cross compiler?

Yes.


-- 


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

[Bug target/29473] -masm=intel combined with -march=athlon64 has some issues.

[nachms+gcc at gmail dot com]

--- Comment #7 from nachms+gcc at gmail dot com  2007-05-20 10:46 ---
I just tested against:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --disable-werror --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.1 20070516 (prerelease) (Debian 4.2-20070516-1)

This problem still exists.


-- 

nachms+gcc at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |major
Version|4.1.2   |4.2.1


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

[Bug target/29473] -masm=intel combined with -march=athlon64 has some issues.

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


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

[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2007-05-20 10:52 ---
b = transpose(conjg(a)) works (also translated into
the library call).


-- 


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

[Bug target/31585] gcc.target/i386/sse-vect-types.c FAILs (also sse-13.c and sse-14.c)

[uros at gcc dot gnu dot org]

--- Comment #3 from uros at gcc dot gnu dot org  2007-05-20 10:54 ---
Subject: Bug 31585

Author: uros
Date: Sun May 20 09:54:23 2007
New Revision: 124868

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124868
Log:
PR target/31585
* gcc.target/i386/sse-vect-types.c: Do not redefine "static"
and "__inline".  Use "-msse" instead of "-msse2".


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/sse-vect-types.c


-- 


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

[Bug target/31585] gcc.target/i386/sse-vect-types.c FAILs (also sse-13.c and sse-14.c)

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2007-05-20 10:55 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |
   |patches/2007-   |
   |04/msg00096.html|
 Status|UNCONFIRMED |RESOLVED
   Keywords|patch   |
 Resolution||FIXED


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

[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-05-20 11:20 ---
The out-of-ssa patch was clearly a hack to make this testcase work.  But a real
fix involves ra and reload, none of which is in the list I like to work on ;)
But maybe Micha can try to see if this is related to PR19398 as Uros hints.
See also PR25216 where this testcase fails with -fPIC.  Oh, and it still
passes with -fomit-frame-pointer.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||matz at suse dot de
OtherBugsDependingO||25216
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-20 11:20:47
   date||
   Target Milestone|--- |4.3.0


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

[Bug fortran/32001] [4.3 regression] MAX intrinsic with large number of arguments

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2007-05-20 11:22 ---
Subject: Bug 32001

Author: dfranke
Date: Sun May 20 10:22:15 2007
New Revision: 124869

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124869
Log:
gcc/fortran:
2007-05-20  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/32001
* check.c (check_rest): Improved argument conformance check and
fixed error message generation.


gcc/testsuite:
2007-05-20  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/32001
* gfortran.dg/min_max_conformance.f90: Added more testcases.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/min_max_conformance.f90


-- 


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

[Bug fortran/32001] [4.3 regression] MAX intrinsic with large number of arguments

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2007-05-20 11:25 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.3.0   |
 Resolution||FIXED


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

[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2007-05-20 11:52 ---
As to comment #2, while we need one more register for the comparison, a and b
are available in the argument frame, so there's no reason to "spill" them, we
just need to reload them into one of the many free registers _after_ the asm().
Instead of leaving us with

(insn 12 15 13 2
/home/richard/src/dataflow-branch/gcc/testsuite/gcc.target/i386/pr21291.c:27
(set (reg:CCZ 17 flags)
(compare:CCZ (mem/c/i:SI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [0 alen+0 S4 A32])
(mem/c/i:SI (plus:SI (reg/f:SI 6 bp)(const_int
20 [0x14])) [0 blen+0 S4 A32]))) 2 {*cmpsi_1_insn} (nil))

which is not matching *cmpsi_1_insn predicates (the above is from greg dump).


-- 


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

[Bug target/32007] New: [4.3 Regression] bootstrap broken on ARM v3

[tbm at cyrius dot com]

Bootstrap is broken on ARM v3.  I get "Unable to determine architecture"
from gcc/config/arm/lib1funcs.asm


-- 
   Summary: [4.3 Regression] bootstrap broken on ARM v3
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC target triplet: arm-linux-gnu


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

[Bug target/32007] [4.3 Regression] bootstrap broken on ARM v3

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2007-05-20 11:52 ---
Caused by http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01850.html


-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||pbrook at gcc dot gnu dot
   ||org
   Keywords||build


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

[Bug target/32007] [4.3 Regression] bootstrap broken on ARM v3

[tbm at cyrius dot com]

--- Comment #2 from tbm at cyrius dot com  2007-05-20 11:54 ---
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01304.html


-- 


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

[Bug c++/32008] New: g++ crashes (internal error) on simple code.

[kuba dot skowron at gmail dot com]

g++ hangs computer for about 5 minutes, then reports "internal error".

On program:

#include 
#include 

using namespace std;

int main()
{
  cout << "\e[18t" << flush
  string s;
  return 0;
}

Compiled with:
g++ -c gcc_bug.cpp

He should report "expected ';'" error on line 9 (after flush, before string s),
but instead computer becomes not responsive, and finally g++ is being killed by
the OS.

This bug is triggerd by invalid code, but forgeting about ';' at the end of the
line is very common and cause in this particular situation very severe effect.

When I don't use "using namespace std;", but explicitly write std::cout,
std::flush and std::string, g++ works as he should.

Occurs on:
  gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)
Also occurs on:
  g++ (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
Doesn't occur on:
  g++ (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)

Additional information:
  output from g++ triggered by 
g++ -v -save-temps gcc_bug.cpp
  can be found at:
http://studenci.fuw.edu.pl/~jskow/www/gcc_bug.out

  preprocessed file can be found at:
http://studenci.fuw.edu.pl/~jskow/www/gcc_bug.ii


-- 
   Summary: g++ crashes (internal error) on simple code.
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kuba dot skowron at gmail dot com


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

[Bug c++/32008] g++ crashes (internal error) on simple code.

[kuba dot skowron at gmail dot com]

--- Comment #1 from kuba dot skowron at gmail dot com  2007-05-20 12:05 
---
Created an attachment (id=13588)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13588&action=view)
preprocessed file triggering the bug

generated by command line:
g++ -v -save-temps gcc_bug.cpp


-- 


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

[Bug c++/32008] g++ crashes (internal error) on simple code.

[kuba dot skowron at gmail dot com]

--- Comment #2 from kuba dot skowron at gmail dot com  2007-05-20 12:07 
---
Created an attachment (id=13589)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13589&action=view)
g++ output (with version and build options)

generated by:
g++ -v -save-temps gcc_bug.cpp


-- 


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

[Bug target/32007] [4.3 Regression] bootstrap broken on ARM v3

[pbrook at gcc dot gnu dot org]

--- Comment #3 from pbrook at gcc dot gnu dot org  2007-05-20 12:18 ---
Subject: Bug 32007

Author: pbrook
Date: Sun May 20 11:18:27 2007
New Revision: 124871

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124871
Log:
2007-04-20  Martin Michlmayr  <[EMAIL PROTECTED]>

PR target/32007
* config/arm/lib1funcs.asm: Define __ARM_ARCH__ on v2/v3 machines.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/lib1funcs.asm


-- 


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

[Bug fortran/32002] [4.2/4.3 regression] insufficient conformance check when assigning the result of an elemental function to an array

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2007-05-20 13:12 ---
This triggers the error ...

real :: a(3), b(2)
a = COS(b(:))
end


-- 


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

[Bug fortran/31196] [4.2/4.1 only] wrong code generated with RESHAPE/TRANSPOSE

[tkoenig at gcc dot gnu dot org]

--- Comment #10 from tkoenig at gcc dot gnu dot org  2007-05-20 13:28 
---
Subject: Bug 31196

Author: tkoenig
Date: Sun May 20 12:28:29 2007
New Revision: 124872

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124872
Log:
2007-05-20  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/31196
Backport from trunk.
* intrinsics/reshape_generic.c (reshape_internal):  Increment
correct variable.

2007-05-20  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/31196
Backport from trunk.
* gfortran.dg/reshape_transpose_1.f90:  New test.


Added:
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/reshape_transpose_1.f90
Modified:
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
branches/gcc-4_2-branch/libgfortran/ChangeLog
branches/gcc-4_2-branch/libgfortran/intrinsics/reshape_generic.c


-- 


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

[Bug c++/32008] g++ crashes (internal error) on simple code.

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-05-20 13:29 ---
GCC 3.3.x isn't maintained anymore.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/31196] [4.1 only] wrong code generated with RESHAPE/TRANSPOSE

[tkoenig at gcc dot gnu dot org]

--- Comment #11 from tkoenig at gcc dot gnu dot org  2007-05-20 13:30 
---
Fixed on 4.2.  Do we want to backport to 4.1?


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.3.0   |4.3.0 4.2.1
Summary|[4.2/4.1 only] wrong code   |[4.1 only] wrong code
   |generated with  |generated with
   |RESHAPE/TRANSPOSE   |RESHAPE/TRANSPOSE


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

[Bug regression/32009] New: building gcc4-4.3.0-20070518 failed on OSX 10.3.9

[dominiq at lps dot ens dot fr]

Building gcc4-4.3.0-20070518 failed on OSX 10.3.9. Copies of

http://gcc.gnu.org/ml/gcc/2007-05/msg00483.html

> Comparing the log of successful and failed builds I have found 
> that the failed one contains -mdynamic-no-pic which does not
> appear in the previous build.  According Apple's doc this
> should be used in "application", but it should not appear
> when building libraries (at least it is my understanding).
>
> I suspect the origin of the problem comes from
>
> 2007-05-16  Paolo Bonzini  <[EMAIL PROTECTED]>
>
> * Makefile.def (bootstrap_stage): Replace stage_make_flags with
> stage_cflags.
> * Makefile.tpl (POSTSTAGE1_HOST_EXPORTS, POSTSTAGE1_FLAGS_TO_PASS):
> Remove CFLAGS/LIBCFLAGS.
> (configure-stage[+id+]-[+prefix+][+module+],
> all-stage[+id+]-[+prefix+][+module+]): Pass it from [+stage_cflags+].
>* Makefile.in: Regenerate.
>
> but there are too many changes to allow me to go further.
>
> BTW I also noticed the nicety
>
> ... -O2 -O2 -g -O2 ... -g -O2 ...
>
> (was ... -O2 -O2 -g -O2 ... -O2 -g -O2 ...)

http://gcc.gnu.org/ml/gcc/2007-05/msg00485.html

form Andreas Tobler

> Thanks Dominique, I just reverted this patch to see if I get further. 
> I have the same problem on 10.4.9 and was to lazy to investigate 
> that deep as you did.
> I'll let you know how it works.
>
> In toplevel, svn up -r 124763 Makefile.tpl Makefile.def Makefile.in

and

http://gcc.gnu.org/ml/gcc/2007-05/msg00487.html

> > In toplevel, svn up -r 124763 Makefile.tpl Makefile.def Makefile.in
>
> I used the files from trunk revision 124627 and the build went fine.
>
> I'll try to find some time to fill a PR


-- 
   Summary: building gcc4-4.3.0-20070518 failed on OSX 10.3.9
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
  GCC host triplet: powerpc-apple-darwin7


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

[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-05-20 15:40 
---
For some reason, the scalarization of conjg(transpose()) is messed up. The
following code:

  complex :: a(1,1), b(1,1)
  a = 0
  b = conjg(transpose(a))
  print *, b(1,1)
  end

ends up as folllows:

  int4 D.1015;
  int4 S.2;

  D.1015 = atmp.1.dim[0].stride;
  S.2 = 1;
  while (1)
{
  if (S.2 > 1) goto L.2;
  {
int4 D.1018;
int4 D.1017;
int4 S.3;

D.1017 = parm.0.offset + atmp.1.dim[1].stride * S.2;
D.1018 = S.2 + -2;
S.3 = 1;
while (1)
  {
if (S.3 > 1) goto L.1;
b[S.3 + D.1018] = CONJ_EXPR <(*(complex4[0:] *)
parm.0.data)[S.3 * D.1015 + D.1017]>;
S.3 = S.3 + 1;
  }
L.1:;
  }
  S.2 = S.2 + 1;
}
  L.2:;

This makes D.1017 be 1, while it should be -1 (or so I think). What is more
confusing is that I can't trigger this scalarization bug with other intrinsics
such as MAX (code below), nor can I understand what is CONJG-specific here...

The following works as expected:

  integer :: a(1,1), b(1,1)
  a = 0
  b = max(transpose(a),a)
  print *, b(1,1)
  end

Maybe there is something to investigate in the difference between these two
codes.


-- 


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

[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-05-20 15:43 
---
(In reply to comment #5)
> What is more
> confusing is that I can't trigger this scalarization bug with other intrinsics

10 seconds after I hit the Commit button, I thought about another testcase, and
it does also trigger the bug:

  integer :: a(1,1)
  real :: b(1,1)
  a = 0
  b = real(transpose(a))
  print *, b(1,1)
  end

This time, the interesting thing is that changing "b = real(transpose(a))" into
"b = transpose(a)" gets rid of the bug. I think it's somewhere hidden in the
intrinsics scalarization, but can't find it. Hopefully someone can go further
with this information!


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-05-19 03:29:11 |2007-05-20 15:43:41
   date||


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

[Bug preprocessor/23479] Implement binary constants with a "0b" prefix

[eweddington at cso dot atmel dot com]

--- Comment #25 from eweddington at cso dot atmel dot com  2007-05-20 16:22 
---
Subject: RE:  Implement binary constants with a "0b"
 prefix



> 
> --- Comment #24 from manu at gcc dot gnu dot org  
> 2007-05-19 16:21 ---
> Joerg,
> 
> any news about this? I cannot find the patch in the patch 
> tracker. It seems it
> was approved by Mark Mitchell
> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01495.html
> 
> Have you committed it?

I work with Joerg on the AVR toolchain and we work at the same company. He's
on vacation right now.

AFAIK, Joerg does not have write priviledges on GCC (you can verify this
with the MAINTAINERS file).

So, yes, it seems like the patch was approved by Mark. No, the patch has not
been committed yet.

The patch is attached to the bug report:

And the patch was submitted to the patches ml:


Can somebody commit this patch?

Thanks,
Eric Weddington


-- 


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

[Bug fortran/31196] [4.1 only] wrong code generated with RESHAPE/TRANSPOSE

[kargl at gcc dot gnu dot org]

--- Comment #12 from kargl at gcc dot gnu dot org  2007-05-20 16:24 ---
(In reply to comment #11)
> Fixed on 4.2.  Do we want to backport to 4.1?
> 

With 4.2 finally released, I think it is time to let
4.1 go.  If gfortran follows the GCC development rules,
then this would need to be a fix for a regression in
4.1.  I'll leave to Thomas to close the bug.


-- 


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

[Bug libfortran/31933] Uninitialized memory when writing real(10) as unformatted

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2007-05-20 16:55 
---
Actually, there are two separate build subdirectories created under the arch
directory in the objdir.  So on systems like mine, two separate libraries are
built.


-- 


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

[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-05-20 17:08 
---
I think it may have to do with the order of resolving,  I think pr32002 is not
picking up the shape checking because the array variables are not resolved
before functions using them are resolved.  I think something similar could be
happening here.


-- 


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

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2007-05-20 17:38 ---
My last comment about this being a GC problem was wrong.  Here's a
backtrace from a compiler containing debug symbols:

(gdb) bt
#0  0x40c5a274 in get_cse_reg_info (regno=66)
at ../../gcc/gcc/cse.c:847
#1  0x40c5d31c in invalidate (x=0x83fffec89d00,
full_mode=VOIDmode) at ../../gcc/gcc/cse.c:1727
#2  0x40c5cf18 in flush_hash_table () at ../../gcc/gcc/cse.c:1661
#3  0x40c69d28 in cse_insn (insn=0x83fffeda8f00, libcall_insn=0x0)
at ../../gcc/gcc/cse.c:5341
#4  0x40c6d480 in cse_extended_basic_block (
ebb_data=0x83fffeff12e0) at ../../gcc/gcc/cse.c:6104
#5  0x40c6df74 in cse_main (f=0x83fffec93ec0, nregs=74)
at ../../gcc/gcc/cse.c:6296
#6  0x40c706f0 in rest_of_handle_cse () at ../../gcc/gcc/cse.c:7032
#7  0x4064a7e0 in execute_one_pass (pass=0x80014d70)
at ../../gcc/gcc/passes.c:1065
#8  0x4064aaa8 in execute_pass_list (pass=0x80014d70)
at ../../gcc/gcc/passes.c:1117
#9  0x4064aae8 in execute_pass_list (pass=0x80012610)
at ../../gcc/gcc/passes.c:1118
#10 0x40852070 in tree_rest_of_compilation (fndecl=0x83fffec79300)
at ../../gcc/gcc/tree-optimize.c:406
#11 0x4021f844 in c_expand_body (fndecl=0x42fec89d00)
at ../../gcc/gcc/c-common.c:4345
#12 0x40b3d09c in cgraph_expand_function (node=0x83fffec79400)
---Type  to continue, or q  to quit---q
 at .Quit
(gdb) p debug_rtx (0x83fffec89d00)
(reg:DI 66 [ D.1605 ])
(gdb) frame 2
#2  0x40c5cf18 in flush_hash_table () at ../../gcc/gcc/cse.c:1661
1661  invalidate (p->exp, VOIDmode);
(gdb) p i
$3 = 3
(gdb) p p
$4 = (struct table_elt *) 0x800100102d88
(gdb) p table[3]
$5 = (struct table_elt *) 0x800100102d88

static void
flush_hash_table (void)
{
  int i;
  struct table_elt *p;

  for (i = 0; i < HASH_SIZE; i++)
for (p = table[i]; p; p = table[i])
  {
/* Note that invalidate can remove elements
   after P in the current hash chain.  */
if (REG_P (p->exp))
  invalidate (p->exp, VOIDmode);
else
  remove_from_table (p, i);
  }
}

So, it looks like we are stuck in flush_hash_table.


-- 


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

[Bug java/32010] New: bootstrap fails; chooses wrong zlib for building jc1

[lucier at math dot purdue dot edu]

Configured with

env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../4.2.0/configure
--build=powerpc64-apple-darwin8.8.0 --host=powerpc64-apple-darwin8.8.0
--target=powerpc64-apple-darwin8.8.0 --with-gmp=/pkgs/gmp-4.2.1-64/
--with-mpfr=/pkgs/gmp-4.2.1-64/ --prefix=/pkgs/gcc-4.2.0-64

and made with make bootstrap.  Bootstrap fails win stage2 with

/Users/gcc-test/programs/gcc/objdir-gcc-4.2.0/./prev-gcc/xgcc
-B/Users/gcc-test/programs/gcc/objdir-gcc-4.2.0/./prev-gcc/
-B/pkgs/gcc-4.2.0-64/powerpc64-apple-darwin8.8.0/bin/   -g -O2 -DIN_GCC   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H  -o jc1 \
java/parse.o java/class.o java/decl.o java/expr.o java/constants.o
java/lang.o java/typeck.o java/except.o java/verify-glue.o java/verify-impl.o
java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o
java/mangle_name.o java/builtins.o java/resource.o java/jcf-write.o
java/buffer.o java/check-init.o java/jcf-depend.o java/jcf-path.o java/boehm.o
java/java-gimplify.o main.o  libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a -L../zlib -lz  ../libcpp/libcpp.a
./../intl/libintl.a  ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
ld64 warning: in /usr/lib/libz.dylib, file is not of required architecture
Undefined symbols:
  _inflateEnd, referenced from:
  _read_zip_member in jcf-io.o
  _inflate, referenced from:
  _read_zip_member in jcf-io.o
  _inflateInit2_, referenced from:
  _read_zip_member in jcf-io.o
ld64-62.1 failed: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [jc1] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [bootstrap] Error 2

Now, I can't find a bug report for this.  I've also bootstrapped the 4.2.0
development branch many times with this configuration; see, e.g.,




-- 
   Summary: bootstrap fails; chooses wrong zlib for building jc1
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
 GCC build triplet: powerpc64-apple-darwin8.8.0
  GCC host triplet: powerpc64-apple-darwin8.8.0
GCC target triplet: powerpc64-apple-darwin8.8.0


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

[Bug target/32011] New: Bad host triplet detection for x86_64 on Linux.

[drab at kepler dot fjfi dot cvut dot cz]

Is there a reason why in the GCC 4.3.0 the x86_64 on Linux is detected as an
x86_64-unknown-linux-gnu instead of an x86_64-pc-linux-gnu as it was in the
past?


-- 
   Summary: Bad host triplet detection for x86_64 on Linux.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drab at kepler dot fjfi dot cvut dot cz
  GCC host triplet: x86_64-*-linux-gnu


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

[Bug target/32011] Bad host triplet detection for x86_64 on Linux.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-20 18:01 ---
This is a config.guess issue and not a GCC issue.


-- 


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

[Bug target/32011] Bad host triplet detection for x86_64 on Linux.

[schwab at suse dot de]

--- Comment #2 from schwab at suse dot de  2007-05-20 18:03 ---
You must have been using a modified version of config.guess, the respective
line hasn't changed since it was added 6 years ago.


-- 


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

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

--- Comment #4 from danglin at gcc dot gnu dot org  2007-05-20 18:15 ---
For reference, this is the rtl at the point of the hang:

(gdb) p debug_rtx_list (get_insns (), 30)
(note 6 0 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(insn 3 6 4 2 pr31944.c:4 (set (reg/v/f:DI 68 [ mle ])
(reg:DI 26 %r26 [ mle ])) 124 {*pa.md:4569} (nil)
(nil))

(insn 4 3 5 2 pr31944.c:4 (set (reg/v/f:DI 69 [ res ])
(reg:DI 25 %r25 [ res ])) 124 {*pa.md:4569} (nil)
(nil))

(note 5 4 8 2 NOTE_INSN_FUNCTION_BEG)

(insn 8 5 9 2 pr31944.c:5 (set (reg:SI 70 [ .type ])
(mem/s:SI (reg/v/f:DI 68 [ mle ]) [3 .type+0 S4 A32])) 71
{*pa.md:2568} (nil)
(nil))

(insn 9 8 10 2 pr31944.c:5 (set (reg:DI 66 [ D.1605 ])
(sign_extend:DI (reg:SI 70 [ .type ]))) 143 {extendsidi2}
(nil)
(nil))

(jump_insn 10 9 11 2 pr31944.c:5 (set (pc)
(if_then_else (ne (subreg/s:SI (reg:DI 66 [ D.1605 ]) 4)
(const_int 1 [0x1]))
(label_ref 18)
(pc))) 46 {*pa.md:1768} (nil)
(expr_list:REG_BR_PROB (const_int 6900 [0x1af4])
(nil)))

(note 11 10 12 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 12 11 13 3 pr31944.c:6 (set (reg:DI 71)
(const_int 0 [0x0])) 124 {*pa.md:4569} (nil)
(nil))

(jump_insn 13 12 14 3 pr31944.c:6 (set (pc)
(if_then_else (ne (reg/v/f:DI 69 [ res ])
(reg:DI 71))
(label_ref:DI 32)
(pc))) 48 {*pa.md:1824} (nil)
(expr_list:REG_BR_PROB (const_int 8500 [0x2134])
(nil)))

(note 14 13 15 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(insn 15 14 18 4 pr31944.c:6 (asm_input/v ("nop") ("pr31944.c") 6) -1 (nil)
(nil))

(code_label 18 15 19 5 2 "" [1 uses])

(note 19 18 20 5 [bb 5] NOTE_INSN_BASIC_BLOCK)

(insn 20 19 21 5 pr31944.c:8 (set (reg:DI 72)
(const_int 0 [0x0])) 124 {*pa.md:4569} (nil)
(nil))

(jump_insn 21 20 22 5 pr31944.c:8 (set (pc)
(if_then_else (ne (reg:DI 66 [ D.1605 ])
(const_int 0 [0x0]))
(label_ref:DI 32)
(pc))) 48 {*pa.md:1824} (nil)
(expr_list:REG_BR_PROB (const_int 4600 [0x11f8])
(nil)))

(note 22 21 23 6 [bb 6] NOTE_INSN_BASIC_BLOCK)

(insn 23 22 24 6 pr31944.c:9 (set (reg:DI 73)
(const_int 0 [0x0])) 124 {*pa.md:4569} (nil)
(nil))

(jump_insn 24 23 25 6 pr31944.c:9 (set (pc)
(if_then_else (ne (reg/v/f:DI 69 [ res ])
(const_int 0 [0x0]))
(label_ref:DI 32)
(pc))) 48 {*pa.md:1824} (nil)
(expr_list:REG_BR_PROB (const_int 8284 [0x205c])
(nil)))

(note 25 24 26 7 [bb 7] NOTE_INSN_BASIC_BLOCK)

(insn 26 25 32 7 pr31944.c:10 (asm_operands/v ("nop") ("") 0 [
(const_int 0 [0x0])
]
 [
(asm_input:SI ("i") ("") 0)
] ("pr31944.c") 10) -1 (nil)
(nil))

(code_label 32 26 35 8 4 "" [3 uses])

(note 35 32 0 8 [bb 8] NOTE_INSN_BASIC_BLOCK)

This problem is present in HEAD as well as 4.1.  Probably, 4.2 is affected as
well.


-- 


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

[Bug target/32012] New: Bad host triplet detection for x86_64 on Linux.

[drab at kepler dot fjfi dot cvut dot cz]

Is there a reason why in the GCC 4.3.0 the x86_64 on Linux is detected as an
x86_64-unknown-linux-gnu instead of an x86_64-pc-linux-gnu as it was in the
past?


-- 
   Summary: Bad host triplet detection for x86_64 on Linux.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drab at kepler dot fjfi dot cvut dot cz
  GCC host triplet: x86_64-*-linux-gnu


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

[Bug target/32012] Bad host triplet detection for x86_64 on Linux.

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2007-05-20 18:29 ---


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


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/32011] Bad host triplet detection for x86_64 on Linux.

[schwab at suse dot de]

--- Comment #3 from schwab at suse dot de  2007-05-20 18:29 ---
*** Bug 32012 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/32011] Bad host triplet detection for x86_64 on Linux.

[drab at kepler dot fjfi dot cvut dot cz]

--- Comment #4 from drab at kepler dot fjfi dot cvut dot cz  2007-05-20 
18:33 ---
(In reply to comment #2)
> You must have been using a modified version of config.guess, the respective
> line hasn't changed since it was added 6 years ago.

Nope, I'm allways using the SVN version. No modifications to config.guess.
Well, but now I see it really isn't the GCC problem. But on a Gentoo the
config.guess responds this way, even the old one (so it's probably true, that
it hasn't changed). Before I was using Mandrake and there it was working. But
anyway, it's no problem. I can get around it easily. :-)


-- 

drab at kepler dot fjfi dot cvut dot cz changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/32012] Bad host triplet detection for x86_64 on Linux.

[drab at kepler dot fjfi dot cvut dot cz]

--- Comment #2 from drab at kepler dot fjfi dot cvut dot cz  2007-05-20 
18:34 ---
Sorry, this bugreport was posted by an accident.


-- 


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

[Bug target/32011] Bad host triplet detection for x86_64 on Linux.

[drab at kepler dot fjfi dot cvut dot cz]

--- Comment #5 from drab at kepler dot fjfi dot cvut dot cz  2007-05-20 
18:40 ---
Same problem is on FC6, though. Also x86_64-unknown-linux-gnu. Just for the
record.


-- 


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

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2007-05-20 19:02 ---
In order to prevent flush_hash_table from looping forever, the call to
invalidate (p->exp, VOIDmode) has to remove the element p.  However, this
doesn't happen.  It only removes the entry if lookup_for_remove finds the
pseudo:

/* Because a register can be referenced in more than one mode,
   we might have to remove more than one table entry.  */
struct table_elt *elt;

while ((elt = lookup_for_remove (x, hash, GET_MODE (x
  remove_from_table (elt, hash);

For some reason, reg:DI 66 isn't found:

(gdb) p lookup_for_remove (0x83fffec89d00, 29, DImode)
$20 = (struct table_elt *) 0x0

I'm thinking that flush_hash_table should check p after calling invalidate
and call remove_from_table if it's nonzero.


-- 


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

[Bug libgomp/32013] New: Use posix95 for libgomp on Irix 6.2

[gcc-tgc at jupiterrise dot com]

Irix 6.2 with pthread patches is not Unix98 compatible so libgomp must use the
posix95 locking primitives.


-- 
   Summary: Use posix95 for libgomp on Irix 6.2
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-tgc at jupiterrise dot com
 GCC build triplet: mips-sgi-irix6.2
  GCC host triplet: mips-sgi-irix6.2
GCC target triplet: mips-sgi-irix6.2


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

[Bug libgomp/32013] Use posix95 for libgomp on Irix 6.2

[gcc-tgc at jupiterrise dot com]

--- Comment #1 from gcc-tgc at jupiterrise dot com  2007-05-20 20:06 ---
Created an attachment (id=13590)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13590&action=view)
Make libgomp choose posix95 for Irix 6.2


-- 


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

[Bug testsuite/31883] [testsuite, gfortran] typos in the dg directives of the gfortran testsuite

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2007-05-20 20:39 
---
I have applied the remaining patches from comments #2 and #3 to my local trunk
and I am regression testing now.  I will post to list with results in
preparation for committing these fixups.


-- 


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

[Bug fortran/31196] [4.1 only] wrong code generated with RESHAPE/TRANSPOSE

[tkoenig at gcc dot gnu dot org]

--- Comment #13 from tkoenig at gcc dot gnu dot org  2007-05-20 21:01 
---
One down, 54 wrong-code or ice-on-valid-code to go :-)

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug testsuite/32014] New: new gcc failures

[dominiq at lps dot ens dot fr]

With the 4.3.0 20070518 snapshot (see PR32009) I have the following new
failures:

Native configuration is powerpc-apple-darwin7.9.0

=== gcc tests ===

Schedule of variations:
unix

...
Running /Users/dominiq/test/gcc-4.3-20070518/gcc/testsuite/gcc.dg/vect/vect.exp
...
FAIL: gcc.dg/vect/vect-64.c (internal compiler error)
FAIL: gcc.dg/vect/vect-64.c (test for excess errors)
WARNING: gcc.dg/vect/vect-64.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-68.c (internal compiler error)
FAIL: gcc.dg/vect/vect-68.c (test for excess errors)
WARNING: gcc.dg/vect/vect-68.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-70.c (internal compiler error)
FAIL: gcc.dg/vect/vect-70.c (test for excess errors)
WARNING: gcc.dg/vect/vect-70.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times vectorized
1 loops 1
FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times vectorized
1 loops 1
XPASS: gcc.dg/vect/vect-iv-4.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
FAIL: gcc.dg/vect/section-anchors-vect-69.c (test for excess errors)
FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times Alignment of
access forced using peeling 4
...

=== gcc Summary ===

# of expected passes44735
# of unexpected failures24
# of unexpected successes   3
# of expected failures  130
# of untested testcases 28
# of unsupported tests  464
/sw/lib/gcc4/bin/gcc  version 4.3.0 20070518 (experimental)

WARNING: Couldn't find the global config file.
Test Run By dominiq on Sun May 20 20:12:54 2007
Native configuration is powerpc-apple-darwin7.9.0

Is this known/expected?


-- 
   Summary: new gcc failures
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
  GCC host triplet: powerpc-apple-darwin7


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

[Bug regression/32009] building gcc4-4.3.0-20070518 failed on OSX 10.3.9

[andreast at gcc dot gnu dot org]

-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||andreast at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-20 21:26:42
   date||


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

[Bug rtl-optimization/31944] Endless loop while building a 64-bit 2.6.20 kernel

[danglin at gcc dot gnu dot org]

--- Comment #6 from danglin at gcc dot gnu dot org  2007-05-20 21:30 ---
This problem isn't present in 3.4.6.


-- 


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

[Bug other/29694] missed warnings about comparisons which are always true/false.

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2007-05-20 21:31 ---
Subject: Bug 29694

Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124875
Log:
2007-05-20  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR middle-end/7651
PR c++/11856
PR c/12963
PR c/23587
PR other/29694
* c.opt (Wtype-limits): New.
* doc/invoke.texi (Wtype-limits): Document it.
(Wextra): Enabled by -Wextra.
* c-opts.c (c_common_post_options): Enabled by -Wextra.
* c-common.c (shorten_compare): Warn with Wtype-limits.

testsuite/
* gcc.dg/compare6.c: Replace Wall with Wtype-limits.
* gcc.dg/Wtype-limits.c: New.
* gcc.dg/Wtype-limits-Wextra.c: New.
* gcc.dg/Wtype-limits-no.c: New.
* g++.dg/warn/Wtype-limits.C: New.
* g++.dg/warn/Wtype-limits-Wextra.C: New.
* g++.dg/warn/Wtype-limits-no.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-Wextra.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-no.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits.C
trunk/gcc/testsuite/gcc.dg/Wtype-limits-Wextra.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits-no.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-opts.c
trunk/gcc/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/compare6.c


-- 


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

[Bug c/12963] Wrong and misleading warning encourages writing non-portable code

[manu at gcc dot gnu dot org]

--- Comment #22 from manu at gcc dot gnu dot org  2007-05-20 21:31 ---
Subject: Bug 12963

Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124875
Log:
2007-05-20  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR middle-end/7651
PR c++/11856
PR c/12963
PR c/23587
PR other/29694
* c.opt (Wtype-limits): New.
* doc/invoke.texi (Wtype-limits): Document it.
(Wextra): Enabled by -Wextra.
* c-opts.c (c_common_post_options): Enabled by -Wextra.
* c-common.c (shorten_compare): Warn with Wtype-limits.

testsuite/
* gcc.dg/compare6.c: Replace Wall with Wtype-limits.
* gcc.dg/Wtype-limits.c: New.
* gcc.dg/Wtype-limits-Wextra.c: New.
* gcc.dg/Wtype-limits-no.c: New.
* g++.dg/warn/Wtype-limits.C: New.
* g++.dg/warn/Wtype-limits-Wextra.C: New.
* g++.dg/warn/Wtype-limits-no.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-Wextra.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-no.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits.C
trunk/gcc/testsuite/gcc.dg/Wtype-limits-Wextra.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits-no.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-opts.c
trunk/gcc/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/compare6.c


-- 


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

[Bug c++/11856] unsigned warning in template

[manu at gcc dot gnu dot org]

--- Comment #23 from manu at gcc dot gnu dot org  2007-05-20 21:32 ---
Subject: Bug 11856

Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124875
Log:
2007-05-20  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR middle-end/7651
PR c++/11856
PR c/12963
PR c/23587
PR other/29694
* c.opt (Wtype-limits): New.
* doc/invoke.texi (Wtype-limits): Document it.
(Wextra): Enabled by -Wextra.
* c-opts.c (c_common_post_options): Enabled by -Wextra.
* c-common.c (shorten_compare): Warn with Wtype-limits.

testsuite/
* gcc.dg/compare6.c: Replace Wall with Wtype-limits.
* gcc.dg/Wtype-limits.c: New.
* gcc.dg/Wtype-limits-Wextra.c: New.
* gcc.dg/Wtype-limits-no.c: New.
* g++.dg/warn/Wtype-limits.C: New.
* g++.dg/warn/Wtype-limits-Wextra.C: New.
* g++.dg/warn/Wtype-limits-no.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-Wextra.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-no.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits.C
trunk/gcc/testsuite/gcc.dg/Wtype-limits-Wextra.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits-no.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-opts.c
trunk/gcc/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/compare6.c


-- 


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

[Bug c/23587] Missing "warning: comparison is always false due to limited range of data type"

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2007-05-20 21:31 ---
Subject: Bug 23587

Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124875
Log:
2007-05-20  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR middle-end/7651
PR c++/11856
PR c/12963
PR c/23587
PR other/29694
* c.opt (Wtype-limits): New.
* doc/invoke.texi (Wtype-limits): Document it.
(Wextra): Enabled by -Wextra.
* c-opts.c (c_common_post_options): Enabled by -Wextra.
* c-common.c (shorten_compare): Warn with Wtype-limits.

testsuite/
* gcc.dg/compare6.c: Replace Wall with Wtype-limits.
* gcc.dg/Wtype-limits.c: New.
* gcc.dg/Wtype-limits-Wextra.c: New.
* gcc.dg/Wtype-limits-no.c: New.
* g++.dg/warn/Wtype-limits.C: New.
* g++.dg/warn/Wtype-limits-Wextra.C: New.
* g++.dg/warn/Wtype-limits-no.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-Wextra.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-no.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits.C
trunk/gcc/testsuite/gcc.dg/Wtype-limits-Wextra.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits-no.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-opts.c
trunk/gcc/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/compare6.c


-- 


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

[Bug libgomp/32013] Use posix95 for libgomp on Irix 6.2

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-05-20 21:33 ---
patches get sent to gcc-patches@, make sure you read
http://gcc.gnu.org/contribute.html also.


-- 


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

[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags

[manu at gcc dot gnu dot org]

--- Comment #26 from manu at gcc dot gnu dot org  2007-05-20 21:31 ---
Subject: Bug 7651

Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124875
Log:
2007-05-20  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR middle-end/7651
PR c++/11856
PR c/12963
PR c/23587
PR other/29694
* c.opt (Wtype-limits): New.
* doc/invoke.texi (Wtype-limits): Document it.
(Wextra): Enabled by -Wextra.
* c-opts.c (c_common_post_options): Enabled by -Wextra.
* c-common.c (shorten_compare): Warn with Wtype-limits.

testsuite/
* gcc.dg/compare6.c: Replace Wall with Wtype-limits.
* gcc.dg/Wtype-limits.c: New.
* gcc.dg/Wtype-limits-Wextra.c: New.
* gcc.dg/Wtype-limits-no.c: New.
* g++.dg/warn/Wtype-limits.C: New.
* g++.dg/warn/Wtype-limits-Wextra.C: New.
* g++.dg/warn/Wtype-limits-no.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-Wextra.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits-no.C
trunk/gcc/testsuite/g++.dg/warn/Wtype-limits.C
trunk/gcc/testsuite/gcc.dg/Wtype-limits-Wextra.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits-no.c
trunk/gcc/testsuite/gcc.dg/Wtype-limits.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-opts.c
trunk/gcc/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/compare6.c


-- 


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

[Bug tree-optimization/32004] [4.3 regression] : gcc.target/i386/pr21291.c

[hjl at lucon dot org]

--- Comment #6 from hjl at lucon dot org  2007-05-20 21:40 ---
forwprop changes


:
  alen_4 = alen_2(D) - blen_3(D);
  out_5 = 0;
  __asm__("":"=r" a_9, "=r" b_10, "=mr" blen_11, "=mr" out_12, "=&r"
tmp_13:"mr"
 d_6(D), "0" a_7(D), "1" b_8(D), "2" blen_3(D), "3" 0:"edx", "eax");
  if (alen_4 == 0)
goto  ();
  else
goto  ();

to

:
  out_5 = 0;
  __asm__("":"=r" a_9, "=r" b_10, "=mr" blen_11, "=mr" out_12, "=&r"
tmp_13:"mr"
 d_6(D), "0" a_7(D), "1" b_8(D), "2" blen_3(D), "3" 0:"edx", "eax");
  if (alen_2(D) == blen_3(D))
goto  ();
  else
goto  ();

If it can use blen_11 instead of blen_3(D), it may compile. If forwprop can't
deal some asm stmts very well, it should skip those asm stmts.


-- 

hjl at lucon dot org changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
   Target Milestone|4.3.0   |---


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

[Bug c/23587] Missing "warning: comparison is always false due to limited range of data type"

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2007-05-20 21:42 ---
Fixed for GCC 4.3 (all warnings have been grouped under -Wtype-limits).


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/31995] can't determine dependence between p->a[x+i] and p->a[x+i+1]

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-05-20 21:44 ---
Created an attachment (id=13591)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13591&action=view)
new patch

This new patch changes one little thing dealing with how with indirect
references are handled in dr_analyze_indices.  If we already inserted indices
for array references and the indirect reference is not changing, dnn't add that
index of 0.  This lets us get rid of the chang in build_classic_dist_vector_1
which I was worried about.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #13587|0   |1
is obsolete||


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

[Bug c++/11856] unsigned warning in template

[manu at gcc dot gnu dot org]

--- Comment #24 from manu at gcc dot gnu dot org  2007-05-20 21:46 ---
As a workaround, the warning can be disabled with -Wno-type-limits.


-- 


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

[Bug tree-optimization/32004] [4.3 regression] : gcc.target/i386/pr21291.c

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2007-05-20 21:50 ---
> If it can use blen_11 instead of blen_3(D), it may compile. If forwprop can't
> deal some asm stmts very well, it should skip those asm stmts.

It cannot use blen_11 instead of blen_3 because the asm will have changed the
value.  forwprop does not even see the asm at all (how would it unless it
looked for all SSAnames that had blen in them which is hard to do in the first
place?).  What forwprop is doing is legal but creates a little extra register
pressure which in turn causes GCC's register allocator to go, I don't know what
the fuck to do because I am a stupid register allocator.


-- 


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

[Bug c/12963] Wrong and misleading warning encourages writing non-portable code

[manu at gcc dot gnu dot org]

--- Comment #23 from manu at gcc dot gnu dot org  2007-05-20 21:50 ---
The diverse warnings of the type "always true/false because of range of data
type" have been grouped under -Wtype-limits that is enabled by -Wextra (and not
by -Wall). The warning can be disabled by using -Wno-type-limits.

Thus, fixed in GCC 4.3. 


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/32004] [4.3 regression] : gcc.target/i386/pr21291.c

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-05-20 21:51 ---
There is almost nothing that can be done on the tree level to fix up this
register allocator issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end


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

[Bug fortran/31618] [4.2, 4.1 only] backspace intrinsic is not working on an unformatted file

[tkoenig at gcc dot gnu dot org]

--- Comment #10 from tkoenig at gcc dot gnu dot org  2007-05-20 22:09 
---
Subject: Bug 31618

Author: tkoenig
Date: Sun May 20 21:07:14 2007
New Revision: 124878

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124878
Log:
2007-05-20  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/31618
Backport from trunk.
* io/transfer.c (read_block_direct):  Instead of calling us_read,
set dtp->u.p.current_unit->current_record = 0 so that pre_position
will read the record marker.
(data_transfer_init):  For different error conditions, call
generate_error, then return.

2007-05-20  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/31618
Backport from trunk.
* gfortran.dg/backspace_8.f:  New test case.


Added:
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/backspace_8.f
Modified:
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
branches/gcc-4_2-branch/libgfortran/ChangeLog
branches/gcc-4_2-branch/libgfortran/io/transfer.c


-- 


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

[Bug middle-end/31935] [Regression 4.3] ICE with -O3 -ftree-loop-linear -ftree-vectorize

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-05-20 22:09 ---
Close.


-- 

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=31935

[Bug fortran/31618] [4.2, 4.1 only] backspace intrinsic is not working on an unformatted file

[tkoenig at gcc dot gnu dot org]

--- Comment #11 from tkoenig at gcc dot gnu dot org  2007-05-20 22:11 
---
Now also fixed on 4.2.1 (revision 124878).  Won't backport to 4.1.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.3.0   |4.3.0 4.2.1
 Resolution||FIXED


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

[Bug fortran/24546] [meta-bug] gfortran debugging problems

[tkoenig at gcc dot gnu dot org]

--- Comment #8 from tkoenig at gcc dot gnu dot org  2007-05-20 22:20 ---
(In reply to comment #7)

> PS: as a minor improvement, we might want to give numeric types a more
> Fortran-like name, with a patch such as the following:

...

Hi FX,

are you planning to submit that patch?  It sounds like a good idea.


-- 


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

[Bug tree-optimization/31995] can't determine dependence between p->a[x+i] and p->a[x+i+1]

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-05-20 23:03 ---
(From update of attachment 13591)
I take this back, this can cause an ICE with some code (which seems like I
should add a testcase).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #13591|0   |1
is obsolete||


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

[Bug tree-optimization/31995] can't determine dependence between p->a[x+i] and p->a[x+i+1]

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-05-20 23:06 ---
(From update of attachment 13587)
This patch is safer and allows us to add more to build_classic_dist_vector_1. 
Like when the two access functions are constants, just take the difference. 
(which might be needed soon anyways).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #13587|1   |0
is obsolete||


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

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

[astrange at ithinksw dot com]

../gcc/configure --prefix=/usr/local/gcc42 --enable-threads --with-arch=nocona
--with-tune=nocona --disable-bootstrap --disable-nls --with-gmp=/sw
--with-mpfr=/sw --with-system-zlib --enable-languages=c,c++,objc,obj-c++
--disable-multilib
Thread model: posix
gcc version 4.3.0 20070513 (experimental)

using pointer-plus r124878

> /usr/local/gcc42/bin/gcc -O3 -c pp-vrp-ice.c
pp-vrp-ice.c: In function 'ff_pred8x8_plane_c':
pp-vrp-ice.c:4: internal compiler error: in extract_range_from_binary_expr, at
tree-vrp.c:1755
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

typedef unsigned char uint8_t;
extern uint8_t ff_cropTbl[256 + 2 * 1024];

void ff_pred8x8_plane_c(uint8_t *src, int stride){
  int j, k;
  int a;
  uint8_t *cm = ff_cropTbl + 1024;
  const uint8_t * const src0 = src+3-stride;
  const uint8_t *src1 = src+4*stride-1;
  const uint8_t *src2 = src1-2*stride;
  int H = src0[1] - src0[-1];
  int V = src1[0] - src2[ 0];
  for(k=2; k<=4; ++k) {
src1 += stride; src2 -= stride;
H += k*(src0[k] - src0[-k]);
V += k*(src1[0] - src2[ 0]);
  }
  H = ( 17*H+16 ) >> 5;
  V = ( 17*V+16 ) >> 5;

  a = 16*(src1[0] + src2[8]+1) - 3*(V+H);
  for(j=8; j>0; --j) {
int b = a;
a += V;
src[0] = cm[ (b ) >> 5 ];
src[1] = cm[ (b+ H) >> 5 ];
src[2] = cm[ (b+2*H) >> 5 ];
src[3] = cm[ (b+3*H) >> 5 ];
src[4] = cm[ (b+4*H) >> 5 ];
src[5] = cm[ (b+5*H) >> 5 ];
src[6] = cm[ (b+6*H) >> 5 ];
src[7] = cm[ (b+7*H) >> 5 ];
src += stride;
  }
}


-- 
   Summary: pointer-plus ICE in extract_range_from_binary_expr, at
tree-vrp.c:1755
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
 GCC build triplet: i386-apple-darwin8.9.1
  GCC host triplet: i386-apple-darwin8.9.1
GCC target triplet: i386-apple-darwin8.9.1


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

[Bug fortran/31207] [4.2.1 only] advance="no" and tabs

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2007-05-20 23:25 
---
This is not a regression.  Was not supported by g77.  Fixed on 4.3

Closing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF

[jvdelisle at gcc dot gnu dot org]

--- Comment #51 from jvdelisle at gcc dot gnu dot org  2007-05-20 23:50 
---
Two testcases for 4.3 pass on 4.2.  Fixed on 4.3.  Because of the problems with
regressions on SPEC, I would rather not backport this.  Closing.

Herald, if something else comes up, please file a new report.  This one is too
long.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

Re: [Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[Daniel Berlin]

On 20 May 2007 04:57:45 -, pluto at agmk dot net
<[EMAIL PROTECTED]> wrote:



--- Comment #25 from pluto at agmk dot net  2007-05-20 05:57 ---
Subject: Re:  [4.2 Regression] possible quadratic behaviour.




--



Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
vi->id instead of rhs.var = id

Remove the id variable declaration.

This would have only affected fortran 



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

[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.

[dberlin at dberlin dot org]

--- Comment #28 from dberlin at gcc dot gnu dot org  2007-05-20 23:52 
---
Subject: Re:  [4.2 Regression] possible quadratic behaviour.

On 20 May 2007 04:57:45 -, pluto at agmk dot net
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #25 from pluto at agmk dot net  2007-05-20 05:57 ---
> Subject: Re:  [4.2 Regression] possible quadratic behaviour.
>

> --
>

Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
vi->id instead of rhs.var = id

Remove the id variable declaration.

This would have only affected fortran 

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


-- 


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

[Bug fortran/31922] [4.2 only] Accessing uninitialized variable for print *, trim(blank_string)

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2007-05-21 00:00 
---
This is not a regression from previous releases. Closing.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/27405] [4.2/4.3 Regression] gcc.c-torture/execute/960209-1.c ICEs on sh64-* with -O3

[kkojima at gcc dot gnu dot org]

--- Comment #6 from kkojima at gcc dot gnu dot org  2007-05-21 00:14 ---
Subject: Bug 27405

Author: kkojima
Date: Sun May 20 23:13:48 2007
New Revision: 124879

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124879
Log:
PR target/27405
Backport from mainline.
* config/sh/sh.md (cmp{eq,gt,gtu}{si,di}_media): Remove.
(cmpsi{eq,gt,gtu}{si,di}_media): Rename to
cmp{eq,gt,gtu}{si,di}_media.
(*cmpne0si_media): Remove.
(*movsicc_umin): Adjust gen_cmp*_media call.
(unordered): Change the mode of unordered and operands[1] to
SImode.
(seq): Adjust gen_cmp*_media calls.  Make the mode of
a temporary result of compare SImode if needed.  If the mode
of operands[0] is DImode, extend the temporary result to DImode.
(slt, sle, sgt, sge, sgtu, sltu, sleu, sgue, sne): Likewise.
(sunorderd): Change the mode of match_operand and unorderd to
SImode.
(cmpeq{sf,df}_media): Remove.
(cmpsieq{sf,df}_media): Rename to cmpeq{sf,df}_media.
(cmp{gt,ge,un}{sf,df}_media): Change the mode of match_operand
and compare operation to SImode.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/sh/sh.md


-- 


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

[Bug fortran/32002] [4.2/4.3 regression] insufficient conformance check when assigning the result of an elemental function to an array

[patchapp at dberlin dot org]

--- Comment #4 from patchapp at dberlin dot org  2007-05-21 00:16 ---
Subject: Bug number PR32002

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-05/msg01315.html


-- 


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

Install problem

[Bluejack]

Friends... prob not worth creating an account in your bugzilla for...
default download of 4.2.0 source distribution... configure with no
options... no .y files changed... make reports:

/usr/local/dev/gcc/gcc-4.2.0/missing bison -t  -o java/parse-scan.c
../../gcc-4.  2.0/gcc/java/parse-scan.y
WARNING: `bison' missing on your system.  You should only need it if
you modified a `.y' file.  You may need the `Bison' package
in order for those modifications to take effect.  You can get
`Bison' from any GNU archive site.
/usr/local/dev/gcc/obj/./prev-gcc/xgcc
-B/usr/local/dev/gcc/obj/./prev-gcc/ -B/u
sr/local/i686-pc-linux-gnu/bin/ -c   -O2 -g -fomit-frame-pointer
-DIN_GCC   -W -  Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-lon  g-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wmis
sing-format-attribute  -Wno-error  -DHAVE_CONFIG_H -I. -Ijava
-I../../gcc-4.2.0/  gcc -I../../gcc-4.2.0/gcc/java
-I../../gcc-4.2.0/gcc/../include -I../../gcc-4.2.
0/gcc/../libcpp/include  -I../../gcc-4.2.0/gcc/../libdecnumber
-I../libdecnumber  java/parse-scan.c -o java/parse-scan.o
xgcc: java/parse-scan.c: No such file or directory
xgcc: no input files

I'll get me a bison and try again; but that seems surprising for a
default build...

hope this helps & sorry to pester you by email.

--
---
Work as though you live in the younger days of a better nation!
-- -- Alasdair Gray

[Bug target/31022] [4.1/4.2/4.3 Regression] [SH4] internal compiler error with inline

[kkojima at gcc dot gnu dot org]

--- Comment #3 from kkojima at gcc dot gnu dot org  2007-05-21 00:23 ---
Subject: Bug 31022

Author: kkojima
Date: Sun May 20 23:22:46 2007
New Revision: 124880

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124880
Log:
PR target/31022
Backport from mainline.
* config/sh/sh.c (sh_adjust_cost): Use the result of single_set
instead of PATTERN.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/sh/sh.c


-- 


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

[Bug target/31480] [4.1/4.2 Regression] ICE with -O -fomit-frame-pointer on SH

[kkojima at gcc dot gnu dot org]

--- Comment #3 from kkojima at gcc dot gnu dot org  2007-05-21 00:25 ---
Subject: Bug 31480

Author: kkojima
Date: Sun May 20 23:25:03 2007
New Revision: 124881

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124881
Log:
PR target/31480
Backport from mainline.
* config/sh/sh.md (length): Check if prev_nonnote_insn (insn)
is null.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/sh/sh.md


-- 


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

[Bug target/31701] [4.1/4.2/4.3 Regression] SH: wrong epilogue for sibling calls

[kkojima at gcc dot gnu dot org]

--- Comment #3 from kkojima at gcc dot gnu dot org  2007-05-21 00:27 ---
Subject: Bug 31701

Author: kkojima
Date: Sun May 20 23:27:22 2007
New Revision: 124882

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124882
Log:
PR target/31701
Backport from mainline.
* config/sh/sh.c (output_stack_adjust): Avoid using the frame
register itself to hold the offset constant.  Tell flow the use
of r4 and r5 when they are used.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/sh/sh.c


-- 


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

[Bug target/31022] [4.1/4.2/4.3 Regression] [SH4] internal compiler error with inline

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2007-05-21 00:54 ---
Subject: Bug 31022

Author: kkojima
Date: Sun May 20 23:54:01 2007
New Revision: 124883

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124883
Log:
PR target/31022
Backport from mainline.
* config/sh/sh.c (sh_adjust_cost): Use the result of single_set
instead of PATTERN.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/sh/sh.c


-- 


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

[Bug target/31480] [4.1/4.2 Regression] ICE with -O -fomit-frame-pointer on SH

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2007-05-21 00:56 ---
Subject: Bug 31480

Author: kkojima
Date: Sun May 20 23:55:48 2007
New Revision: 124884

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124884
Log:
PR target/31480
Backport from mainline.
* config/sh/sh.md (length): Check if prev_nonnote_insn (insn)
is null.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/sh/sh.md


-- 


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

[Bug target/31701] [4.1/4.2/4.3 Regression] SH: wrong epilogue for sibling calls

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2007-05-21 00:57 ---
Subject: Bug 31701

Author: kkojima
Date: Sun May 20 23:57:32 2007
New Revision: 124885

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124885
Log:
PR target/31701
Backport from mainline.
* config/sh/sh.c (output_stack_adjust): Avoid using the frame
register itself to hold the offset constant.  Tell flow the use
of r4 and r5 when they are used.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/sh/sh.c


-- 


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

[Bug target/27405] [4.2/4.3 Regression] gcc.c-torture/execute/960209-1.c ICEs on sh64-* with -O3

[kkojima at gcc dot gnu dot org]

--- Comment #7 from kkojima at gcc dot gnu dot org  2007-05-21 01:00 ---
Fixed.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[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 #1 from pinskia at gcc dot gnu dot org  2007-05-21 01:01 ---
I can confirm this, it is due to sccp which creates int * 2B so we have two
things a type mismatch and also now an invalid IR.  Fixing right now.


-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-05-21 01:01:17
   date||


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

[Bug target/31022] [4.1/4.2/4.3 Regression] [SH4] internal compiler error with inline

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2007-05-21 01:01 ---
Fixed.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/31480] [4.1/4.2 Regression] ICE with -O -fomit-frame-pointer on SH

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2007-05-21 01:01 ---
Fixed.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/31701] [4.1/4.2/4.3 Regression] SH: wrong epilogue for sibling calls

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2007-05-21 01:02 ---
Fixed.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/31395] [4.2 Only] Colon edit descriptor is ignored unless preceded by a comma or a slash

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2007-05-21 01:05 
---
Subject: Bug 31395

Author: jvdelisle
Date: Mon May 21 00:04:43 2007
New Revision: 124886

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124886
Log:
2007-05-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/31395
* io/format.c (parse_format_list): Fix parsing. Regression against g77.
Backport from 4.3.

Modified:
branches/gcc-4_2-branch/libgfortran/ChangeLog
branches/gcc-4_2-branch/libgfortran/io/format.c


-- 


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

[Bug fortran/31395] [4.2 Only] Colon edit descriptor is ignored unless preceded by a comma or a slash

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-05-21 01:06 
---
Subject: Bug 31395

Author: jvdelisle
Date: Mon May 21 00:06:46 2007
New Revision: 124887

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124887
Log:
2007-05-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/31395
* gfortran.dg/fmt_colon.f90: New test.

Added:
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/fmt_colon.f90
Modified:
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/31395] [4.2 Only] Colon edit descriptor is ignored unless preceded by a comma or a slash

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2007-05-21 01:07 
---
Fixed on 4.2.1 and 4.3. Closing.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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