[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-25 
08:40 ---
I bootstraped a 20050123 shapshot with the d-19609
patch attached and lags_complex_divide_method=1 on
ia64-unknown-linux-gnu, and I got this bootstrap failure
in libgfortran:

/home/zfkts/gcc-bin/gcc/xgcc -B/home/zfkts/gcc-bin/gcc/
-B/home/zfkts/ia64-unknown-linux-gnu/bin/
-B/home/zfkts/ia64-unknown-linux-gnu/lib/ -isystem
/home/zfkts/ia64-unknown-linux-gnu/include -isystem
/home/zfkts/ia64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.0-20050123/libgfortran -I.
-iquote../../../gcc-4.0-20050123/libgfortran/io -std=gnu99 -O2 -g -O2 -c
../../../gcc-4.0-20050123/libgfortran/generated/pow_r4_i4.c -o pow_r4_i4.o
>/dev/null 2>&1
../../../gcc-4.0-20050123/libgfortran/generated/pow_c4_i4.c: In function
'pow_c4_i4':
../../../gcc-4.0-20050123/libgfortran/generated/pow_c4_i4.c:44: internal
compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4518
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [pow_c4_i4.lo] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory 
`/home/zfkts/gcc-bin/ia64-unknown-linux-gnu/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/home/zfkts/gcc-bin/ia64-unknown-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/home/zfkts/gcc-bin'
make: *** [bootstrap] Error 2

I'll check a simple complex division next.

Thomas

-- 


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-25 
08:48 ---
Same thing:

$ cat cdivide.c
#include 
#include 
#include 

int main()
{
float complex a,b,c;
c = a/b;
}

$ ~/gcc-bin/gcc/xgcc -fdump-rtl-all-all -fdump-tree-all -B ~/gcc-bin/gcc/ 
cdivide.c
cdivide.c: In function 'main':
cdivide.c:9: internal compiler error: in purge_dead_edges, at cfgrtl.c:2460
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ cat cdivide.c.t14.oplower

;; Function main (main)

main ()
{
  float D.2722;
  float D.2721;
  float D.2720;
  float D.2719;
  float D.2718;
  float D.2717;
  float D.2716;
  float D.2715;
  float D.2714;
  float D.2713;
  float D.2712;
  float D.2711;
  float D.2710;
  float D.2709;
  float D.2708;
  float D.2707;
  float D.2706;
  float D.2705;
  float D.2704;
  float D.2703;
  float D.2700;
  float D.2699;
  float D.2698;
  float D.2697;
  float D.2696;
  float D.2695;
  complex float c;
  complex float b;
  complex float a;
  complex float D.2690;

:
  D.2695 = REALPART_EXPR ;
  D.2696 = IMAGPART_EXPR ;
  D.2697 = REALPART_EXPR ;
  D.2698 = IMAGPART_EXPR ;
  D.2699 = ABS_EXPR ;
  D.2700 = ABS_EXPR ;
  if (D.2699 < D.2700) goto ; else goto ;

:;
  D.2705 = D.2697 / D.2698;
  D.2706 = D.2697 * D.2705;
  D.2707 = D.2706 + D.2698;
  D.2708 = D.2695 * D.2705;
  D.2709 = D.2708 + D.2696;
  D.2710 = D.2696 * D.2705;
  D.2711 = D.2710 - D.2695;
  D.2712 = D.2709 / D.2707;
  D.2713 = D.2711 / D.2707;
  D.2703 = D.2712;
  D.2704 = D.2713;

:;
  D.2714 = D.2698 / D.2697;
  D.2715 = D.2698 * D.2714;
  D.2716 = D.2715 + D.2697;
  D.2717 = D.2696 * D.2714;
  D.2718 = D.2717 + D.2695;
  D.2719 = D.2695 * D.2714;
  D.2720 = D.2696 - D.2719;
  D.2721 = D.2718 / D.2716;
  D.2722 = D.2720 / D.2716;
  D.2703 = D.2721;
  D.2704 = D.2722;

:
  D.2690 = COMPLEX_EXPR ;
  c = D.2690;
  return;

}


-- 


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

[Bug c++/19620] New: exception not caught when passing through C code

[jkanze at cheuvreux dot com]

When an exception is thrown, terminate is called, even though
there is an appropriate handler, if there is any C code between
the exception and the handler.  This is a serious problem because
a lot of third party software uses a C ABI and callbacks.
(Note that this works with Sun CC.)

-- main.cc 

#include 
#include 
#include 

extern "C"
{
extern void enrollCallback( void (*pf)() ) ;
extern void doCallback() ;
}

void
f()
{
throw std::runtime_error( "Just a test" ) ;
}


extern "C" void callback()
{
f() ;
}

int
main()
{
enrollCallback( &callback ) ;
try {
doCallback() ;
} catch ( std::exception const& error ) {
std::cout << "Exception caught: " << error.what() << std::endl ;
} catch ( ... ) {
std::cout << "Unknown exception caught" << std::endl ;
}
return 0 ;
}
 test.c ---

static void (*pf)() ;

void
enrollCallback( void (*cb)() )
{
pf = cb ;
}

void
doCallback()
{
(*pf)() ;
}
-- end sources ---
Desired behavior: Program outputs:
>   Exception caught: Just a test
when run.  (This is the behavior of Sun CC.)

Actual behavior: terminate is called.

-- 
   Summary: exception not caught when passing through C code
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkanze at cheuvreux dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug fortran/19443] log10 statement does not work properly in gfortran

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-01-25 
09:45 ---
I am sorry, I missed this thread completely:

I think that this is a problem with gfortran's log10(real*4).

The following works correctly with the gcc built at the same time as gfortran - 
gcc (GCC) 4.0.0 20050117 (experimental):

#include 
#include 

int main (void)
{
  float tst4 = 1.0e-5;
  double tst8 = 1.0e-5;
  printf ("Literal %f\n", 10*log10 (1.0e-5));
  printf ("Float...%f\n", 10*log10 (tst4));
  printf ("Double..%f\n", 10*log10 (tst8));
  return 0;
}

program test
  implicit none
  REAL*4 :: tst4
  real*8 :: tst8
  tst4 = 1e-5_4
  tst8 = 1e-5_8
  write (*,*) "log with real*4 ..", 10*log (1e-5_4), 10*log (tst4)
  write (*,*) "log with real*8 ..", 10*log (1e-5_8), 10*log (tst8)
  write (*,*) "log10 with real*4 ", 10*log10 (1e-5_4), 10*log10 (tst4)
  write (*,*) "log10 with real*8 ", 10*log10 (1e-5_8), 10*log10 (tst8)
end program test

 log with real*4 ..  -115.1292  -115.1292
 log with real*8 ..  -115.129254649702   -115.129254649702
 log10 with real*4   -50.0  -Infinity
 log10 with real*8   -50.0   -50.0

-- 


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

[Bug libfortran/19478] reading back from /dev/null

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-01-25 
10:37 ---
I do not believe this to be a bug:

An end-of-file condition occurs when no more records exist in a file during a 
sequential read, or when an end-of-file record produced by the ENDFILE statement
is encountered. End-of-file conditions do not occur in direct-access READ 
statements.

For A editting If w is equal to or greater than the length (len) of the input 
item, the rightmost characters are assigned to that item. The leftmost excess 
characters are ignored.

Adding a second read to the test program, generates the EOF condition a nd it 
is correctly trapped.

-- 


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

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

[sebastian dot pop at cri dot ensmp dot fr]

--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr  
2005-01-25 10:32 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> Adding the instantiation cache was compile time neutral on normal code,
> so I don't think the effect on scev cost is significant.
> 

How that?  You end up querying and caching an evolution for every
instantiation of an SSA_NAME!  

I will quantify the number of queries wrt the number of times this
information is useful.  I think that with my patch, the instantiation
cache information is used zero times on a bootstrap.

> The problem is that we end up calling the instantiate_parameters_1
> function 83214+2453273 (outside + recursive) times (for N=100).
> We also call analyze_scalar_evolution_1 1146317 times.  Many of these
> calls create POLYNOMIAL_CHREC nodes (2894131 calls to build3_stat).
> Large part of 5142869 of build_int_cst_wide calls is very likely also
> due to scev analysis.  This is not going to be cheap.  Removing the
> instantiation cache definitely would not decrease the number of
> instantiate_parameters_1 calls (might increase it, in fact, although
> I don't know how significantly).
> 

This also could be a bad use of the scev analysis.

For Steven: you can have a O(N**3) algorithm very simply:

  loop O(N) times
loop O(N) times
  algorithm in O(N)

> One part of the problem is that loop optimizers need to throw away the
> scev caches after each change to loops, which leads to recounting the
> information too much.  Allowing to invalidate only changed parts helps,
> but seems to be relatively costly on normal code -- you need to scan the
> hash table for things that refer to removed or from some other reason
> invalidated ssa names, which is slow.  

Just set the SSA_NAME to not_analyzed_yet or NULL_TREE, and the next time
you'll ask for the evolution of this SSA_NAME you'll analyze the
evolution from scratch.



-- 


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

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

[sebastian dot pop at cri dot ensmp dot fr]

--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr  
2005-01-25 10:39 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> 
> How?  If the reference is left in symbolic form, it means that you know
> nothing about its value, so the only thing you can do with it is to
> check its equality/inequality, in code like
> 
> while (...)
>   {
> i = something_weird ();
> 
> a[i] = ...;  (a)
> a[i+1] = ...;  (b)
> a[i] = ...;  (c)
>   }
> 

The following is probably a more frequent case:

i = 0
x = something_weird () or a function parameter
loop
  i = i + 1 
  a[i] = ...
  ... = a[i + x]
endloop

where you end with a symbolic distance vector.



-- 


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-25 10:49 
---
Hi, everything looks fine here (20050124 on x86-linux), double checked the 
formulas, bootstrapped c, c++, tested a few other divisions besides the
testcase (now ok), and cannot reproduce the last dump of Thomas. The below
is mine, seems ok (e.g., the goto at the end of block L0 is present):

;; Function main (main)

main ()
{
  float D.2643;
  float D.2642;
  float D.2641;
  float D.2640;
  float D.2639;
  float D.2638;
  float D.2637;
  float D.2636;
  float D.2635;
  float D.2634;
  float D.2633;
  float D.2632;
  float D.2631;
  float D.2630;
  float D.2629;
  float D.2628;
  float D.2627;
  float D.2626;
  float D.2625;
  float D.2624;
  float D.2621;
  float D.2620;
  float D.2619;
  float D.2618;
  float D.2617;
  float D.2616;
  complex float c;
  complex float b;
  complex float a;
  complex float D.2611;

:
  D.2616 = REALPART_EXPR ;
  D.2617 = IMAGPART_EXPR ;
  D.2618 = REALPART_EXPR ;
  D.2619 = IMAGPART_EXPR ;
  D.2620 = ABS_EXPR ;
  D.2621 = ABS_EXPR ;
  if (D.2620 < D.2621) goto ; else goto ;

:;
  D.2626 = D.2618 / D.2619;
  D.2627 = D.2618 * D.2626;
  D.2628 = D.2627 + D.2619;
  D.2629 = D.2616 * D.2626;
  D.2630 = D.2629 + D.2617;
  D.2631 = D.2617 * D.2626;
  D.2632 = D.2631 - D.2616;
  D.2633 = D.2630 / D.2628;
  D.2634 = D.2632 / D.2628;
  D.2624 = D.2633;
  D.2625 = D.2634;
  goto ;

:;
  D.2635 = D.2619 / D.2618;
  D.2636 = D.2619 * D.2635;
  D.2637 = D.2636 + D.2618;
  D.2638 = D.2617 * D.2635;
  D.2639 = D.2638 + D.2616;
  D.2640 = D.2616 * D.2635;
  D.2641 = D.2617 - D.2640;
  D.2642 = D.2639 / D.2637;
  D.2643 = D.2641 / D.2637;
  D.2624 = D.2642;
  D.2625 = D.2643;

:
  D.2611 = COMPLEX_EXPR ;
  c = D.2611;
  return;

}

-- 


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

[Bug fortran/19574] specification expression failure

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-01-25 
10:57 ---
The segmentation fault seems to me to have the same source as PR19561 - 
temporaries are not being allocated/assigned properly.

This does the first wriet OK and then seg faults on the second:

! { dg-do run }
module funcs
   implicit none
   contains
  function f (x)
 character(*), intent(in) :: x
 integer f(len(x))
 f = 0
  end function f
end module funcs
program spec_expr_test
   use funcs
   implicit none
   integer, dimension(10)  :: i
   i(1:5) = f ('test')
   write (*,*) i(1:5)
   write (*,*) f('untest')
end program spec_expr_test
! { dg-error "Segmentation fault (core dumped)" }


-- 


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

[Bug target/19598] [arm] non-optimal handling of invalid immediate constant in XOR

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-01-25 
10:59 ---
Confirmed.

arm_split_constant() already knows how to handle XOR, so it should be just a
matter of copying the model used for andsi3 into the xorsi3 expander.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Priority|P2  |P3
   Last reconfirmed|-00-00 00:00:00 |2005-01-25 10:59:46
   date||


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

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

[sebastian dot pop at cri dot ensmp dot fr]

--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr  
2005-01-25 11:02 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> 
> (*) I hope; scev is a mess of mutualy recursive functions --
> analyze_scalar_evolution calling number_of_iterations calling
> instantiate_parameters calling analyze_scalar_evolution again, with
> instantiate_parameters hacked so that the infinite cycle cannot occur is
> my favourite one.  Nobody can say anything sure about behavior of scev
> -- it is not even well defined what analyze_scalar_evolutions will
> return to you, 

It returns to you an evolution that might contain SSA_NAMEs.

> unless you call instantiate_parameters or resolve_mixers
> on the result.
> 

And once you call instantiate_parameters on the result you're
guaranteed that what you get does contain only determined constants,
or otherwise the result is chrec_dont_know.



-- 


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

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

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

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-01-25 11:14 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

> rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> > Adding the instantiation cache was compile time neutral on normal code,
> > so I don't think the effect on scev cost is significant.
> > 
> 
> How that?  You end up querying and caching an evolution for every
> instantiation of an SSA_NAME!  

which is pretty cheap (constant time operation); note that we do an
equivalent lookup in the analyze_scalar_evolution call in any case, also
without causing any compile time problems.  I haven't measured any slowdown on
normal testcases.

> I will quantify the number of queries wrt the number of times this
> information is useful.  I think that with my patch, the instantiation
> cache information is used zero times on a bootstrap.

I don't think so.  Please come up with some numbers, otherwise this
discussion is pointless.

> > The problem is that we end up calling the instantiate_parameters_1
> > function 83214+2453273 (outside + recursive) times (for N=100).
> > We also call analyze_scalar_evolution_1 1146317 times.  Many of these
> > calls create POLYNOMIAL_CHREC nodes (2894131 calls to build3_stat).
> > Large part of 5142869 of build_int_cst_wide calls is very likely also
> > due to scev analysis.  This is not going to be cheap.  Removing the
> > instantiation cache definitely would not decrease the number of
> > instantiate_parameters_1 calls (might increase it, in fact, although
> > I don't know how significantly).
> > 
> 
> This also could be a bad use of the scev analysis.

partly -- see the analysis at the PR.  However one O(n) per query comes
from scev itself.

> For Steven: you can have a O(N**3) algorithm very simply:
> 
>   loop O(N) times
> loop O(N) times
>   algorithm in O(N)
> 
> > One part of the problem is that loop optimizers need to throw away the
> > scev caches after each change to loops, which leads to recounting the
> > information too much.  Allowing to invalidate only changed parts helps,
> > but seems to be relatively costly on normal code -- you need to scan the
> > hash table for things that refer to removed or from some other reason
> > invalidated ssa names, which is slow.  
> 
> Just set the SSA_NAME to not_analyzed_yet or NULL_TREE, and the next time
> you'll ask for the evolution of this SSA_NAME you'll analyze the
> evolution from scratch.

This does not work, of course.  When the ssa name is removed, you must
remove all references to it from the cache.  Otherwise you will ICE when
you try to process the relevant entry in (say) instantiate_parameters.
What's worse, the ssa name may get reused by ssa name management, thus
causing you not even be able to note the change, and thus possibly to
misscompilations.


-- 


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

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

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

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-01-25 11:16 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

> > How?  If the reference is left in symbolic form, it means that you know
> > nothing about its value, so the only thing you can do with it is to
> > check its equality/inequality, in code like
> > 
> > while (...)
> >   {
> > i = something_weird ();
> > 
> > a[i] = ...;  (a)
> > a[i+1] = ...;  (b)
> > a[i] = ...;  (c)
> >   }
> > 
> 
> The following is probably a more frequent case:
> 
> i = 0
> x = something_weird () or a function parameter
> loop
>   i = i + 1 
>   a[i] = ...
>   ... = a[i + x]
> endloop
> 
> where you end with a symbolic distance vector.

But here x is a loop invariant.  Nothing would change here if we were
keeping the evolutions fully instantiated.


-- 


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

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

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

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-01-25 11:29 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

> > (*) I hope; scev is a mess of mutualy recursive functions --
> > analyze_scalar_evolution calling number_of_iterations calling
> > instantiate_parameters calling analyze_scalar_evolution again, with
> > instantiate_parameters hacked so that the infinite cycle cannot occur is
> > my favourite one.  Nobody can say anything sure about behavior of scev
> > -- it is not even well defined what analyze_scalar_evolutions will
> > return to you, 
> 
> It returns to you an evolution that might contain SSA_NAMEs.

Hmm... if this is all you can tell, I start fear even more; this does
not define any semantics at all :-)

More seriously -- which of the possibilities?  If I have loops like

while (...)
  {
while (...)
  {
x_1 = something ();
  }
x_2 = phi (x_1);
x_3 = x_2 + 1;
  }

What will analyze_scalar_evolutions return for x_3? There are (at least)
three possible valid values:

x_3
x_2 + 1
x_1 + 1

In this example probably the last one will be chosen, but in more
complicated cases you cannot tell (without simulating what scev analysis
does).  It might be better to not export analyze_scalar_evolution at
all and to force it to be used through
instantiate_parameters/resolve_mixers, that have at least a well defined
semantics of return value -- I hope.  Till recently I believed that I
made the functions to behave reasonably in cases when values defined
inside loop are used outside of it (through chain of lcssa phi nodes),
but my attempt to remove the hacks that ensure sane behavior of the
results for ivopts causes misscompilations; I am investigating the cause
now.


-- 


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

[Bug tree-optimization/18316] Missed IV optimization

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-01-25 
11:35 ---
Reopening as an enhancement request for ivopts.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug libgcj/19621] New: Network-performance issue in java.io.PrintStream

[mkrause at atronicsystems dot com]

When using a PrintStream in order to output 101 bytes via a socket, the output 
is split into to packets with 100 and 1 byte respectively. A native JDK sends 
101 bytes/packet.

The program reads

import java.io.PrintStream;
import java.net.Socket;
public class Test100ByteProblem {
public static void main(String args[]){
Socket s;
try {
int i = 0;
s = new Socket("127.0.0.1", );
PrintStream ps = new PrintStream(s.getOutputStream());
while(i++<20){
ps.
print("q
");
ps.flush();
}
s.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}


$gcj -v 
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libgcj.spec
rename spec lib to liborig
Configured with: /var/tmp/portage/gcc-3.3.2/work/gcc-3.3.2/configure 
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include 
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man 
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared 
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib 
--enable-languages=c,c++,f77,objc,java --enable-threads=posix 
--enable-long-long 
--disable-checking --enable-cstdio=stdio --enable-clocale=generic 
--enable-__cxa_atexit --enable-version-specific-runtime-libs 
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3 
--with-local-prefix=/usr/local --enable-shared --enable-nls 
--without-included-gettext --x-includes=/usr/X11R6/include 
--x-libraries=/usr/X11R6/lib --enable-interpreter --enable-java-awt=xlib 
--with-x --disable-multilib
Thread model: posix
gcc version 3.3.2  (Gentoo Linux 3.3.2, propolice)

-- 
   Summary: Network-performance issue in java.io.PrintStream
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mkrause at atronicsystems dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug ada/18302] ACATS test c953002 (and others) hangs

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-25 
12:07 ---
Subject: Bug 18302

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2005-01-25 12:07:40

Modified files:
gcc/testsuite  : ChangeLog 
gcc/ada: ChangeLog Make-lang.in 
gcc/testsuite/ada/acats: run_all.sh 
Added files:
gcc/testsuite/ada/acats: run_test.exp 

Log message:
2004-11-28  James A. Morrison  <[EMAIL PROTECTED]>

PR ada/18302
* Make-lang.in (check-gnat): Set EXPECT environment variable.

* ada/acats/run_all.sh (target_run): Run test through run_test.expect.
* ada/acats/run_test.expect: Expect script for ACATS tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.3389.2.170.2.41&r2=1.3389.2.170.2.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.428.2.7.2.8&r2=1.428.2.7.2.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Make-lang.in.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.70.2.2.2.2&r2=1.70.2.2.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ada/acats/run_test.exp.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ada/acats/run_all.sh.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.14.18.2&r2=1.14.18.3



-- 


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

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

[sebastian dot pop at cri dot ensmp dot fr]

--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr  
2005-01-25 12:03 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> 
> --- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
> dot cz  2005-01-25 11:14 ---
> Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)
> 
> > rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> > > Adding the instantiation cache was compile time neutral on normal code,
> > > so I don't think the effect on scev cost is significant.
> > > 
> > 
> > How that?  You end up querying and caching an evolution for every
> > instantiation of an SSA_NAME!  
> 
> which is pretty cheap (constant time operation); note that we do an
> equivalent lookup in the analyze_scalar_evolution call in any case, also
> without causing any compile time problems.  I haven't measured any slowdown on
> normal testcases.
> 
> > I will quantify the number of queries wrt the number of times this
> > information is useful.  I think that with my patch, the instantiation
> > cache information is used zero times on a bootstrap.
> 
> I don't think so.  Please come up with some numbers, otherwise this
> discussion is pointless.
> 

during a bootstrap: 

instantiation cache queries: 1146452

instantiation cache uses: 247452 of which 143977 were scev_not_known,
the other were SSA_NAMEs.

this was counted with a grep|wc with the following patch: 

Index: tree-scalar-evolution.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-scalar-evolution.c,v
retrieving revision 2.16
diff -d -u -p -r2.16 tree-scalar-evolution.c
--- tree-scalar-evolution.c 18 Jan 2005 11:36:26 -  2.16
+++ tree-scalar-evolution.c 25 Jan 2005 12:00:57 -
@@ -1898,8 +1898,15 @@ get_instantiated_value (htab_t cache, tr
   pattern.var = version;
   info = htab_find (cache, &pattern);
 
+  fprintf (stdout, "IC_query \n");
+
   if (info)
-return info->chrec;
+{
+  fprintf (stdout, "IC_used_once \n");
+  print_generic_expr (stdout, info->chrec, 0);
+  fprintf (stdout, "\n");
+  return info->chrec;
+}
   else
 return NULL_TREE;
 }
@@ -1915,6 +1922,8 @@ set_instantiated_value (htab_t cache, tr
   pattern.var = version;
   slot = htab_find_slot (cache, &pattern, INSERT);
 
+  fprintf (stdout, "IC_query \n");
+
   if (*slot)
 info = *slot;
   else
@@ -1990,7 +1999,8 @@ instantiate_parameters_1 (struct loop *l
 result again.  */
   bitmap_set_bit (already_instantiated, SSA_NAME_VERSION (chrec));
   res = analyze_scalar_evolution (def_loop, chrec);
-  res = instantiate_parameters_1 (loop, res, allow_superloop_chrecs, 
cache);
+  if  (res != chrec_dont_know)
+   res = instantiate_parameters_1 (loop, res, allow_superloop_chrecs, 
cache);
   bitmap_clear_bit (already_instantiated, SSA_NAME_VERSION (chrec));
 
   /* Store the correct value to the cache.  */
@@ -2000,8 +2010,14 @@ instantiate_parameters_1 (struct loop *l
 case POLYNOMIAL_CHREC:
   op0 = instantiate_parameters_1 (loop, CHREC_LEFT (chrec),
  allow_superloop_chrecs, cache);
+  if (op0 == chrec_dont_know)
+   return chrec_dont_know;
+
   op1 = instantiate_parameters_1 (loop, CHREC_RIGHT (chrec),
  allow_superloop_chrecs, cache);
+  if (op1 == chrec_dont_know)
+   return chrec_dont_know;
+
   if (CHREC_LEFT (chrec) != op0
  || CHREC_RIGHT (chrec) != op1)
chrec = build_polynomial_chrec (CHREC_VARIABLE (chrec), op0, op1);
@@ -2010,8 +2026,14 @@ instantiate_parameters_1 (struct loop *l
 case PLUS_EXPR:
   op0 = instantiate_parameters_1 (loop, TREE_OPERAND (chrec, 0),
  allow_superloop_chrecs, cache);
+  if (op0 == chrec_dont_know)
+   return chrec_dont_know;
+
   op1 = instantiate_parameters_1 (loop, TREE_OPERAND (chrec, 1),
  allow_superloop_chrecs, cache);
+  if (op1 == chrec_dont_know)
+   return chrec_dont_know;
+
   if (TREE_OPERAND (chrec, 0) != op0
  || TREE_OPERAND (chrec, 1) != op1)
chrec = chrec_fold_plus (TREE_TYPE (chrec), op0, op1);
@@ -2020,8 +2042,14 @@ instantiate_parameters_1 (struct loop *l
 case MINUS_EXPR:
   op0 = instantiate_parameters_1 (loop, TREE_OPERAND (chrec, 0),
  allow_superloop_chrecs, cache);
+  if (op0 == chrec_dont_know)
+   return chrec_dont_know;
+
   op1 = instantiate_parameters_1 (loop, TREE_OPERAND (chrec, 1),
  allow_superloop_chrecs, cache);
+  if (op1 == chrec_dont_know)
+return chrec_dont_know;
+
   if (TREE_OPERAND (chrec, 0) != op0
  || TREE_OPERAND (chrec, 1) != op1)
 chrec = chrec_fold_minus (TREE_TYPE (chrec), op0, op1);
@@ -2030,8 +2058,14 @@

[Bug java/17255] [meta-bug] Fixes should be back-ported to 3.4 branch

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-25 
12:12 ---
Subject: Bug 17255

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2005-01-25 12:12:09

Modified files:
gcc/java   : ChangeLog class.c decl.c expr.c java-tree.h 
 parse.y 

Log message:
2004-05-10  Andrew Haley  <[EMAIL PROTECTED]>

PR java/17255
* parse.y (create_class): Set TYPE_VFIELD.
* decl.c (java_init_decl_processing): Likewise.

* expr.c (build_invokevirtual): Remove DECL_VINDEX offset adjustment.
* class.c (make_method_value): Replace DECL_VINDEX with call to
get_method_index().
(get_dispatch_vector): Likewise.
(layout_class_method): Likewise.
Replace set of DECL_VINDEX with call to set_method_index().
(set_method_index): New function.
(get_method_index): New function.
* java-tree.h (set_method_index): New function decl.
(get_method_index): New function decl.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.1315.2.15.2.9&r2=1.1315.2.15.2.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.176.2.1&r2=1.176.2.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.176&r2=1.176.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.181.4.2&r2=1.181.4.2.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.194.6.1&r2=1.194.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.464.4.2.2.2&r2=1.464.4.2.2.3



-- 


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

[Bug middle-end/19084] [4.0 Regression] ICE: internal consistency failure

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-25 
12:15 ---
Subject: Bug 19084

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2005-01-25 12:15:21

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/execute: 20050111-1.c 
gcc/testsuite/gcc.dg: 20050111-1.c 

Log message:
PR middle-end/19084
PR rtl-optimization/19348
* gcc.dg/20050111-1.c: New test.
* gcc.c-torture/execute/20050111-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.3389.2.170.2.43&r2=1.3389.2.170.2.44
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050111-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050111-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.6.1



-- 


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

[Bug rtl-optimization/19348] [4.0 Regression] internal consistency error while compiling linux kernel

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-25 
12:15 ---
Subject: Bug 19348

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2005-01-25 12:15:21

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/execute: 20050111-1.c 
gcc/testsuite/gcc.dg: 20050111-1.c 

Log message:
PR middle-end/19084
PR rtl-optimization/19348
* gcc.dg/20050111-1.c: New test.
* gcc.c-torture/execute/20050111-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.3389.2.170.2.43&r2=1.3389.2.170.2.44
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050111-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050111-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.6.1



-- 


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

[Bug middle-end/19616] [4.0 regression] missed tail call

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-25 
12:37 ---
The patch is of course wrong :-( 
GCC 3.3 and GCC 3.4 can both do the tail call, so this is a new problem 
for GCC 4.0.  I'm going to do a better investigation this time. 

-- 


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-25 12:39 
---
Thomas, before attaching stuff to the PR, please double check your setup: on
x86, at least, the problem is definitely fixed and I cannot reproduce your
dumps. I'm currently testing on x86_64.

-- 


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

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

[sebastian dot pop at cri dot ensmp dot fr]

--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr  
2005-01-25 12:44 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> More seriously -- which of the possibilities?  If I have loops like
> 
> while (...)
>   {
> while (...)
>   {
> x_1 = something ();
>   }
> x_2 = phi (x_1);
> x_3 = x_2 + 1;
>   }
> 
> What will analyze_scalar_evolutions return for x_3? There are (at least)
> three possible valid values:
> 
> x_3

This would be the answer if analyze_scalar_evolutions would be the
identity function.  If you want, you could change analyze_scalar_evolutions
such that it behaves like that, and decide that the instantiation do
the rest of the work (I mean moving the code that is currently in
analyze_scalar_evolutions to the instantiation phase).

> x_2 + 1

If you decide to reconstruct the tree expression, there is no reason
to stop on a phi node that has a single argument.  Why would you like
to get this answer as the reconstructed tree?

> x_1 + 1
> 

IMO this would be the answer, although I didn't checked.



-- 


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

[Bug libfortran/19595] eor and advance="yes" should not mix

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-25 
12:44 ---
The following fixes the parsing issue:

--- transfer.c.orig 2005-01-25 13:43:28.0 +0100
+++ transfer.c  2005-01-25 13:43:35.0 +0100
@@ -1041,7 +1041,7 @@

   if (read_flag)
 {
-  if (ioparm.eor != 0 && advance_status == ADVANCE_NO)
+  if (ioparm.eor != 0 && advance_status != ADVANCE_NO)
generate_error (ERROR_MISSING_OPTION,
"EOR specification requires an ADVANCE specification of
NO");

End-of-record handling for formatted read is generally broken, which
also includes eor (see PR 19568).

-- 


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

[Bug target/19393] [3.4 Regression] Assembler error: branch out of range

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-25 
12:50 ---
Subject: Bug 19393

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-01-25 12:50:36

Modified files:
gcc: ChangeLog 
gcc/config/arm : arm.md 

Log message:
PR target/19393
Backport:
2004-03-30  Nick Clifton  <[EMAIL PROTECTED]>
* config/arm/arm.md (thumb_jump): Reduce the backward branch
range, and increase the forward branch range, to allow for
the fact that the PC will be off by 4.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.782&r2=2.2326.2.783
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.md.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.154.4.2&r2=1.154.4.3



-- 


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

[Bug target/19393] [3.4 Regression] Assembler error: branch out of range

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-01-25 
12:51 ---
Nick patched this on the trunk back in March last year.  I've backported the
patch to the branch.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/19183] [3.4 Regression] ICE with -fPIC

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-25 
13:07 ---
Recategorizing.


-- 
   What|Removed |Added

  Component|ada |middle-end


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

[Bug c++/19622] New: [4.0 regression] ICE, dwarf2, using statement, libc functions

[jan at etpmod dot phys dot tue dot nl]

The following C++ generates an ICE with today's trunk when -g is passed: 
 
extern int strlen (const char *__s) throw(); 
 
namespace std { 
using ::strlen; 
} 
 
void foo() 
{ 
using std::strlen; 
} 
 
[EMAIL PROTECTED] g++ -g -c t.cpp 
t.cpp: In function ?void foo()?: 
t.cpp:9: internal compiler error: tree check: expected class ?declaration?, 
have ?exceptional? (@@dummy) in lookup_decl_die, at dwarf2out.c:5415 
 
Obviously, this is a reduction of a usual pattern, 
 
#include  
void foo() 
{ 
using std::strlen; 
} 
 
The same result is obtained when strlen is replaced by another libc-function 
like printf. If 'strlen' is replaced by anything else (like 'bar', say), 
everything is fine.

-- 
   Summary: [4.0 regression] ICE, dwarf2, using statement, libc
functions
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan at etpmod dot phys dot tue dot nl
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug middle-end/19616] [4.0 regression] missed tail call

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-25 
14:21 ---
It worked with a tail call until this patch got applied: 
 
+2004-07-10  Zdenek Dvorak  <[EMAIL PROTECTED]> 
+ 
+   * calls.c (check_sibcall_argument_overlap_1): Handle pointers 
+   to incoming args space correctly. 
 

-- 


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

[Bug tree-optimization/19623] New: ICE: compiling SPECfp2000 benchmark fails in 191.fma3d

[ola at ctmagazin dot de]

Compiler used: GCC 4.0 Snapshot as of 2005-01-16.


Optimization flags used:

OPTIMIZE   =  -march=opteron -O3 -funroll-loops -ftree-vectorize


Error doesn't occur with:

OPTIMIZE   =  -march=opteron -O3 -funroll-loops


---


Compiler output (taken from file 
/cpu2000/benchspec/CFP2000/191.fma3d/run/0019/make.err)

---
 In file beam.f90:1379

IF (AK .EQ. 0.0) GO TO 200
 1
 In file beam.f90:1447

 200ENDDO
2
Warning: Obsolete: GOTO at (1) jumps to END of construct at (2)
 In file beam.f90:1387

IF ((Psi - AK*AK) .LE. 0.0) GO TO 200
1
 In file beam.f90:1447

 200ENDDO
2
Warning: Obsolete: GOTO at (1) jumps to END of construct at (2)
 In file beam.f90:1397

IF ((Psi - AK*AK) .LE. 0.0) GO TO 200
1
 In file beam.f90:1447

 200ENDDO
2
Warning: Obsolete: GOTO at (1) jumps to END of construct at (2)
beam.f90: In function ‘beam_stress_integration’:
beam.f90:675: internal compiler error: in ix86_expand_fp_absneg_operator, at con
fig/i386/i386.c:8057
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
specmake: *** [beam.o] Error 1

-- 
   Summary: ICE: compiling SPECfp2000 benchmark fails in 191.fma3d
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ola at ctmagazin dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/19624] New: PRE pessimizes ivopts

[rguenth at tat dot physik dot uni-tuebingen dot de]

The attached testcase is pessimized by PRE.  Be sure to get tree-level complete
loop unrolling enabled, f.i. with -O2 -funroll-loops with current mainline.

With PRE, a lot less computations are hoisted out of the inner loop.  Note this
is not a regression to 3.4, which is not able to decompose Loc 
appropriately
or avoid instantiating temporary objects of this type.

-- 
   Summary: PRE pessimizes ivopts
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/19624] PRE pessimizes ivopts

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-25 14:45 ---
Created an attachment (id=8060)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8060&action=view)
testcase

The testcase is reduced from a complex POOMA program.

-- 


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-25 
14:50 ---
(In reply to comment #13)
> Thomas, before attaching stuff to the PR, please double check your setup: on
> x86, at least, the problem is definitely fixed and I cannot reproduce your
> dumps. I'm currently testing on x86_64.

Paolo,

I just redid the following commands, in order, on an
ia64-unknown-linux-gnu machine:

With the most recent snapshot:

$ bzcat gcc-4.0-20050123.tar.bz2 | tar -xvf -
$ cd gcc-4.0-20050123/
$ cd gcc
$ patch -R < ~/d-19609
$ vi toplev.c

changed 

int flag_complex_divide_method = 1;

$ cd ~/gcc-bin
$ rm -rf *
$ ../gcc-4.0-20050123/configure --prefix=$HOME --enable-languages="c,f95"
$ make -j3 bootstrap

... with the same bootstrap failure.

This setup has never caused problems before.

Thomas

-- 


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

[Bug tree-optimization/19624] PRE pessimizes ivopts

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-25 14:52 ---
Oh, in principle this should compile to roughly the same as

void c_test(double *a, double *b, int ei, int ej, int stridea, int strideb)
{
  for (int j=0; jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=19624

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-25 15:01 
---
> I just redid the following commands, in order, on an
> ia64-unknown-linux-gnu machine:
> 
> With the most recent snapshot:
>
> $ bzcat gcc-4.0-20050123.tar.bz2 | tar -xvf -
> 
> ... with the same bootstrap failure.
> 
> This setup has never caused problems before.

This is an ia64 specific issue, therefore: testing on x86 and
x86-64 is ok, and definitely no bootstrap failures.

Also, if you got a bootstrap failure, where did you get those
dumps from?!?

-- 


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-25 
15:12 ---
(In reply to comment #15)

> This is an ia64 specific issue, therefore: testing on x86 and
> x86-64 is ok, and definitely no bootstrap failures.

Interesting.  How did you do the testing?  What version did you test
against?  How did you test?  Maybe something is broken in 20050123
that got fixed later, which caused this.

If you could retrace the exact steps I outlined in comment #14,
and still get no failure, then this indeed a target problem.
 
> Also, if you got a bootstrap failure, where did you get those
> dumps from?!?

As you can see from the error messages in comment #9, building
libgfortran failed during "make bootstrap".  Maybe "bootstrap failure"
is not the correct term for this; if so, what is?

Thomas

-- 


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

[Bug tree-optimization/19505] [4.0 Regression] Java bytecode ICE in except.c remove_unreachable_regions

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2005-01-25 15:12 
---
Here's a test case for this bug, copied from PR18931. This will fail when
compiling from bytecode produced by Sun's javac, but not from bytecode produced
by gcj or ecj. 

public class PR19505 {

  public int getByte() 
  {
return 1;
  }

  public void ls(String p) throws Exception{
try{
  p.toString();

  int type=getByte();

  if(type!=100){
throw new Exception("");
  }
  if(type==100) return;
  throw new Exception();
}
catch(Exception e){
  throw new Exception("");
}
  }
}



-- 


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

[Bug middle-end/19616] [4.0 regression] missed tail call

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-25 
15:13 ---
The test case for PR15387 does not fail with mainline  
if Zdenek's patch is reverted. 
 

-- 
   What|Removed |Added

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


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-25 15:20 
---
> Interesting.  How did you do the testing?  What version did you test
> against?  How did you test?  Maybe something is broken in 20050123
> that got fixed later, which caused this.

Nothing special, just current mainline, applied the patch, changed the
flag to 1, bootstrapped and tested all the languages besides ada. AFAICS,
this is *definitely* a target problem, the patch works fine on x86 and
x86_64.

> As you can see from the error messages in comment #9, building
> libgfortran failed during "make bootstrap".  Maybe "bootstrap failure"
> is not the correct term for this; if so, what is?

It's a normal bootstrap failure during the build of libjava. But in that
case, the bootstrap doesn't complete, indeed. Therefore, how did you get
the last dumps? Of course not using a compiler normally installed! Perhaps
you installed the compiler anyway "by hand" from the build dir, bootstrap
failure notwithstanding?







-- 


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

[Bug tree-optimization/19624] PRE pessimizes ivopts

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-01-25 
15:23 ---
Just as an FYI, i have absoutely no plans to make it so ivopts and PRE interact
perfectly.
I only plan to disable transforms in PRE that are always unprofitable.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dberlin at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-25 15:23:01
   date||


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

[Bug tree-optimization/19624] PRE pessimizes ivopts

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-25 15:27 ---
I guess making PRE and ivopts playing nicely together perfectly is near to
impossible - but any improvement in the 4.0 timeframe is welcome!

-- 


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

[Bug tree-optimization/19624] PRE pessimizes ivopts

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-01-25 
15:35 ---
Subject: Re:  PRE pessimizes ivopts

On Tue, 2005-01-25 at 15:27 +, rguenth at tat dot physik dot
uni-tuebingen dot de wrote:
> --- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
> dot de  2005-01-25 15:27 ---
> I guess making PRE and ivopts playing nicely together perfectly is near to
> impossible

Yes, hence why i don't plan on promising it :)
There are always optimization interactions that are very very hard to
control or predict.
The best you can do is not make your optimization do things that are
always unprofitable, try to make them interact better where possible,
and hope for the best.

>  - but any improvement in the 4.0 timeframe is welcome!
> 



-- 


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-25 
15:40 ---
(In reply to comment #17)

> Therefore, how did you get
> the last dumps?

I used the xgcc from the build subdirectoy:

$ ~/gcc-bin/gcc/xgcc -fdump-rtl-all-all -fdump-tree-all -B ~/gcc-bin/gcc/ 
cdivide.c


-- 


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

[Bug c++/19620] exception not caught when passing through C code

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-01-25 15:53 ---
Subject: Re:  New: exception not caught when passing through C code

"jkanze at cheuvreux dot com" <[EMAIL PROTECTED]> writes:

| When an exception is thrown, terminate is called, even though
| there is an appropriate handler, if there is any C code between
| the exception and the handler.  This is a serious problem because
| a lot of third party software uses a C ABI and callbacks.
| (Note that this works with Sun CC.)

This is documented somewhere in the docs, I think.  
If you mix C codes with C++ and exceptions are raised (through
callbacks) and you need exceptions to smoothly travel across language
boundaries, you need to compile the C code with -fexceptions.

And yes, I too believe that Sun's approach is very sensible.

Ah, I found the doc:

==
@item -fexceptions
@opindex fexceptions
Enable exception handling.  Generates extra code needed to propagate
exceptions.  For some targets, this implies GCC will generate frame
unwind information for all functions, which can produce significant data
size overhead, although it does not affect execution.  If you do not
specify this option, GCC will enable it by default for languages like
C++ which normally require exception handling, and disable it for
languages like C that do not normally require it.  However, you may need
to enable this option when compiling C code that needs to interoperate
properly with exception handlers written in C++.  You may also wish to
disable this option if you are compiling older C++ programs that don't
use exception handling.
==

I thinks the PR can be closed.

-- Gaby


-- 


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

[Bug AWT/16722] AWT application leaks memory

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2005-01-25 15:56 
---
Using the latest GCC HEAD awt code, I can no longer reproduce this problem.
Sweet! I'm closing the PR.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-25 
15:57 ---
Paolo,

could you upload the .t14.oplower dump that you got from your working
version with the d-19609 patch?

Thomas

-- 


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

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

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
   Severity|critical|normal
  Component|tree-optimization   |target
   Keywords||ice-on-valid-code, ssemmx
Summary|ICE: compiling SPECfp2000   |ICE: compiling SPECfp2000
   |benchmark fails in 191.fma3d|benchmark fails in 191.fma3d
   ||with -ftree-vectorizer


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-25 16:01 
---
Is in Comment #11, and looks fine.

-- 


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

[Bug middle-end/19616] [4.0 regression] missed tail call

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-25 
16:07 ---
With "-O2" at the time the patch for PR15387 was applied, we had the 
following .optimized tree for sister: 
 
;; Function sister (sister) 
 
sister (f, b) 
{ 
  int * tmp; 
  int T.2; 
  int T.1; 
  int * f.0; 
 
: 
  f.0 = (int *)&f; 
  brother (*(f.0 + 4B) == b, b) [tail call]; 
  return; 
 
} 
 
 
That resulted in this RTL: 
 
(insn 3 8 4 0 (set (reg/v:SI 59 [ b ]) 
(mem/i:SI (plus:SI (reg/f:SI 53 virtual-incoming-args) 
(const_int 12 [0xc])) [2 b+0 S4 A32])) -1 (nil) 
(expr_list:REG_EQUIV (mem/i:SI (plus:SI (reg/f:SI 53 
virtual-incoming-args) 
(const_int 12 [0xc])) [2 b+0 S4 A32]) 
(nil))) 
 
(insn 11 9 13 1 (set (reg:SI 58 [ f.0 ]) 
(reg/f:SI 53 virtual-incoming-args)) -1 (nil) 
(nil)) 
 
(insn 15 14 16 1 (set (mem/i:SI (plus:SI (reg/f:SI 53 virtual-incoming-args) 
(const_int 4 [0x4])) [0 S4 A32]) 
(reg/v:SI 59 [ b ])) -1 (nil) 
(nil)) 
 
(insn 16 15 17 1 (set (reg:SI 61) 
(mem:SI (plus:SI (reg:SI 58 [ f.0 ]) 
(const_int 4 [0x4])) [2 S4 A32])) -1 (nil) 
(nil)) 
 
So reg 61 gets set to the value of 'b' that just got stored in *(f.0 + 4). 
 
CVS today generates this tree dump and RTL: 
;; Function sister (sister) 
 
Analyzing Edge Insertions. 
sister (f, b) 
{ 
  int f$c; 
  int f$a; 
  int f$b; 
  int * tmp; 
  int D.1134; 
  int D.1133; 
 
: 
  brother (b == f.b, b) [tail call]; 
  return; 
 
} 
 
 
(insn 3 6 4 0 (set (reg/v:SI 58 [ b ]) 
(mem/i:SI (plus:SI (reg/f:SI 53 virtual-incoming-args) 
(const_int 12 [0xc])) [3 b+0 S4 A32])) -1 (nil) 
(expr_list:REG_EQUIV (mem/i:SI (plus:SI (reg/f:SI 53 
virtual-incoming-args) 
(const_int 12 [0xc])) [3 b+0 S4 A32]) 
(nil))) 
 
(insn 17 7 18 1 (set (mem:SI (plus:SI (reg/f:SI 56 virtual-outgoing-args) 
(const_int 4 [0x4])) [0 S4 A32]) 
(reg/v:SI 58 [ b ])) -1 (nil) 
(nil)) 
 
(insn 18 17 19 1 (set (reg:SI 63) 
(mem/s:SI (plus:SI (reg/f:SI 53 virtual-incoming-args) 
(const_int 4 [0x4])) [3 f.b+0 S4 A32])) -1 (nil) 
(nil)) 
 
 
Note how b is now stored to virtual-*outgoing*-args. 
 

-- 


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

[Bug c++/19367] [4.0 Regression] ICE: tree_check in lookup_local_die with local `using'

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
16:10 ---
*** Bug 19622 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||jan at etpmod dot phys dot
   ||tue dot nl


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

[Bug c++/19622] [4.0 regression] ICE, dwarf2, using statement, libc functions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
16:10 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

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

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

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-01-25 15:54 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

> rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> > More seriously -- which of the possibilities?  If I have loops like
> > 
> > while (...)
> >   {
> > while (...)
> >   {
> > x_1 = something ();
> >   }
> > x_2 = phi (x_1);
> > x_3 = x_2 + 1;
> >   }
> > 
> > What will analyze_scalar_evolutions return for x_3? There are (at least)
> > three possible valid values:
> > 
> > x_3
> 
> This would be the answer if analyze_scalar_evolutions would be the
> identity function.  If you want, you could change analyze_scalar_evolutions
> such that it behaves like that, and decide that the instantiation do
> the rest of the work (I mean moving the code that is currently in
> analyze_scalar_evolutions to the instantiation phase).
> 
> > x_2 + 1
> 
> If you decide to reconstruct the tree expression, there is no reason
> to stop on a phi node that has a single argument.  Why would you like
> to get this answer as the reconstructed tree?

because this answer preserves loop closed ssa form -- the answer x_1 + 1
copy propagates the value outsied of the loop.  In some applications
this choice could make sense.


-- 


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-25 15:51 
---
Ok, sorry, didnt' pay attention to that detail (while working on the library,
usually we install the compiler... ;)

