[Bug middle-end/20355] MEM_READONLY_P & MEM_VOLATILE_P properties are lost on BLKmode rtl operands.

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-03-07 
08:50 ---
A testcase?

-- 


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

[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-03-07 
08:51 ---
(In reply to comment #15)

> +case TARGET_EXPR:
> +  {
> + tree r = tsubst_copy (t, args, complain, in_decl);
> +
> + TREE_TYPE (r) = RECUR (TREE_TYPE (t));
> + TARGET_EXPR_SLOT (r) = RECUR (TARGET_EXPR_SLOT (t));
> + TARGET_EXPR_INITIAL (r) = RECUR (TARGET_EXPR_INITIAL (t));
> + TARGET_EXPR_CLEANUP (r) = RECUR (TARGET_EXPR_CLEANUP (t));
> +
> + if (TREE_TYPE (TARGET_EXPR_SLOT (t))
> + == TREE_TYPE (TARGET_EXPR_INITIAL (t)))
> +   TREE_TYPE (TARGET_EXPR_SLOT (r)) =
> + TREE_TYPE (TARGET_EXPR_INITIAL (r));
> +
> + if (TREE_TYPE (t) == TREE_TYPE (TARGET_EXPR_SLOT (t)))
> +   TREE_TYPE (r) = TREE_TYPE (TARGET_EXPR_SLOT (r));
> +
> + return r;
> +  }
> +

Can you add a comment that TARGET_EXPR is being used to represent C99 compound 
literals?


-- 


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

[Bug c/18624] cannot detect local variable set but never used

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-03-07 
08:55 ---
(In reply to comment #3)
> This should be done in the front-ends.

Why? How?


-- 


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

[Bug preprocessor/20356] New: New #include_next behaviour breaks limits.h

[jakub at gcc dot gnu dot org]

If some /usr/include header uses
#include "limits.h"
instead of
#include 
it gets error: #include nested too deeply.
There are 2 limits.h headers, /usr/lib/gcc/*/*/include/limits.h and
/usr/include/limits.h that try to include each other with #include_next,
guarded with the defines that protect multiple header inclusion for the other
one.
" instead of < causes /usr/include/limits.h to be included first
(normally is /usr/lib/gcc/*/*/include/limits.h first) and this does:
#if defined __GNUC__ && !defined _GCC_LIMITS_H_
/* `_GCC_LIMITS_H_' is what GCC's file defines.  */
# include_next 

In older GCC releases, this include_next would load the next limits.h in the
search path, which is /usr/lib/gcc/*/*/include/limits.h, but GCC4 includes
/usr/include/limits.h again (and does so until reaching the nesting limit).

-- 
   Summary: New #include_next behaviour breaks limits.h
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: *-linux


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

[Bug preprocessor/20356] [4.0/4.1 Regression] New #include_next behaviour breaks limits.h

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
09:02 ---
I think this is related to PR 20348.

-- 
   What|Removed |Added

Summary|New #include_next behaviour |[4.0/4.1 Regression] New
   |breaks limits.h |#include_next behaviour
   ||breaks limits.h
   Target Milestone|--- |4.0.0


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

[Bug c++/20357] New: Multiply defined assembler symbols for template instantiations

[heinlein at informatik dot uni-ulm dot de]

The following code produces the assembler message: 
"Error: symbol `_ZN1XIXadL_Z1fvEEEC1Ev' is already defined". 
If the declaration of f in main is omitted, everything is fine. 
 
typedef void (*Func) (); 
template  
struct X { X () {} }; 
void f () {} 
X x; 
int main () { 
  void f (); 
  X x; 
}

-- 
   Summary: Multiply defined assembler symbols for template
instantiations
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heinlein at informatik dot uni-ulm dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-07 09:53 
---
>This is the problem.  From the HP-UX 10 manpage
>
>  If both x and y are zero, atan2() returns NaN.
>
>The behavior changed in HP-UX 11
>
>  If both x and y are zero, atan2() returns zero.

I see. We are assuming the latter behavior, as per IEC 60559, F.9.1.4 of the
C99 Standard. Most current C libraries implement it, indeed. I'm afraid we
can't do much...

-- 


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

[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-07 
09:54 ---
An interesting thing in the head comment of unsafe_for_reeval in 3.4.x:

   This assumes that CALL_EXPRs and TARGET_EXPRs are never replicated in
   an expression tree, so that it safe to unsave them and the surrounding
   context will be correct.

This assumption is violated by the C++ FE.  On the other hand, unsafe_for_reeval
is gone in 4.0 so I'm not sure we really care at this point.


-- 
   What|Removed |Added

 Status|REOPENED|ASSIGNED


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

[Bug c++/20358] New: Data member of local class of friend function of template class considered a member template

[heinlein at informatik dot uni-ulm dot de]

The following code produces the inappropriate error message: 
"data member `a' cannot be a member template". 
 
template  
struct X { 
friend void f () { 
struct L { 
int a; 
}; 
} 
}; 
int main () { X x; }

-- 
   Summary: Data member of local class of friend function of
template class considered a member template
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heinlein at informatik dot uni-ulm dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-07 10:09 
---
Or, better: we can't do much in the right timeframe. When Roger's work will
go in, for float, double and long double complex types will be simply called
pow(0.0, 1.0/3) in this case, instead of the tricky sequence of log, exp, sin
and so on. This will also fix this problem, I think, but only for 4.1, and,
maybe, 4.0.x...

-- 


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

[Bug middle-end/20249] [4.0/4.1 Regression] ICE with -fprofile-arcs on ppc

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-03-07 
10:29 ---
Patch:

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00621.html

-- 
   What|Removed |Added

   Keywords||patch


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

typeinfo and exceptions

[Tim Janik]

hi all.
i really fail to see what i'm doing wrong in the following code:
struct Exception : std::exception {
  Exception (const char *format, ...) __attribute__((__format__ (__printf__, 2, 
3)));
  [...]
};
struct Obj {
  Obj () { throw Exception ("%s: error", typeid (this).name()); }
};
try { Obj a; } catch (std::exception &e) {
  printf ("exception: what(): %s\n", e.what());
}
it does however produce garbage (with 3.3 and 3.4) instead of Obj's typename:
exception: what(): 44`l$@: error
i have attached a full test case with 2 throw statements that
will both produce a garbage typename. i'm not sure this isn't
a compiler bug, so any help is apprechiated.
---
ciaoTJ#include 
#include 
#include 
#include 
#include 

struct Exception : std::exception {
  Exception (const char *format, ...) __attribute__((__format__ (__printf__, 2, 3)));
  virtual const char* what() const throw() { return reason ? reason : "out of memory"; }
  Exception (const Exception &e) : reason (e.reason ? strdup (e.reason) : NULL) {}
  ~Exception() throw() { if (reason) free (reason); }
private:
  char *reason;
  Exception& operator= (const Exception&);
};

Exception::Exception (const char *format, ...)
{
  va_list args;
  va_start (args, format);
  reason = NULL;
  if (asprintf (&reason, format, args) < 0 || !reason)
reason = NULL; /* indicate "out of memory" */
  va_end (args);
}

struct Obj {
  Obj ()
  {
const char *thisname = typeid (this).name();
printf ("A: thisname: %s\n", thisname);
throw Exception ("%s: error", typeid (this).name());
throw Exception ("%s: error", thisname);
  }
};

int
main (int   argc,
  char *argv[])
{
  try {
Obj a;
  } catch (std::exception &e) {
printf ("exception: what(): %s\n", e.what());
  }
  return 0;
}

[Bug c/20359] New: Incorrect code with global register variables

[simonmar at microsoft dot com]

Global register variables rear their ugly head again.  Here's a simple test case
that generates incorrect code on x86_64 with gcc 3.4.2:

$ cat bug.c
register void * R1 __asm__("%r13");

extern void g(void);
static void f(void) {
 R1 = g;
 goto *R1;
}
$ gcc -v  
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
$ gcc -O -S bug.c

The generated code for function f is:

f:
.LFB2:
movl$g, %eax
jmp *%rax

Note the assignment to the global register variable R1 has been lost.

This is breaking the Glasgow Haskell Compiler (http://www.haskell.org/ghc/) on
the x86_64 platform.  It might be related to the (closed) bug #7871.

-- 
   Summary: Incorrect code with global register variables
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simonmar at microsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-*-linux
  GCC host triplet: x86_64-*-linux
GCC target triplet: x86_64-*-linux


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

[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-07 13:48 
---
Created an attachment (id=8350)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8350&action=view)
Tweak to the test at the beginning of pow(const complex<_Tp>&, const _Tp&)


-- 


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

[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-07 13:49 
---
Digging more (in C99 and Posix), it seems that pow(x,y) always behaves the same
for x == +0 and x == -0: this would imply that probably it's safe to have in
the generic code something like the attached (vs mainline, very same change
also for 4.0 and 3.4). And should also improve the QoI of complex::pow(0, 0),
aligning it to the real case, as per F.9.4.4

Can you test it on the targets you have access to?

-- 


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

[Bug c++/20358] Data member of local class of friend function of template class considered a member template

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-03-07 
14:24 ---
Yes, this is a bug in GCC 3.3.x and earlier versions.
Bug fixes to GCC 3.3.x branch is now limited to certain
regression.  So this bug will not be fixed there.
The latest released branch, GCC 3.4.x, does not have this bug.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/20357] Multiply defined assembler symbols for template instantiations

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-03-07 
14:29 ---
Confirm as a bug.  It's still present in the mainline.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-07 14:29:51
   date||


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

[Bug testsuite/20360] New: 20021014-1.c fails on account of unsupported build option

[tprince at computer dot org]

FAIL: gcc.dg/20021014-1.c (test for excess errors)

may be corrected by adding cygwin as one of the target platforms which use -pg,
according to the following patch:

*** 20021014-1.cFri Sep  3 11:09:33 2004
--- new/20021014-1.cMon Mar  7 06:03:27 2005
***
*** 3,6 
--- 3,7 
  /* { dg-options "-O2 -p" } */
  /* { dg-options "-O2 -p -static" { target hppa*-*-hpux* } } */
+ /* { dg-options "-O2 -pg" { target *-*-cygwin* } } */
  /* { dg-error "profiler" "No profiler support" { target xstormy16-*-* } 0 } */
  /* { dg-error "" "consider using `-pg' instead of `-p' with gprof(1)" { target
 *-*-freebsd* } 0 } */

-- 
   Summary: 20021014-1.c fails on account of unsupported build
option
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tprince at computer dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-07 
14:44 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable 
types

On Mar  7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:

> Alexandre Oliva wrote:
>>> This doesn't look quite right.  First, we're trying to get rid of
>>> tsubst_copy; we should not add new calls.  You should do the RECURs
>>> here, and then build up the new node.
>> I'd have to use build3 (TARGET_EXPR...) or introduce a new call to
>> create a target_expr with given slot, initial and cleanup, because
>> AFAICT there isn't any that takes a cleanup.

> Yes, you should use build3.

Ok.

>> They don't, and they can't without this piece of code.  When we tsubst
>> INITIAL, an incomplete array type (T[]), that had been used as the
>> type of the slot and the target_expr itself in
>> finish_compound_literal(), called while processing a template,
>> digest_init() (or something else; I no longer remember exactly)
>> completes the array type with the number of entries in the INITIAL
>> CONSTRUCTOR.

> Then you should tsubst the INITIAL first, and unconditionally copy the
> type to the TARGET_EXPR when you use build3.

But what if the TARGET_EXPR had been created for different purposes,
and did have a different type than that of the initializer?  Say, a
Base& being bound to a Derived TARGET_EXPR?  That's why I'm performing
the tests the way I am.

> Or, even better, call
> the same functions in semantics.c that the parser would call if not in
> a template.  In other words, call finish_compound_literal again, from
> pt.c.  That's the overall design: we try to reuse the same semantic
> routines again at template instantiation time.

Yeah, I know we'd like to do that, but we can't.  At that point we
have no clue what that TARGET_EXPR or the CONSTRUCTOR in its initial
came from.  We'd have to create a new tree node type for compound
literals to be able to call finish_compound_literal at that point.



-- 


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

[Bug target/20360] 20021014-1.c fails on account of unsupported build option

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|testsuite   |target


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

[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-03-07 14:52 ---
Subject: Re:  FAIL: 26_numerics/complex/pow.cc execution test

> Can you test it on the targets you have access to?

I'll try this evening.

Thanks,
Dave


-- 


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

[Bug rtl-optimization/20359] Incorrect code with global register variables

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |rtl-optimization
   Keywords||wrong-code


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

[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-07 15:04 
---
> I'll try this evening.

Excellent. Probably, we want this change, irrespective of the improvements 
related
to Roger's work. However, probably this means that, for consistency, also the
other overloads of complex::pow must be tweaked a bit...

-- 


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

[Bug rtl-optimization/20359] Incorrect code with global register variables

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
15:05 ---
Looking at the version which you quoted, it is only 3.2.2:
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

and not 3.4.2, can you try again with 3.4.2 or later?

-- 


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

[Bug target/20360] 20021014-1.c fails on account of unsupported build option

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
15:10 ---
A better way is do error this out just like xstormy16 and/or freebsd instead of 
what you did.

-- 


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

[Bug rtl-optimization/20359] Incorrect code with global register variables

[simonmar at microsoft dot com]

--- Additional Comments From simonmar at microsoft dot com  2005-03-07 
15:11 ---
Sorry, cut & pasted that gcc -v output from the wrong window.  The bug really 
does occur with 3.4.2, here's the correct -v output:

$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-
exceptions --enable-languages=c,c++,objc,java,f77 --enable-java-awt=gtk --
host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)


-- 


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

[Bug c++/20357] Multiply defined assembler symbols for template instantiations

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
15:11 ---
What is happening here is that multiple decls for f is getting in the way.  
Either we have to look at the 
DECL_UID or change the C++ front-end to only have one decl for f.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-07 15:11:53
   date||


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

[Bug rtl-optimization/20359] Incorrect code with global register variables

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
15:13 ---
Works on the mainline.

-- 
   What|Removed |Added

  Known to work||4.0.0


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

[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test

[pcarlini at suse dot de]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug other/18675] 6 * local variables set but never used

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-03-07 15:18 
---
Just checked in patches.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/19878] [4.0 Regression] ICE in import_export_decl

[jgrimm2 at us dot ibm dot com]

--- Additional Comments From jgrimm2 at us dot ibm dot com  2005-03-07 
16:01 ---
Verified. Thanks.

-- 
   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug c++/19916] [3.4/4.0/4.1 Regression] Segmentation fault in __static_initialization_and_destruction_0

[jgrimm2 at us dot ibm dot com]

--- Additional Comments From jgrimm2 at us dot ibm dot com  2005-03-07 
16:04 ---
Verified. Thanks.

-- 
   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-07 16:05 
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
 types

Alexandre Oliva wrote:

>>Then you should tsubst the INITIAL first, and unconditionally copy the
>>type to the TARGET_EXPR when you use build3.
> 
> 
> But what if the TARGET_EXPR had been created for different purposes,
> and did have a different type than that of the initializer?  Say, a
> Base& being bound to a Derived TARGET_EXPR?  That's why I'm performing
> the tests the way I am.

Are you sure that we can use TARGET_EXPR as a type-conversion node?  I 
would think in that case that the INITIAL for the TARGET_EXPR would be a 
call to the derived class constructor.  Hmm.  I suppose the type of such 
  a constructor is "void", so it may indeed be the case that there's 
really no relationship between the types.  Good point.

> Yeah, I know we'd like to do that, but we can't.  At that point we
> have no clue what that TARGET_EXPR or the CONSTRUCTOR in its initial
> came from.  We'd have to create a new tree node type for compound
> literals to be able to call finish_compound_literal at that point.

Then we really should do that.  We could have COMPOUND_LITERAL_EXPR 
whose type would be the type in the (syntactic) cast, and whose argument 
would be the CONSTRUCTOR for the brace-enclosed initializer.  We'd 
create one of these things if the TYPE, or any of the initializers, was 
dependent.

The games that you want to play with type-equality are just too fragile.



-- 


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

[Bug target/20322] [4.0/4.1 Regression] Miscompilation of libcpp/expr.c at -O2+

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-03-07 16:06 
---
Patch here: 

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2005-03-07 16:06:06
   date||


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

[Bug target/19087] Overflowed address in dwarf debug line information

[dwatkins at tascsystems dot com]

--- Additional Comments From dwatkins at tascsystems dot com  2005-03-07 
16:31 ---
Hello,

I have an update.  Torlief sent me a beta set of AS4 parser DLLs built to work 
ONLY with 32 bit address sizes in dwarf information.  I tried it out and 
noticed the following differences.

1.  Single stepping through my program now appears to work much better.  I no 
longer observe jumping back and forth between two source files as before.

2.  Disassembler view shows the source for the code above 0x8000 (word 
address) in the proper locations with code above 0x8000.

I also noticed the following side effects which don't directly bear on the 
subject of this bug, but may be related to the same root causes.

1.  On my development PC using latest WinAVR distribution and AS4.11 with the 
distribution parser DLLs, in one source module, I can hover over a global 
variable and see the address and value.  On my quarantined environment I use to 
experiment / debug the tool suite, I observe "invalid location" when I hover 
over the same variables.

2.  On my development PC, in the same source module, when I hover over a local 
(automatic) variable, no "hover-over" popup information is displayed.  On my 
quarantined environment, when I hover over the same variables, I see data 
values.

I must mention something about my quarantined environment.  I built it just 
before the latest WinAVR release so I think I want to make sure that it is in 
sync with all the same patches used for the latest WinAVR before concluding my 
test here, ... but so far the results appear very promising.


-- 


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

[Bug fortran/20361] New: -fmax-stack-var-size=N not working for equivalence

[paulthomas2 at wanadoo dot fr]

The enclosed example causes a segmentation fault at runtime under Cygwin.  
Reducing the length of pool1 by 1 allows it to run.  This length looks like 
2^18 less a header block so paging/memory/stack was suspected.  Note this does 
not occur in Linux or native Windows versions of gfortran. 

Setting -fmax-stack-var-size appropriately makes no difference but
d:/irun/bin/gfortran -Wl,--stack=210 fixes the problem.

-fmax-stack-var-size seems to work for non-equivalence variables but is broken 
for equivalenced variables - see correspondence on the list between myself and 
A.Pinskia dated 6-7 March 2005 under the subject: Re: Equivalence segfault in 
TEST_FPU.F90

Test programme and output:
__

program test_equivalence
 real*8  ::  pool1(260105),pool2(1)
 equivalence (pool1,pool2)
end program test_equivalence

$ d:/irun/bin/gfortran -v test_prequi.f90
Driving: d:/irun/bin/gfortran -v test_prequi.f90 -lgfortranbegin -lgfortran
Using built-in specs.
Configured with: ../gcc/configure --with-mpfr=/gmp-gcc4 --with-gmp=/gmp-gcc4 -en
able-languages=c,f95 --prefix=/cygdrive/d/irun
Thread model: single
gcc version 4.0.0 20050129 (experimental)
/cygdrive/d/irun/libexec/gcc/i686-pc-cygwin/4.0.0/f951.exe test_prequi.f90 -qui
et -dumpbase test_prequi.f90 -mtune=pentiumpro -auxbase test_prequi -version -o
/cygdrive/c/DOCUME~1/PAULTH~1/LOCALS~1/Temp/cc1r1KUq.s
GNU F95 version 4.0.0 20050209 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.0.0 20050131 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
as -o /cygdrive/c/DOCUME~1/PAULTH~1/LOCALS~1/Temp/ccK4DcrJ.o /cygdrive/c/DOCUME
~1/PAULTH~1/LOCALS~1/Temp/cc1r1KUq.s
/cygdrive/d/irun/libexec/gcc/i686-pc-cygwin/4.0.0/collect2.exe -Bdynamic --dll-
search-prefix=cyg /lib/crt0.o -L/cygdrive/d/irun/lib/gcc/i686-pc-cygwin/4.0.0 -L
/cygdrive/d/irun/lib/gcc/i686-pc-cygwin/4.0.0/../../.. /cygdrive/c/DOCUME~1/PAUL
TH~1/LOCALS~1/Temp/ccK4DcrJ.o -lgfortranbegin -lgfortran -lgcc -lcygwin -luser32
-lkernel32 -ladvapi32 -lshell32 -lgcc

[EMAIL PROTECTED] /cygdrive/d/gfortran
$ ./a
Segmentation fault (core dumped)

-- 
   Summary: -fmax-stack-var-size=N not working for equivalence
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paulthomas2 at wanadoo dot fr
CC: gcc-bugs at gcc dot gnu dot org,pinskia at physics dot
uc dot edu


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

[Bug fortran/20361] -fmax-stack-var-size=N not working for equivalence

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
16:35 ---
Just I note, my last name is Pinski, not Pinskia, the a is for my first name.

Confirmed.

-- 
   What|Removed |Added

 CC|pinskia at physics dot uc   |pinskia at gcc dot gnu dot
   |dot edu |org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2005-03-07 16:35:24
   date||


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

[Bug java/20362] New: ICE: bus error if missed interface used in abstract class and output file specified

[bojan at antonovic dot com]

Class C is abstract and implements interface I. Class Bugtest has main() and
imports C. All are in a different package hierarchy levels (see code).

crashing:
gcj -o bugtest --main=BugTest *.class */*.class

working:
gcj -o bugtest --main=BugTest *.class
gcj -o bugtest --main=BugTest *.class */*.class */*/*.class
gcj --main=BugTest *.class
gcj --main=BugTest *.class */*.class */*/*.class

correctly complaining:
gcj --main=BugTest *.class */*.class
/usr/bin/ld: Undefined symbols:
foo::deepfoo::I::class$
collect2: ld returned 1 exit status

source codes:

1. I.java:
package foo.deepfoo;

public interface I {
}

2. C.java:
package foo;

import foo.deepfoo.I;

public abstract class C implements I {

}

3. import foo.C;   

public class BugTest {

public static void main (String args[]) {
}
}

-- 
   Summary: ICE: bus error if missed interface used in abstract
class and output file specified
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bojan at antonovic dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-07 
17:05 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable 
types

On Mar  7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:

> Are you sure that we can use TARGET_EXPR as a type-conversion node?

Actually, no.  I was led to believe so because there is a function
that creates a TARGET_EXPR given an initializer and a type, in
addition to the one that takes the type from the initializer.

> I would think in that case that the INITIAL for the TARGET_EXPR
> would be a call to the derived class constructor.

I was thinking references, actually, so there wouldn't be a
constructor involved.  I.e., I was trying to preserve the earlier
behavior of TARGET_EXPRs (i.e., mostly do nothing with them), while
adjusting the behavior only as much as needed for this new use.

>> We'd have to create a new tree node type for compound literals to
>> be able to call finish_compound_literal at that point.

> Then we really should do that.

Eek.  What for?  All we need to do is adjust its type.  A new tree
node scattered all over the place feels like way too much overhead for
this.

> The games that you want to play with type-equality are just too fragile.

I still don't see why.  All I am doing is ensuring the equality is
maintained if it existed.  If they weren't equal in the first place, I
just don't change anything.  As a result, in the case in which I know
the equality is important and present, it will be preserved.  In other
cases, we get the behavior we had before.

Why are you so uncomfortable with it?  Is it just the general thought
that `pointer equality between type tree nodes is bad´, before
actually looking into the problem it's trying to address, or other
reasons pertaining to this particular issue?



-- 


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

[Bug java/20362] ICE: bus error if missed interface used in abstract class and output file specified

[bojan at antonovic dot com]

--- Additional Comments From bojan at antonovic dot com  2005-03-07 17:06 
---
Created an attachment (id=8351)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8351&action=view)
source code in tbz.


-- 


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

[Bug java/20215] gcj does not accept classes with same name fields

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-07 
17:11 ---
Subject: Bug 20215

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-07 17:11:29

Modified files:
libjava: ChangeLog link.cc 
libjava/include: jvm.h 

Log message:
PR java/20215:
* include/jvm.h (_Jv_Linker::find_field_helper): Updated.
* link.cc (find_field_helper): Added 'type' argument.
(find_field): Updated.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.3&r2=1.3391.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/link.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10&r2=1.10.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/jvm.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.77&r2=1.77.2.1



-- 


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

[Bug java/18212] nativ compilation with multiple jars fails / gives internal compiler error

[bojan at antonovic dot com]

--- Additional Comments From bojan at antonovic dot com  2005-03-07 17:11 
---
Bug 18212 can be splitted, and be seen as duplicate, of bugs 20351 and 20362.

I mark it as duplicate of bug 20362. (If patches for 20362 and 20351 fail for
18212, it can be reopened). 

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug java/20362] ICE: bus error if missed interface used in abstract class and output file specified

[bojan at antonovic dot com]

--- Additional Comments From bojan at antonovic dot com  2005-03-07 17:11 
---
*** Bug 18212 has been marked as a duplicate of this bug. ***

-- 


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

[Bug java/20215] gcj does not accept classes with same name fields

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-07 
17:18 ---
Subject: Bug 20215

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-07 17:18:33

Modified files:
libjava: ChangeLog link.cc 
libjava/include: jvm.h 

Log message:
PR java/20215:
* include/jvm.h (_Jv_Linker::find_field_helper): Updated.
* link.cc (find_field_helper): Added 'type' argument.
(find_field): Updated.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3399&r2=1.3400
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/link.cc.diff?cvsroot=gcc&r1=1.10&r2=1.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/jvm.h.diff?cvsroot=gcc&r1=1.77&r2=1.78



-- 


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

[Bug rtl-optimization/20359] [3.3/3.4 regression] Incorrect code with global register variables

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-03-07 17:28 ---
Confirmed.

---
/* { dg-do run { targets i?86-*-* || x86_64-*-* || powerpc*-*-* } } */
/* { dg-options "-O1" } */

void abort (void);
void exit (int);

#if defined __x86_64__ || defined __powerpc__
register void (*r)(void) asm("%r13");
#elif defined __i386__
register void (*r)(void) asm("%esi");
#endif

void g ()
{
  if (r != g)
abort ();
  else
exit (0);
}

int main ()
{
  r = g;
  goto *r;
}
---

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|x86_64-*-linux  |
   GCC host triplet|x86_64-*-linux  |
 GCC target triplet|x86_64-*-linux  |
  Known to fail||3.3.5 3.4.4
  Known to work|4.0.0   |4.0.0 3.2.3
   Last reconfirmed|-00-00 00:00:00 |2005-03-07 17:28:46
   date||
Summary|Incorrect code with global  |[3.3/3.4 regression]
   |register variables  |Incorrect code with global
   ||register variables
   Target Milestone|--- |3.4.4


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

[Bug middle-end/20355] MEM_READONLY_P & MEM_VOLATILE_P properties are lost on BLKmode rtl operands.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-03-07 17:30 
---
Subject: Re:  MEM_READONLY_P & MEM_VOLATILE_P
 properties are lost on BLKmode rtl operands.

> - Additional Comments From giovannibajo at libero dot it  2005-03-07
> A testcase?
> 
> -- 

- Understood. I'll post a patch shortly to avr's backend which otherwise
  should work as intended, if rtl BLK mode memory reference operands had
  properly retained their MEM_READONLY_P etc. attributes.





-- 


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

[Bug rtl-optimization/19683] MIPS wrong-code for 64-bit multiply.

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-07 
17:48 ---
Subject: Bug 19683

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-07 17:48:47

Modified files:
gcc: ChangeLog reload1.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/torture: pr19683-1.c 

Log message:
PR rtl-optimization/19683
* reload1.c (choose_reload_regs): Pass the number of bits, not the
number of bytes, to smallest_int_for_mode.  Fix arguments to
REG_CANNOT_CHANGE_MODE_P.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7711&r2=2.7712
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload1.c.diff?cvsroot=gcc&r1=1.462&r2=1.463
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5118&r2=1.5119
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/pr19683-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug inline-asm/20314] Bogus differ in number of alternatives error

[jakub at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-07 17:51:33
   date||


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

[Bug rtl-optimization/19683] MIPS wrong-code for 64-bit multiply.

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-07 
17:51 ---
Subject: Bug 19683

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-07 17:51:36

Modified files:
gcc: ChangeLog reload1.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/torture: pr19683-1.c 

Log message:
PR rtl-optimization/19683
* reload1.c (choose_reload_regs): Pass the number of bits, not the
number of bytes, to smallest_int_for_mode.  Fix arguments to
REG_CANNOT_CHANGE_MODE_P.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.30&r2=2.7592.2.31
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.461&r2=1.461.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.22&r2=1.5084.2.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/pr19683-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug rtl-optimization/19683] MIPS wrong-code for 64-bit multiply.

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-03-07 
17:54 ---
Patch applied to mainline and 4.0.  Will apply to 3.4 branch
in a week or so if nothing goes wrong.


-- 
   What|Removed |Added

  Known to fail|4.0.0 3.4.3 3.3.1   |3.4.3 3.3.1
  Known to work||4.1.0 4.0.0


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

[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-07 18:05 
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
 types

Alexandre Oliva wrote:
> On Mar  7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 
> 
>>Are you sure that we can use TARGET_EXPR as a type-conversion node?
> 
> 
> Actually, no.  I was led to believe so because there is a function
> that creates a TARGET_EXPR given an initializer and a type, in
> addition to the one that takes the type from the initializer.

OK, so if there's no conversion, then my suggestion (i.e., copy the type 
from the substituted initializer) should work fine.

> I was thinking references, actually, so there wouldn't be a
> constructor involved.  I.e., I was trying to preserve the earlier
> behavior of TARGET_EXPRs (i.e., mostly do nothing with them), while
> adjusting the behavior only as much as needed for this new use.

TARGET_EXPRs create objects.  I'm not sure if we ever create 
TARGET_EXPRs with REFERENCE_TYPE, but if so, there initializers should 
have the same type.

>>Then we really should do that. 
> 
> Eek.  What for?  All we need to do is adjust its type.  A new tree
> node scattered all over the place feels like way too much overhead for
> this.

There are two situations:

1. The type is derivable from the operands.

In that case, you can do that, as I've suggested above, by creating the 
operands, and then applying a *uniform, unconditional* operation to the 
type of the operands to determine the type of the TARGET_EXPR.

2. The type is not derivable from the operands.

In that case, you should be going through the same semantics.c routines 
that we do at parse time.

The truth is that (2) is a better choice no matter what, because we 
really want dependent expressions to have a representation that is very 
nearly isomorphic to the source code.  We have to introduce nodes 
corresponding to G++ extensions in other places (like 
statement-expressions); this is no different.  However, I can live with 
(1), for expediency sake.

>>The games that you want to play with type-equality are just too fragile.
> 
> I still don't see why.

First, you're using "==".  As I've told you, that's incredibly fragile. 
  You're depending on a very non-local property that in the case that 
you're interested in, the types will always be ==.  But, minor changes 
elsewhere might make them same_type_p, but not ==, in some cases.  Then, 
your code breaks, probably undetectably.  To a first approximation, the 
only place == should be used for types is in same_type_p itself.

Second, you're applying a non-uniform manipulation on the types of the 
TARGET_EXPR, based on a non-local property about how TARGET_EXPRs are 
created, without actually checking that the condition you're interested 
in (incomplete array types) applies.

This is not an approach that's going to be robust over time.



-- 


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

[Bug fortran/20363] New: interface body has incorrect scope

[paulthomas2 at wanadoo dot fr]

 

-- 
   Summary: interface body has incorrect scope
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paulthomas2 at wanadoo dot fr
CC: dave dot offiler at metoffice dot gov dot uk,gcc-bugs at
gcc dot gnu dot org


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

[Bug fortran/20363] interface body has incorrect scope

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-03-07 
18:40 ---
(In reply to comment #0)
> Sorry about that I was adding Michael Metcalf to the cc and it, well, went.

$ cat snafu.f90
module snafu
  interface foo
subroutine really_snafu (foo)
  integer, intent (inout)  :: foo
end subroutine really_snafu
  end interface foo
end module snafu
[EMAIL PROTECTED] /cygdrive/d/gfortran
$ d:/irun/bin/gfortran  -c snafu.f90
 In file snafu.f90:4

  integer, intent (inout)  :: foo
1
Error: Symbol 'foo' at (1) cannot have a type

This is incorrect because the interface body is a new separate scope(thanks 
Michael).


-- 


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

[Bug c/20364] New: Segfault with -Xpreprocessor argument

[neothglf dot neothglf at laposte dot net]

Segmentation Fault while trying to compile a file with the -Xpreprocessor 
argument :

If the file specified after -Xpreprocessor , does not exist, then gcc crash.

How to reproduce the bug :

$ gcc filename.c -Xpreprocessor file_which_does_not_exist

--filename.c must exist.

Here is what it gives :

$ gcc fpexe.c -Xpreprocessor a
cc1: ss : No such file or directory
cc1: erreur interne du compilateur: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: Segfault with -Xpreprocessor argument
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neothglf dot neothglf at laposte dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
  Component|c   |middle-end
   Keywords||ice-on-valid-code
Summary|Segfault with -Xpreprocessor|[3.4 Regression] Segfault
   |argument|with -Xpreprocessor argument
   Target Milestone|--- |3.4.4


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

[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
18:58 ---
Confirmed, here is the backtrace:
#0  0x080ef546 in init_emit () at ../../gcc/emit-rtl.c:5354
#1  0x08133b2e in prepare_function_start (fndecl=0x0) at 
../../gcc/function.c:6460
#2  0x08275fef in toplev_main (argc=0, argv=0xbfffe9b0) at 
../../gcc/toplev.c:4539
#3  0x0809962e in main (argc=0, argv=0x0) at ../../gcc/main.c:35

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords|ice-on-valid-code   |ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2005-03-07 18:58:59
   date||


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

[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
19:02 ---
Fixed in 4.0.0 by:
http://gcc.gnu.org/ml/gcc/2004-04/msg00645.html

-- 
   What|Removed |Added

 CC||wilson at gcc dot gnu dot
   ||org


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

[Bug rtl-optimization/20365] New: simplify_plus_minus results are erratic

[amylaar at gcc dot gnu dot org]

simplify_plus_minus uses an unstabilized qsort call.  This makes
the perfomed optimizations dependent on the qsort implementation.
The observed problem was that a mingw hosted compiler generated
different code than a Linux/GNU hosted compiler.
A patch is here:
http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00665.html

-- 
   Summary: simplify_plus_minus results are erratic
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 17652
 nThis:


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

[Bug other/17652] [meta-bug] GCC 4.1 pending patches

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||20365


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

[Bug c++/20366] New: AIX g++ -D_LARGE_FILES fails to compile #include

[gcc-bugzilla at gcc dot gnu dot org]

The compiler's C++ headers do not appear to work properly on AIX when
the compiler is run with -D_LARGE_FILES.  This macro causes the
system headers to #define symbols like fopen, while the C++ headers
unconditionally #undef these symbols.

Environment:
System: AIX bigblue 2 5 000F699D4C00



host: powerpc-ibm-aix5.2.0.0
build: powerpc-ibm-aix5.2.0.0
target: powerpc-ibm-aix5.2.0.0
configured with: /usr0/slammert/gcc-3.4.3/configure --with-as=/usr/bin/as 
--with-ld=/usr/bin/ld --disable-nls --enable-languages=c,c++ --enable-threads 
--enable-version-specific-runtime-libs

How-To-Repeat:
On AIX 5.2, compile the following program with
3.4.3 g++ -D_LARGE_FILES:

#include 
int main(void) { return 0; }

You will get output similar to the following:

In file included from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/powerpc-ibm-aix5.2.0.0/bits/c++locale.h:43,
 from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/iosfwd:46,
 from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/ios:44,
 from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/ostream:45,
 from 
/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/iostream:45,
 from bug0.C:1:

/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:108: error: 
`::fgetpos' has not been declared

/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:110: error: 
`::fopen' has not been declared

/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:115: error: 
`::freopen' has not been declared

/usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/include/c++/cstdio:118: error: 
`::fsetpos' has not been declared
--- Additional Comments From dsanderson at panasas dot com  2005-03-07 
19:12 ---
Fix:
I can work around this problem and still compile a program with a
64-bit off_t by compiling with -maix64 instead of -D_LARGE_FILES.

-- 
   Summary: AIX g++ -D_LARGE_FILES fails to compile #include

   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dsanderson at panasas dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-ibm-aix5.2.0.0
  GCC host triplet: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0


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

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c++ |target


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

[Bug rtl-optimization/20365] simplify_plus_minus results are erratic

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
19:21 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2005-03-07 19:21:10
   date||


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

[Bug java/20362] ICE: bus error if missed interface used in abstract class and output file specified

[bojan at antonovic dot com]

--- Additional Comments From bojan at antonovic dot com  2005-03-07 19:21 
---
Compiling the .java files directly works:

working:
gcj -o bugtest --main=BugTest *.java */*.java
gcj --main=BugTest *.java */*.java */*/*.java

Compiling the code by gcj -C first instead with javac makes no difference.

-- 


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

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-03-07 19:30 
---
G++ and libstdc++ on AIX currently is configured to enable _LARGE_FILE_API, 
but not _LARGE_FILES.  _LARGE_FILE_API exposes the 64-bit functions with 
separate names off64_t and fopen64(), but does not redefine the original 
functions with their counterparts supporting 64-bit types.

-- 


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

[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-03-07 19:37 
---
Created an attachment (id=8352)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8352&action=view)
minimized test case

This test case is minimized from ammp and gets "fatal error: internal
consistency failure" when compiled with "-m32 -O2 -fmodulo-sched" with
the 4.0 branch built last for powerpc64-unknown-linux-gnu.

-- 


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

[Bug other/17652] [meta-bug] GCC 4.1 pending patches

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||20367


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

[Bug rtl-optimization/20367] New: alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs

[amylaar at gcc dot gnu dot org]

This has been discussed here:

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03141.html

-- 
   Summary: alias analysis doesn't take into account that variables
that haven't their address taken can't alias arbitrary
MEMs
   Product: gcc
   Version: 3.2
Status: UNCONFIRMED
  Keywords: alias
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 17652
 nThis:


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

[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-07 
20:01 ---
Created an attachment (id=8353)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8353&action=view)
patch against 3.4

The previous patch had the problem that the non-existence of a MEM_EXPR was
taken
to mean that no static variable is involved.  This updated patch uses a
MEM_EXPR with the new special node unspecified_indirect_ref_node to indicate
that no
static variable is involved.  Thus, when two MEMs are merged and thus loose
their MEM_EXPR, the optimization should still be safe.


-- 


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

[Bug c/20368] New: internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777

[olh at suse dot de]

after some broken changes to a glibc src file:

[EMAIL PROTECTED]:~/objglibc-40-O1> 
/home/abuild/install_gcc40-2-O1/libexec/gcc/powerpc64-unknown-linux-gnu/4.0.0/cc1
 -fpreprocessed ~/src/glibc-mainline/math/s_isnan.i -quiet -dumpbase s_isnan.c 
-mnew-mnemonics -auxbase-strip /home/abuild/objglibc-40-O1/math/s_isnan.os -g 
-O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -Wno-uninitialized 
-std=gnu99 -version -fpic -o s_isnan.s  
  GNU C 
version 4.0.0 20050306 (prerelease) (powerpc64-unknown-linux-gnu)   

   compiled by GNU C version 4.0.0 20050306 (prerelease).   

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 

 ../sysdeps/powerpc/fpu/s_isnan.c:37: error: '__isnanf' undeclared here 
(not in a function) 
  ../sysdeps/powerpc/fpu/s_isnan.c:37: warning: type defaults to 
'int' in declaration of '__GI___isnanf' 
  ../sysdeps/powerpc/fpu/s_isnan.c:37: warning: type 
defaults to 'int' in declaration of '__isnanf'
../sysdeps/powerpc/fpu/s_isnan.c:41: internal compiler error: tree check: 
expected function_type or method_type, have integer_type in start_function, at 
c-decl.c:5777
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: internal compiler error: tree check: expected
function_type or method_type, have integer_type in
start_function, at c-decl.c:5777
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olh at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug c/20368] internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777

[olh at suse dot de]

--- Additional Comments From olh at suse dot de  2005-03-07 20:10 ---
Created an attachment (id=8354)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8354&action=view)
/tmp/s_isnan.i.bz2


-- 


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

[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-07 
20:27 ---
Here is an example out of the google cache:
http://66.102.9.104/search?q=cache:BGnyHfyQlSYJ:gcc.gnu.org/ml/gcc-patches/2004-02/msg01638.html+unspecified_indirect_ref_node&hl=en

RFA: alias analysis for non-addressed variables vs. INDIRECT_REF

* From: Joern Rennecke 
* To: gcc-patches at gcc dot gnu dot org
* Date: Wed, 18 Feb 2004 18:24:58 + (GMT)
* Subject: RFA: alias analysis for non-addressed variables vs. INDIRECT_REF

As discussed before, we are currently missing opportunities to
hoist out accesses of non-addressed variables.  I have now
modified my patch so that a special node unspecified_indirect_ref_node
is used in MEM_EXPRs to mark memory accesses that are generated
from an otherwise unspecified INDIRECT_REF.

Consider this test case:

int
f(int s, int *a)
{
  static int i;
  for (i = 0; i < 800; i++)
s += a[i];
  return s;
}

For the inner loop, this is the code that I get for sh-elf at -O2 -m4
with mainline from 2004-02-17 without my patch:

.L5:
mov.l   @r7,r1
mov r1,r0
shll2   r0
mov.l   @(r0,r5),r2
add #1,r1
cmp/gt  r6,r1
mov.l   r1,@r7
bf/s.L5
add r2,r3

And this with the patch; the loads and stores if the loop induction
variable 'i' (@r7) have been hoisted out, and the a[i] giv has been
strength reduced from @(r0,r5) to @r5+.

.L5:
mov.l   @r5+,r1
add #1,r2
cmp/gt  r3,r2
bf/s.L5
add r1,r0



-- 


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

[Bug c/20368] internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777

[schwab at suse dot de]

-- 
   What|Removed |Added

   Keywords||error-recovery, ice-on-
   ||invalid-code


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

[Bug other/17652] [meta-bug] GCC 4.1 pending patches

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||20369


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

[Bug rtl-optimization/20369] New: noce_emit_move_insn emits invalid insns

[amylaar at gcc dot gnu dot org]

noce_emit_move_insn calls emit_move_insn without checking that
the thus generated insn is valid.

-- 
   Summary: noce_emit_move_insn emits invalid insns
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 17652
 nThis:


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

[Bug rtl-optimization/20369] noce_emit_move_insn emits invalid insns

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-07 
21:12 ---
Created an attachment (id=8355)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8355&action=view)
proposed fix


-- 


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

[Bug middle-end/20355] MEM_READONLY_P & MEM_VOLATILE_P properties are lost on BLKmode rtl operands.

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


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

[Bug other/17652] [meta-bug] GCC 4.1 pending patches

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||20370


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

[Bug rtl-optimization/20370] New: dead_or_predictable doesn't resize reg_n_info

[amylaar at gcc dot gnu dot org]

dead_or_predictable calls propagate_block without checking first if there
is suddicient space in reg_n_info.  That can lead to memory corruption.

-- 
   Summary: dead_or_predictable doesn't resize reg_n_info
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Keywords: wrong-code, ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 17652
 nThis:


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

[Bug rtl-optimization/20370] dead_or_predictable doesn't resize reg_n_info

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-07 
21:32 ---
Created an attachment (id=8356)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8356&action=view)
proposed fix


-- 


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

[Bug other/17652] [meta-bug] GCC 4.1 pending patches

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||20371


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

[Bug middle-end/20371] New: Some corner cases of MS bitfields don't work

[amylaar at gcc dot gnu dot org]

See comments in patch

-- 
   Summary: Some corner cases of MS bitfields don't work
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 17652
 nThis:


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

[Bug regression/20372] New: Reversed branch-on-count loop (DoLoop)

[pthaugen at us dot ibm dot com]

Noticed a regression relative to 4.0 on the code generated for one of the loops
in zaxpy.f of the SPEC wupwise benchark. The loop is transformed into a
branch-on-count loop, but the target on the branch is the loop exit (return in
this case) instead of the loop start. The 'bct' is immediately followed by an
unconditional branch to the loop start.

Here's a snippet of the generated code (this is for the first loop in the
source, even though it appears as the second loop in the generated code). 'L18'
is the epilog block.

.L15:

addi %r0,%r7,-1  # D.511, ix,
...
...
stfdx %f11,%r11,%r31 # (* zy), SR.12
bdz .L18
b .L15

-- 
   Summary: Reversed branch-on-count loop (DoLoop)
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pthaugen at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc*-*-*
  GCC host triplet: powerpc*-*-*
GCC target triplet: powerpc*-*-*


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

[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-07 
21:57 ---
Subject: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail

loop attempts to eliminate a biv represented by a pseudo in favor of a
giv represented by (plus (reg) (const_int -1)).  Unfortunately, the
biv pseudo appears in an insn that doesn't accept anything but a
register, so validate_change fails and the error goes unnoticed.

The patch below fixes the problem and passed bootstrap on
x86_64-linux-gnu (testing still pending), but I'm not very comfortable
with the use of location for the assignment.  Is this a safe change?
Any loop experts around willing to take a second look on this?  Thanks
in advance,

Index: gcc/ChangeLog
from  Alexandre Oliva  <[EMAIL PROTECTED]>

PR target/20126
* loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed,
set the original address pseudo to the correct value before the
original insn and leave the insn alone.

Index: gcc/loop.c
===
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.522
diff -u -p -r1.522 loop.c
--- gcc/loop.c 17 Jan 2005 08:46:15 - 1.522
+++ gcc/loop.c 7 Mar 2005 21:37:43 -
@@ -5470,9 +5470,16 @@ loop_givs_rescan (struct loop *loop, str
mark_reg_pointer (v->new_reg, 0);
 
   if (v->giv_type == DEST_ADDR)
-   /* Store reduced reg as the address in the memref where we found
-  this giv.  */
-   validate_change (v->insn, v->location, v->new_reg, 0);
+   {
+ /* Store reduced reg as the address in the memref where we found
+this giv.  */
+ if (! validate_change (v->insn, v->location, v->new_reg, 0))
+   /* Not replaceable; emit an insn to set the original giv reg from
+  the reduced giv.  */
+   v->insn = loop_insn_emit_before (loop, 0, v->insn,
+gen_move_insn (*v->location,
+   v->new_reg));
+   }
   else if (v->replaceable)
{
  reg_map[REGNO (v->dest_reg)] = v->new_reg;

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}


-- 


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

[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-07 
21:58 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable 
types

On Mar  7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:

>>> The games that you want to play with type-equality are just too fragile.
>> I still don't see why.

> First, you're using "==".  As I've told you, that's incredibly
> fragile.

Not for the purpose I've been trying to describe.

The condition I want to maintain is that, if the TARGET_EXPR had the
type of its INITIAL before template substitution, then it must have
the type of its INITIAL after template substitution, because whatever
transformations the INITIAL type might undergo won't be applied to the
TARGET_EXPR.  It's that simple, so it should be quite obvious that
`==' is what I'm looking for.  It's not just same_type_p; if the types
of the TARGET_EXPR was not taken from the INITIAL, then I don't care
how it evolves.

> You're depending on a very non-local property that in the
> case that you're interested in, the types will always be ==.

No, I'm only guaranteeing that, if this property held before template
substitution, it still holds afterwards.  If it didn't hold before, it
still won't hold afterwards.  It's much simpler than what you
describe.

> But, minor changes elsewhere might make them same_type_p, but not
> ==, in some cases.

If that's fine for those cases, it will remain so after template
substitution.  Sounds *exactly* like what I want.

> Second, you're applying a non-uniform manipulation on the types of the
> TARGET_EXPR, based on a non-local property about how TARGET_EXPRs are
> created, without actually checking that the condition you're
> interested in (incomplete array types) applies.

Huh?!?  No, I'm not.  Read the code again.  It goes like this:

  if the decl type and the initializer type were the same before,
make them the same after

  if the target_expr type and the decl type were the same before,
make them the same after

and that's it.  It's that simple.  Nothing non-uniform about it.



-- 


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

[Bug regression/20372] Reversed branch-on-count loop (DoLoop)

[pthaugen at us dot ibm dot com]

--- Additional Comments From pthaugen at us dot ibm dot com  2005-03-07 
21:59 ---
Created an attachment (id=8357)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8357&action=view)
Source file


