[Bug pch/19540] New: document pch directory feature

[Ralf dot Wildenhues at gmx dot de]

Please document that it is possible to store a pch of
  foo.h
in a directory named
  foo.h.gch/
such that subsequent compiles will search all files in
that directory for a good precompiled header candidate.

(See also http://gcc.gnu.org/ml/gcc/2005-01/msg01087.html)

-- 
   Summary: document pch directory feature
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ralf dot Wildenhues at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug pch/19541] New: deprecation of -I- makes precompiled headers less usable

[Ralf dot Wildenhues at gmx dot de]

As noted in this thread:
http://gcc.gnu.org/ml/gcc/2005-01/msg01087.html
there is no way to make use of a precompiled header without
-I- in a VPATH build in case the header source and the C or
C++ source file including it reside in the same source directory.

Please consider adding a flag (-icwd?) to the preprocessor which will
cause the current directory to be search for pch before the source
directory.  Or consider to change the default pch search order.

-- 
   Summary: deprecation of -I- makes precompiled headers less usable
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ralf dot Wildenhues at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-20 
09:04 ---
This is odd. 
 
For a struct { char a[8]; } count_type_elements returns 8. 
For a union { char a[8]; } count_type_elements returns 1. 
 
This confuses the following code in gimplify_init_constructor: 
 
/* ??? This bit ought not be needed.  For any element not present 
   in the initializer, we should simply set them to zero.  Except 
   we'd need to *find* the elements that are not present, and that 
   requires trickery to avoid quadratic compile-time behavior in 
   large cases or excessive memory use in small cases.  */ 
else if (num_ctor_elements < num_type_elements) 
  cleared = true; 
 
num_ctor_elements == 1 and num_type_elements == 1, so we don't clear. 
 

-- 


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

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-20 
09:10 ---
>From expr.c:count_type_elements: 
 
case UNION_TYPE: 
case QUAL_UNION_TYPE: 
  { 
/* Ho hum.  How in the world do we guess here?  Clearly it isn't 
   right to count the fields.  Guess based on the number of words.  */ 
HOST_WIDE_INT n = int_size_in_bytes (type); 
if (n < 0) 
  return -1; 
return n / UNITS_PER_WORD; 
  } 
 
So we cannot use count_type_elements in gimplify_init_constructor. 
 
I think we should somehow compute the size of the CONSTRUCTOR and compare 
it with int_size_in_bytes (TREE_TYPE (object))...? 

-- 


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

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 
09:15 ---
> From expr.c:count_type_elements: 
>  
> case UNION_TYPE: 
> case QUAL_UNION_TYPE: 
>   { 
> /* Ho hum.  How in the world do we guess here?  Clearly it isn't 
>right to count the fields.  Guess based on the number of words.  
> */ 
> HOST_WIDE_INT n = int_size_in_bytes (type); 
> if (n < 0) 
>   return -1; 
> return n / UNITS_PER_WORD; 
>   } 
>  
> So we cannot use count_type_elements in gimplify_init_constructor. 

Can't we compute the result for unions based on the type of the first member?


-- 


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

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[stevenb at suse dot de]

--- Additional Comments From stevenb at suse dot de  2005-01-20 09:26 
---
Subject: Re:  [4.0 Regression] Violation of C99 6.7.8 =?utf-8?q?=A721_for?= 
unions

> Can't we compute the result for unions based on the type of the first
> member?

Ehm??  "union { int i; char c[256]; }"

However, we can use int_size_in_bytes on object and on the
first field of the constructor in the gimplifier.









-- 


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

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 
09:31 ---
> Ehm??  "union { int i; char c[256]; }"

Doesn't look much buggier than what we currently have... maybe take the max on
all the fields then?  That said, I don't know what count_type_elements is for,
it is clearly brain-damaged for unions at the moment.


-- 


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

[Bug target/16533] ICE on va-arg-25.c testcase when -Os and -msse are given

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-11-06 18:25:06 |2005-01-20 09:48:44
   date||


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

[Bug c++/19542] New: attribute(sentinel) has problems with C++ __null

[marcus at jet dot franken dot de]

when using __attribute__((__sentinel__)) with the C++ NULL defined 
as __null, a sentinel warning is still triggered. 
 
Attached testcase gives: 
 
g++ -c xx.cc -Wall 
xx.cc: In function ‘void g()’: 
xx.cc:5: warning: missing sentinel in function call

-- 
   Summary: attribute(sentinel) has problems with C++ __null
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at jet dot franken 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=19542

[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 
09:51 ---
> This patch is a rework of the sparc-rtems* target based upon the ELF
> NetBSD/SPARC target.  As a reqork, I was able to also fix
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14537 (unix is predefined).
> 
> With this fix, I can build RTEMS and run C and C++ test applications.

Thanks for your efforts.

[Note the bogus reference to PR 14536 in the ChangeLog entry.  And the format
is rather PR target/14537 than the other way around.]

> Is it OK to commit?

I'm not very fond of the patch because it trades an explicit dependency on
Solaris for an implicit dependency on NetBSD, bringing the bugs in the process.
For example:

+/* A 64 bit v9 compiler with stack-bias,
+   in a Medium/Low code model environment.  */
+
+#undef TARGET_DEFAULT
+#define TARGET_DEFAULT \
+  (MASK_V9 + MASK_PTR64 + MASK_64BIT /* + MASK_HARD_QUAD */ \
+   + MASK_STACK_BIAS + MASK_APP_REGS + MASK_FPU + MASK_LONG_DOUBLE_128)
+
+#undef SPARC_DEFAULT_CMODEL
+#define SPARC_DEFAULT_CMODEL CM_MEDANY

Note the discrepancy between the comment (Medium/Low) and the actual setting
(Medium/Any).  Then in the specs

+%{p:-mcmodel=medlow} \
+%{pg:-mcmodel=medlow}}"

This code model frobbing is a bug that I've asked the NetBSD maintainers to fix,
with no effect for the time being.

> The sparc-elf target probably be reworked in a similar fashion with some
> sharing with sparc-rtems.  If a sparc maintainer feels this is the correct
> thing to do, then let's file a PR against sparc-elf and I will fix that.  But
> that is beyond my maintainership responsibility.

The bugreport for sparc-elf was posted yesterday on gcc-patches so I now think
we need to find a generic solution for all the embedded targets.  I proposed to
duplicate the Solaris configuration files for them and remove the offending bits
from there; this was agreed upon by Daniel and the RM so I'm going to do it now.

Once the work is done, sparc-rtems will very likely build again so your patch
would not be necessary anymore.  But you're an RTEMS maintainer so I can't bar
you from installing it anyway if you deem it profitable.


-- 


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

[Bug c++/19542] attribute(sentinel) has problems with C++ __null

[marcus at jet dot franken dot de]

--- Additional Comments From marcus at jet dot franken dot de  2005-01-20 
09:52 ---
Created an attachment (id=8003)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8003&action=view)
xx.cc

testcse, compile with -Wall

-- 


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

[Bug target/19350] Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-01-16 18:50:28 |2005-01-20 09:52:49
   date||


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

[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 
09:54 ---
Sort of fixing.


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

[Bug target/19350] Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-20 
10:16 ---
Subject: Bug 19350

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-20 10:15:15

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

Log message:
PR target/19350
* config/i386/i386.c (ix86_expand_vector_move_misalign): Convert
to V4SFmode in SSE1 fallback load path.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7197&r2=2.7198
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.784&r2=1.785



-- 


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

[Bug target/19350] Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 10:17 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/19350] Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug target/19418] _mm_cast*, icc8.1 new intrinsics

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-01-13 05:47:29 |2005-01-20 10:22:05
   date||


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