Anyway, I'm going to build and test on ia64 too.

-- 


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

[Bug c++/19620] exception not caught when passing through C code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
16:11 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/11813] make -fexceptions default for c and objective-c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
16:11 ---
*** Bug 19620 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||jkanze at cheuvreux dot com


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-25 16:13 
---
... indeed, IMH-not-compiler-hacker, opinion, t14 should be the same on x86
and ia64...

-- 


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

[Bug c++/19625] New: GCC accepts a default value for the first argument of a template function

[Matthieu dot Moy at imag dot fr]

The following code compiles, and should not :

template
T f2(const char * s2, T arg2, T arg3);

template
T f2(const char * s2 = 0, // bug
 T arg2, T arg3) {
  return (s2)?arg2:arg3;
}


Same for the following :


template
class foo {
  T f2(const char * s2, T arg2, T arg3);
};

template
T foo::f2(const char * s2 = 0, // bug
 T arg2, T arg3) {
  return (s2)?arg2:arg3;
}


Or for the even simpler


template
class foo {
  T f2(const char * s2 = 0, T arg2, T arg3); // bug
};

-- 
   Summary: GCC accepts a default value for the first argument of a
template function
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Matthieu dot Moy at imag dot fr
CC: gcc-bugs at gcc dot gnu dot org


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

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