-- 


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

[Bug middle-end/20371] Some corner cases of MS bitfields don't work

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-07 
22:00 ---
An analysis and a patch is here:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00298.html

This patch has been used in the meantime in a 3.4 based compiler to
compile various software like Linux kernels etc.

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug rtl-optimization/20372] Reversed branch-on-count loop (DoLoop)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
22:04 ---
I saw this too for some C code somewhere (but that was not a regression at 
least as far as I could see).

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|regression  |rtl-optimization
   Keywords||missed-optimization


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

[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry

[aoliva at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-02-21 22:15:27 |2005-03-07 22:15:35
   date||


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

[Bug rtl-optimization/20372] [4.0/4.1 Regression] Reversed branch-on-count loop (DoLoop)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
22:19 ---
Here is a simplified C code which shows the problem:
int *ggg;
void f(int l1, int l2)
{
  int i;
  if (l1)
  {
for(i=0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=20372

[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-03-07 22:39 
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
 types

Alexandre Oliva wrote:
> On Mar  7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 
> 
The games that you want to play with type-equality are just too fragile.
>>>
>>>I still don't see why.
> 
> 
>>First, you're using "==".  As I've told you, that's incredibly
>>fragile.
> 
> 
> Not for the purpose I've been trying to describe.

We're at risk of descending into "Yes. No. Yes. No."

I think it's fragile.  Now, reasonable people can disagree about 
software engineering -- it's an art form, not a science -- but my 
opinion is that this is fragile.

I've explained why:

(a) we should never use "==" to compare types, because there's no 
guarantee that the compiler will continue to use "==" types in places 
where it does at present; it might instead switch one of them to be 
same_type_p.  Think about it this way: == has no semantic meaning in 
C++; the only relationship the language knows about is same_type_p.  So, 
using == means that you're doing something with types that doesn't have 
semantics grounded in the language, which doesn't make sense, except in 
places that are trying to get debugging information correct, etc.

(b) you're applying a non-uniform transformation depending on non-local 
knowledge.  What I mean by "non-uniform" is that the assignment to the 
type of the TARGET_EXPR is conditional.  If it were an unconditional 
assignment, I'd be less nervous; then, you'd be asserting that the type 
of the TARGET_EXPR should always be the type of its initializer, which 
might make sense.  What I mean by "non-local" is that your 
transformation only works because of some far-off logic that determins 
how TARGET_EXPRs are created.  It doesn't depend on any documented 
property of TARGET_EXPRs that is enforced throughout the compiler.

Consider the comments you should write for your code:

/* Code in  creates TARGET_EXPRs with "==" types, and 
that must be preserved here.  If you change that code, don't forget to 
update this code!  */

And, then, you should add something to the TARGET_EXPR documentation 
along the lines of:

/* Some TARGET_EXPRs have the same TREE_TYPE as their initializers; some 
don't.  The kinds that do are ...; the kinds that don't are ...  When 
instantiating templates, we preserve equality for types that "==", but 
not necessarily those that are same_type_p.  */

Finally, I've explained that the entire approach is contrary to the way 
we want to do things in templates, which is that you keep a syntactic 
form for dependent expressions until instantiation time, and then run 
through the same exact routines you would have in the parser.  That's 
really the only way we can be sure that the semantics match up.

I'm sorry you're frustruated, but I don't think that your approach is 
the right way to go.

>>But, minor changes elsewhere might make them same_type_p, but not
>>==, in some cases.
>  
> If that's fine for those cases, it will remain so after template
> substitution.  Sounds *exactly* like what I want.

Why would you want that?  If before substitution, the operand had a 
typedef type for the incomplete array, and the TARGET_EXPR had a 
different typedef type for the same incomplete array, wouldn't you want 
to update the type of the TARGET_EXPR?

In the context of a 4.0 patch, I'd be willing to consider a patch like 
yours, using same_type_p instead of "==", and with suitable comments 
explaining what's going on.  For 4.1, we should do better.



-- 


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

[Bug target/19087] Overflowed address in dwarf debug line information

[dwatkins at tascsystems dot com]

--- Additional Comments From dwatkins at tascsystems dot com  2005-03-07 
22:50 ---
Hello,

I applied the GCC and binutil patches to ensure that my gcc is the same as that 
used in WinAVR Feb14/05 distribution.  I then built libc1.2.3 and clean built 
my project.  Loaded it all into AS4.11 with the beta parser DLLs.  No 
difference.

With the 32 bit dwarf address, line number info seems ok, local automatic 
variables seem ok but the static and global variables all appear as invalid 
locations when hovering over them.

I'll wait for any comments from Torleif as to whether this is at the AS4 
parsing end or during one of the earlier stages (i.e. in GCC or binutils).

Regards,

Darcy

-- 


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

[Bug pch/11341] [cygwin] [pch] ICE in ggc_pop_context, at ggc-page.c:1441 while compiling libstc++3

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
23:16 ---
Fixed by:
2005-03-08  Earl Chew <[EMAIL PROTECTED]>
David Billinghurst <[EMAIL PROTECTED]>

* config/i386/host-cygwin.c: New file to support precompiled
headers on cygwin
* config/i386/x-cygwin: Use host-cygwin.c on cygwin host
* config.host: Use above files for cygwin host.



-- 
   What|Removed |Added

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


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

[Bug tree-optimization/18546] tree vectorizer does not understand RETURN_DECL

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
23:21 ---
I can confirm this has been fixed now.

-- 
   What|Removed |Added

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


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

[Bug target/19887] g++.dg/warn/weak1.C fails on HPUX

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-03-07 23:36 
---
Also fails on hppa2.0w-hpux now the testsuite knows that platform
supports weak symbols.  On that platform there's also

FAIL: gcc.dg/special/weak-1.c execution test

which could be related.


-- 


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

[Bug fortran/20373] New: INTRINSIC symbols can be given the wrong type

[tobi at gcc dot gnu dot org]

INTRINSIC dsqrt
INTEGER dsqrt
END

compiles without giving an error.  This is invalid: and intrinsic always has the
type defined by 13.13 in the standard, it may only be reaffirmed but not
overwritten.

-- 
   Summary: INTRINSIC symbols can be given the wrong type
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/20373] INTRINSIC symbols can be given the wrong type

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-07 
23:56 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-07 23:56:25
   date||


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

[Bug fortran/20373] INTRINSIC symbols can be given the wrong type

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-03-08 00:11 
---
A remark: this doesn't lead to wrong code, 
   integer, intrinsic :: dsqrt
   print *, dsqrt(4.d0)
   end
prints the expected 2.

-- 


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

[Bug tree-optimization/15784] fold misses binary optimization

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-03-08 
00:21 ---
More on the latent bug that the patch for this PR uncovers: 
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00448.html 

-- 


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

[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-03-08 
00:27 ---
I reckon this is already fixed by tree-ssa, or we'll be fixed by the incoming 
TARGET_MEM_REF work. Zdenek?

-- 
   What|Removed |Added

 CC||rakdver at atrey dot karlin
   ||dot mff dot cuni dot cz


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