[Bug fortran/19543] New: formated output for logical(8) variables fails

[coudert at clipper dot ens dot fr]

When outputing a logical(8) variable, the output can be 'T' even if the variable
is set to .FALSE.! Here is a testcase!

program test
  implicit none
  logical(4), parameter :: l4 = .FALSE.
  logical(8), parameter :: l8 = .FALSE.

  print *, l4, l8
  print *, 'foo', l8
  if (l8) print *, 'l8 is true'
end

This produces the two lines:
 F T
 foo T

which is, of course, not right! What is troubling me is that removing any of the
print statements induces a correct output for the other (and, in fact, removing
the 'foo' string induces correct output).

This bug occurs on i686-linux. This reduced snippet has been worked out from a
code that fails in a similar way on i686-mingw
(http://home.comcast.net/~kmbtib/gfortran_bugs/REF_JVB_GFTN_002.html).

-- 
   Summary: formated output for logical(8) variables fails
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19208] [3.4/4.0 Regression] Spurious error about variably modified type

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-01-20 
10:43 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01305.html

-- 
   What|Removed |Added

   Keywords||patch


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

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

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
10:45 ---
For gfortran, this is a regression against g77.
See this test program:

$ cat complex-scale.f
  program main
  implicit none
  complex ca,cb,cc
  data ca /(+2.3955909e+19,-1.2258349e-38)/
  data cb /(+0.000e+00,-1.7649423e+19)/
  cc = ca/cb
  print *,cc
  print *,-real(ca)/aimag(cb)
  end
$ gfortran complex-scale.f
$ ./a.out
 (  0.00, +Infinity)
   1.357320
$ g77 complex-scale.f
$ ./a.out
 (0.,1.35731959)
  1.35731959


-- 


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

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
10:47 ---
Added PR 18902 because complex division isn't scaled at the moment
(it is in g77).

-- 
   What|Removed |Added

  BugsThisDependsOn||18902


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

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