[sebastian dot pop at cri dot ensmp dot fr]

--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr  
2005-01-25 16:26 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

> > If you decide to reconstruct the tree expression, there is no reason
> > to stop on a phi node that has a single argument.  Why would you like
> > to get this answer as the reconstructed tree?
> 
> because this answer preserves loop closed ssa form -- the answer x_1 + 1
> copy propagates the value outsied of the loop.  In some applications
> this choice could make sense.
> 

Okay, if it makes sense, you could modify the analyzer such that it
stops reconstructing the tree once it is on the phi following a loop.
This won't change the information provided after the instantiation.



-- 


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

[Bug c++/19625] GCC accepts a default value for the first argument of a template function

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||accepts-invalid


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

[Bug c++/19625] GCC accepts a default value for the first argument of a template function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
16:31 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/16829] default parameter can be not one of the last in template function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
16:31 ---
*** Bug 19625 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||Matthieu dot Moy at imag dot
   ||fr


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

[Bug rtl-optimization/15853] [3.3 Regression] temporaries are not destroyed and overwritten later

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-25 
16:42 ---
Stepping down for now.


-- 
   What|Removed |Added

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


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-25 
16:43 ---
(In reply to comment #22)
> ... indeed, IMH-not-compiler-hacker, opinion, t14 should be the same on x86
> and ia64...

Quite.

Could you maybe run a C-only bootstrap with the 20050123 snapshot,
modified by the patch and setting flags_complex_divide_method=1, and
see wether you can reproduce the problem?  If so, then this has
been fixed by something else in the meantime (which would be
excellent :-)

Thomas

-- 


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

[Bug ada/19600] [4.0 Regression] All acats tests fail

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-25 
16:43 ---
Investigating.


-- 
   What|Removed |Added

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


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

[Bug tree-optimization/19626] New: Aliasing says stores to local memory do alias

[rguenth at tat dot physik dot uni-tuebingen dot de]

Given the attached testcase, for reference, the interesting function is
this:

int loc_test(void)
{
const Loc<2> dX(1, 0);
const Loc<2> k(0, 1);
return k[0].first() + dX[0].first();
}

aliasing tells us that the initializations of dX and k alias each
other:

:
  D.2540 = (struct Loc<1> *) &dX.D.2210.D.2166.domain_m.buffer;
  #   dX_357 = V_MAY_DEF ;
  #   k_358 = V_MAY_DEF ;
  *&(&D.2540->D.2094)->D.2057.domain_m = 1;
  #   dX_365 = V_MAY_DEF ;
  #   k_364 = V_MAY_DEF ;
  *&(&(D.2540 + 4B)->D.2094)->D.2057.domain_m = 0;
  D.2682 = (struct Loc<1> *) &k.D.2210.D.2166.domain_m.buffer;
  #   dX_337 = V_MAY_DEF ;
  #   k_338 = V_MAY_DEF ;
  *&(&D.2682->D.2094)->D.2057.domain_m = 0;
  #   dX_361 = V_MAY_DEF ;
  #   k_63 = V_MAY_DEF ;
  *&(&(D.2682 + 4B)->D.2094)->D.2057.domain_m = 1;
  D.2769 = (struct Loc<1> *) &k.D.2210.D.2166.domain_m.buffer;
  D.2791 = (struct Loc<1> *) &dX.D.2210.D.2166.domain_m.buffer;
  return (&D.2769->D.2094)->D.2057.domain_m + 
(&D.2791->D.2094)->D.2057.domain_m;

which is of course (trivially) not true.  This may be obfuscated by
the actual implementation of the template class Loc (see attached
complete testcase).

At the RTL level we are able to optimize this to just return 1, as
expected.  This pessimizes tree loop optimizations if such constructs
are used inside a loop and as induction variable.

-- 
   Summary: Aliasing says stores to local memory do alias
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/19626] Aliasing says stores to local memory do alias

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-01-25 16:57 ---
Created an attachment (id=8062)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8062&action=view)
testcase


