[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

--- Comment #10 from bonzini at gnu dot org  2008-04-01 07:08 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap

hjl dot tools at gmail dot com wrote:
> --- Comment #5 from hjl dot tools at gmail dot com  2008-03-31 18:16 
> ---
> (In reply to comment #4)
>> Patch seems fine, but before approving it I would like a description of why
>> "tries to [...] relink itself" (important part is *re*link itself), and that
>> description should also go in exec-tool.in.
>>
> 
> I am not a libtool person. My best understanding is when shared library
> is enabled, libtool will create a shell script, ld-new, and the real
> executable as .libs/ld-new.  But .libs/ld-new isn't suitable to be
> used in place directly. When the ld-new shell script is run the first
> time, it will relink a new real linker, .libs/lt-ld-new, and use
> .libs/lt-ld-new instead of .libs/ld-new. I hope libtool person can
> provide a real explanation in exec-tool.in.

Ah, right, now I remember seeing this behavior too.  If you wish to 
explore Ralf's proposed usage of -no-fast-install, I would prefer that 
but I cannot approve that patch (which would have to go to the binutils 
maintainers).

Otherwise, please add a comment like this:

# When ld-new is first executed from the build tree, libtool
# will relink it as .libs/lt-ld-new, so that it can give it
# an RPATH that refers to the build tree.  While doing this
# we need to use the previous-stage linker, or we have an infinite
# loop.

and commit the patch.

Paolo


-- 


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

[Bug debug/27574] [4.1/4.2/4.3/4.4 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor

[pinskia at gcc dot gnu dot org]

--- Comment #20 from pinskia at gcc dot gnu dot org  2008-04-01 07:11 
---
I am just going to test this patch and relook at it when the test is finished
but I can see what the issue is.  at -O0 we have unit-at-a-time on.  Though
there is still an issue if we don't have any clones, I think.  I will relook
more into it after the bootstrap/test finishes.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-07-22 17:45:51 |2008-04-01 07:11:38
   date||


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

[Bug fortran/35743] allocate negative memory for zero-sized WHERE construct

[pault at gcc dot gnu dot org]

-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-28 23:59:40 |2008-04-01 07:24:05
   date||


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

[Bug fortran/35745] Divide incorrectly extracted from WHERE block?; run time abort

[pault at gcc dot gnu dot org]

-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-28 22:05:10 |2008-04-01 07:24:30
   date||


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

[Bug fortran/35780] [4.3/4.4 Regression] internal compiler error for complicated PARAMETER expressions

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2008-04-01 07:29 ---
(In reply to comment #1)
> Confirm. This is a 4.3.x/4.4.0 regression
> 
> Fails: 2007-05-09-r124566
> Works: 2007-05-08-r124539
> 
> There are three checkins in that period, I think the following is most likely.
> I reverted that patch and then the test case passed.
> 
> r124541 | pault | 2007-05-08 13:58:25 +0200 (Tue, 08 May 2007) | 18 lines
> 2007-05-08  Paul Thomas  <[EMAIL PROTECTED]>
> 
> PR fortran/29397
> PR fortran/29400
> * decl.c (add_init_expr_to_sym): Expand a scalar initializer
> for a parameter array into an array expression with the right
> shape.
> * array.c (spec_dimen_size): Remove static attribute.
> * gfortran.h : Prototype for spec_dimen_size.
> 

Oh bother! - OK, I'll put the WHERE patch aside and the allocatable components
and get this one sorted.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-31 21:17:12 |2008-04-01 07:29:15
   date||


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

[Bug c++/33878] Pure virtual method body omitted from template

[herwig at gdsys dot de]

--- Comment #7 from herwig at gdsys dot de  2008-04-01 07:58 ---
(In reply to comment #5)
> (In reply to comment #0)
> > The following stripped down code shows pure virtual method definitions for 
> > both
> > a normal base class and a templated base class. To my surprise, the 
> > templated
> > class' body is not generated,
> 
> Your example code contains neither a call to TBase::pvMethod (which would
> trigger an implicit instantiation of this function from its template) nor an
> explicit instantiation of either the entire class or of this function.
> Consequently, the compiler doesn't instantiate your template.
> 
> If you intend to call TBase::pvMethod from somewhere where the definition
> of this template is not visible, you need to add an explicit instantiation of
> this function for 'int' as the template arg.
> 
> W.
> 

Wolfgang,

thanks for the clarification. I should have realized it myself, though. I
solved the problem in another way, but out of pure curiosity: How can I
implicitly instatiate this function when it's ought to be called only as a
fallback, in case something went wrong (bad cast, call to half-destroyed object
from another thread, etc.). It needs to be a generic solution as the real
application is a library base template derived from a normal base class used in
a CRTP-manner. I think that is why an implicit instantiation is needed. Or am I
wrong here? Probably I am. :)

Thanks for your reply,
Björn!


-- 


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

[Bug fortran/35786] New: OpenMP Fortran PRIVATE on parameter gives error in gfc_finish_var_decl

[J dot Hogg at rl dot ac dot uk]

Using the parameter ONE in the PRIVATE stanza of the parallel do in the below
code produces the shown error. This error only occurs if the subroutine is in a
module file.

[EMAIL PROTECTED] $ gfortran-4.3 -fopenmp -c test.f90
test.f90: In function ‘test’:
test.f90:8: internal compiler error: in gfc_finish_var_decl, at
fortran/trans-decl.c:510
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] $ cat test.f90
module testmod
  implicit none

  real, parameter :: one = 1.0

contains

subroutine test
integer i

real, dimension(4) :: a = (/ 1, 2, 3, 4 /)
real, dimension(4) :: b

!$OMP PARALLEL DO PRIVATE(I, ONE)
do i = 1,size(a)
  b(i) = one*a(i)
end do
!$OMP END PARALLEL DO

print *, "b = ", b
end subroutine test
end module
[EMAIL PROTECTED] $ gfortran-4.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --program-suffix=-4.3
Thread model: posix
gcc version 4.3.0 (GCC)


-- 
   Summary: OpenMP Fortran PRIVATE on parameter gives error in
gfc_finish_var_decl
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[d at domob dot eu]

--- Comment #15 from d at domob dot eu  2008-04-01 08:12 ---
The bootstrap problem is fixed, but with dynamic lengths I'm still struggling
;)
However, the following program without typespec in the array constructor also
fails (according to my judging what it should do) both with 4.3 and my
(patched) SVN version; I don't have access to an unpatched one:

PROGRAM test
  CALL foo (8, "short")
CONTAINS
  SUBROUTINE foo (n, s)
INTEGER :: n
CHARACTER(len=*) :: s
CHARACTER(len=n) :: arr(2)
arr = (/ 'test', s /)
WRITE (*,*) arr(1)
WRITE (*,*) arr(2)
WRITE (*,*) s
WRITE (*,*)
  END SUBROUTINE foo
END PROGRAM test

Is this anouther bug or do I misinterpret something?


-- 


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

[Bug libfortran/35471] libgfortran fails with nonstandard

[george at gcc dot gnu dot org]

--- Comment #7 from george at gcc dot gnu dot org  2008-04-01 08:24 ---
Can't verify that the patch provided works.  After three attempts at a build
(one just by patching libgfortran.h followed by a "make", one by "make
clean-target-libgfortran" followed by "make" and one built from scratch in an
empty object directory), all fail in a way similar as this (can't show initial
make commands because they overflow my 10,000 line default conversation
buffer):

...
.libs/in_unpack_generic.o: In function `putc_unlocked':
.libs/in_unpack_generic.o(.text+0x2220): multiple definition of `putc_unlocked'
.libs/backtrace.o(.text+0x27c0): first defined here
.libs/in_unpack_generic.o: In function `fputc_unlocked':
.libs/in_unpack_generic.o(.text+0x2280): multiple definition of
`fputc_unlocked'
.libs/backtrace.o(.text+0x2820): first defined here
.libs/in_unpack_generic.o: In function `putchar':
.libs/in_unpack_generic.o(.text+0x22e0): multiple definition of `putchar'
.libs/backtrace.o(.text+0x2880): first defined here
.libs/in_unpack_generic.o: In function `getchar_unlocked':
.libs/in_unpack_generic.o(.text+0x2310): multiple definition of
`getchar_unlocked'
.libs/backtrace.o(.text+0x28b0): first defined here
.libs/in_unpack_generic.o: In function `getc_unlocked':
.libs/in_unpack_generic.o(.text+0x2360): multiple definition of `getc_unlocked'
.libs/backtrace.o(.text+0x2900): first defined here
.libs/in_unpack_generic.o: In function `getchar':
.libs/in_unpack_generic.o(.text+0x23b0): multiple definition of `getchar'
.libs/backtrace.o(.text+0x2950): first defined here
.libs/in_unpack_generic.o: In function `vprintf':
.libs/in_unpack_generic.o(.text+0x23e0): multiple definition of `vprintf'
.libs/backtrace.o(.text+0x2980): first defined here
collect2: ld returned 1 exit status
gmake[3]: *** [libgfortran.la] Error 1
gmake[3]: Leaving directory
`/usr2/local/src/gcc-4.3-20080204/gcc-linux/i686-pc-linux-gnu/libgfortran'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/usr2/local/src/gcc-4.3-20080204/gcc-linux/i686-pc-linux-gnu/libgfortran'
gmake[1]: *** [all-target-libgfortran] Error 2
gmake[1]: Leaving directory `/usr2/local/src/gcc-4.3-20080204/gcc-linux'
gmake: *** [all] Error 2

gmake is GNU make 3.81 (if not used, the build fails due to outdated make
unable to cope with features of newer make versions)

configured with

../gcc/configure MAKE=gmake --enable-languages=fortran

gmp 4.2.2 configure: ./configure
mpfr 2.3.0 configure: ./configure LDFLAGS=-L/usr/local/lib


-- 


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

[Bug target/35419] [4.3/4.4 Regression] bfin libgcc build error

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu dot
   ||org
   Priority|P3  |P4


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

[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list

[reichelt at gcc dot gnu dot org]

--- Comment #3 from reichelt at gcc dot gnu dot org  2008-04-01 11:11 
---
i686-pc-linux-gnu or x86_64-unknown-linux-gnu (with -m32)


-- 


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

[Bug libfortran/35471] libgfortran fails with nonstandard

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2008-04-01 10:43 
---
(In reply to comment #7)
> .libs/in_unpack_generic.o: In function `putc_unlocked':
> .libs/in_unpack_generic.o(.text+0x2220): multiple definition of 
> `putc_unlocked'
> .libs/backtrace.o(.text+0x27c0): first defined here

That one is weird. Does the C compiler otherwise work OK? I'm wondering whether
some of your headers (the one that have putc_unlocked) are incorrectly
fixincluded.


-- 


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

[Bug tree-optimization/35776] Simple loop isn't optimized well

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-01 11:05 ---
4.3 produces

.L5:
callf
subl$1, %ebx
jne .L5

thus fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |tree-optimization
   Keywords||missed-optimization
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug middle-end/35781] [4.4 Regression]: Revision 133759 breaks ia64

[hubicka at gcc dot gnu dot org]

--- Comment #5 from hubicka at gcc dot gnu dot org  2008-04-01 08:41 ---
Subject: Bug 35781

Author: hubicka
Date: Tue Apr  1 08:41:14 2008
New Revision: 133786

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

PR middle-end/35781
* m32c/m32.c (m32c_leaf_function_p, m32c_function_needs_enter): Use
rtl.emit instead cfun->emit.
* sparc/sparc.h (INIT_EXPANDERS): Likewise.
* ia64/ia64.h (INIT_EXPANDERS): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64.h
trunk/gcc/config/m32c/m32c.c
trunk/gcc/config/sparc/sparc.h


-- 


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

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2008-04-01 10:17 ---
(In reply to comment #15)
> However, the following program without typespec in the array constructor also
> fails (according to my judging what it should do)

Different compilers give different output for this one, but this is no problem
as the program is invalid. "gfortran -fbounds-check" shows the problem:

Fortran runtime error: Different CHARACTER lengths (4/5) in array constructor

That is the reason why (/ typespec :: element-list /)  is needed. How long
should be each element for  (/ "a", "bb", "ccc" /) ? One, two, three or ...
characters? One could argue that is should match the longest, but this is an
arbitrary choice and makes the run-time array construction slower. Actually,
with the Intel compiler, 's, "test"' and '"test", s' produce different results
;-)


-- 


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

[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2008-04-01 10:28 ---
On i686-apple-darwin9, the failure occurs only in 32 bit mode (default). I also
occurs on powerpc-apple-darwin8.5.0:

http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00013.html


-- 


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

[Bug middle-end/35768] gcc.c-torture/compile/20010226-1.c:22: ICE: in do_output_reload, at reload1.c:7331

[rsandifo at nildram dot co dot uk]

--- Comment #6 from rsandifo at nildram dot co dot uk  2008-04-01 08:52 
---
Subject: Re:  gcc.c-torture/compile/20010226-1.c:22: ICE: in do_output_reload,
at reload1.c:7331

"dave at hiauly1 dot hia dot nrc dot ca" <[EMAIL PROTECTED]> writes:
>> I suppose the assumption in pa.md is that the scratch output reload
>> should be in the same mode as the input operand.
>
> I think the constraint should be changed from "=&0" to "+&0" to indicate
> that the operand is both read and written.  Possibly, this will fix the
> problem.

Well, "=" is correct for matching operands; "+" isn't.  As I say,
the problem is simply that we have something that is logically an
output value -- (scratch) -- but that does not have a mode.
Changing "=" to "+" wouldn't solve that; the (scratch) would
still be an output value.

Richard


-- 


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

[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-04-01 09:18 ---
Can't reproduce.  What target?


-- 


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

[Bug pch/13675] #including a precompiled header more than once in the same unit fails

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2008-04-01 10:58 ---
Subject: Bug 13675

Author: jakub
Date: Tue Apr  1 10:58:02 2008
New Revision: 133790

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133790
Log:
PR pch/13675
* files.c (struct _cpp_file): Remove pch field.
(pch_open_file): Don't set file->pch, just file->pchname.
(should_stack_file): After pfile->cb.read_pch call
free pchname and clear pchname, don't close file->fd.
Test file->pchname instead of file->pch.  Don't close fd after cb.
(_cpp_stack_include): Test file->pchname instead of file->pch.

* c-pch.c (c_common_read_pch): On error close (fd) resp. fclose (f).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-pch.c
trunk/libcpp/ChangeLog
trunk/libcpp/files.c


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #11 from oblivian at users dot sourceforge dot net  2008-04-01 
10:24 ---
(In reply to comment #10)
> Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
>  source tree doesn't bootstrap
> # When ld-new is first executed from the build tree, libtool
> # will relink it as .libs/lt-ld-new, so that it can give it
> # an RPATH that refers to the build tree.  While doing this
> # we need to use the previous-stage linker, or we have an infinite
> # loop.

That doesn't make sense from what I'm seeing, so either I need to reopen the
bug that I submitted or we are headed down the wrong path.

The stage 1 ld works as far as linking the stage 1 gcc which is directly after
it.  It's only when we get to stage 2 that things break.  If the above were
true, I would not be able to get to stage 2 since the stage 1 ld would have to
use the host ld to link itself and from the logs I have...

>From stage 1 gcc configure output:
checking what linker to use... newly built ld
And gcc stage 1 compiles and links.

Beyond this, I will reiterate that I can do a complete bootstrap of the 4.3.0
compiler in phase 1, without this patch, and it completes building all stages
and works.  The compiler in phase 2 of the build, when linking against
libraries not in the root /lib and /usr/lib directories is what is confusing
the stage 2 programs and not allowing it to work.

It appears after more searching that binutils configure scripts are trying to
pull the sys_lib_search_path_spec variable from the stage 1 xgcc for all stage
2 programs, and that stage 1 gcc is building and linking against correct
library paths, but not incorporating those paths into it's output for
-print-search-dirs.  Since it doesn't have these paths correctly
sys_lib_search_path_spec is set incorrectly by stage 2 configure in ld and
libtool gets generated with incorrect library paths thus infecting itself with
the host libraries and causing havoc to ensue with the build.

So to summarize what I see:

Stage 1 ld is built against /tools/lib libraries
Stage 1 gcc is built against /tools/lib libraries, but doesn't output these
paths with -print-search-dirs
Stage 2 ld is build using mixed paths from stage 1 gcc and the environment and
tries to link against /lib libraries which apparently causes it to go nuts
since everything it is built with is trying for /tools/lib or the recursive
loop is libtool flip flopping between linking to /lib then to /tools/lib
without making up it's mind.


-- 


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

[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-04-01 09:39 ---
The test fails on i686-apple-darwin9 at revision 133785:

FAIL: gcc.dg/pr35729.c scan-rtl-dump-times loop2_invariant "Decided to move
invariant" 0


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

--- Comment #12 from bonzini at gnu dot org  2008-04-01 11:21 ---
I think there are two bugs.  One is the infinite loop, and H.J.'s patch is
"masking" it by patching gcc/exec-tool.in (which is why I'd prefer to have the
"masking" in ld/Makefile.am).  The other is yours, which does not have anything
to do with the infinite loop AFAICS.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

--- Comment #14 from bonzini at gnu dot org  2008-04-01 11:54 ---
hm, I see now.  H.J. hold on.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #13 from oblivian at users dot sourceforge dot net  2008-04-01 
11:51 ---
(In reply to comment #12)
> I think there are two bugs.  One is the infinite loop, and H.J.'s patch is
> "masking" it by patching gcc/exec-tool.in (which is why I'd prefer to have the
> "masking" in ld/Makefile.am).  The other is yours, which does not have 
> anything
> to do with the infinite loop AFAICS.
> 
I too have an infinite loop at stage 2 "gcc" which is the linker calling itself
recursively, but as you can see from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35451, I've been tracing the route
of the problem.  I agree that the patch is "masking" the problem, but I still
think it's a change to gcc that is causing binutils breakage.  This may need to
be fixed in binutils, but right now I need to figure out what changed in gcc.

I did forget to mention the following last night as well...
I ran a bootstrap with H.J's patch and it compiles through, but is pulling host
libraries.
I also ran a profiledbootstrap with H.J.'s patch and it can't find newer gcov_
symbols since it appears to no longer be linking with the latest 4.3.0
libraries and trying against older 4.1.2 gcc libraries.

After some stuff I've done this morning, I think it is most definitely related
to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 and the search path
cleanup on the 4.3.0 branch.  I applied the patch as a test, and now I get a
/tools/usr/lib directory in the sys_lib_search_path_dirs of my binutils libtool
files BEFORE the standard /lib /usr/lib.  I think to fix both problems someone
needs to describe the "correct" way of providing the retargeted search paths to
the binutils configure scripts for stage 2 and beyond.  And sysroot is just
broken for this at this point, I went through multiple iterations of sysroot
trials with no success.

I tried adding BOOT_LDFLAGS=-B/tools/usr/lib -B/tools/lib to and passing
BOOT_CFLAGS with the same as well and they don't make it to the binutils
program configure scripts.

Any insight is appreciated.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #15 from oblivian at users dot sourceforge dot net  2008-04-01 
11:57 ---
In fact the more I think about it, the search path clean up is what has
definitely got to be killing this build.  The binutils configure scripts rely
on the retargeted search paths to come from the previous stage gcc, which have
now been removed.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

--- Comment #16 from bonzini at gnu dot org  2008-04-01 12:08 ---
> The stage 1 ld works as far as linking the stage 1 gcc which is directly after
> it.  It's only when we get to stage 2 that things break. 

This is a red herring.  stage 1 ld goes through the same relink process, but it
uses the host ld to do that (no problem).  stage 2 ld adds a further
indirection through stage 1's gcc/collect-ld, which is a small script to
discern between when to use prev-ld/ld-new and when to use ld/ld-new; the
presence of a shell script as ld/ld-new, and the fact that the script *uses ld
itself*, is what confuses the gcc/collect-ld script.

So H.J.'s patch in some sense is right, because it fixes the "buggy" script. 
The reason I'd prefer ld to be patched is that H.J.'s fix is a tad brittle and
susceptible to changes in libtool; avoiding the one-time relinking is simpler. 
But OTOH, until the patched ld/Makefile.am goes into a released version there
is no way to bootstrap a gcc+binutils tree. :-(  I'll make up my mind soon.

Anyway, any other problem you have regarding search paths, as I said, a second
bug, and one that should not cause any kind of infinite loop.  We have to fix
that one too, of course, but let's sort out this one first, please.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-01 12:08:52
   date||


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #17 from oblivian at users dot sourceforge dot net  2008-04-01 
12:14 ---
I understand the difference now, and thanks.

Still not sure why I can make it through the whole host bootstrap phase without
his patch though.  Maybe a 4.4 specific change issue?

Let me know if you open a second bug on my issue.


-- 


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

[Bug c++/33878] Pure virtual method body omitted from template

[bangerth at math dot tamu dot edu]

--- Comment #8 from bangerth at math dot tamu dot edu  2008-04-01 12:52 
---
Subject: Re:  Pure virtual method body omitted from template


> thanks for the clarification. I should have realized it myself, though. I
> solved the problem in another way, but out of pure curiosity: How can I
> implicitly instatiate this function

That's a self-contradiction. The term "implicit instantiation" refers to 
something that the compiler does without any explicit user request, so 
there is no way to "implicitly instatiate this function yourself" :-)

You could explicitly instantiate this function, but...

> It needs to be a generic solution

The only possibility in this case would be to put the function into your 
header file. I believe that that should work in your case.

Best
 Wolfgang

-
Wolfgang Bangerthemail:[EMAIL PROTECTED]
 www: http://www.math.tamu.edu/~bangerth/


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #19 from oblivian at users dot sourceforge dot net  2008-04-01 
12:40 ---
(In reply to comment #18)
> Created an attachment (id=15402)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15402&action=view) [edit]
> my version of H.J.'s patch
> 
> I think this is the right way to do it, more or less.
> 
> Can anyone test it?  (I don't have binutils checked out right now...)
> 
> You have to run autoconf too.
> 
Yeah I'll apply it now, hold on for about 4 hours.


-- 


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

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[d at domob dot eu]

--- Comment #17 from d at domob dot eu  2008-04-01 12:53 ---
I see, thanks!  I thought it would be the longest length (i.e., clipped by the
array definition assigned to).


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

--- Comment #18 from bonzini at gnu dot org  2008-04-01 12:33 ---
Created an attachment (id=15402)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15402&action=view)
my version of H.J.'s patch

I think this is the right way to do it, more or less.

Can anyone test it?  (I don't have binutils checked out right now...)

You have to run autoconf too.


-- 


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

[Bug fortran/35786] OpenMP Fortran PRIVATE on parameter gives error in gfc_finish_var_decl

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-04-01 13:22 ---
Thanks for the report; the internal compiler error is definitely a compiler
bug. However, I believe the program is invalid.

If I read "2.8.3.3 private clause" in the OpenMP 2.5 specification correctly,
the items in the private(list) need to variables which are definable or
allocatable. However, "ONE" is not even a variable. Thus the program is
invalid. However, an error message such as the one of sunf95 should be given
instead of an ICE.


sunf95 writes:
!$OMP PARALLEL DO PRIVATE(I, ONE)
 ^
"dfff.f90", Line = 14, Column = 34: ERROR: Object ONE must be a variable to be
in the PRIVATE clause of the PARALLEL DO directive.

ifort writes:
!$OMP PARALLEL DO PRIVATE(I, ONE)
-^
fortcom: Error: dfff.f90, line 14: Subobjects are not allowed in this OpenMP
clause; a named variable must be specified.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic, ice-on-invalid-
   ||code, openmp
   Last reconfirmed|-00-00 00:00:00 |2008-04-01 13:22:13
   date||


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

[Bug target/23482] [ColdFire] ICE in in final_scan_insn

[schwab at suse dot de]

--- Comment #9 from schwab at suse dot de  2008-04-01 13:29 ---
Fixed in 4.3, wontfix for the older versions.


-- 

schwab at suse dot de changed:

   What|Removed |Added

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


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

[Bug middle-end/23458] ICE on m68k (-O3)

[schwab at suse dot de]

--- Comment #3 from schwab at suse dot de  2008-04-01 13:24 ---
This is no longer reproducible, closing as fixed.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-04-01 13:31 ---
Testing a patch with a langhook.


-- 

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 |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-29 18:55:45 |2008-04-01 13:31:20
   date||


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

[Bug target/23695] [ColdFire] Illegal move of byte intoo address register causes compiler to ICE

[schwab at suse dot de]

--- Comment #5 from schwab at suse dot de  2008-04-01 13:32 ---
No longer reproducible with 4.3.


-- 

schwab at suse dot de changed:

   What|Removed |Added

  Known to work||4.3.0


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

[Bug target/25343] [4.1/4.2/4.3/4.4 regression] [m68k] testsuite failures

[schwab at suse dot de]

--- Comment #6 from schwab at suse dot de  2008-04-01 13:34 ---
WONTFIX for the pch issue.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/35788] New: MIPS stack overflow caused by addui instruction

[derrick_chi at msn dot com]

Hello 

   I am using the latest version of cygwin to compile c++ programs into to
mips-elfs, and I have several serious problems.  One in particular is that fact
that the allocation and deallocation of memory on the stack for function and
procedure calls is not done correctly.  For some reason the compiler allocates
memory on the stack by issuing a Addui sp,sp with some negative number, however
the negative number is only sixteen bits and therefore because the instruction
is an add unsigned immediate this negative number gets treated like a positve
number.  Now once the statements in the function have been executed, you get to
the code which attempts to deallocate the space on the stack which was
allocated at the beginning, well the compiler does this by issuing another
addui but this time using the positve version of the number which was used
before, well this part would work just fine if the prior allocation had been
done with an add immediate instruction but because it doesn't what happens is
the stack grows a little more now you can imagine this can become a problem
very quickly, causing stack overflow.  I have pasted in some dissasembly code
below for you guys to take a look just look at any one of the function at the
allocation and deallocation of memory on the stack and you'll see it.


senchk.bin: file format elf32-tradbigmips

Disassembly of section .text:

 :
start():
   0:   201c2fa8addigp,zero,12200
   4:   0c00010fjal 43c 
   8:   nop

000c <_exit>:
   c:   1000    

0014 <_Z10delay_funcii>:
_Z10delay_funcii():
/cygdrive/c/users/TheOne1/sde-6.06/sde/examples/Init_Program/DELAY_FUNC.H:5
#ifndef _DELAY_FUNC_H_
#define _DELAY_FUNC_H_

void delay_func (int delay_count, int time_scale)
{
  14:   27bdfff0addiu   sp,sp,-16
  18:   afbe0008sw  s8,8(sp)
  1c:   03a0f021moves8,sp
  20:   afc40010sw  a0,16(s8)
  24:   afc50014sw  a1,20(s8)
/cygdrive/c/users/TheOne1/sde-6.06/sde/examples/Init_Program/DELAY_FUNC.H:8
int delay_counter;

if ( time_scale == 1 ) {
  28:   8fc30014lw  v1,20(s8)
  2c:   24020001li  v0,1
  30:   14620018bne v1,v0,94 <_Z10delay_funcii+0x80>
  34:   nop
/cygdrive/c/users/TheOne1/sde-6.06/sde/examples/Init_Program/DELAY_FUNC.H:11


delay_counter = 0;
  38:   afc0sw  zero,0(s8)
/cygdrive/c/users/TheOne1/sde-6.06/sde/examples/Init_Program/DELAY_FUNC.H:12
while ( delay_counter != delay_count * 500 ) {   // changed
from 5000 to 500 because the time was too long, it exceed a second by
about 6 times
  3c:   8fc40010lw  a0,16(s8)
  40:   nop
  44:   00801021movev0,a0
  48:   00021940sll v1,v0,0x5
  4c:   00641823subuv1,v1,a0
  50:   00031180sll v0,v1,0x6
  54:   00431023subuv0,v0,v1
  58:   000210c0sll v0,v0,0x3
  5c:   00441021adduv0,v0,a0
  60:   00021880sll v1,v0,0x2
  64:   00431021adduv0,v0,v1
  68:   00021980sll v1,v0,0x6
  6c:   8fc2lw  v0,0(s8)
  70:   nop
  74:   10620052beq v1,v0,1c0 <_Z10delay_funcii+0x1ac>
  78:   nop
/cygdrive/c/users/TheOne1/sde-6.06/sde/examples/Init_Program/DELAY_FUNC.H:14

delay_counter ++;
  7c:   8fc2lw  v0,0(s8)
  80:   nop
  84:   24420001addiu   v0,v0,1
  88:   afc2sw  v0,0(s8)
  8c:   1000ffebb   3c <_Z10delay_funcii+0x28>
  90:   nop
/cygdrive/c/users/TheOne1/sde-6.06/sde/examples/Init_Program/DELAY_FUNC.H:18

}

} else if ( time_scale == 2 ) {
  94:   8fc30014lw  v1,20(s8)
  98:   24020002li  v0,2
  9c:   14620016bne v1,v0,f8 <_Z10delay_funcii+0xe4>
  a0:   nop
/cygdrive/c/users/TheOne1/sde-6.06/sde/examples/Init_Program/DELAY_FUNC.H:21


delay_counter = 0;
  a4:   afc0sw  zero,0(s8)
/cygdrive/c/users/TheOne1/sde-6.06/sde/examples/Init_Program/DELAY_FUNC.H:22
while ( delay_counter != delay_count * 5000 ) {
  a8:   8fc30010lw  v1,16(s8)
  ac:   nop
  b0:   00601021movev0,v1
  b4:   00021080sll v0,v0,0x2
  b8:   00431021adduv0,v0,v1
  bc:   000210c0sll v0,v0,0x3
  c0:   00431023subuv0,v0,v1
  c4:   00021100sll v0,v0,0x4
  c8:   00431021adduv0,v0,v1
  cc:   000218c0sll v1,v0,0x3
  d0:   8fc2lw  v0,0(s8)
  d4:   nop
  d8:   10620039beq v1,v0,1c0 <_Z10delay_funcii+0x1ac>
  dc:   nop
/cygdrive/c/users/TheOne1/sde-6.06/sde/examples/

[Bug c++/35788] MIPS stack overflow caused by addui instruction

[derrick_chi at msn dot com]

--- Comment #2 from derrick_chi at msn dot com  2008-04-01 14:27 ---
Created an attachment (id=15404)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15404&action=view)
C++ function


-- 


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

[Bug c++/35788] MIPS stack overflow caused by addui instruction

[derrick_chi at msn dot com]

--- Comment #3 from derrick_chi at msn dot com  2008-04-01 14:27 ---
Created an attachment (id=15405)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15405&action=view)
global variables .h file


-- 


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

[Bug c++/35788] MIPS stack overflow caused by addui instruction

[derrick_chi at msn dot com]

--- Comment #4 from derrick_chi at msn dot com  2008-04-01 14:28 ---
Created an attachment (id=15406)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15406&action=view)
delay function


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #21 from oblivian at users dot sourceforge dot net  2008-04-01 
13:53 ---
(In reply to comment #20)
> if it reaches the end of ld compilation in stage2, that's already enough.  
> (and
> less than 4 hours).
> 

Sorry, but for me to test it I have to wait until the pass 2 compiler, since
that's the one that breaks.  So I can at least tell you it didn't break the
pass 1 compiler in < 4 hours.  Of course I've already had to restart the build
5 times to get my scripts to run autoconf in the gcc subdirectory so we'll see
how long it takes to get through pass 1 (i just restarted the build hopefully
for the last time).


-- 


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

[Bug fortran/35786] OpenMP Fortran PRIVATE on parameter gives error in gfc_finish_var_decl

[J dot Hogg at rl dot ac dot uk]

--- Comment #2 from J dot Hogg at rl dot ac dot uk  2008-04-01 14:13 ---
(In reply to comment #1)
> Thanks for the report; the internal compiler error is definitely a compiler
> bug. However, I believe the program is invalid.

I know the program is invalid (thought that went without saying, I should
probably be more verbose in the future), it was more of a feature request for a
nice error message.

Thanks for your help,
Jonathan.


-- 


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

[Bug c++/35788] MIPS stack overflow caused by addui instruction

[derrick_chi at msn dot com]

--- Comment #1 from derrick_chi at msn dot com  2008-04-01 14:26 ---
Created an attachment (id=15403)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15403&action=view)
C++ code 


-- 


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

[Bug c++/35788] MIPS stack overflow caused by addui instruction

[derrick_chi at msn dot com]

--- Comment #5 from derrick_chi at msn dot com  2008-04-01 14:28 ---
Created an attachment (id=15407)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15407&action=view)
i2c function


-- 


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

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[burnus at gcc dot gnu dot org]

--- Comment #18 from burnus at gcc dot gnu dot org  2008-04-01 14:18 ---
> I see, thanks!  I thought it would be the longest length (i.e., clipped by the
> array definition assigned to).

For completeness: See "4.7 Construction of array values" in the Fortran 2003
standard (http://gcc.gnu.org/wiki/GFortranStandards). There one finds:

"C494 (R466) If type-spec is omitted, each ac-value expression in the
array-constructor shall have the same type and kind type parameters."

This does not apply yet as we have everywhere default-kind character variables.
But it continues a few lines later as follows (note the "same length type
parameter"):

"If type-spec is omitted, each ac-value expression in the array constructor
shall have the same length type parameters; in this case, the type and type
parameters of the array constructor are those of the ac-value expressions.

"If type-spec appears, it specifies the type and type parameters of the array
constructor. Each ac-value expression in the array-constructor shall be
compatible with intrinsic assignment to a variable of this type and type
parameters.[...]"


In general, it is quite helpful to look at the specification in the Fortran
standard, when one implements something. (Although it takes some time to get
somewhat used to the standard; still I find it quite readable.) A Fortran
textbook or Reid's F2003 intro
(ftp://ftp.nag.co.uk/sc22wg5/N1601-N1650/N1648.pdf) are helpful, but at the end
the standard is the only official and definite reference. If you need
interpretation help or help searching, write me an email (or try the IRC, link
see http://gcc.gnu.org/wiki/GFortran). It if gets too difficult, one ends up
asking at comp.lang.fortran or even requesting an official interpretation (cf.
PR 34805).


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

--- Comment #20 from bonzini at gnu dot org  2008-04-01 13:49 ---
if it reaches the end of ld compilation in stage2, that's already enough.  (and
less than 4 hours).


-- 


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

[Bug tree-optimization/35787] [4.4 Regression]: Revision 133680 breaks 447.dealII

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-01 14:11 ---
I probably already have a fix.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-01 14:11:19
   date||
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/35787] New: [4.4 Regression]: Revision 133680 breaks 447.dealII

[hjl dot tools at gmail dot com]

Revision 133680 breaks 447.dealII in SPEC CPU 2006:

error_estimator.cc: In static member function 'static void
KellyErrorEstimator::integrate_over_irregular_face(const DoFHandler&,
const Quadrature<(dim - 1)>&, const std::vector >&, const std::vector >&, const Function*, std::map::face_iterator, std::vector >,
std::less::face_iterator>,
std::allocator::face_iterator,
std::vector > > > >&,
KellyErrorEstimator::PerThreadData&, const typename
DoFHandler::active_cell_iterator&, unsigned int, FEFaceValues&,
FESubfaceValues&) [with InputVector = BlockVector, int dim = 3]':
error_estimator.cc:801: internal compiler error: in set_value_range, at
tree-vrp.c:347


-- 
   Summary: [4.4 Regression]: Revision 133680 breaks 447.dealII
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/33878] Pure virtual method body omitted from template

[herwig at gdsys dot de]

--- Comment #9 from herwig at gdsys dot de  2008-04-01 14:38 ---
(In reply to comment #8)
> Subject: Re:  Pure virtual method body omitted from template
> 
> 
> > thanks for the clarification. I should have realized it myself, though. I
> > solved the problem in another way, but out of pure curiosity: How can I
> > implicitly instatiate this function
> 
> That's a self-contradiction. The term "implicit instantiation" refers to 
> something that the compiler does without any explicit user request, so 
> there is no way to "implicitly instatiate this function yourself" :-)

Great, I already had the feeling my brain dead-locked when thinking about a
solution. :)

> You could explicitly instantiate this function, but...
> 
> > It needs to be a generic solution
> 
> The only possibility in this case would be to put the function into your 
> header file. I believe that that should work in your case.

Okay, you mean in the header file where I derive a class from TBase. There I'll
write something like:

class MyClass : public TBase
{
// My class goes here, espacially overiding pvMethod()...
};

void TBase::pvMethod()
{
// Not so generic dummy function
// Copy and paste error handling here ;)
}

Not exactly what I wanted...

Or did you mean that the function definition is in the TBase header file? If
so: It is.

Thanks for your kind help!

Regards,
Björn!


-- 


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

[Bug c++/33878] Pure virtual method body omitted from template

[bangerth at math dot tamu dot edu]

--- Comment #10 from bangerth at math dot tamu dot edu  2008-04-01 14:44 
---
Subject: Re:  Pure virtual method body omitted from template


> Or did you mean that the function definition is in the TBase header file? If
> so: It is.

Yes. Since the class declaration must be visible from the place where you 
call this function, and since then also the function's definition 
(=implementation) is visible, the template should be instantiated at the 
place where you call the member function. Is this not the case?

Best
 W.

-
Wolfgang Bangerthemail:[EMAIL PROTECTED]
 www: http://www.math.tamu.edu/~bangerth/


-- 


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

[Bug tree-optimization/35787] [4.4 Regression]: Revision 133680 breaks 447.dealII

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2008-04-01 14:57 ---
Subject: Re:  [4.4 Regression]: Revision 133680
 breaks 447.dealII

On Tue, 1 Apr 2008, bangerth at dealii dot org wrote:

> --- Comment #2 from bangerth at dealii dot org  2008-04-01 14:54 ---
> (In reply to comment #0)
> > error_estimator.cc: In static member function 'static void
> > KellyErrorEstimator::integrate_over_irregular_face(const 
> > DoFHandler&,
> > const Quadrature<(dim - 1)>&, const std::vector > std::allocator >&, const std::vector > std::allocator >&, const Function*, std::map > DoFHandler::face_iterator, std::vector 
> > >,
> > std::less::face_iterator>,
> > std::allocator::face_iterator,
> > std::vector > > > >&,
> > KellyErrorEstimator::PerThreadData&, const typename
> > DoFHandler::active_cell_iterator&, unsigned int, FEFaceValues&,
> > FESubfaceValues&) [with InputVector = BlockVector, int dim = 
> > 3]':
> > error_estimator.cc:801: internal compiler error: in set_value_range, at
> > tree-vrp.c:347
> 
> I'm the guy responsible for this, uh, let's say: awkward, function signature.
> I'm sorry you had to hit this error in the function with the worst number
> of arguments in all of 447.dealII :-)

Then you obviously never saw signatures of tramp3d :-)

Richard.


-- 


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

[Bug tree-optimization/35787] [4.4 Regression]: Revision 133680 breaks 447.dealII

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2008-04-01 14:54 ---
(In reply to comment #0)
> error_estimator.cc: In static member function 'static void
> KellyErrorEstimator::integrate_over_irregular_face(const 
> DoFHandler&,
> const Quadrature<(dim - 1)>&, const std::vector std::allocator >&, const std::vector std::allocator >&, const Function*, std::map DoFHandler::face_iterator, std::vector >,
> std::less::face_iterator>,
> std::allocator::face_iterator,
> std::vector > > > >&,
> KellyErrorEstimator::PerThreadData&, const typename
> DoFHandler::active_cell_iterator&, unsigned int, FEFaceValues&,
> FESubfaceValues&) [with InputVector = BlockVector, int dim = 3]':
> error_estimator.cc:801: internal compiler error: in set_value_range, at
> tree-vrp.c:347

I'm the guy responsible for this, uh, let's say: awkward, function signature.
I'm sorry you had to hit this error in the function with the worst number
of arguments in all of 447.dealII :-)

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org


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

[Bug tree-optimization/9079] [tree-ssa] Inline constant function pointers

[jamborm at gcc dot gnu dot org]

--- Comment #18 from jamborm at gcc dot gnu dot org  2008-04-01 14:50 
---
I'm now working on a proper fix.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-03-01 02:53:11 |2008-04-01 14:50:54
   date||


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

[Bug tree-optimization/35787] [4.4 Regression]: Revision 133680 breaks 447.dealII

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-01 15:14 ---
Btw, I don't see this error in our runs - what flags do you use for
compilation?
Which target is affected and can you attach preprocessed source?


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #22 from oblivian at users dot sourceforge dot net  2008-04-01 
15:30 ---
Doesn't work.  In my setup enable-fast-install is not getting set, but the
prev-ld is generating an lt-ld-new, so it assumes it should use the current ld
instead of the prev-ld binary.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

--- Comment #23 from bonzini at gnu dot org  2008-04-01 15:36 ---
and if you modify collect-ld manually to set it to yes?


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #24 from oblivian at users dot sourceforge dot net  2008-04-01 
15:39 ---
(In reply to comment #23)
> and if you modify collect-ld manually to set it to yes?
> 
Sure that works, but doesn't that defeat the purpose? :)


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #25 from oblivian at users dot sourceforge dot net  2008-04-01 
15:41 ---
(In reply to comment #24)
> (In reply to comment #23)
> > and if you modify collect-ld manually to set it to yes?
> > 
> Sure that works, but doesn't that defeat the purpose? :)
> 
How about changing it to != no?


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[Ralf dot Wildenhues at gmx dot de]

--- Comment #26 from Ralf dot Wildenhues at gmx dot de  2008-04-01 15:42 
---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc +
binutils source tree doesn't bootstrap

* bonzini at gnu dot org wrote on Tue, Apr 01, 2008 at 05:36:52PM CEST:
> --- Comment #23 from bonzini at gnu dot org  2008-04-01 15:36 ---
> and if you modify collect-ld manually to set it to yes?

fast-install cannot work on all systems, and does not work on some where
it could be made to.  What I suggesteded was to use -no-fast-install:
you do not want the relink to happen for the execution of the
uninstalled program.

Sorry, I cannot look into this until later.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

--- Comment #27 from bonzini at gnu dot org  2008-04-01 15:42 ---
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap

oblivian at users dot sourceforge dot net wrote:
> --- Comment #24 from oblivian at users dot sourceforge dot net  
> 2008-04-01 15:39 ---
> (In reply to comment #23)
>> and if you modify collect-ld manually to set it to yes?
>>
> Sure that works, but doesn't that defeat the purpose? :)

Gives me enough context to commit a patch that actually works.

Paolo


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[hjl dot tools at gmail dot com]

--- Comment #28 from hjl dot tools at gmail dot com  2008-04-01 15:49 
---
Created an attachment (id=15408)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15408&action=view)
A setup for combined gcc/binutils source tree

This is the setup to create a combined gcc/binutils source tree. You
can use it to verify if bootstrap works.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[hjl dot tools at gmail dot com]

--- Comment #29 from hjl dot tools at gmail dot com  2008-04-01 15:50 
---
(In reply to comment #27)
> 
> Gives me enough context to commit a patch that actually works.
> 
> Paolo
> 

Please get

http://gcc.gnu.org/bugzilla/attachment.cgi?id=15408

and create a combined gcc/binutils source tree to verify your patch. Thanks.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[bonzini at gnu dot org]

--- Comment #30 from bonzini at gnu dot org  2008-04-01 16:11 ---
Created an attachment (id=15409)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15409&action=view)
new patch

@Ralf: yes, I understood that (I just wanted to understand if the failure was
just that my way of setting enable_fast_install was too hacky).

This patch should work.  It creates a good collect-ld for me.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Attachment #15402|0   |1
is obsolete||


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

[Bug c/35592] Want attribute to enable precision loss warning

[felix-gcc at fefe dot de]

--- Comment #4 from felix-gcc at fefe dot de  2008-04-01 16:09 ---
I'm not familiar enough with how gcc works to say whether warning about
precision loss that turns out important later on can be done at all.

But I think we should not reject an idea because it only handles 60% of the
cases.  Instead we should be happy we only have to worry about the other 40%,
not about 100% from then on.

I agree that signed int to size_t conversion for memcpy should also be warned
about by some attribute.  Could be done by the same attribute.


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #31 from oblivian at users dot sourceforge dot net  2008-04-01 
16:44 ---
(In reply to comment #30)
> Created an attachment (id=15409)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15409&action=view) [edit]
> new patch
> 
> @Ralf: yes, I understood that (I just wanted to understand if the failure was
> just that my way of setting enable_fast_install was too hacky).
> 
> This patch should work.  It creates a good collect-ld for me.
> 

Nope

/build/scripts/tools/toolchain-pass-2/build/gcc/../prev-binutils/nm-new: cannot
execute: No such file or directory
No symbols seen -- broken or mis-installed nm?

This was in libgcc before the stage 1 directories are moved to prev-


-- 


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

[Bug middle-end/35781] [4.4 Regression]: Revision 133759 breaks ia64

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-04-01 16:51 ---
Revision 133786 doesn't work for C++:

libtool: compile:  /export/build/gnu/gcc/build-ia64-linux/./gcc/xgcc
-shared-libgcc -B/export/build/gnu/gcc/build-ia64-linux/./gcc -nostdinc++
-L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src
-L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/gcc-4.4/ia64-unknown-linux-gnu/bin/
-B/usr/gcc-4.4/ia64-unknown-linux-gnu/lib/ -isystem
/usr/gcc-4.4/ia64-unknown-linux-gnu/include -isystem
/usr/gcc-4.4/ia64-unknown-linux-gnu/sys-include
-I/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/include/ia64-unknown-linux-gnu
-I/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/include
-I/net/gnu-13/export/gnu/src/gcc/gcc/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -c
/net/gnu-13/export/gnu/src/gcc/gcc/libstdc++-v3/src/allocator-inst.cc  -fPIC
-DPIC -o .libs/allocator-inst.o
/net/gnu-13/export/gnu/src/gcc/gcc/libstdc++-v3/src/strstream.cc: In destructor
'virtual std::ostrstream::~ostrstream()':
/net/gnu-13/export/gnu/src/gcc/gcc/libstdc++-v3/src/strstream.cc:374: internal
compiler error: in prepare_function_start, at function.c:3943 
Please submit a full bug report, 
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [strstream.lo] Error 1 


-- 


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

[Bug middle-end/35781] [4.4 Regression]: Revision 133759 breaks ia64

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2008-04-01 16:52 ---
(In reply to comment #4)
> Created an attachment (id=15400)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15400&action=view) [edit]
> patch for cfun->emit rtl.emit changes
> 
> I tested this patch with a C only bootstrap on an ia64-linux system.  The 
> bootstrap completed successfully.
> 

Jim, your patch may not work for C++.


-- 


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

[Bug ada/35789] Ada2WSDL

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gcc-bugs at gcc dot gnu dot
   ||org


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

[Bug ada/35789] Ada2WSDL

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-01 17:21 ---
Can you read http://gcc.gnu.org/bugs.html and provide the rest of the
information?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/35788] MIPS stack overflow caused by addui instruction

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-04-01 17:36 ---
Can you provide the preprocessed source and also the exact version of GCC you
are using?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
 Status|UNCONFIRMED |WAITING
  Component|c++ |target
 GCC target triplet||mips-elf


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

[Bug target/35713] [4.4 Regression] invalid type for va_arg with _Decimal128

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2008-04-01 17:58 ---
For powerpc-linux this affects _Decimal128, 128-bit long double, and _Complex
double.  I'm testing a patch.


-- 


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

[Bug target/25343] [4.1/4.2/4.3/4.4 regression] [m68k] testsuite failures

[zippel at gcc dot gnu dot org]

--- Comment #7 from zippel at gcc dot gnu dot org  2008-04-01 17:53 ---
Actually for the PCH issue there is a fix:

http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01607.html


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #24 from joel at gcc dot gnu dot org  2008-04-01 18:02 ---
With Laurent's test program, I have traces of good (powerpc/psim) and bad
(qemu) runs.  The traced include only entry and exit status info for the
following calls are:


_CPU_Context_switch
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_signal
pthread_cond_timedwait
pthread_cond_wait
pthread_create
pthread_exit
pthread_getschedparam
pthread_mutex_destroy
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_timedlock
pthread_mutex_unlock
pthread_setschedparam
rtems_stack_checker_is_blown
rtems_task_create

There are two anomalies in the i386 run:

The first call to pthread_setschedparam() returns EINVAL because it is passed a
sched_param with priority == 0.  This field is 122 on the valid psim run. 
Backtrace indicates we are still in initialization.  I do not know how to tell
where the 0 came from before here. 

#2  0x0010153f in system.task_primitives.operations.set_priority (t=0x1dbb38, 
prio=0, loss_of_inheritance=0) at s-taprop.adb:764
#3  0x0010451d in system.tasking.initialize () at s-taskin.adb:188
#4  0x00103fc8 in system.tasking.initialization.init_rts () at s-tasini.adb:322
#5  0x0010032b in adainit ()


Later there is a pthread_mutex_unlock() call which passes in a bad mutex id. 
This does not occur on the psim run.

The bad pthread_setschedparam call is not THAT far into the execution and the
traced calls up until this point are the same.

ENTER pthread_create
EXIT pthread_create (0)
ENTER _CPU_Context_switch
ENTER pthread_create
EXIT pthread_create (0)
ENTER pthread_exit
ENTER _CPU_Context_switch
ENTER pthread_mutex_init
EXIT pthread_mutex_init (0)
ENTER pthread_cond_init
EXIT pthread_cond_init (0)
ENTER pthread_mutex_init
EXIT pthread_mutex_init (0)
ENTER pthread_mutex_lock
EXIT pthread_mutex_lock (0)
ENTER pthread_mutex_unlock
EXIT pthread_mutex_unlock (0)
ENTER pthread_setschedparam


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #32 from oblivian at users dot sourceforge dot net  2008-04-01 
18:55 ---
(In reply to comment #30)
> This patch should work.  It creates a good collect-ld for me.
> 

How about a simple change without the whole fast-install patch.

if test -x $scriptdir/../prev-$dir/$prog; then
  exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
else
  exec $scriptdir/../$dir/$prog ${1+"$@"}
fi

Thats it.  Just prefer the use of the previous stage utilities. No worrying
about the state of the current stage utilities.  Unless I'm missing something
(e.g. internal gcc reasons) doesn't this meet the primary requirement
bootstrapping the compiler (i.e. building the current stage with the previous)
and prevents mixing partially finished utilities inside the stage?
It also keeps the exec-tool.in script clean from specialized code depending on
the target it's being run as (well except for the invoke case statement at the
top).

I'm currently through stage 2 with this simple change to exec-tool.in.

As long as this doesn't break any rules, it should allow the sysroot problems I
had to disappear as well, which will fix my prefix issue as well.


-- 


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

[Bug target/25343] [4.1/4.2/4.3/4.4 regression] [m68k] testsuite failures

[schwab at suse dot de]

--- Comment #8 from schwab at suse dot de  2008-04-01 18:57 ---
Ok, lets fix it for real.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #33 from oblivian at users dot sourceforge dot net  2008-04-01 
19:04 ---
(In reply to comment #32)
> (In reply to comment #30)
> > This patch should work.  It creates a good collect-ld for me.
> > 
> 
> How about a simple change without the whole fast-install patch.
>
How about not, since intl configure now gives me this:
xgcc: ldgram.o: No such file or directory
xgcc: ldlex.o: No such file or directory
xgcc: lexsup.o: No such file or directory
xgcc: ldlang.o: No such file or directory
xgcc: mri.o: No such file or directory
xgcc: ldctor.o: No such file or directory
xgcc: ldmain.o: No such file or directory
xgcc: ldwrite.o: No such file or directory
xgcc: ldexp.o: No such file or directory
xgcc: ldemul.o: No such file or directory
xgcc: ldver.o: No such file or directory
xgcc: ldmisc.o: No such file or directory
xgcc: ldfile.o: No such file or directory
xgcc: ldcref.o: No such file or directory
xgcc: sha1.o: No such file or directory
xgcc: eelf_i386.o: No such file or directory
xgcc: ei386linux.o: No such file or directory
xgcc: ../bfd/.libs/libbfd.so: No such file or directory
xgcc: ../libiberty/libiberty.a: No such file or directory

Oh well. I thought it would work


-- 


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

[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

[oblivian at users dot sourceforge dot net]

--- Comment #34 from oblivian at users dot sourceforge dot net  2008-04-01 
19:04 ---
Sorry make that stage 3 intl gives me the above


-- 


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

[Bug c/35592] Want attribute to enable precision loss warning

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-04-01 19:18 ---
Can you cook up some code examples where you'd like to see a warning?


-- 


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

[Bug c++/35782] support for standard layout types

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-01 19:20 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-01 19:20:05
   date||


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

[Bug c++/33486] namespace association doesn't handle parallel namespaces

[bkoz at gcc dot gnu dot org]

--- Comment #7 from bkoz at gcc dot gnu dot org  2008-04-01 19:34 ---

Hey Jason, can we get this fixed on 4_3-branch? (Could probably get away with
just 
gcc/cp/name-lookup.c fix, no?)

-benjamin


-- 


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

[Bug c/35592] Want attribute to enable precision loss warning

[felix-gcc at fefe dot de]

--- Comment #6 from felix-gcc at fefe dot de  2008-04-01 19:34 ---
Sure. For example:

  char* c=malloc(lseek(somefd,0,SEEK_END);

on a platform where off_t is 64-bit, but where size_t is 32-bit.  For example:
i686-linux with #define _FILE_OFFSET_BITS 64.

Now that I'm thinking about it, would it be possible to have a generic overflow
warning in that context?  For example,

  malloc(p->len+1)

So that gcc sees I'm adding something there, and if the range is not clamped
down before that gives an error?


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[laurent at guerby dot net]

--- Comment #25 from laurent at guerby dot net  2008-04-01 19:40 ---
The binder will generate a call to Set_Globals
  pragma Import (C, Set_Globals, "__gnat_set_globals");

  Set_Globals
(Main_Priority=> -1,
 Time_Slice_Value => -1,
 WC_Encoding  => 'b',
 Locking_Policy   => ' ',
 Queuing_Policy   => ' ',
 Task_Dispatching_Policy  => ' ',
 Restrictions => Restrictions'Address,
 Interrupt_States => Interrupt_States'Address,
 Num_Interrupt_States => 0,
 Unreserve_All_Interrupts => 0,
 Exception_Tracebacks => 0,
 Zero_Cost_Exceptions => 1,
 Detect_Blocking  => 0);


That should set the following global in s-taskin.adb:

   Main_Priority : Integer;
   pragma Import (C, Main_Priority, "__gl_main_priority");
   --  Priority for main task. Note that this is of type Integer, not
   --  Priority, because we use the value -1 to indicate the default
   --  main priority, and that is of course not in Priority'range.

Which is checked in System.tasking.initialize

  --  Initialize Environment Task

  if Main_Priority = Unspecified_Priority then
 Base_Priority := Default_Priority;
  else
 Base_Priority := Priority (Main_Priority);
  end if;

Default_Priority is defined in system-rtems.ads :

   Default_Priority : constant Priority := 122;

so my advice is breakpoint on the if above and see what happens. double check
that you compile using the right system.ads.


-- 


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

[Bug c++/35790] New: operator new susceptible to integer overflow

[felix-gcc at fefe dot de]

operator new has an implicit *sizeof(type), and during that operation there can
occur an integer overflow.  Example:

int* foo() {
  return new int[0x4000];
}

Compiled for a 32-bit target, this allocates 0 bytes.  Most compilers do not
detect this either, but the Microsoft compiler instead generates code that in
case of overflow generates an allocation for 0x bytes that will then
fail.

g++ should also do that.  It catches many subtle security bugs, and it costs
much less than for example -fstack-protector, which everyone agrees is a great
idea.


-- 
   Summary: operator new susceptible to integer overflow
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: felix-gcc at fefe dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/35788] MIPS stack overflow caused by addui instruction

[derrick_chi at msn dot com]

--- Comment #7 from derrick_chi at msn dot com  2008-04-01 20:32 ---
Hello 

   I've already attached the source code I'm using, and I'm not sure of the
version of GCC but I just recently downloaded cygwin so its got to be a fairly
up to date version.  If there is a command I can enter to find out for sure
please let me know, and I'll get it to you. You'll have to forgive my ignorance
I'm not an expert in using GCC.


-- 


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

[Bug c/35436] [4.1/4.2/4.3/4.4 regression] ICE with attribute "format"

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2008-04-01 20:34 
---
Subject: Bug 35436

Author: reichelt
Date: Tue Apr  1 20:33:37 2008
New Revision: 133800

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133800
Log:
PR c/35436
* c-format.c (init_dynamic_gfc_info): Ignore invalid locus type.

* gcc.dg/format/gcc_gfc-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/format/gcc_gfc-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-format.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/35436] [4.1/4.2/4.3 regression] ICE with attribute "format"

[reichelt at gcc dot gnu dot org]

--- Comment #3 from reichelt at gcc dot gnu dot org  2008-04-01 20:37 
---
Fixed on mainline.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3/4.4 regression]|[4.1/4.2/4.3 regression] ICE
   |ICE with attribute "format" |with attribute "format"


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

[Bug ada/35791] New: V-table messed up with interface composition

[prog at msobczak dot com]

with Ada.Text_IO;

procedure A is

   package Stuff is

  type Base_1 is interface;
  procedure P_1 (X : in Base_1) is abstract;

  type Base_2 is interface;
  procedure P_2 (X : in Base_2) is abstract;

  type Middle is interface and Base_1 and Base_2;

  type Concrete is new Middle with null record;
  procedure P_1 (X : in Concrete);
  procedure P_2 (X : in Concrete);

  function Make_Concrete return Concrete;

   end Stuff;

   package body Stuff is

  procedure P_1 (X : in Concrete) is
  begin
 Ada.Text_IO.Put_Line ("Concrete.P_1");
  end P_1;

  procedure P_2 (X : in Concrete) is
  begin
 Ada.Text_IO.Put_Line ("Concrete.P_2");
  end P_2;

  function Make_Concrete return Concrete is
 C : Concrete;
  begin
 return C;
  end Make_Concrete;

   end Stuff;

   use Stuff;

   B_1 : Base_1'Class := Make_Concrete;
   B_2 : Base_2'Class := Make_Concrete;

begin
   B_1.P_1;
   B_2.P_2;
end;

$ gnatmake a
$ ./a
Concrete.P_1
Concrete.P_1
$

In other words, both calls dispatched to the same procedure.

Some experiments led me to the interesting observation:
Changing this:

  type Middle is interface and Base_1 and Base_2;

to this:

  type Middle is interface and Base_2 and Base_1;

results in:

$ ./a
Concrete.P_2
Concrete.P_2

Again, both calls dispatched to the same procedure, but now I know
that in both cases the dispatch goes to the *first* progenitor of the
Middle interface.
The expected result is:

Concrete.P_1
Concrete.P_2

irrespectively of the interface composition order.

$ gnatmake --version
GNATMAKE 4.4.0 20080314 (experimental) [trunk revision 133226]


-- 
   Summary: V-table messed up with interface composition
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prog at msobczak dot com


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

[Bug ada/35791] V-table messed up with interface composition

[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=35791

[Bug c++/35790] operator new susceptible to integer overflow

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-01 20:46 ---
There is no overflow here really as sizeof is unsigned and unsigned types don't
overflow, they wrap.

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


-- 

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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2008-04-01 20:46 
---
*** Bug 35790 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||felix-gcc at fefe dot de


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

[Bug fortran/35780] internal compiler error for complicated PARAMETER expressions

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2008-04-01 20:47 ---
I do not agree that this is a regression.  Try

 MODULE MODS

  INTEGER, PARAMETER, DIMENSION(10) ::  A = [(i, i = 1,10)]

  INTEGER, PARAMETER, DIMENSION(10)  :: B = ISHFTC(3, A, 5)   !ICE

  END MODULE MODS

on 4.2 or 4.1.  It so happens that the scalar initializer for A works because
the array is not expanded.  Otherwise, the above fails.

Nonetheless, I'll fix it:)

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4 Regression]|internal compiler error for
   |internal compiler error for |complicated PARAMETER
   |complicated PARAMETER   |expressions
   |expressions |


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2008-04-01 20:47 
---
Also note unsigned types don't overflow, they wrap.  So as far as I can tell,
C++ defines this as being returning too small of a size.


-- 


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

[Bug ada/35791] [Ada] V-table messed up with interface composition

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2008-04-01 20:49 ---
confirmed on trunk 133715


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-01 20:49:40
   date||
Summary|V-table messed up with  |[Ada] V-table messed up with
   |interface composition   |interface composition


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

[Bug ada/35792] New: Illegal program not detected, RM 3.10.1(4/2)

[ludovic at ludovic-brenta dot org]

If an incomplete_type_declaration includes the reserved word tagged,
then a full_type_declaration that completes it shall declare a tagged
type.

The error for T3 is detected, but not T1 or T2.

package pak1 is
   type T1 is tagged;
   type T2 is tagged;
   type T3 is tagged;
   protected type T1 is end T1;
   task type T2;
   type T3 is null record;
end pak1;

gnatmake -gnat05 pak1
gcc-4.1 -c -gnat05 pak1.ads
pak1.ads:4:09: full declaration of type "T3" defined at line 7 must be tagged

gnatmake -gnat05 pak1
gcc-4.3 -c -gnat05 pak1.ads
pak1.ads:4:09: full declaration of type "T3" defined at line 7 must be tagged


-- 
   Summary: Illegal program not detected, RM 3.10.1(4/2)
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ludovic at ludovic-brenta dot org


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

[Bug ada/35793] New: Illegal program not detected, RM 3.8(12)

[ludovic at ludovic-brenta dot org]

RM 3.8(12):
If the discriminant is used to define the constraint of a component, ...
then its name shall appear alone as a direct_name (not as part of ...
an expanded name).

The error for x3 is detected, but not x1.

package pak1 is
   type T1(n: natural) is null record;

   type T2(n: natural) is record
x1: string (1 .. T2.n);
x2: string (1 .. n);
x3: T1(T2.n);
x4: T1(n);
end record;
end pak1;

gcc-4.1 -c -gnat05 pak1.ads
pak1.ads:7:18: discriminant must appear alone as a direct name

gcc-4.3 -c -gnat05 pak1.ads
pak1.ads:7:18: discriminant must appear alone as a direct name


-- 
   Summary: Illegal program not detected, RM 3.8(12)
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ludovic at ludovic-brenta dot org


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[felix-gcc at fefe dot de]

--- Comment #15 from felix-gcc at fefe dot de  2008-04-01 21:24 ---
I think we can all agree it does not matter what we call this problem.
Real world programs have security problems because of this.
-fstack-protector carries a much larger run-time cost and gcc still offers it,
and there is even less grounds to argue by any C or C++ standard that it's not
the programmer's fault.  gcc still offers it.

As mentioned in the other bug, Microsoft Visual C++ already does this check. 
They do it like this.  After the multiplication they check of the overflow flag
is set, which on x86 indicates the result does not fit in the lower 32 bits. 
If so, instead of the truncated value it passes (size_t)-1 the operator new,
which causes that operator new to fail (in the default case at least, a user
may define its own operator new and that one might still return something).

My favorite solution would be for the code to fail immediately.  Throw an
exception or return NULL, depending on which operator new the program called.


-- 


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

[Bug ada/35794] New: Illegal program not detected, RM 4.1.3(9.2/2)

[ludovic at ludovic-brenta dot org]

-- RM 4.1.3(9.2/2):
-- The selector_name shall resolve to denote a view of a subprogram
-- declared immediately within the declarative region in which an
-- ancestor of the type T is declared.

package pak1 is

   package pak2 is
  type T1 is tagged private;
   private
  type T1 is tagged null record;
  function f1(x: T1) return integer;
   end pak2;

   x1: pak2.T1;
   x2: integer := x1.f1;   -- ERROR: f1 not declared in visible part of pak2
end pak1;

gcc-4.1 -c -gnat05 pak1.ads
cannot generate code for file pak1.ads (package spec)
to check package spec for errors, use -gnatc


-- 
   Summary: Illegal program not detected, RM 4.1.3(9.2/2)
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ludovic at ludovic-brenta dot org


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

[Bug ada/35794] Illegal program not detected, RM 4.1.3(9.2/2)

[ludovic at ludovic-brenta dot org]

--- Comment #1 from ludovic at ludovic-brenta dot org  2008-04-01 21:26 
---
gcc-4.3 -c -gnat05 pak1.ads
pak1.ads:11:21: no selector "f1" for private type "T1" defined at line 4


-- 

ludovic at ludovic-brenta dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.1.2
  Known to work||4.3.0
 Resolution||FIXED


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

[Bug c++/19351] operator new[] can return heap blocks which are too small

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2008-04-01 21:51 
---
I agree.  Patches welcome.


-- 


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