[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-20 10:57 ---
This is also somewhat related to PR19401 as we do not unroll loops completely
with just -O2 at the moment, which is important for the second testcase.

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
10:58 ---
The Lapack installation hints under
http://www.netlib.org/lapack/html/installation.hints
show that some adjustment was necessary for Crays because

# 1. The Cray compilers implement a complex divide without scaling.  To run
#the complex linear equation tests on the T3D, I had to modify SLABAD to
#take the square root of overflow and underflow.  I ran the eigenvalue
#tests with the default version of SLABAD. 

Currently, gcc also uses a naive complex division algorithm without
scaling, see PR 18092.  This may be the cause of a lot of the complex
LAPACK failures.  Unfortunately, this is not easily changed, because
the scaled algorithm is currently broken, see PR 19486.

Thomas

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
11:01 ---
PR 18902 *sigh*

-- 


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

[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.

[martin at mpa-garching dot mpg dot de]

-- 
   What|Removed |Added

 CC||martin at mpa-garching dot
   ||mpg dot de


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

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 11:28 
---
(In reply to comment #7)
> So we cannot use count_type_elements in gimplify_init_constructor. 

Well, not for unions anyway.

> I think we should somehow compute the size of the CONSTRUCTOR and compare 
> it with int_size_in_bytes (TREE_TYPE (object))...? 

For unions, that may be what we have to do.  With any luck, the element
being initialized will be the largest element of the union, which would
mean we wouldn't have to emit the clear.

For structures, this would mean that any structure with holes would get
cleared.  Which would clearly pessimize a very common case.


-- 


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

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-20 
11:49 ---
> For structures, this would mean that any structure with holes would get
> cleared.  Which would clearly pessimize a very common case.

I considered that too.  But, what about structures that
contain a union?

typedef struct {
  int i;
  union {
int j[2];
float f;
  } u;
} S;
 
void abort (void) __attribute__((noreturn));
 
int main(void)
{
  S s = { .i = 1, {.f = 1.0 } };
  if (s.u.j[1] != 0)
abort ();
  return 0;
} 


-- 


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

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

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-20 11:50 
---
Hi Thomas, can you possibly figure out from the ChangeLog the author of the
algorithm with scaling, which currently seems broken, and add him in CC? We
want to fix it, in the first place.

-- 


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

[Bug c++/19508] [4.0 regression] dwarf2, ICE on __attribute__(aligned) in class template

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-01-20 
12:09 ---
The problem here is that tsubst does not know about attributes, and we knew 
this already. So it won't look into DECL_ORIGINAL_TYPE because it assumes it is 
always NULL for template parameters. You may want to notice that the attribute 
is in fact ignored:


template   
struct BVector  
{  
  typedef T value_type __attribute__ ((aligned(8)));  
  value_type v;
};  
BVector m;  

int main()
{
  printf("%d\n", __alignof__(m.v));
}


This prints "4" on i686-pc-linux-gnu (if you compile it without -g to avoid the 
ICE).

I tried tsubsting within the ORIGINAL_TYPE of a TYPE_DECL too, and it works in 
avoiding the ICE, but for nothing else. Also, the long-term solution is to not 
apply attributes to template types, store the attribute list aside and apply it 
after substitution. So, after all, this would not be a step forward not even in 
that direction.

Thus, it is better to simply not apply the attribute to template types at all.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |giovannibajo at libero dot
   |dot org |it
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-01-20 04:36:26 |2005-01-20 12:09:35
   date||


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

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

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-20 12:10 
---
A first implementation of the algorithm was already in 3_4, under the name
expand_cmplxdiv_wide (in optabs.cc), then Rth rewrote it in the tree-ssa branch
as part of the new tree-complex.cc (It would be mildly interesting to see if
the version in 3_4 works) In the meanwhile, I'm adding Rth in CC of 19486.

-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[pcarlini at suse dot de]

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug ada/19409] ACATS c460010 - valgrind detects wrong code

[baldrick at free dot fr]

--- Additional Comments From baldrick at free dot fr  2005-01-20 12:15 
---
Here is a simpler example: 
 
with Ada.Text_IO; use Ada.Text_IO; 
 
procedure T is 
 
   type Index_Type is range 0 .. 4; -- does not fail if lower bound is 1 
 
   type Unconstrained_Array_Type is array (Index_Type range <>) of Integer; 
 
   subtype Array_Type is Unconstrained_Array_Type (2..4); 
 
   Target : array (1 .. 1) of Array_Type; 
 
   procedure Check (Index : Index_Type; Value : Integer) is 
   begin 
  if Target (1) (Index) /= Value then 
 Put_Line ("Expected " & Integer'Image (Value) & ", found " & 
Integer'Image (Target (1) (Index))); 
  end if; 
   end Check; 
begin 
   Target := (1 => (1 => 20, 2 => 30, 3 => 40)); -- the assignment requires 
sliding 
 
   Check (2, 20); 
   Check (3, 30); 
   Check (4, 40); 
end; 
 
> gnatmake -s -g t 
... 
> ./t 
Expected  20, found  30 
Expected  30, found  40 
Expected  40, found  134596128 
 
This seems to be a front-end problem.  In the dump t.adb.t02.original the 
assignment is: 
 
  A15b[1]{lb: 1 sz: 12}[1]{lb: 2 sz: 4} = 20; 
  A15b[1]{lb: 1 sz: 12}[2]{lb: 2 sz: 4} = 30; 
  A15b[1]{lb: 1 sz: 12}[3]{lb: 2 sz: 4} = 40; 
 
For the first assignment, notice the lower bound of 2, but the assignment to 
element 1.  All the assignments are off by one index. 

-- 


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

[Bug c++/19508] [4.0 regression] dwarf2, ICE on __attribute__(aligned) in class template

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-01-20 
12:19 ---
Paolo, I think I'm going to have a warning like this:

19508.cc:7: warning: cannot apply attributes to template parameter 'T'

for the time being, to warn the user that the attribute is being ignored. I 
hope this does not conflict with some of yours TR1 plans.

-- 


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

[Bug c++/19508] [4.0 regression] dwarf2, ICE on __attribute__(aligned) in class template

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-20 12:26 
---
> Paolo, I think I'm going to have a warning like this:

Well, if I understand well the current status, we *must* warn the user about
that. And, of course, I believe the current (for 4.0, that is) usage in tr1/
type_traits will *not* trigger the warning, because is ok. Indeed, I see the
alignment request respected in this kind of situation:

  template
struct aligned_storage<_Len, 1>
{
  union type
  {
unsigned char __data[_Len];
char __align __attribute__((aligned(1)));
  };
};

-- 


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

[Bug c++/19508] [4.0 regression] dwarf2, ICE on __attribute__(aligned) in class template

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-20 12:32 
---
Anyway, just regtest libstdc++-v3, as I already said: by now we have plenty
of the above usage and plenty of tests. Either at compile time or at run time
something will show up, in case.

-- 


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

[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

[joel at gcc dot gnu dot org]

--- Additional Comments From joel at gcc dot gnu dot org  2005-01-20 12:42 
---
(In reply to comment #10)

> I'm not very fond of the patch because it trades an explicit dependency on
> Solaris for an implicit dependency on NetBSD, bringing the bugs in the 
> process.

In general, I don't like the rtems targets having much meat to them.  
I don't like the implicit dependency either.  

> For example:
> 
> +/* A 64 bit v9 compiler with stack-bias,
> +   in a Medium/Low code model environment.  */
> +
> +#undef TARGET_DEFAULT
> +#define TARGET_DEFAULT \
> +  (MASK_V9 + MASK_PTR64 + MASK_64BIT /* + MASK_HARD_QUAD */ \
> +   + MASK_STACK_BIAS + MASK_APP_REGS + MASK_FPU + MASK_LONG_DOUBLE_128)
> +
> +#undef SPARC_DEFAULT_CMODEL
> +#define SPARC_DEFAULT_CMODEL CM_MEDANY
> 
> Note the discrepancy between the comment (Medium/Low) and the actual setting
> (Medium/Any).  Then in the specs
> 
> +%{p:-mcmodel=medlow} \
> +%{pg:-mcmodel=medlow}}"
> 
> This code model frobbing is a bug that I've asked the NetBSD maintainers to 
> fix,
> with no effect for the time being.

And I unknowingly inherited it.  I trusted that the NetBSD code was right 
to start. :(
 
> > The sparc-elf target probably be reworked in a similar fashion with some
> > sharing with sparc-rtems.  If a sparc maintainer feels this is the correct
> > thing to do, then let's file a PR against sparc-elf and I will fix that.  
> > But
> > that is beyond my maintainership responsibility.
> 
> The bugreport for sparc-elf was posted yesterday on gcc-patches so I now think
> we need to find a generic solution for all the embedded targets.  I proposed 
> to
> duplicate the Solaris configuration files for them and remove the offending 
> bits
> from there; this was agreed upon by Daniel and the RM so I'm going to do it 
> now.

The bug repport was posted or a fix?  This PR covered both sparc-elf and
sparc-rtems* since I verified when I reported it that both were broken.

> Once the work is done, sparc-rtems will very likely build again so your patch
> would not be necessary anymore.  But you're an RTEMS maintainer so I can't bar
> you from installing it anyway if you deem it profitable.

I would rather have a thin sparc-rtems configuration wrapping sparc-elf, so I
won't commit it if you can fix both targets quickly.  Make sure unix is not part
of the cpp predefines on sparc-elf and sparc-rtems when you do, please.

FYI Ralf tracked down one warning we got linking sparc apps to this:

>>>I think the cause is sparc/sparc.h's LINK_GCC_C_SEQUENCE_SPEC:
>>>
>>>#define LINK_GCC_C_SEQUENCE_SPEC "%G %L %G %L"

The RTEMS LIB_SPEC includes a "-T linkcmds" which can only show up in the
final ld command once.  The double inclusion of %L seems to appear and
disappear from release to release.  3.2.x did not have it.

I don't know which target needs this but if it is important to them,
we can override it in rtemself.h.  But I wanted to you watch this one
as you fix sparc-elf/rtems.



-- 


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

[Bug c++/19544] New: Difference in behaviour if default constructor added

[chris at bubblescope dot net]

While looking at PR 19510, I noticed the following strangeness.

Consider:
--
#include
struct ptr
{
int* a;
ptr() {}
};
std::vector v(1);
--
At -O3 -Wall
This code produces the error message:
./include/c++/4.0.0/bits/stl_construct.h: In function 'void
__static_initialization_and_destruction_0(int,int)':
./include/c++/4.0.0/bits/stl_construct.h:81: warning: 'SR.186' is used
uninitalized in this function

This warning is not generated if I declare ptr without a default constructor,
although 12.1/7 seems to imply that the default generated constructor should be
exactly what I have written down.

-- 
   Summary: Difference in behaviour if default constructor added
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: caj at cs dot york dot ac dot uk,gcc-bugs at gcc dot gnu
dot org


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

[Bug c++/19542] attribute(sentinel) has problems with C++ __null

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-01-20 
13:11 ---
__null is 0 of integer type, while attribute sentinel checks for 0 of pointer 
type. Remember this is not the same because it depends on the ABI: on some 
platforms, pushing a 0 of integer type into the stack for a call is different 
from pushing a 0 of pointer type. In fact, using __null for (eg) concat() is 
actually a real bug.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-20 13:18 
---
> You would have to tell me how should I configure gcc-3.4.3 makefiles to 
> compile
> it with mt_allocator.cc.

Unfortunately, that will not suffice, I'm afraid. In order to actually use the
current mt_allocator with 3.4 you have also to change some exports in 
config/linker-map.gnu.

All in all, probably the easiest path is actually testing a snapshot of 4.0: 
each
week a new one is available as a tarball, or you can use CVS.


-- 


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

[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2005-01-20 13:25 
---
Adding ssemmx keyword, because this problem is triggered by -mfpmath=sse.

-- 
   What|Removed |Added

   Keywords||ssemmx


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

[Bug libstdc++/19545] New: static libstdc++.a does not link against shared objects

[niki dot waibel at gmx dot net]

i usually compile c++ code using static libstdc++, which is no problem on:
i386-pc-solaris2.9, sparc-sun-solaris2.8, sparc-sun-solaris2.9 and i686-pc-
linux-gnu using gcc-3.4.3 and binutils-2.15.94.0.2.

only on x86_64-unknown-linux-gnu i get (not always, but very often) sthg like
===
/misc/x86_64-unknown-linux-gnu/bin/ld: /misc/x86_64-unknown-linux-gnu/opt/gcc/3.
4.3/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/libstdc++.a(allocator.o): relocation 
R_X86_64_32S against `__gnu_cxx::__pool_alloc_base::_S_free_list' can not be 
used when making a shared object; recompile with -fPIC
/misc/x86_64-unknown-linux-gnu/opt/gcc/3.4.3/lib/gcc/x86_64-unknown-linux-gnu/3.
4.3/libstdc++.a(allocator.o): could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libdb_cxx-4.3.la] Error 1
===
i know that this can be solved using the shared version of libstdc++, but i'd 
like to have binaries with do not depend on libstdc++ AND i'd like to 
understand 
what's wrong here.

(maybe this is a binutils problem -- i am not sure...)

-- 
   Summary: static libstdc++.a does not link against shared objects
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: niki dot waibel at gmx dot net
CC: gcc-bugs at gcc dot gnu dot org
 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=19545

[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-20 
13:33 ---
(In reply to comment #12)
>
> FYI Ralf tracked down one warning we got linking sparc apps to this:
> 
> >>>I think the cause is sparc/sparc.h's LINK_GCC_C_SEQUENCE_SPEC:
> >>>
> >>>#define LINK_GCC_C_SEQUENCE_SPEC "%G %L %G %L"

> The RTEMS LIB_SPEC includes a "-T linkcmds" which can only show up in the
> final ld command once.  The double inclusion of %L seems to appear and
> disappear from release to release.  3.2.x did not have it.
We had a local fix for 3.*.

> I don't know which target needs this but if it is important to them,
FWIW: IMO, all targets implcitly relying on the sparc/sparc.h's
LINK_GCC_C_SEQUENCE_SPEC are broken.
Grep'ing the sources reveals all major sparc-targets to override this
LINK_GCC_C_SEQUENCE_SPEC, so I don't expect removing it there to do much harm.

Probably, "%G %L %G %L" also is SunOS/Solaris specific and actually does not
belong into sparc.h. Also, I fail to understand how "LINK_GCC_C_SEQUENCE_SPEC"
can be target-cpu specific. It is target-os specific.

> we can override it in rtemself.h.
I don't really like this. IMO, the sparc backend suffers from its SunOS/Solaris
history and should be cleaned up.

-- 


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

[Bug c++/19542] attribute(sentinel) has problems with C++ __null

[marcus at jet dot franken dot de]

--- Additional Comments From marcus at jet dot franken dot de  2005-01-20 
13:44 ---
well, i am not specifying the NULL, the code actually has "NULL". 
 
However it gets defined by the gcc stdef.h file: 
 
#if defined (_STDDEF_H) || defined (__need_NULL) 
#undef NULL /* in case  has defined it. */ 
#ifdef __GNUG__ 
#define NULL __null 
#else   /* G++ */ 
#ifndef __cplusplus 
#define NULL ((void *)0) 
#else   /* C++ */ 
#define NULL 0 
#endif  /* C++ */ 
#endif  /* G++ */ 
#endif  /* NULL not defined and  or need NULL.  */ 
#undef  __need_NULL 
 
 
So: 
- is gcc wrong? 
- should the code always use (type*)NULL  in such vararg lists? 

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

[bangerth at dealii dot org]

-- 
   What|Removed |Added

Summary|MMX load intrinsic produces |MMX load intrinsic produces
   |SSE superflus instructions  |SSE superfluous instructions
   |(movlps)|(movlps)


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

[Bug c++/19508] [4.0 regression] dwarf2, ICE on __attribute__(aligned) in class template

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-01-20 
14:05 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01325.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

[joel at gcc dot gnu dot org]

--- Additional Comments From joel at gcc dot gnu dot org  2005-01-20 14:17 
---
(In reply to comment #13)
> (In reply to comment #12)
> >
> > FYI Ralf tracked down one warning we got linking sparc apps to this:
> > 
> > >>>I think the cause is sparc/sparc.h's LINK_GCC_C_SEQUENCE_SPEC:
> > >>>
> > >>>#define LINK_GCC_C_SEQUENCE_SPEC "%G %L %G %L"
> 
> > The RTEMS LIB_SPEC includes a "-T linkcmds" which can only show up in the
> > final ld command once.  The double inclusion of %L seems to appear and
> > disappear from release to release.  3.2.x did not have it.
> We had a local fix for 3.*.
> 
> > I don't know which target needs this but if it is important to them,
> FWIW: IMO, all targets implcitly relying on the sparc/sparc.h's
> LINK_GCC_C_SEQUENCE_SPEC are broken.
> Grep'ing the sources reveals all major sparc-targets to override this
> LINK_GCC_C_SEQUENCE_SPEC, so I don't expect removing it there to do much harm.
> 
> Probably, "%G %L %G %L" also is SunOS/Solaris specific and actually does not
> belong into sparc.h. Also, I fail to understand how "LINK_GCC_C_SEQUENCE_SPEC"
> can be target-cpu specific. It is target-os specific.
> 
> > we can override it in rtemself.h.
> I don't really like this. IMO, the sparc backend suffers from its 
> SunOS/Solaris
> history and should be cleaned up.

Ralf pointed out in a private email that this definition in sparc.h is 
inconsistent with that used by other targets and the generic config/rtems.h
works fine on all other *-rtems* targets.  He is really right.  The sparc
is inconsistent and if Solaris really needs this, they should override the
normal GCC value. 

-- 


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

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
14:49 ---
Note PR 18755 blocks this if we go the SRA after loop optimization which seems 
like a better idea.

-- 
   What|Removed |Added

  BugsThisDependsOn||18755


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
14:52 ---
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.

I should note this looks like a latent bug.  Could you attach the 
-fdump-tree-all -fdump-rtl-all-all 
dumps?

-- 


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

[Bug libstdc++/8246] Cast increases alignment in __default_alloc_template on Sparcs

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-20 14:51 
---
The original problem has been fixed and the HP/SGI pool_allocator is in deep
bug fix only mode now.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/19544] Difference in behaviour if default constructor added

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
14:56 ---
This is a library bug.

-- 
   What|Removed |Added

  Component|c++ |libstdc++
   Keywords||diagnostic


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

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

[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-20 14:57 ---
Subject: Re:  unrolling happens too late/SRA
 does not happen late enough

> Note PR 18755 blocks this if we go the SRA after loop optimization which
> seems like a better idea.

I do not completely understand this sentence ;)  I argue that SRA after
loop is a bad idea, because SRA, in my testcases, will expose new
oportunities for selecting ivs, so we'll need to run another loop after
SRA.  So I chose for

  loop0
  sra
  loop

instead of

  sra
  loop
  sra
  loop

which is one pass less.  Also with -ftree-early-loop-optimize we get
in .vars for PR18755:

;; Function float foobar() (_Z6foobarv)

float foobar() ()
{
:
  return a.array[3] * b.array[3] + b.array[2] * a.array[2] + b.array[1] *
a.array[1] + a.array[0] * b.array[0] + 0.0;

}

which is what we want?  Or do we now just paper over another problem here?

I'm confused...

Richard.



-- 


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

[Bug libstdc++/19545] static libstdc++.a does not link against shared objects

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
14:59 ---
  --with-pic  try to use only PIC/non-PIC objects default=use both


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/19542] attribute(sentinel) has problems with C++ __null

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
15:00 ---
C++ is differrent from C.
NULL in C++ is defined special in that it is defined as an int but C is 
different.  You should always use a 
cast when you passing to a varargs otherwise you might get a problem on 64bit 
targets and otherwise.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/18946] [4.0 regression] ICE in pushdecl

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
15:02 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c++/19542] attribute(sentinel) has problems with C++ __null

[marcus at jet dot franken dot de]

--- Additional Comments From marcus at jet dot franken dot de  2005-01-20 
15:05 ---
thanks! 

-- 


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

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-01-20 
15:06 ---
Subject: Re:  unrolling happens too late/SRA
 does not happen late enough



On Thu, 20 Jan 2005, 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-20 14:57 ---
> Subject: Re:  unrolling happens too late/SRA
> does not happen late enough
>
>> Note PR 18755 blocks this if we go the SRA after loop optimization which
>> seems like a better idea.
>
> I do not completely understand this sentence ;)  I argue that SRA after
> loop is a bad idea, because SRA, in my testcases, will expose new
> oportunities for selecting ivs, so we'll need to run another loop after
> SRA.

Wiat, why are we running SRA twice again at all?
I can't figure this out from the bug report, other than seeing that we 
"could sra c.array", but i don't see why that requires a loop opt first.

If you are just trying to convince it that constant indexed accesses to 
each prat of that array is actually a different element, the 
structure-aliasing branch will help (though not quite yet, because i've 
punted on array_ref until i add the code to not punt when we have constant 
indexed array_ref)


-- 


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

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
15:07 ---
(In reply to comment #9)
> Subject: Re:  unrolling happens too late/SRA
>  does not happen late enough
> 
> which is what we want?  Or do we now just paper over another problem here?

Yes you are paper over another problem.  The point is ivopts and unroll are 
interacting badly here, how 
I don't know, but unroll is not marking the new ADDR_EXPR as invariant which 
causes the problem I am 
see. No SRA should happen after loop.  Nothing else at least for the current 
time. Loop setup is too 
slow at this point.  Once we have more and more optimizations which keep 
uptodate the loop structors 
we can do an early unrolling.

-- 


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

[Bug pch/19540] document pch directory feature

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
15:13 ---
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompiled-Headers

If you need to precompile the same header file for different languages, 
targets, or compiler options, 
you can instead make a directory named like all.h.gch, and put each precompiled 
header in the 
directory, perhaps using -o. It doesn't matter what you call the files in the 
directory, every precompiled 
header in the directory will be considered. The first precompiled header 
encountered in the directory 
that is valid for this compilation will be used; they're searched in no 
particular order.

So this was documented already.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/19544] Difference in behaviour if default constructor added

[chris at bubblescope dot net]

--- Additional Comments From chris at bubblescope dot net  2005-01-20 15:14 
---
Heres another test-case...

#include

struct ptr
{
int* a;
ptr() {}
};

struct foo
{
ptr array[1];
foo() { std::uninitalized_fill_n(array,1,ptr()); }
};

foo f;

Which shows it isn't limited to libstdc++ (assuming uninitalized_fill_n is
correct, which I'm fairly sure it is).

-- 


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

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

[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-20 15:15 ---
Subject: Re:  unrolling happens too late/SRA
 does not happen late enough

On 20 Jan 2005, dberlin at dberlin dot org wrote:

> Wiat, why are we running SRA twice again at all?
> I can't figure this out from the bug report, other than seeing that we
> "could sra c.array", but i don't see why that requires a loop opt first.

We don't run sra twice.  But an early loop unrolling will change f.i.

  for (unsigned int d=0; d<4; ++d)
c.array[d] = a.array[d] * b.array[d];

to

c.array[0] = a.array[0] * b.array[0];
c.array[1] = a.array[1] * b.array[1];
c.array[2] = a.array[2] * b.array[2];
c.array[3] = a.array[3] * b.array[3];

and SRA can only scalarize this variant, not if the loop is still
there.  That's the whole point of the loop<->sra ordering problem.
And of course sra may then expose new interesting choices for iv's
of outer loops - at least I think.

Richard.

--
Richard Guenther 
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/



-- 


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

[Bug libstdc++/19544] Difference in behaviour if default constructor added

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
15:21 ---
Invalid, as you default constructor is not doing its job of initializing:
ptr() {}



-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 
15:24 ---
> The bug repport was posted or a fix?  This PR covered both sparc-elf and
> sparc-rtems* since I verified when I reported it that both were broken.

Bug report and fix, but the fix was to link sol2-c.c in.

> I would rather have a thin sparc-rtems configuration wrapping sparc-elf, so I
> won't commit it if you can fix both targets quickly.  Make sure unix is not
> part of the cpp predefines on sparc-elf and sparc-rtems when you do, please.

Sure.  I'll post it to gcc-patches and CC the interested parties so that they
could comment, before commiting it.

[About LINK_GCC_C_SEQUENCE_SPEC]

> I don't know which target needs this but if it is important to them,
> we can override it in rtemself.h.  But I wanted to you watch this one
> as you fix sparc-elf/rtems.

It comes from: http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00176.html

The V7 variant of libgcc/_muldi3.o has a dependency on .umul (and _divdi3.o on
.udiv) which are provided by the libc because V7 doesn't have the instructions.
So we need the double group-inclusion of "%G %L" by default, unless the linker
is smarter (like on Linux).

> Probably, "%G %L %G %L" also is SunOS/Solaris specific and actually does not
> belong into sparc.h. Also, I fail to understand how "LINK_GCC_C_SEQUENCE_SPEC"
> can be target-cpu specific. It is target-os specific.

It is actually ABI-specific.  I think the V7 ABI more or less mandates it.


-- 


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

[Bug pch/19541] deprecation of -I- makes precompiled headers less usable

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
15:29 ---
Actually I don't understand the problem, using a PCH directory file makes this 
work without any trouble 
really and without any thinking (and I already showed that it was documented).

-- 


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

[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 
15:31 ---
> FWIW: IMO, all targets implicitly relying on the sparc/sparc.h's
> LINK_GCC_C_SEQUENCE_SPEC are broken.

I don't think so.  I can tell you for sure that Solaris is not broken.

> Grep'ing the sources reveals all major sparc-targets to override this
> LINK_GCC_C_SEQUENCE_SPEC, so I don't expect removing it there to do much harm.

Note the Linux variant: "%{static:--start-group} %G %L %{static:--end-group}"
which means that the group "%G %L" is repeatedly searched.  Of course the Sun
linker (at least the ancient versions) is not that smart so we need to use the
double inclusion by default.

> Probably, "%G %L %G %L" also is SunOS/Solaris specific and actually does not
> belong into sparc.h. Also, I fail to understand how "LINK_GCC_C_SEQUENCE_SPEC"
> can be target-cpu specific. It is target-os specific.

It is actually ABI-specific.  I think the V7 ABI more or less mandates it.

> I don't really like this. IMO, the sparc backend suffers from its
> SunOS/Solaris history and should be cleaned up.

The default values of settings are indeed chosen for Solaris and I don't expect
to change that in the near future.


-- 


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

[Bug fortran/19546] New: Internal subroutine setting function return value gives internal compiler error

[nburrell at unc dot edu]

With gcc 4.0.0 20050119 
on powerpc-apple-darwin7.7.0 (Dual G5 mac running Mac OS X 10.3.7) 
and GCC configured with: /Users/nburrell/Desktop/gcc-4.0-cvs/gcc/configure 
--with-mpfr=/Users/
nburrell/usr --with-gmp=/Users/nburrell/usr --prefix=/Users/nburrell/usr 
--enable-
languages=c,f95

running the command gfortran -Wall -v -save-temps test_gfortran.f90 gives the 
following output:

[EMAIL PROTECTED]/isis_home/research/pvsim/test]$ gfortran -Wall -v -save-temps 
test_gfortran.f90
Driving: gfortran -Wall -v -save-temps test_gfortran.f90 -lgfortranbegin 
-lgfortran -shared-libgcc
Using built-in specs.
Configured with: /Users/nburrell/Desktop/gcc-4.0-cvs/gcc/configure 
--with-mpfr=/Users/nburrell/
usr --with-gmp=/Users/nburrell/usr --prefix=/Users/nburrell/usr 
--enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050119 (experimental)
 /Users/nburrell/usr/libexec/gcc/powerpc-apple-darwin7.7.0/4.0.0/f951 
test_gfortran.f90 -fPIC 
-quiet -dumpbase test_gfortran.f90 -auxbase test_gfortran -Wall -version -o 
test_gfortran.s
GNU F95 version 4.0.0 20050119 (experimental) (powerpc-apple-darwin7.7.0)
compiled by GNU C version 4.0.0 20050118 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
test_gfortran.f90: In function 'set_value':
test_gfortran.f90:15: internal compiler error: in gfc_conv_variable, at 
fortran/trans-expr.c:317
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

where test_gfortran.f90 has the following contents:

MODULE random_standard_normal_mod

  IMPLICIT NONE

CONTAINS

  FUNCTION random_standard_normal()
IMPLICIT NONE

REAL :: y
REAL :: random_standard_normal

y = 4.

CALL set_value
RETURN

  CONTAINS

SUBROUTINE set_value

  IMPLICIT NONE

  random_standard_normal = y
END SUBROUTINE set_value
  END FUNCTION random_standard_normal
END MODULE random_standard_normal_mod

-- 
   Summary: Internal subroutine setting function return value gives
internal compiler error
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nburrell at unc dot edu
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-apple-darwin7.7.0


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

[Bug fortran/19543] formated output for logical(8) variables fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
15:35 ---
  int4 C.417 = 0;
  int4 C.416 = 0;

  _gfortran_transfer_logical (&C.417, 8);



-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2005-01-20 15:35:42
   date||


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

[Bug c++/19542] attribute(sentinel) has problems with C++ __null

[matz at suse dot de]

--- Additional Comments From matz at suse dot de  2005-01-20 15:35 ---
I agree that C++ is special, and that NULL in C++ is only a null pointer 
constant (but not a null pointer).  Hence, yes, strictly speaking a cast 
would be needed even for NULL in va_lists. 
 
But, as a matter of fact, GCC defines __null as an integer node having value 
zero, and type exactly as wide as a pointer would be (i.e. somewhat 
similar to 0L).  So, giving this to a va_list, which expects a pointer 
would work correctly, also on LP64 platforms.  This is the reason for the 
existance of __null (as otherwise we could simply define NULL to "0" and 
still be completely standard conformant).  This suggests that those 
who implemented __null did it because they wanted to enable its use 
in situations where in C a lonely "NULL" is enough. 
 
As a QOI issue it would be better if this warning wouldn't trigger for this 
use.  In our packages it triggers quite often in C++ code, most of them 
being false positives.  That's in difference to C, where most of these 
warnings indeed are problems for LP64 platforms. 
 
I believe (but haven't verified) that the warning could additionally check 
for the node being == null_node, and not warn in this case.  This wouldn't 
make the warning less usefull AFAICS, and for C++ would reduce the number 
of false positives. 

-- 


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

[Bug fortran/19546] Internal subroutine setting function return value gives internal compiler error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
15:42 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-01-20 15:42:32
   date||


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

[Bug pch/19541] deprecation of -I- makes precompiled headers less usable

[Ralf dot Wildenhues at gmx dot de]

--- Additional Comments From Ralf dot Wildenhues at gmx dot de  2005-01-20 
15:47 ---
mkdir src build
echo 'extern int foo;' > src/foo.h
echo >src/bar.c '#include "foo.h"
int bar(void) { return foo; }'
cd build
gcc -o foo.h.gch ../src/foo.h
gcc -H -c ../src/bar.c

This will not use the gch in the current directory,
unless I also specify `-I. -I-'.

Putting the pch under the source tree works against all VPATH build
principles (read-only source tree).  It does not matter whether I
use a directory build/foo.h.gch/ or a file.

(The other bug I reported was indeed false, apologies for the
reading disability that struck me there.)

-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
15:56 ---
Created an attachment (id=8008)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8008&action=view)
C failing source code


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
15:57 ---
Created an attachment (id=8009)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8009&action=view)
preprocessed source code


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
15:58 ---
Created an attachment (id=8010)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8010&action=view)
00.expand


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
15:58 ---
Created an attachment (id=8011)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8011&action=view)
original


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
15:59 ---
Created an attachment (id=8012)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8012&action=view)
generic


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
15:59 ---
Created an attachment (id=8013)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8013&action=view)
vcg


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
16:00 ---
Created an attachment (id=8014)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8014&action=view)
gimple


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
16:00 ---
Created an attachment (id=8015)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8015&action=view)
useless


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
16:01 ---
Created an attachment (id=8016)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8016&action=view)
lower


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
16:01 ---
Created an attachment (id=8017)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8017&action=view)
eh


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
16:02 ---
Created an attachment (id=8018)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8018&action=view)
cfg


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-20 
16:03 ---
Created an attachment (id=8019)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8019&action=view)
oplower