-- 


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-25 
17:00 ---
#ifdef EGG_ON_FACE_MODE

Sorry to have kept everybody from doing something more worthwile.

The problem was that I hadn't noticed that the patch for
PR 19468 wasn't yet in the 20050123 snapshot which I was
using, and that rth's patch was with respect to mainline,
which contains the PR 19468 patch, which is why PR 19468
crept back in for me, but not for anybody else who was looking
at this.

#endif

So, yes, this is fixed with the attached patch.

Thomas

-- 


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

[Bug c++/16829] default parameter can be not one of the last in template function

[Matthieu dot Moy at imag dot fr]

--- Additional Comments From Matthieu dot Moy at imag dot fr  2005-01-25 
17:05 ---
Bug 19625 contains two other similar testcases. They're worth trying once the
bug is fixed.

-- 


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-25 17:06 
---
OK ;) In Italy we say something like "anything is ok, if ends ok" ;)

Anyway, in the meanwhile an ia64-linux bootstrap completed fine here. I'm 
running
the testsuite now.

-- 


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

[Bug rtl-optimization/19627] New: if-conversion2 generates wrong code / crash on SH4

[michael dot schwingen at lancom dot de]

gcc generates wrong code on the test case when called with
/opt/cgcc-3.4.3-20050125/bin/sh-elf-gcc -m4 -S -Os -fomit-frame-pointer test2.c

Adding -fno-if-conversion2 creates working code. It seems that the code that
modifies the stack pointer to make space for function arguments is shifted
across a branch to a point where some paths through the function end up with a
wrong stack pointer at the end.

Attached: test2.c, test2.s, test2.c.27.flow2, test2.c.29.ce3

-- 
   Summary: if-conversion2 generates wrong code / crash on SH4
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot schwingen at lancom dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: unknown-i686-linux
  GCC host triplet: unknown-i686-linux
GCC target triplet: unknown-sh-elf


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

[Bug tree-optimization/19626] Aliasing says stores to local memory do alias

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
17:15 ---
If you had used the correct types in the first place instead of this crazy 
uninitialized pointer this works 
(almost):
  dX.D.2220.D.2170.domain_m.buffer[0].D.2098.D.2055.domain_m = 1;
  dX.D.2220.D.2170.domain_m.buffer[1].D.2098.D.2055.domain_m = 0;

  k.D.2220.D.2170.domain_m.buffer[0].D.2098.D.2055.domain_m = 0;
  k.D.2220.D.2170.domain_m.buffer[1].D.2098.D.2055.domain_m = 1;
  return k.D.2220.D.2170.domain_m.buffer[0].D.2098.D.2055.domain_m + 
dX.D.2220.D.2170.domain_m.buffer[0].D.2098.D.2055.domain_m;