OK, that's it.

-- 
   What|Removed |Added

Attachment #7972 is|0   |1
   obsolete||
Attachment #7979 is|0   |1
   obsolete||
Attachment #7980 is|0   |1
   obsolete||


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

[Bug target/19491] va_start incorrect, Number of floating point and integer registers counted incorrectly

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-01-20 16:07 
---
GCC 3.3 used the magic number of 1000 when initializing the number of 
arguments.  This bug report does not state the exact failure mode of the 
example, but the slightly greater than 1000 words (256 arguments) might 
interact incorrectly with the magic value 1000.  The use of "1000" was removed 
in GCC 3.4, so I would recommend retesting with that GCC release.  The lack of 
description about the failure makes it difficult for anyone else to confirm 
the report or test if the problem already is corrected.

-- 


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

[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-20 
16:11 ---
(In reply to comment #16)
> > FWIW: IMO, all targets implicitly relying on the sparc/sparc.h's
> > LINK_GCC_C_SEQUENCE_SPEC are broken.
> 
> I don't think so.  I can tell you for sure that Solaris is not broken.
> 
> > Grep'ing the sources reveals all major sparc-targets to override this
> > LINK_GCC_C_SEQUENCE_SPEC, so I don't expect removing it there to do much 
> > harm.
> 
> Note the Linux variant: "%{static:--start-group} %G %L %{static:--end-group}"
> which means that the group "%G %L" is repeatedly searched. 

Hmm, we have 
--start-group  -lrtemsbsp -lrtemscpu  -lc -lgcc --end-group
in all of RTEMS-gcc specs. This might explain, why we don't see this issue.

> Of course the Sun
> linker (at least the ancient versions) is not that smart so we need to use the
> double inclusion by default.
Note _Sun_, not _sparc_.

-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-01-20 16:37 
---
With binutils bfd/version.h:
#define BFD_VERSION_DATE 20050115
and everything else as in original
description, I still get the same error.
(Needed to rm -rf gprof to get past
a binutils-specific error.)
Will now try today's binutils CVS.

-- 


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

[Bug c/19547] New: floating point registers not preserved during function call

[jack at cs dot york dot ac dot uk]

This is a bug report for GCC 2.95.3. The bug also exists in 2.95.2.
I am cross-compiling for arm-linux on an i386 Linux system, using
the command line:
arm-linux-gcc -static -O -g -c au1.c

The code fragment below is taken from the mpeg2enc package. When
compiled with -O, it does not work correctly: the value of s changes
between the line marked XXX and the line marked YYY. This is because
s is stored in register f5, which is clobbered by __kernel_cos, a
glibc function called by cos. I don't know whether f5 should be
preserved by the calling function or the callee, but nothing is preserving
it at present, and this results in the bug.

The code works correctly when compiled without optimisation, because the
value of s is stored on the stack.

I don't think that this problem is confined to register f5 or the
functions involved here, but I don't have any evidence for that.
It occurs with any level of optimisation, not just -O.

// Code fragment: (note: based on init_fdct() in fdctref.c, in mpeg2enc)

#include 

#define PI M_PI

void Test ( double c [ 8 ][ 8 ] )
{
  int i, j;
  double s;

  for (i=0; i<8; i++)
  {
s = (i==0) ? sqrt(0.125) : 0.5;

printf ( "Begin: s = %1.4f\n" , s ) ; // XXX
for (j=0; j<8; j++)
{
double p = PI / 8.0 ;

printf ( " p: %1.4f " , p ) ;

p *= (double) i ; 
printf ( "%1.4f " , p ) ;

p *= ( (double) j ) + 0.5 ;
printf ( "%1.4f " , p ) ;

p = cos ( p ) ; 
printf ( "%1.4f " , p ) ;

p *= s ; 
printf ( "%1.4f\n" , p ) ;

c [ i ][ j ] = p ;
}
printf ( "Now: s = %1.4f\n" , s ) ; // YYY
  }
}

// End code fragment

Here is a typical output produced by one iteration (i = 1) of the outer
for loop, when compiled with -O.

Begin: s = 0.5000
 p: 0.3927 0.3927 0.1963 0.9808 0.
 p: 0.3927 0.3927 0.5890 0.8315 0.
 p: 0.3927 0.3927 0.9817 0.5556 0.
 p: 0.3927 0.3927 1.3744 0.1951 0.
 p: 0.3927 0.3927 1.7671 -0.1951 -0.
 p: 0.3927 0.3927 2.1598 -0.5556 -0.
 p: 0.3927 0.3927 2.5525 -0.8315 -1.7958
 p: 0.3927 0.3927 2.9452 -0.9808 -2.1183
Now: s = 2.1598

As you can see, s has changed.



Here is a disassembly of the Test() function when optimised with -O:

// Begin disassembly

au1.o: file format elf32-littlearm

Disassembly of section .text:

 :

#define PI M_PI

void Test ( double c [ 8 ][ 8 ] )
{  
   0:   e1a0c00dmov ip, sp
   4:   e92dd8f0stmdb   sp!, {r4, r5, r6, r7, fp, ip, lr, pc}
   8:   ed6d4206sfm f4, 2, [sp, #-24]!
   c:   e24cb004sub fp, ip, #4  ; 0x4
  10:   e1a07000mov r7, r0
  int i, j;
  double s;
  
  for (i=0; i<8; i++)
  14:   e3a06000mov r6, #0  ; 0x0
  { 
s = (i==0) ? sqrt(0.125) : 0.5;
  18:   e356cmp r6, #0  ; 0x0
  1c:   1a11bne 68 <.text+0x68>
  20:   ed9f9107ldfdf1, [pc, #28]
  24:   ee408181sqtdf0, f1
  28:   ee90f110cmf f0, f0
  2c:   0a0dbeq 68 <.text+0x68>
  30:   ed2d9102stfdf1, [sp, #-8]!
  34:   e8bd0003ldmia   sp!, {r0, r1}
  38:   ebfebl  38 
  3c:   ee00d180mvfdf5, f0
  40:   ea12b   90 <.text+0x90>
  44:   3fc0swicc   0x00c0
  48:   andeq   r0, r0, r0
  4c:   ee00d18emvfdf5, #0.5

printf ( "Begin: s = %1.4f\n" , s ) ; // XXX
  50:   e59f00c0ldr r0, [pc, #192]  ; 118 <.text+0x118>
  54:   ed2dd102stfdf5, [sp, #-8]!
  58:   e8bd0006ldmia   sp!, {r1, r2}
  5c:   ebfebl  5c <.text+0x5c>
for (j=0; j<8; j++)
  60:   e3a04000mov r4, #0  ; 0x0
  64:   e59f50b0ldr r5, [pc, #176]  ; 11c <.text+0x11c>
{
double p = PI / 8.0 ;
  68:   ed9fc12cldfdf4, [pc, #176]

printf ( " p: %1.4f " , p ) ;
  6c:   e59f00b4ldr r0, [pc, #180]  ; 128 <.text+0x128>
  70:   ed2dc102stfdf4, [sp, #-8]!
  74:   e8bd0006ldmia   sp!, {r1, r2}
  78:   ebfebl  78 <.text+0x78>

p *= (double) i ;
  7c:   ee006190fltdf0, r6
  80:   ee104184mufdf4, f0, f4
printf ( "%1.4f " , p ) ;
  84:   e1a5mov r0, r5
  88:   ed2dc102stfdf4, [sp, #-8]!
  8c:   e8bd0006ldmia   sp!, {r1, r2}
  90:   ebfebl  90 <.text+0x90>

p *= ( (double) j ) + 0.5 ;
  94:   ee004190fltdf0, r4
  98:   ee00018eadfdf0, f0, #0.5
  9c:   ee144180mufdf4, f4, f0
printf ( "%1.4f " , p ) ; 
  a0:   e1a5mov r0, r5
  a4:   ed2dc102stfdf4, [sp, #-8]!
  a8:   e8bd0006ldmia   sp!, {r1, r2}
  ac:   ebfebl  ac <.text+0xac>
  
p = cos ( p ) ;
  b0:   ed2dc102stfdf4, [sp, #-8]!
  b4:   e8bd0003ldmia   sp!, {r0, r1}
  b8:   ebfebl  b8 <.text+0xb8>
  bc:   ee00c180mvfdf4, f0
printf ( "%1.4f " , p ) ;
  c0:   e1a5mov r0, r5
  c4:   ed2dc102stfdf4, [sp, #-8]!
  c8:   e8bd0006ldmia   sp!, {r1, r2}
  cc:   ebf

[Bug c/19547] floating point registers not preserved during function call

[jack at cs dot york dot ac dot uk]

--- Additional Comments From jack at cs dot york dot ac dot uk  2005-01-20 
16:40 ---
Created an attachment (id=8020)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8020&action=view)
Preprocessor output for the code fragment


-- 


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

[Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 
17:01 ---
> With binutils bfd/version.h:
> #define BFD_VERSION_DATE 20050115
> and everything else as in original
> description, I still get the same error.

Ouch!  Daniel Jacobowitz once said this error can originate in an old assert.h
lying around somewhere.

I can tell you that I can bootstrap current GCC mainline with all languages
enabled and Binutils 2.15 CVS or 2.15.94 CVS on the 5 SPARC/Solaris machines I
have access to (Solaris 2.5.1, 2.6, 7, 8 and 9).


-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
17:17 ---
Thanks for the dumps, this looks like a middle-end which can be reproduced 
without changing 
flags_complex_divide_method, let me try to get a testcase for that.  (but first 
I have to read my other 
emails).

-- 


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

[Bug c/19547] floating point registers not preserved during function call

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-01-20 
17:18 ---
It's the callee's responsibility to save f4...f7 if it wants to use them.  So
the problem is in glibc.

Note that gcc 2.95 isn't supported any more, so the most we'd likely do in this
sort of case is fix the latest release if it could be shown to have the same
problem.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary| floating point registers   |floating point registers not
   |not preserved during|preserved during function
   |function call   |call


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

[Bug c/19547] floating point registers not preserved during function call

[jack at cs dot york dot ac dot uk]

--- Additional Comments From jack at cs dot york dot ac dot uk  2005-01-20 
17:35 ---
> It's the callee's responsibility to save f4...f7 if it wants to use them.  So 
>   
the problem is in glibc. 

Ah, I see.

However, when I recompile the glibc function in question (__kernel_cos), f4...f7
are not saved. As the function is written entirely in C, surely this must be the
fault of the compiler?

This is glibc-2.1.3, and the file I am recompiling is
sysdeps/libm-ieee754/k_cos.c (which I will attach).


-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c/19547] floating point registers not preserved during function call

[jack at cs dot york dot ac dot uk]

--- Additional Comments From jack at cs dot york dot ac dot uk  2005-01-20 
17:37 ---
Created an attachment (id=8021)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8021&action=view)
glibc function in which floating point registers are not preserved


-- 


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

[Bug c/19547] floating point registers not preserved during function call

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
17:37 ---
(In reply to comment #3)
> This is glibc-2.1.3, and the file I am recompiling is
> sysdeps/libm-ieee754/k_cos.c (which I will attach).

Well consider 2.95.3 is old nothing matters unless you try a newer compiler.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/19548] New: RTEMS CPP specs not merged from 3.2/3.2 branches

[joel at gcc dot gnu dot org]

Somehow, this necessary patch was only applied to the 3.2 and 3.3 release
branches.  The RTEMS community has skipped the 3.4 branch so never noticed it
missing there.  Anyway, it never got on the head.

http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/sysv4.h?rev=1.113.4.1&content-type=text/x-cvsweb-markup

We didn't notice it until we were paying attention to RTEMS build failures.
The toolset will build without this but isn't functional.

Is this OK to merge?

-- 
   Summary: RTEMS CPP specs not merged from 3.2/3.2 branches
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,ralf dot corsepius at
rtems dot org
GCC target triplet: powerpc-rtems


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
17:54 ---
Oh, I know where the problem is, we are missing a goto:
:;
  D.2703 = D.2697;
  D.2704 = D.2698;


Should have a goto associated with it.

-- 


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

[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|enhancement |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-20 18:00:11
   date||


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

[Bug c++/19076] Pointer to member function not matched to pointer to member template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-20 
18:02 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 18:03 
---
(In reply to comment #12)
> But, what about structures that contain a union?

We'll need to consider the question "do we need to clear" one nesting
level at a time, and propagate it up.


-- 


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

[Bug target/19491] va_start incorrect, Number of floating point and integer registers counted incorrectly

[suriya at cs dot utexas dot edu]

--- Additional Comments From suriya at cs dot utexas dot edu  2005-01-20 
18:05 ---
Created an attachment (id=8022)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8022&action=view)
Test case, should return success


-- 


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

[Bug target/19491] va_start incorrect, Number of floating point and integer registers counted incorrectly

[suriya at cs dot utexas dot edu]

--- Additional Comments From suriya at cs dot utexas dot edu  2005-01-20 
18:07 ---

(In reply to comment #1)
> GCC 3.3 used the magic number of 1000 when initializing the number of 
> arguments.  This bug report does not state the exact failure mode of the 
> example, but the slightly greater than 1000 words (256 arguments) might 
> interact incorrectly with the magic value 1000.  The use of "1000" was 
> removed 
> in GCC 3.4, so I would recommend retesting with that GCC release.  The lack 
> of 
> description about the failure makes it difficult for anyone else to confirm 
> the report or test if the problem already is corrected.


The same problem exists with GCC 3.4.

Let me restate the problem. va_start(va_list, param) sets fields { gpr, fpr,
overflow_arg_area, reg_save_area } in the va_list structure. `gpr' is an index
into the reg_save_area. Parameters are passed into integer registers r3 through
r10. So, the index into the integer portion of reg_save_area (where the 8
integer registers, followed by the floating point registers are saved) should be
between 0 and 7 (both inclusive) to be meaningful. Any value greater than 7
indicates that the next parameter is not in the integer save area but in
overflow_arg_area.

For example, if the function was int foo(int a0, int a1, ...), then gpr would be
2, to indicate that the next integer parameter (afdter a1) is in offset 2 (the
parameter was passed in r5) of the reg_save_area.

For example, if the function was int foo(int a0, int a1, int a2, int a3, int a4,
int a5, int a6, int a7, ...), then gpr would be 8. This means that this is an
offset greater than 7 and as a result the next integer parameter (passed after
a7) is inthe overflow_arg_area.

For example, if the function was foo(int a0, int a1, int a2, int a3, int a4, int
a5, int a6, int a7, int a8, ...), then gprturns out to be be 9 (confirmed using
 gdb). This is again a value greater than 7 indicating that the next integer
parameter (passed after a8) is in the overflow_arg_area.

va_arg which gets the next argument, compares gpr to 8 to decide from which area
the load the parameter from.

In the above examples, gpr is not bound to a maximum value of 8, but instead
increments for each additional argument. gpr is of type char. As a result, if
there are 256 parameters before the ellipsis '...', gpr takes a value 0 (due to
overflow). This, incorrectly indicates (because va_arg compares gpr to 8, and 0
< 8) that the parameter is in the reg_save_area, though in reality, the
parameter is in the overflow_arg_area.

The test program I sent, had 256 parameters followed by the ellipsis.
va_arg(list, int) should give the value of the 257th parameter (counting from
one), which is  (in the example, the last argument passed by main). The
program should return success, however it doesn't, because of incorrect setting
of gpr in va_start.

-- 


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

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-20 
18:34 ---
Subject: Bug 19530

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-20 18:34:13

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386.c mmintrin.h mmx.md 

Log message:
PR target/19530
* config/i386/mmintrin.h (_mm_cvtsi32_si64): Use
__builtin_ia32_vec_init_v2si.
(_mm_cvtsi64_si32): Use __builtin_ia32_vec_ext_v2si.
* config/i386/i386.c (IX86_BUILTIN_VEC_EXT_V2SI): New.
(ix86_init_mmx_sse_builtins): Create it.
(ix86_expand_builtin): Expand it.
(ix86_expand_vector_set): Handle V2SFmode and V2SImode.
* config/i386/mmx.md (vec_extractv2sf_0, vec_extractv2sf_1): New.
(vec_extractv2si_0, vec_extractv2si_1): New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7201&r2=2.7202
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.786&r2=1.787
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/mmintrin.h.diff?cvsroot=gcc&r1=1.15&r2=1.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/mmx.md.diff?cvsroot=gcc&r1=1.5&r2=1.6



-- 


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