-- 
   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||alias, missed-optimization,
   ||TREE
   Priority|P2  |P3


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

[Bug rtl-optimization/19627] if-conversion2 generates wrong code / crash on SH4

[michael dot schwingen at lancom dot de]

--- Additional Comments From michael dot schwingen at lancom dot de  
2005-01-25 17:15 ---
Created an attachment (id=8063)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8063&action=view)
C source code


-- 


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

[Bug rtl-optimization/19627] if-conversion2 generates wrong code / crash on SH4

[michael dot schwingen at lancom dot de]

--- Additional Comments From michael dot schwingen at lancom dot de  
2005-01-25 17:16 ---
Created an attachment (id=8064)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8064&action=view)
assembler output containing wrong code


-- 


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

[Bug rtl-optimization/19627] if-conversion2 generates wrong code / crash on SH4

[michael dot schwingen at lancom dot de]

--- Additional Comments From michael dot schwingen at lancom dot de  
2005-01-25 17:17 ---
Created an attachment (id=8065)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8065&action=view)
last correct RTL 


-- 


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

[Bug rtl-optimization/19627] if-conversion2 generates wrong code / crash on SH4

[michael dot schwingen at lancom dot de]

--- Additional Comments From michael dot schwingen at lancom dot de  
2005-01-25 17:17 ---
Created an attachment (id=8066)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8066&action=view)
first wrong RTL


-- 


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

[Bug rtl-optimization/19627] if-conversion2 generates wrong code / crash on SH4

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
  GCC build triplet|unknown-i686-linux  |
   GCC host triplet|unknown-i686-linux  |
 GCC target triplet|unknown-sh-elf  |sh-elf
   Keywords||ice-on-valid-code, wrong-
   ||code


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

[Bug java/19070] internal compiler error: in generate_bytecode_conditional, at java/jcf-write.c:1271

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
17:18 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/19626] Aliasing says stores to local memory do alias

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
17:20 ---
  D.2540 = (struct Loc<1> *) &dX.D.2210.D.2166.domain_m.buffer;
That confuses the aliasing mechanism
buffer is of type int* but you are casting it to Loc<1> *.

-- 


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

[Bug ada/19600] [4.0 Regression] All acats tests fail

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-25 
17:24 ---
> This looks like wrong code as nothing in the ada front-end/testsuite changed.

Confirmed.

> Here are the only changes that might have an effect (on targets since it seems
> like it was all targets where this happens):

It's actually

2005-01-21  Ian Lance Taylor  

PR tree-optimization/13000
* tree-inline.c: Include "tree-flow.h".
(expand_call_inline): If warn_return_type, warn if non-void inline
function falls through.
* tree-cfg.c (execute_warn_function_return): Don't warn about
control reaching end if TREE_NO_WARNING is set.  Set
TREE_NO_WARNING.
* gimple-low.c (block_may_fallthru): Don't assume that SWITCH_EXPR
has been lowered.
* gimplify.c (shortcut_cond_expr): Don't emit a jump over the else
branch if we don't need one.
* c-typeck.c: Include "tree-flow.h"
(c_finish_bc_stmt): Don't add a goto if the current statement
list doesn't fall through to the current point.

and most notably

* gimplify.c (shortcut_cond_expr): Don't emit a jump over the else
branch if we don't need one.


For these lines in make.adb:Scan_Make_Arg:

  elsif Argv = "-bargs"
  or else
Argv = "-cargs"
  or else
Argv = "-largs"
  or else
Argv = "-margs"
  then
 case Argv (2) is
when 'c' => Program_Args := Compiler;
when 'b' => Program_Args := Binder;
when 'l' => Program_Args := Linker;
when 'm' => Program_Args := None;

when others =>
   raise Program_Error;
 end case;

  --  A special test is needed for the -o switch within a -largs
  --  since that is another way to specify the name of the final
  --  executable.

  elsif Program_Args = Linker
and then Argv = "-o"
  then
 Make_Failed ("switch -o not allowed within a -largs. " &
  "Use -o directly.");

  --  Check to see if we are reading switches after a -cargs,
  --  -bargs or -largs switch. If yes save it.

  elsif Program_Args /= None then

 --  Check to see if we are reading -I switches in order
 --  to take into account in the src & lib search directories.

the flow-of-control fallthrus through the latter 2 'elsif's.


-- 


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

[Bug libfortran/18891] write with no open causes core dump

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
17:33 ---
Fixed by:
2004-12-14  Steve Ellcey  <[EMAIL PROTECTED]>

* libgfortran/io/transfer.c (us_read): Use memcpy/memset
instead of assignment to fill unaligned buffer.
(us_write): Ditto.
(next_record_w): Ditto.

Next time try placing PR component/bug number in the changelog/commit message 
and bugzilla will 
pick it up automatically.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/18891] write with no open causes core dump

[sje at cup dot hp dot com]

--- Additional Comments From sje at cup dot hp dot com  2005-01-25 17:20 
---
The patch for this fix was checked in.  The final patch was:

http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00953.html

Does anything else need to be done for this to be closed?

-- 


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

[Bug middle-end/19616] [4.0 regression] missed tail call

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-25 
18:16 ---
rth suggested not TERing into function arguments of a tail call, which 
seems like a good idea that I will give a try. 
 

-- 


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

[Bug ada/18706] [4.0 Regression] ACATS ce2208b ICE expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:637

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
18:16 ---
As I said this is an Ada front-end bug.

-- 
   What|Removed |Added

  Component|tree-optimization   |ada


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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-25 
18:19 ---
Subject: Bug 19609

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-25 18:19:10

Modified files:
gcc: ChangeLog tree-complex.c 

Log message:
PR middle-end/19609
* tree-complex.c (expand_complex_div_wide): Use the correct formulae.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7269&r2=2.7270
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-complex.c.diff?cvsroot=gcc&r1=2.17&r2=2.18



-- 


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

[Bug middle-end/18902] Naive (default) complex division algorithm

[rth at gcc dot gnu dot org]

-- 
Bug 18902 depends on bug 19609, which changed state.

Bug 19609 Summary: [4.0 Regression] real and imaginary part interchanged when 
flags_complex_divide_method=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19609

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-25 18:26 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/19556] [4.0 Regression] ICE with -march=pentium-m (during bootstrap)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-25 
18:44 ---
Subject: Bug 19556

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-25 18:44:05

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386.c i386.md 

Log message:
PR target/19556
PR target/19584
* config/i386/i386.c (x86_inter_unit_moves): Zero.
(ix86_preferred_reload_class): Rewrite fp-constant section, with
80387 enabled, to return a proper subclass.  Return the subset that
overlaps with GENERAL_REGS for PLUS.
* config/i386/i386.md (movsi_1, movdi_2): Set type to "mmx" for pxor.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7270&r2=2.7271
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.789&r2=1.790
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.612&r2=1.613



-- 


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

[Bug target/19584] [4.0 Regression] ICE: insn does not satisfy its constraints

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-25 
18:44 ---
Subject: Bug 19584

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-25 18:44:05

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386.c i386.md 

Log message:
PR target/19556
PR target/19584
* config/i386/i386.c (x86_inter_unit_moves): Zero.
(ix86_preferred_reload_class): Rewrite fp-constant section, with
80387 enabled, to return a proper subclass.  Return the subset that
overlaps with GENERAL_REGS for PLUS.
* config/i386/i386.md (movsi_1, movdi_2): Set type to "mmx" for pxor.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7270&r2=2.7271
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.789&r2=1.790
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.612&r2=1.613



-- 


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

[Bug target/19556] [4.0 Regression] ICE with -march=pentium-m (during bootstrap)

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-25 18:51 
---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01815.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/19584] [4.0 Regression] ICE: insn does not satisfy its constraints

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-25 18:51 
---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01815.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
19:11 ---
Removing the target milestone per Mark: 
.
This is only known to happen on VAX.

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug c++/17401] [3.4/4.0 Regression] ICE with invalid pure specifier

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
19:14 ---
Is this fixed or just keeping open for a reason?

-- 


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

[Bug c++/17964] [4.0 Regression] cpp error messages contain wrong line in C++

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Priority|P1  |P2


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

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

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |minor
   Priority|P2  |P3


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

[Bug tree-optimization/19505] [4.0 Regression] Java bytecode ICE in except.c remove_unreachable_regions

[aph at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/19337] [4.0 Regression] ada does not compile at -O3 (nested functions related)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-25 
19:32 ---
Subject: Bug 19337

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-25 19:32:53

Modified files:
gcc: ChangeLog tree-inline.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: 20050119-1.c 

Log message:
PR tree-optimize/19337
* gcc.c-torture/compile/20050119-1.c: New test.

PR tree-optimize/19337
* tree-inline.c (initialize_inlined_parameters): Copy
saved_static_chain_decl only.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7271&r2=2.7272
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcc&r1=1.167&r2=1.168
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4935&r2=1.4936
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050119-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/18370] [3.4/4.0 Regression] cp_parser_initializer_list uninit variable problems

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
19:47 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug tree-optimization/19337] [4.0 Regression] ada does not compile at -O3 (nested functions related)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-25 
19:49 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

Documentation "bug"

[Ethan Tira-Thompson]

Regarding:
http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html#Function%20Attributes
When using an attribute that take parameter arguments, such as the 
format attribute, one needs to start counting parameters at *2* in C++ 
because (i'm assuming here) 'this' (the current object's address) is 
argument 1.

This took me a while to figure out why I kept getting "error: format 
string arg not a string type", but it seems to work now.

thanks,
 -ethan