[Bug libgcj/10353] [3.3/3.4/4.0 regression] Java testsuite failures

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-21 
08:13 ---
Subject: Bug 10353

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-21 08:12:39

Modified files:
.  : ChangeLog configure.in configure 

Log message:
PR libgcj/10353
* configure.in (noconfigdirs) : Add libgcj.
* configure: Regenerate.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.1054&r2=1.1055
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.in.diff?cvsroot=gcc&r1=1.339&r2=1.340
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.diff?cvsroot=gcc&r1=1.202&r2=1.203



-- 


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

[Bug tree-optimization/19951] ICE in tree_split_edge, at tree-cfg.c:3199 with -ftree-vectorize

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-21 
08:40 ---
Fixed.


-- 
   What|Removed |Added

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


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

[Bug libstdc++/20091] [4.0 Regression] 18_support/14026.cc execution test fails

[micis at gmx dot de]

--- Additional Comments From micis at gmx dot de  2005-02-21 09:00 ---
With the actual snapshot (20050220) ACE5.4.2 fails to compile even at -O0 with 
link errors which may be related to this bug:

(.gnu.linkonce.t._ZN5Kokyu23DSRT_Dispatcher_FactoryI20mif_scheduler_traitsE22cre
ate_DSRT_dispatcherERKNS_15DSRT_ConfigInfoE
[Kokyu::DSRT_Dispatcher_Factory::create_DSRT_dispatcher
(Kokyu::DSRT_ConfigInfo const&)]+0x125): In function 
`Kokyu::DSRT_Dispatcher_Factory::create_DSRT_dispatcher
(Kokyu::DSRT_ConfigInfo const&)':
../../../Kokyu/Kokyu_dsrt.cpp:81: undefined reference to 
`__cxa_get_exception_ptr'
.obj/MIF.o
(.gnu.linkonce.t._ZN5Kokyu23DSRT_Dispatcher_FactoryI20mif_scheduler_traitsE22cre
ate_DSRT_dispatcherERKNS_15DSRT_ConfigInfoE
[Kokyu::DSRT_Dispatcher_Factory::create_DSRT_dispatcher
(Kokyu::DSRT_ConfigInfo const&)]+0x217):../../../Kokyu/Kokyu_dsrt.cpp:90: 
undefined reference to `__cxa_get_exception_ptr'
.obj/MIF.o
(.gnu.linkonce.t._ZN5Kokyu23DSRT_Dispatcher_FactoryI20mif_scheduler_traitsE22cre
ate_DSRT_dispatcherERKNS_15DSRT_ConfigInfoE
[Kokyu::DSRT_Dispatcher_Factory::create_DSRT_dispatcher
(Kokyu::DSRT_ConfigInfo const&)]+0x3af):../../../Kokyu/Kokyu_dsrt.cpp:99: 
undefined reference to `__cxa_get_exception_ptr'
.obj/MIF.o
(.gnu.linkonce.t._ZN21ACE_Bound_Ptr_CounterI16ACE_Thread_MutexE15internal_create
Ei[ACE_Bound_Ptr_Counter::internal_create(int)]+0x87): In 
function `ACE_Bound_Ptr_Counter::internal_create(int)':
/home/cie019/ace542-gcc40/ACE_wrappers/ace/Bound_Ptr.inl:15: undefined 
reference to `__cxa_get_exception_ptr'
.obj/MIF.o
(.gnu.linkonce.t._ZN5Kokyu27DSRT_Direct_Dispatcher_ImplI20mif_scheduler_traitsE1
0schedule_iEiRKNS1_15QoSDescriptor_tE[non-virtual thunk to 
Kokyu::DSRT_Direct_Dispatcher_Impl::schedule_i(int, 
mif_scheduler_traits::QoSDescriptor_t const&)]+0x124): In function 
`Kokyu::DSRT_Direct_Dispatcher_Impl::schedule_i(int, 
mif_scheduler_traits::QoSDescriptor_t const&)':
../../../Kokyu/DSRT_Direct_Dispatcher_Impl_T.cpp:210: undefined reference to 
`__cxa_get_exception_ptr'
.obj/MIF.o
(.gnu.linkonce.t._ZN5Kokyu23DSRT_CV_Dispatcher_ImplI20mif_scheduler_traitsE10sch
edule_iEiRKNS1_15QoSDescriptor_tE
[Kokyu::DSRT_CV_Dispatcher_Impl::schedule_i(int, 
mif_scheduler_traits::QoSDescriptor_t const&)]
+0x190):../../../Kokyu/DSRT_CV_Dispatcher_Impl_T.cpp:81: more undefined 
references to `__cxa_get_exception_ptr' follow
collect2: ld returned 1 exit status
make[4]: *** [MIF] Error 1

Michael Cieslinski


-- 


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

[Bug c++/20118] spurious error

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-02-21 09:29 
---
Adding "template<>" indeed made the diagnostic go away. Can you change this
report to a complaint about the rather unhelpful diagnostic?

Ivan

-- 


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

[Bug bootstrap/13770] [doc] --with-gc not documented

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-21 
10:03 ---
Subject: Bug 13770

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-21 10:03:09

Modified files:
gcc: ChangeLog 
gcc/doc: install.texi 

Log message:
2005-02-21  Richard Guenther  <[EMAIL PROTECTED]>

PR bootstrap/13770
* doc/install.texi: Document --with-gc.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7547&r2=2.7548
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/install.texi.diff?cvsroot=gcc&r1=1.335&r2=1.336



-- 


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

[Bug c++/20119] New: reading other stack variable memory space for shorts

[dirkjan at magma-da dot com]

the following command
g++ -g -S -dA -fno-strict-aliasing test_enum_cast2.cxx

produces 
   # test_enum_cast2.cxx:13
.loc 1 13 0
movl-12(%ebp), %eax
incl%eax
movw%ax, -2(%ebp)

which shows a movl for a short variable.

This is interpreted as possibly uninitialized memory read by purify (depending
on other stack variables and if they are initialized). Rational/IBM tells me
they do report the actual behaviour. Is there a way to avoid this movl and use
really word size? (I expect this to be an optimization but it hurds in this 
case)

the example is:
test_enum_cast2.cxx:
struct KEY{
  const char *name; //if removed this line then no error in purify (as it then 
reads
from initialized variable var set to 1 from the stack
  short type;
 };


int main(){
 short var=1; //if this is left uninit and key.type is set to 1 directly then no
erro
r in purify
 KEY key;
  key.name=0;
  key.type=var;

   var = key.type + 1;

 }

Thanks Dirk-Jan

-- 
   Summary: reading other stack variable memory space for shorts
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dirkjan at magma-da dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/20102] Incorrect floating point code generated when assigning to "packed" structure

[oakad at yahoo dot com]

--- Additional Comments From oakad at yahoo dot com  2005-02-21 10:39 
---
I would like to notice that the issue only arises with packed structs, which 
are mostly found in places where exception handling is undesirable. Non-packed 
structs are always aligned anyway. 

-- 


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

[Bug c++/20119] reading other stack variable memory space for shorts

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
10:44 ---
Fixed in 4.0.0, not a regression.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||2.95 3.2 3.3.3 3.4.0
  Known to work||4.0.0
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug bootstrap/13770] [doc] --with-gc not documented

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
10:47 ---
Fixed in 4.0.0, 3.4.0 was known to be broken with 64bit (there was a bug report 
about it).

-- 
   What|Removed |Added

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


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

[Bug c++/20119] reading other stack variable memory space for shorts

[dirkjan at magma-da dot com]

--- Additional Comments From dirkjan at magma-da dot com  2005-02-21 10:57 
---
Subject: Re:  reading other stack variable memory space for
 shorts

Any chance to do something about it on older versions? (3.2.x 3.3.x 
3.4.x) I cannot compile with 4.0.0 for a while I am afraid. Compiler 
upgrades already cost some extensive testing to find the gcc bugs we run 
into. Doing a not released 4 upgrade and later again higher is not feasable.

Thanks,
Dirk-Jan



> Fixed in 4.0.0, not a regression.
> 


-- 


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

[Bug c++/20119] reading other stack variable memory space for shorts

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-02-21 11:19 
---
(In reply to comment #2)

> Any chance to do something about it on older versions? (3.2.x 3.3.x 
> 3.4.x)

No. We fix only regressions or very serious bugs in those versions.


-- 


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

[Bug c++/20119] reading other stack variable memory space for shorts

[dirkjan at magma-da dot com]

--- Additional Comments From dirkjan at magma-da dot com  2005-02-21 12:04 
---
Subject: Re:  reading other stack variable memory space for
 shorts

Well there is no 4.0.0 released and even it it was it will take a while 
before the code base of us does compile and we found the gcc bugs we run 
into this time.

I understand your point, I was just wondering if there is any way for me 
to work around this issue now by setting any compile flag or so. Or even 
put a patch in our own gcc being used.

Dirk-Jan

falk at debian dot org wrote:
> --- Additional Comments From falk at debian dot org  2005-02-21 11:19 
> ---
> (In reply to comment #2)
> 
> 
>>Any chance to do something about it on older versions? (3.2.x 3.3.x 
>>3.4.x)
> 
> 
> No. We fix only regressions or very serious bugs in those versions.
> 
> 


-- 


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

[Bug c++/20073] [4.0 regression] ICE initializing const array

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-21 12:43 
---
Patch here: 
Mark's request: 
Unfortunately, I'm afraid I don't know the C++ frontend enough to handle that.
TREE_READONLY flag is set in code common to C/C++, c_apply_type_quals_to_decl.
For C/ObjC, we know that the type will never have TYPE_NEEDS_CONSTRUCTING,
so it is fine that way, but for C++ if the type is not yet complete
at the c_apply_type_quals_to_decl (for C++ this is the usual case), we might
set TREE_READONLY flag prematurely and the type when completed might have
TYPE_NEEDS_CONSTRUCTING.
Now, if we want to avoid setting it until we know it doesn't need constructing,
we could e.g. wrap c_apply_type_quals_to_decl into cp_apply_type_quals_to_decl
that will avoid marking it TREE_READONLY if the type is not yet complete and
in say complete_vars and cp_finish_decl mark it readonly if cp_type_quals (type)
& TYPE_QUAL_CONST and !TYPE_NEEDS_CONSTRUCTING (type).  Unfortunately, e.g.
split_nonconstant_init clears this flag even for vars that don't have
TYPE_NEEDS_CONSTRUCTNG set, so if we did that, we'd suddenly change the variable
back to have TREE_READONLY set while it should have it set.

-- 
   What|Removed |Added

 CC||jason at redhat dot com,
   ||mark at codesourcery dot com
 AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

[Bug c++/20098] Unresolved dependent "static const" symbol in template

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-21 
13:14 ---
Here's chapter and verse from the standard.

[9.4.2]/4 aka [class.static.data]/4:

If a static data member is of const integral or const enumeration type,
its declaration in the class definition can specify a constant-initializer
which shall be an integral constant expression (5.19). In that case, the
member can appear in integral constant expressions within its scope.
The member shall still be defined in a namespace scope if it is used in
the program and the namespace scope definition shall not contain an
initializer.


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org


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

[Bug fortran/20120] New: real(kind=16) and sqrt function cause ICE in print statement

[coudert at clipper dot ens dot fr]

real(16) :: a
  print *, sqrt(a)
end

$ ./bin/gfortran a.f90
a.f90: In function ‘MAIN__’:
a.f90:2: internal compiler error: in gfc_get_intrinsic_lib_fndecl, at
fortran/trans-intrinsic.c:499

-- 
   Summary: real(kind=16) and sqrt function cause ICE in print
statement
   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
 GCC build triplet: sparc-sun-solaris2.9
  GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9


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

[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2005-02-21 13:48 
---
In --enable-bootstrap mode GCC doesn't have this problem (intl rebuild at each 
stage with --enable-bootstrap option).

-- 


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

[Bug fortran/20120] real(kind=16) and sqrt function cause ICE in print statement

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
14:11 ---
Confirmed, another testcase (without print):
real(16) :: a
real(16) :: b
b = sqrt(a)
end

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|sparc-sun-solaris2.9|
   GCC host triplet|sparc-sun-solaris2.9|
 GCC target triplet|sparc-sun-solaris2.9|sparc-sun-solaris2.9,
   ||powerpc-darwin
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 14:11:01
   date||


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

[Bug middle-end/5169] paradoxical subreg problem

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2005-02-21 14:14 ---
Subject: Re:  paradoxical subreg problem

On Sun, 2005-02-20 at 00:34 +, jsm28 at gcc dot gnu dot org wrote:
> --- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-20 
> 00:34 ---
> The testcase no longer exhibits the bug, so this PR seems to represent
> some underlying problem with compiler internals rather than any longer
> being concerned with the failure of a particular testcase.
> 
> Jeff Law had a patch at .
> The discussion doesn't indicate anything in particular wrong with it,
> was there some reason it wasn't applied?
I don't think we ever came to a solid decision about which approach
was better.  My patch was simpler, but there may have been other
cases that Alan's patch handled that mine didn't.

I do think we all agreed that (subreg (mem)) was evil :-)

I think the fact that unrelated changes masked all these issues and
as a result this has been largely ignored for the last few years.

jeff



-- 


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

[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-21 14:15 
---
The following checklist for implementation of extended identifiers has
been discussed with and prioritised by Zack.  No doubt Neil will point
out if there are any missing technical points.

External specifications
===

Reasonable efforts should be made to get specifications of handling of
extended identifiers (that UCNs and other non-ASCII characters in
identifiers are encoded in UTF-8, at least on platforms using ASCII in
the symbol names in the first place) into the following
specifications.  Actually succeeding in doing so is not a blocker for
getting an implementation into GCC.

* ELF:
,
where it says "External C symbols have the same names in C and object
files' symbol tables.".  I have attempted to get such wording in, the
last version proposed being:

  Unless the operating system ABI specifies otherwise, it is
  recommended that characters in external C symbols, including
  characters outside the basic source character set whether or not
  designated in source files by universal character names, are encoded
  in UTF-8 in object files' symbol tables.

and discussions being with [EMAIL PROTECTED]

* C++ ABI: .  The
appropriate form would be to add a statement that once the ABI has
constructed a C symbol name which may contain UCNs, such name should
be encoded according to the underlying C ABI, following
.

The following specification already includes all the required text,
and GCC should implement it before a release is made supporting
extended identifiers:

* DWARF3: the DW_AT_use_UTF8 attribute should be set on the
compilation unit entry for each compilation unit with any UTF-8
identifiers (including ones such as structure element names which
appear in debug information but not otherwise in external
identifiers).  It may in fact be harmless to set it unconditionally.

GCC implementation issues
=

The following specific issues should be dealt with in the GCC
implementation.  Everything implemented needs appropriate tests in the
testsuite to cover it, for both C and C++.

(a) Probably implemented already; if not, should be done before
feature is turned on by default in mainline:

* The precise sets of characters permitted in identifiers in each
standard (C99 and C++03) should be followed.

* A UCN is equivalent to the character it denotes.  This should be
implemented initially for the case of $, but if we start accepting
other extended characters then it should be implemented for them as
well.

* The \U and \u UCNs for the same character, and UCNs differing in
upper or lower case for hex digits, are equivalent.

* The greedy algorithm applies for lexing UCNs: for example,
a\U000z is three preprocessing tokens {a}{\}{U000z} (and
shouldn't get a diagnostic on lexing, presuming macros are defined
such that the eventual token sequence is valid).

* The spelling of UCNs is preserved for the # and ## operators.

* UCNs must not be accepted in identifiers or preprocessing numbers in
strict C90 mode: what in C99 would be an identifier with a UCN in C90
is multiple preprocessing tokens and if the identifier fragments are
defined appropriately as macros this could occur in a valid C90
program.

* I think the only reasonable interpretation of the lexing rules in
the context of forbidden characters is that first identifiers are
lexed (allowing any UCNs) then bad characters yield an error (rather
than stopping the identifier before the bad character and treating it
as not a UCN).

* These rules apply to identifiers as preprocessing tokens at any
time, including before concatenation.  So it is not the case in C99
that splitting an identifier anywhere yields two valid preprocessing
tokens: the second half could begin with a UCN for a digit and not be
a valid identifier.  (Invalid identifiers in C99 don't require
diagnostics, but I don't think we want to use this laxity.)

(b) Not done and needs to happen before the feature is turned on by
default in mainline:

* The GCC testsuite should include a test that the same UCN links
between C and an extern "C" C++ identifier.

* There should be a warning by default for all identifiers (as
preprocessing tokens at any stage, e.g. including both before and
after concatenation) not in NFKC, which may be disabled by -Wno-nfkc.

* Preprocessing numbers can contain UCNs (and extended characters such
as $ considered equivalent to them).

(c) Should happen before a release is made containing this feature:

* All uses of identifiers and DECL_ASSEMBLER_NAME in the compiler
should be audited to determine what sort of identifier is appropriate
in each case.  All places where an identifier may appear in a
diagnostic must handle extended identifiers appropriately; if the
locale cann

[Bug fortran/20120] real(kind=16) and sqrt function cause ICE in print statement

[coudert at clipper dot ens dot fr]

--- Additional Comments From coudert at clipper dot ens dot fr  2005-02-21 
14:21 ---
Same happens with kind=10 on i686-linux-gnu:
  real(10) :: a, b
  b = sqrt(a)
  end

>From gfc_get_intrinsic_lib_fndecl:
  if (ts->type == BT_REAL)
{
  switch (ts->kind)
{
case 4:
  pdecl = &m->real4_decl;
  break;
case 8:
  pdecl = &m->real8_decl;
  break;
default:
  gcc_unreachable ();
}
}

-- 
   What|Removed |Added

 GCC target triplet|sparc-sun-solaris2.9,   |sparc-sun-solaris2.9,
   |powerpc-darwin  |powerpc-darwin, i686-gnu-
   ||linux


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

[Bug middle-end/19874] ICE in emit_move_insn with __attribute__((mode (QI))) enum

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-21 14:28 
---
This is a regression from GCC 3.4.x and earlier btw.

The problem seems to be that STRIP_USELESS_TYPE_CONVERSION strips
E to E __attribute__ ((mode (__byte__))) conversion as useless, although
it has different TYPE_MODE and TYPE_PRECISION.
This is because both have the same TYPE_MAIN_VARIANT.
I tried following patch which cures this for C, but unfortunately breaks
C++ at the same time (C++ needs both enums to have the same main variant):
--- gcc/c-common.c.jj   2005-02-14 09:25:46.0 +0100
+++ gcc/c-common.c  2005-02-21 14:43:53.0 +0100
@@ -4364,7 +4364,7 @@ handle_mode_attribute (tree *node, tree
}

  if (!(flags & (int) ATTR_FLAG_TYPE_IN_PLACE))
-   type = build_variant_type_copy (type);
+   type = build_distinct_type_copy (type);

  /* We cannot use layout_type here, because that will attempt
 to re-layout all variants, corrupting our original.  */
--- gcc/c-typeck.c.jj   2005-02-19 00:31:52.0 +0100
+++ gcc/c-typeck.c  2005-02-21 15:07:51.249019189 +0100
@@ -755,12 +755,19 @@ comptypes (tree type1, tree type2)
   if (c_dialect_objc () && objc_comptypes (t1, t2, 0) == 1)
val = 1;

-case ENUMERAL_TYPE:
 case UNION_TYPE:
   if (val != 1 && !same_translation_unit_p (t1, t2))
val = tagged_types_tu_compatible_p (t1, t2);
   break;

+/* Don't consider enum E { A, B } and enum E __attribute__((mode (byte)))
+   to be compatible.  */
+case ENUMERAL_TYPE:
+  if (val != 1 && TYPE_MODE (t1) == TYPE_MODE (t2)
+  && !same_translation_unit_p (t1, t2))
+val = tagged_types_tu_compatible_p (t1, t2);
+  break;
+
 case VECTOR_TYPE:
   val = TYPE_VECTOR_SUBPARTS (t1) == TYPE_VECTOR_SUBPARTS (t2)
&& comptypes (TREE_TYPE (t1), TREE_TYPE (t2));

Alternative would be e.g. to change c_types_compatible_p to special case
ENUMERAL_TYPEs and requiring there TYPE_MODE () to be compatible.


-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/20121] New: Aliasing lameness results in missing common subexpressions

[law at redhat dot com]

Our aliasing code is failing pretty badly in disambiguating memory addresses,
which in turn can lead to missing opportunities to remove memory operations.

Here's an exmaple taken from GCC itself (find_unreachable_blocks):

typedef unsigned int size_t;
extern void *xmalloc (size_t) __attribute__ ((__malloc__));
struct edge_def
{
  struct basic_block_def *dest;
  int flags;
};
typedef struct edge_def *edge;
struct basic_block_def
{
  int flags;
};
typedef struct basic_block_def *basic_block;
extern int n_basic_blocks;
extern edge frob ();
void
find_unreachable_blocks (int frobit)
{
  basic_block *tos, *worklist, bb;
  tos = worklist = xmalloc (sizeof (basic_block) * n_basic_blocks);
  edge e = frob();
  if (!(e->dest->flags & 4))
{
  e->dest->flags |= 4;
  *tos++ = e->dest;
}
}


The store into e->dest->flags does not affect e or e->dest.  Thus we only need
to load e->dest once.  Unfortunately, we load it twice.

I'll be checking this testcase into the testsuite (xfailed appropriately).

-- 
   Summary: Aliasing lameness results in missing common
subexpressions
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: law at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: Any
  GCC host triplet: Any
GCC target triplet: Any


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

[Bug tree-optimization/20121] Aliasing lameness results in missing common subexpressions

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug tree-optimization/20121] Aliasing lameness results in missing common subexpressions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
14:54 ---
Confirmed, CCing Daniel because he is working on structure aliasing right now.

-- 
   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org, pinskia at gcc dot gnu
   ||dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 14:54:40
   date||


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

[Bug c++/20118] missing template<> causes werid errors

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
14:57 ---
Confirmed, note on the mainline we get only:
t.cc:4: error: too few template-parameter-lists

Which kinda makes sense but we have no template paramater lists in the source.

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 14:57:38
   date||
Summary|spurious error  |missing template<> causes
   ||werid errors


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

[Bug tree-optimization/20121] Aliasing lameness results in missing common subexpressions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
15:00 ---
This is basically PR 13761 almong other bugs.

-- 
   What|Removed |Added

  BugsThisDependsOn||13761


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

[Bug tree-optimization/19786] [4.0 Regression] Aliasing optimisation bug

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
15:15 ---
This is an aliasing bug:
  #   VUSE ;
  D.11241_367 = this_127->D.8251._M_impl._M_finish;

But if we do:
  D.11300_379 = &this_127->D.8251._M_impl._M_finish;
  __i_380 = D.11300_379;
  #   VUSE ;
  SR.361_381 = *__i_380;

I think __i is const int * or something like that which causes the problem.
See how we have two different type tags.

-- 
   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org
   Keywords||alias


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

[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-02-21 
15:44 ---
regression testing of the patch in gcc 4.0 20050218 was successful.

-- 


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

[Bug c++/20103] [4.0 regression] ICE in create_tmp_var

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
15:45 ---
Why is the front-end producing a CONSTRUTOR when the variable needs to 
constructed.

The front-end should have produced its own temporary variable instead of 
producing a CONSTRUCTOR.

-- 


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

[Bug tree-optimization/20122] New: Wrong code with gcc 4.0 tree-vectorizer

[micis at gmx dot de]

This small test program generates a segfault if it is compiled with:
gcc40 -march=opteron -O2 -ftree-vectorize gccbug.cpp -o gccbug

Segfault does not occur when __attribute__((noinline)) is omitted.
It occurs with snapshot 20050213 and snapshot 20050220,
but not with snapshot 20050130


Michael Cieslinski


==
#include 

static struct KStructType
{union{
short Kernshort[8][24];
__m128i KernSSE[8][3];
};} KU  __attribute__(( aligned(16) ));

static void VecBug(short Kernel[8][24]) __attribute__((noinline));
static void VecBug(short Kernel[8][24])
{
for (int k = 0; k<8; k++)
for (int i = 0; i<24; i++)
KU.Kernshort[k][i] = Kernel[k][i];
}

int main (int argc, char **argv)
{
short Kernel[8][24];
for (int k = 0; k<8; k++)
for (int i = 0; i<24; i++)
Kernel[k][i] = 0;

VecBug(Kernel);

return 0;
}

-- 
   Summary: Wrong code with gcc 4.0 tree-vectorizer
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
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=20122

[Bug fortran/20108] incorrect run time error on formatted read

[coudert at clipper dot ens dot fr]

--- Additional Comments From coudert at clipper dot ens dot fr  2005-02-21 
16:34 ---
gfortran seems to handle incorrectly the case when we ask for more integers than
we provide (Intel compiler, for example, set j and k to 0 in the following
case). Reduced testcase:

$ cat a.f
  program main
  implicit none
  integer i,j,k
  character c
  read(5,'(a1,3i5)') c,i,j,k
  end
$ cat data
c1
c1

The error message is:
At line 5 of file a.f
Fortran runtime error: Bad value during integer read

If the second line of the data file is removed, the message becomes:
"Fortran runtime error: End of file"

Reproduced on i686-linux and sparc-sun-solaris2.9

-- 


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

[Bug fortran/20108] incorrect run time error on formatted read

[coudert at clipper dot ens dot fr]

-- 
   What|Removed |Added

 CC||coudert at clipper dot ens
   ||dot fr


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

[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-02-21 
16:38 ---
While merging the patch in a 3.4.3 based branch, I noticed three small issues:

- The rest_of_handle_life prototype in passes.c is not necessary.  It is a
  vestige from a previous (more intrusive) attempt to provide life
  information to if_convert.
- In passes.c:rest_of_handle_if_conversion, at the end of the
  flag_expensive_optimizations code, EXIT_BLOCK_PTR->global_live_at_start
  has to be cleared for compatibility with this patch:

  2004-05-17  J"orn Rennecke <[EMAIL PROTECTED]>

* cse.c (trivially_dead_nonlocal_regs): New variable.
(note_dead_set): New function.
(delete_trivially_dead_insns): If life info is available, update it.

  For completeness, we might also clear ENTRY_BLOCK_PTR->global_live_at_end.
- config/pa/pa.c:pa_commutative_p is missing the parameter list:
  (rtx x, int outer_code)


-- 


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

[Bug libstdc++/17922] [3.3/3.4 regression] Spurious warnings about std::ios_base::seekdir

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-21 
16:58 ---
Subject: Bug 17922

CVSROOT:/cvs/gcc
Module name:gcc
Branch: libstdcxx_so_7-branch
Changes by: [EMAIL PROTECTED]   2005-02-21 16:58:28

Modified files:
libstdc++-v3   : ChangeLog.libstdcxx_so_7-branch 
libstdc++-v3/config/io: c_io_stdio.h 
libstdc++-v3/include/bits: ios_base.h 
libstdc++-v3/src: ios.cc 
libstdc++-v3/testsuite/27_io/ios_base/cons: assign_neg.cc 
copy_neg.cc 
libstdc++-v3/testsuite/27_io/ios_base/types/fmtflags: 
  case_label.cc 
libstdc++-v3/testsuite/27_io/ios_base/types/iostate: 
 case_label.cc 
libstdc++-v3/testsuite/27_io/ios_base/types/openmode: 
  case_label.cc 
libstdc++-v3/testsuite/27_io/ios_base/types/seekdir: 
 case_label.cc 

Log message:
2005-02-21  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/17922 (ABI-unsafe half)
* config/io/c_io_stdio.h (struct __ios_flags): Remove.
* include/bits/ios_base.h (enum _Ios_Fmtflags, enum _Ios_Openmode,
enum _Ios_Iostate, enum _Ios_Seekdir): Remove *_end enumerators.
(class ios_base): Adjust fmtflags, iostate, openmore, seekdir
static constants.
* src/ios.cc: Remove definitions of __ios_flags constants.
* testsuite/27_io/ios_base/types/fmtflags/case_label.cc: Adjust,
removing the dummy label.
* testsuite/27_io/ios_base/types/iostate/case_label.cc: Likewise.
* testsuite/27_io/ios_base/types/openmode/case_label.cc: Likewise.
* testsuite/27_io/ios_base/types/seekdir/case_label.cc: Likewise.
* testsuite/27_io/ios_base/cons/assign_neg.cc: Adjust dg-error
line numbers.
* testsuite/27_io/ios_base/cons/copy_neg.cc: Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.libstdcxx_so_7-branch.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.1.2.36&r2=1.1.2.37
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config/io/c_io_stdio.h.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.7.18.1&r2=1.7.18.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/ios_base.h.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.40.6.3&r2=1.40.6.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/ios.cc.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.55.6.2&r2=1.55.6.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/ios_base/cons/assign_neg.cc.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.9.6.2&r2=1.9.6.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/ios_base/cons/copy_neg.cc.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.9.6.2&r2=1.9.6.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/ios_base/types/fmtflags/case_label.cc.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.1.6.1&r2=1.1.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/ios_base/types/iostate/case_label.cc.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.1.6.1&r2=1.1.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/ios_base/types/openmode/case_label.cc.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.1.6.1&r2=1.1.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/ios_base/types/seekdir/case_label.cc.diff?cvsroot=gcc&only_with_tag=libstdcxx_so_7-branch&r1=1.1.6.1&r2=1.1.6.2



-- 


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

[Bug middle-end/5169] paradoxical subreg problem

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-02-21 
17:34 ---
Subject: Re:  paradoxical subreg problem

On Mon, 21 Feb 2005, law at redhat dot com wrote:

> > Jeff Law had a patch at .
> > The discussion doesn't indicate anything in particular wrong with it,
> > was there some reason it wasn't applied?
> I don't think we ever came to a solid decision about which approach
> was better.  My patch was simpler, but there may have been other
> cases that Alan's patch handled that mine didn't.
> 
> I do think we all agreed that (subreg (mem)) was evil :-)
> 
> I think the fact that unrelated changes masked all these issues and
> as a result this has been largely ignored for the last few years.

Perhaps we should apply both patches to eliminate this latent bug or bugs 
and allow the PR to be closed?  (After 4.0 branches given that the bug is 
apparently latent at present so we shouldn't need to risk these patches in 
4.0.)



-- 


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

[Bug ada/20089] [4.0 Regression] gnatmake broken when building ada tools

[pluto at pld-linux dot org]

--- Additional Comments From pluto at pld-linux dot org  2005-02-21 17:53 
---
CC'ed. 

-- 
   What|Removed |Added

 CC||pluto at pld-linux dot org


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

[Bug fortran/20058] Error on kind 16 hex data statement

[kargl at gcc dot gnu dot org]

--- Additional Comments From kargl at gcc dot gnu dot org  2005-02-21 18:23 
---
For a patch see

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01253.html



-- 
   What|Removed |Added

   Keywords||patch


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

[Bug fortran/20058] Error on kind 16 hex data statement

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 18:45:29
   date||


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

[Bug tree-optimization/20122] Wrong code with gcc 4.0 tree-vectorizer

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
18:49 ---
I think this is related to PR 19716.  Note the tree level looks correct to me.

-- 


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

[Bug c++/20123] New: mangled name of typeid doesn't encode cv-qualifer.

[yanliu at ca dot ibm dot com]

Here is a testcase:
#include 
int const volatile v5[10] = {0};
int
main (int argc, char **argv) {
  const std::type_info& t = typeid (::v5);
}

According to Itanium C++ ABI, the mangled name of typeid(::v5) should follow 
the following grammer rules:
  ::= _Z 
  ::= 
::= TI  # typeinfo structure
   ::= 
  ::= A  _ 

To my understanding, the element type follows the  rule and is used to 
encode the type of variable v5[10]:
 ::=  
::= [r] [V] [K] # restrict (C99), volatile, 
const


So the mangled name should be: __ZTIA10_VKi. But using gcc 4.0 compiler, I am 
getting "__ZTIA10_i" mangled name instead. 

Please verify the problem, thanks.

-- 
   Summary: mangled name of typeid doesn't encode cv-qualifer.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yanliu at ca dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/20124] New: gfortran prints -.01 incorrectly

[dir at lanl dot gov]

Actually + and - .01 print as zero -


[dir:~/tests/gfortran] dir% gfortran -o print01 print01.f
[dir:~/tests/gfortran] dir% print01
  0.00  0.00
STOP 0
[dir:~/tests/gfortran] dir% cat print01.f
  program main
  x=-.01
  y=.01
  write(6,1000)x,y
  stop
 1000 format (2f10.2)
  end

-- 
   Summary: gfortran prints -.01 incorrectly
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-apple-darwin7.8.0


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

[Bug c++/20123] mangled name of typeid doesn't encode cv-qualifer.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
19:17 ---
hmm, ICC 8.0 on ia32-linux produces the same mangled name for the variable too.

-- 
   What|Removed |Added

   Keywords||ABI


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

[Bug libfortran/20124] gfortran prints -.01 incorrectly

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

OtherBugsDependingO||19292
  nThis||
 Status|UNCONFIRMED |NEW
  Component|fortran |libfortran
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 19:23:22
   date||


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

[Bug fortran/20125] New: gfortran - backspace on binary files errors

[dir at lanl dot gov]

I don't know if backspace ever works, but while trying to run some calculations
the read after a backspace got some run time errors, crashed, and sometimes hung
the program -

[dir:~/tests/gfortran] dir% gfortran -o backspace backspace.f
[dir:~/tests/gfortran] dir% backspace
At line 5 of file backspace.f
Fortran runtime error: End of file
[dir:~/tests/gfortran] dir% cat backspace.f
  program main
  i=1
  write(3)i
  backspace 3
  read(3)i
  stop
  end

-- 
   Summary: gfortran - backspace on binary files errors
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-apple-darwin7.8.0


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

[Bug tree-optimization/19786] [4.0 Regression] Aliasing optimisation bug

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-02-21 
19:30 ---
Subject: [PR tree-optimization/19786] fix alias grouping lossage

The problem here was that we added type tags to other tag's may-alias
lists without adding them to the corresponding bitmaps.  Later on,
when group_aliases performed an union of the bitmaps and discarded the
lists, we lost information about the aliases, which enabled LIM to
hoist a pointer access out of a loop because it appeared to be
invariant, since the VDEF supposed to modify it was missing.

Thanks to Jakub for having isolated the source of the problem, and
Diego for discussing tree-ssa alias analysis with me for a few hours
today.

Here's the patch I'm testing.  Ok to install if it bootstraps and
regtests successfully?

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

PR tree-optimization/19786
* tree-ssa-alias.c (compute_flow_insensitive_aliasing): Add one
tag to another's may-alias bitmap when adding to the other's list.

Index: gcc/tree-ssa-alias.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.69
diff -u -p -r2.69 tree-ssa-alias.c
--- gcc/tree-ssa-alias.c 17 Feb 2005 16:19:42 - 2.69
+++ gcc/tree-ssa-alias.c 21 Feb 2005 19:15:40 -
@@ -1116,6 +1116,7 @@ compute_flow_insensitive_aliasing (struc
  /* Since TAG2 does not have any aliases of its own, add
 TAG2 itself to the alias set of TAG1.  */
  add_may_alias (tag1, tag2);
+ SET_BIT (may_aliases1, var_ann (tag2)->uid);
}
}
 }
Index: gcc/testsuite/ChangeLog
from  Alexandre Oliva  <[EMAIL PROTECTED]>

PR tree-optimization/19786
* g++.dg/tree-ssa/pr19786.C: New.

Index: gcc/testsuite/g++.dg/tree-ssa/pr19786.C
===
RCS file: gcc/testsuite/g++.dg/tree-ssa/pr19786.C
diff -N gcc/testsuite/g++.dg/tree-ssa/pr19786.C
--- /dev/null   1 Jan 1970 00:00:00 -
+++ gcc/testsuite/g++.dg/tree-ssa/pr19786.C 21 Feb 2005 19:15:54 -
@@ -0,0 +1,48 @@
+// { dg-do run }
+/* { dg-options "-O2" } */
+
+// We used to get alias grouping wrong on this one, hoisting accesses
+// to the vector's end out of the loop.
+
+#include 
+#include 
+
+struct A
+{
+  double unused;  // If I remove it => it works.
+  std::vector v;
+
+  A() : v(1) {}
+};
+
+inline // If not inline => it works.
+A g()
+{
+  A r;
+  r.v.resize(2);
+  r.v[0] = 1;
+
+  while (!r.v.empty() && r.v.back() == 0)
+r.v.pop_back();
+
+  return r;
+}
+
+A f(const A &a)
+{
+  if (a.v.empty())  return a;
+  if (a.v.empty())  return a;
+
+  // A z = g(); return z;  // If I return like this => it works.
+  return g();
+}
+
+int main()
+{
+  A a;
+  A b;
+  A r = f(a);
+  assert(r.v.size() != 0);
+
+  return 0;
+}

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

[Bug tree-optimization/19786] [4.0 Regression] Aliasing optimisation bug

[dnovillo at redhat dot com]

--- Additional Comments From dnovillo at redhat dot com  2005-02-21 19:33 
---
Subject: Re: [PR tree-optimization/19786] fix alias grouping lossage

Alexandre Oliva wrote:

>   PR tree-optimization/19786
>   * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Add one
>   tag to another's may-alias bitmap when adding to the other's list.
> 
OK.  Thanks.


Diego.


-- 


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

[Bug fortran/4885] BACKSPACE example that doesn't work as of gcc/g77-3.0.x

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |3.0.x


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

[Bug libfortran/20125] gfortran - backspace on binary files errors

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

OtherBugsDependingO||19292
  nThis||
 Status|UNCONFIRMED |NEW
  Component|fortran |libfortran
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 19:36:16
   date||


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

[Bug c++/20123] mangled name of typeid doesn't encode cv-qualifer.

[yanliu at ca dot ibm dot com]

--- Additional Comments From yanliu at ca dot ibm dot com  2005-02-21 19:37 
---
For function parameters, the cv-qualifers should not be mangled. I suspect GCC 
treates this typeid as a function, thus ignoring the encoding of cv-qualifers. 
At least, the C++ ABI is not clear in this aspect.  

-- 


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

[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-02-21 
19:47 ---
Subject: Re:  UCNs not recognized in identifiers
 (c++/c99)

On Mon, 21 Feb 2005, geoffk at geoffk dot org wrote:

> > * These rules apply to identifiers as preprocessing tokens at any
> > time, including before concatenation.  So it is not the case in C99
> > that splitting an identifier anywhere yields two valid preprocessing
> > tokens: the second half could begin with a UCN for a digit and not be
> > a valid identifier.  (Invalid identifiers in C99 don't require
> > diagnostics, but I don't think we want to use this laxity.)
> 
> The second half would a pp-number, instead.  It is always true that 
> splitting an identifier between characters yields two valid 
> preprocessing tokens.

It would not be a pp-number, as a UCN for a digit is still an 
identifier-nondigit rather than a digit in terms of the syntax and 
pp-numbers can't start with identifiers-nondigits.

> > * All uses of identifiers and DECL_ASSEMBLER_NAME in the compiler
> > should be audited to determine what sort of identifier is appropriate
> > in each case.
> 
> I don't understand this sentence.  What different sorts of identifiers 
> are there, and how could they be appropriate or not appropriate?

Identifiers found in input, with input spelling.  (Input includes -D and 
-U options on the command line - in principle the command line should be 
interpreted in the user's locale by default just like source files.)

UTF-8 (or, I suppose, UTF-EBCDIC) internally encoded identifiers.

Identifiers in mangled form in any case where they are mangled for output.

Identifiers in diagnostics (possibly including cases where bits of a 
diagnostic get built up with sprintf), which need converting to the user's 
locale for display or to be displayed using UCNs.

I don't know if collect2 might also need to know something about extended 
identifiers.

The aim is that every datastructure with an identifier should have the 
encoding (input, internal, output, diagnostic) well-defined and 
conversions between these should be handled properly.



-- 


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

[Bug libfortran/20125] gfortran - backspace on binary files errors

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
19:49 ---
Note backspace does work in some testcases but how many and what the situation 
I don't know right.

-- 
   What|Removed |Added

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


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

[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

[zack at codesourcery dot com]

--- Additional Comments From zack at codesourcery dot com  2005-02-21 20:14 
---
Subject: Re:  UCNs not recognized in identifiers
 (c++/c99)

"geoffk at geoffk dot org" <[EMAIL PROTECTED]> writes:

> Although I agree that these are all (except the below) nice things to 
> have, I don't think I agree that they are all preconditions to having 
> any part of an implementation.  For instance, an implementation that 
> said sorry() when using # on an identifier from a UCN would still be 
> more useful than the complete lack of implementation we have now.

In my book, a complete lack of implementation of this particular
feature is better than an incomplete one.  This is because I see the
vast majority of the work required to do a complete implementation as
being due-diligence tasks needed to ensure that the feature cannot
crash the compiler, cause wrong code generation, or introduce
compatibility problems, and as long as someone is going to do all that
work, why shouldn't they do the rest of the job as long as they're in
there?

> The second half would a pp-number, instead.  It is always true that
> splitting an identifier between characters yields two valid
> preprocessing tokens.

Joseph has mostly explained this, but I should add that what you get
if you split, say, "a\u0660b", between the "a" and the backslash is
two identifiers, the second of which's "initial character is a
universal character name designating a digit", which violates a
shall-clause in a semantics paragraph, and therefore provokes
undefined behavior. (C99 6.4.2.1p3.)

Standing policy is that all cases which provoke undefined behavior
inside the preprocessor, except already-documented GNU extensions,
shall produce hard errors.  I am tempted to make a partial exception
in this case in the interest of better compatibility with C++.  Almost
all of the UCNs in the "digits" block of C99 annex D are completely
excluded from C++98 annex E - so "a\u0660b" for instance is an invalid
identifier, and we never get as far as wondering what happens if we
split it before the backslash.  However, the range 0e50-0e59 is in the
"Thai" range of C++98/E, but *both* the "Thai" and the "Digits" ranges
of C99/D.  It would be sensible, IMO, to resolve the error in C99/D by
removing 0e50-0e59 from the "Digits" range, thus permitting those
characters to begin identifiers in both C and C++.  [Note that
currently ucnid.tab takes the opposite position.]

zw


-- 


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

[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

[zack at codesourcery dot com]

--- Additional Comments From zack at codesourcery dot com  2005-02-21 20:23 
---
Subject: Re:  UCNs not recognized in identifiers
 (c++/c99)

"geoffk at geoffk dot org" <[EMAIL PROTECTED]> writes:

>>> The second half would a pp-number, instead.  It is always true that
>>> splitting an identifier between characters yields two valid
>>> preprocessing tokens.
>>
>> It would not be a pp-number, as a UCN for a digit is still an
>> identifier-nondigit rather than a digit in terms of the syntax and
>> pp-numbers can't start with identifiers-nondigits.
>
> That's a defect in the standard, the tail of an identifier is supposed 
> to be either an identifier or a pp-number, that's why pp-number exists.

Arguably yes.  *shrug* You perhaps begin to see why I did not want
this feature implemented?  Or at least why I want it done with great
caution and consideration of all these corner cases?

Does your opinion of this particular corner case change in view of C++
not permitting most of the "digit" UCNs in identifiers at all?

zw


-- 


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

Possible C compiler bug

[Bob Green]

I get a segmentation fault when a C program allocates
an 8MB array in the subroutine "main()".  The
specifics are listed below.  Any help understanding
if this is a bug would be greatly appreciated.

Thanks,
Bob


gcc version
===
gcc -v produces:
Reading specs from
/usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1256, based on gcc
version 3.1 20021003 (prerelease)

input file
==
input file called debug.c contains:
main()
{
float a[2048][1024];
}

compiler options

no compiler options were given (command was: gcc
debug.c)

.i file
===
compiling with the -save-temps flag produces the
following .i file:
# 1 "debug.c"
main ( )
{
float a [ 2048 ] [ 1024 ] ;
}

machine and OS
==
Apple PowerBook G4 running Mac OS X Version 10.3.8
Build 7U16

compiler cofiguration
=
used default configuration for Apple Developer's Kit

incorrect output

running a.out produces the following error:
Segmentation fault






__ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

Re: Possible C compiler bug

[Andrew Pinski]

On Feb 21, 2005, at 3:28 PM, Bob Green wrote:
I get a segmentation fault when a C program allocates
an 8MB array in the subroutine "main()".  The
specifics are listed below.  Any help understanding
if this is a bug would be greatly appreciated.
No this is not a bug, you are allocating the 8MB on the stack.
The stack size on ppc-darwin before 7 is only 512K though the stacksize
on ppc-darwin after 7 is 8M, you will still not be able to run the 
program
as there is overhead.
You need to either change the stack size limit or allocate it on the 
heap.

-- Pinski

[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

[zack at codesourcery dot com]

--- Additional Comments From zack at codesourcery dot com  2005-02-21 20:54 
---
Subject: Re:  UCNs not recognized in identifiers
 (c++/c99)

"geoffk at geoffk dot org" <[EMAIL PROTECTED]> writes:

>>> The second half would a pp-number, instead.  It is always true that
>>> splitting an identifier between characters yields two valid
>>> preprocessing tokens.
>>
>> Joseph has mostly explained this, but I should add that what you get
>> if you split, say, "a\u0660b", between the "a" and the backslash is
>> two identifiers, the second of which's "initial character is a
>> universal character name designating a digit", which violates a
>> shall-clause in a semantics paragraph, and therefore provokes
>> undefined behavior. (C99 6.4.2.1p3.)
>
> A shall-clause in a semantics paragraph requires a diagnostic, C99 
> 5.1.1.3.

Um, no, 5.1.1.3 does not say that.  It says a diagnostic is required
for a violation of any "syntax rule or constraint"; shall-clauses in
semantics paragraphs are neither.  Constraints only appear in
constraints paragraphs.  See 4p2 for the meaning of shall-clauses
outside constraints paragraphs.

zw


-- 


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

[Bug c++/14500] most specialized function template vs. non-template function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:08 ---
Any news on this?

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Last reconfirmed|2004-04-04 03:00:26 |2005-02-21 21:08:31
   date||


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

[Bug c++/20028] [3.4 Regression] class and then template class gives an ICE

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-21 
21:11 ---
Subject: Bug 20028

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-02-21 21:11:51

Modified files:
gcc/cp : ChangeLog class.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: crash34.C 

Log message:
gcc/cp/ChangeLog:
PR c++/20028
* class.c (finish_struct): Initialize TYPE_SIZE_UNIT of a
template along with TYPE_SIZE.
gcc/testsuite/ChangeLog:
PR c++/20028
* g++.dg/template/crash34.C: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.200&r2=1.3892.2.201
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.595.4.9&r2=1.595.4.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.363&r2=1.3389.2.364
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash34.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug middle-end/20109] printf optimizations and non-ASCII character sets

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:28 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:28:43
   date||


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

[Bug c/20110] format checking and non-ASCII character sets

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:28 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:28:55
   date||


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

[Bug middle-end/20111] real_nan and non-ASCII character sets

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:29 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid, rejects-
   ||valid
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:29:23
   date||


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

[Bug libfortran/20074] reshape of pointer array segfaults at runtime

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:32 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:32:11
   date||


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

[Bug c++/20028] [3.4 Regression] class and then template class gives an ICE

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:34 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/20092] gfortran not correctly padding keyboard or text file input

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:36 ---
Confirmed.

-- 
   What|Removed |Added

OtherBugsDependingO||19292
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:36:20
   date||


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

[Bug rtl-optimization/20117] [4.0 Regression] duplicated labels in PIC

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:38 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |rtl-optimization
 Ever Confirmed||1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:38:06
   date||
Summary|[4.0.0 Regression]  |[4.0 Regression] duplicated
   |duplicated labels in PIC|labels in PIC


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

[Bug libfortran/19302] intrinsic_nearest.f90 fails

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-21 
21:39 ---
Subject: Bug 19302

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-21 21:39:33

Modified files:
libgfortran: ChangeLog 
libgfortran/intrinsics: c99_functions.c 

Log message:
PR libfortran/19302
* intrinsics/c99_functions.c (nextafterf): Special-case infinite
numbers.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.160&r2=1.161
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/c99_functions.c.diff?cvsroot=gcc&r1=1.9&r2=1.10



-- 


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

[Bug c++/20098] [4.0 Regression] Missed optimization with static const and templates

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:40 ---
It was broken sinece at least 20050201.
It worked with 20050113.

Confirmed, a missed optimization regression.

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Priority|P2  |P3
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:40:51
   date||
Summary|Unresolved dependent "static|[4.0 Regression] Missed
   |const" symbol in template   |optimization with static
   ||const and templates
   Target Milestone|--- |4.0.0


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

[Bug libfortran/19302] intrinsic_nearest.f90 fails

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-02-21 
21:42 ---
Patch installed.


-- 
   What|Removed |Added

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


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

[Bug libfortran/20108] incorrect run time error on formatted read

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
21:44 ---
Confirmed with the reduced testcase, G77 does the correct thing also.

-- 
   What|Removed |Added

OtherBugsDependingO||19292
  nThis||
 Status|UNCONFIRMED |NEW
  Component|fortran |libfortran
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:44:19
   date||


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

[Bug c/20126] New: Inlined memcmp makes one argument null on entry

[jkohen at users dot sourceforge dot net]

Hi, I found out a compiler bug triggered by compiling Python 2.3 with GCC 4.0
"pre5." I've been able to track it down to a small fragment which I'll attach
below. The bug is a regression as GCC 3.4.4 20050203 produces a working 
application.

This is the compiler's output and compilation command-line:
Using built-in specs.
Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada
--prefix=/usr --libexecdir=/usr/lib --enable-shared --with-system-zlib
--enable-nls --enable-threads=posix --without-included-gettext
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --enable-mpfr x86_64-linux
Thread model: posix
gcc version 4.0.0 20050125 (experimental) (Debian 4.0-0pre5.0.0.1.gcc4)
 /usr/lib/gcc/x86_64-linux/4.0.0/cc1 -E -quiet -v ptest.c -mtune=k8 -Wall
-Wstrict-prototypes -O3 -fpch-preprocess -o ptest.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux/4.0.0/../../../../x86_64-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-linux/4.0.0/include
 /usr/include
End of search list.
 /usr/lib/gcc/x86_64-linux/4.0.0/cc1 -fpreprocessed ptest.i -quiet -dumpbase
ptest.c -mtune=k8 -auxbase ptest -O3 -Wall -Wstrict-prototypes -version -o 
ptest.s
GNU C version 4.0.0 20050125 (experimental) (Debian 4.0-0pre5.0.0.1.gcc4)
(x86_64-linux)
compiled by GNU C version 4.0.0 20050125 (experimental) (Debian
4.0-0pre5.0.0.1.gcc4).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -V -Qy --64 -o ptest.o ptest.s
GNU ensamblador versión 2.15 (x86_64-linux) utilizando BFD versión 2.15
 /usr/lib/gcc/x86_64-linux/4.0.0/collect2 --eh-frame-hdr -m elf_x86_64
-dynamic-linker /lib/ld-linux-x86-64.so.2 -o ptest
/usr/lib/gcc/x86_64-linux/4.0.0/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-linux/4.0.0/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-linux/4.0.0/crtbegin.o -L/usr/lib/gcc/x86_64-linux/4.0.0
-L/usr/lib/gcc/x86_64-linux/4.0.0
-L/usr/lib/gcc/x86_64-linux/4.0.0/../../../../lib64
-L/usr/lib/gcc/x86_64-linux/4.0.0/../../.. -L/lib/../lib64 -L/usr/lib/../lib64
ptest.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/x86_64-linux/4.0.0/crtend.o
/usr/lib/gcc/x86_64-linux/4.0.0/../../../../lib64/crtn.o

In case the information is ambiguous, the compiler is a 64-bit binary generating
64-bit binaries.

Please check http://lists.debian.org/debian-amd64/2005/02/msg00505.html for some
comments I wrote on the relevant assembly output.

-- 
   Summary: Inlined memcmp makes one argument null on entry
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkohen at users dot sourceforge dot net
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=20126

[Bug c/20126] Inlined memcmp makes one argument null on entry

[jkohen at users dot sourceforge dot net]

--- Additional Comments From jkohen at users dot sourceforge dot net  
2005-02-21 21:47 ---
Created an attachment (id=8246)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8246&action=view)
The program that causes the failure

I use Python's data structures, that's the explanation for the weird
structures.

-- 


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

[Bug target/20126] Inlined memcmp makes one argument null on entry

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |target
   Keywords||wrong-code


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

[Bug target/20126] Inlined memcmp makes one argument null on entry

[jkohen at users dot sourceforge dot net]

--- Additional Comments From jkohen at users dot sourceforge dot net  
2005-02-21 21:48 ---
Created an attachment (id=8247)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8247&action=view)
A slightly modified version that does work.

I'm sorry if it's irrelevant, but here's a slightly different version that
works correctly. I was trying to make the fragment small by removing some
duplicate code, but that change makes it work. You can diff this against
ptest.i and see the few differences pretty clearly.

-- 


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

[Bug target/20126] Inlined memcmp makes one argument null on entry

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Attachment #8246|text/plain  |application/octet-stream
  mime type||


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

[Bug target/20126] Inlined memcmp makes one argument null on entry

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Attachment #8247|text/plain  |application/octet-stream
  mime type||


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

[Bug c/20127] New: wrong code for volatile struct members?

[schlie at comcast dot net]

The following code does not treat volatile struct members as volatile,
assuming such declarations are valid; if not would exect a warning:

typedef struct {
  volatile int a;
  volatile int b;
  } s;

int main (void){

  s x = {0, 1};
  s y = {2, 3};
  
  x = y;
  y = x;
  
  return x.a + y.a;

}

generates:

00c6 :
  volatile int a;
  volatile int b;
  } s;

int main (void){
  c6:   cf ef   ldi r28, 0xFF   ; 255
  c8:   d0 e1   ldi r29, 0x10   ; 16
  ca:   de bf   out 0x3e, r29   ; 62
  cc:   cd bf   out 0x3d, r28   ; 61

  s x = {0, 1};
  s y = {2, 3};
  
  x = y;
  y = x;
  
  return x.a + y.a;

}
  ce:   84 e0   ldi r24, 0x04   ; 4
  d0:   90 e0   ldi r25, 0x00   ; 0
  d2:   0c 94 6b 00 jmp 0xd6 <_exit>

-- 
   Summary: wrong code for volatile struct members?
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ppc-apple-darwin7.8
  GCC host triplet: ppc-apple-darwin7.8
GCC target triplet: avr-unknown-unknown


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
22:15 ---
Reduced testcase (and shows that this is also a 3.3/3.4/4.0 Regression too):
#include 
#include 
#include 
typedef struct {
struct _object *_ob_next;
struct _object *_ob_prev;
int ob_refcnt;
struct _typeobject *ob_type;
int ob_size;
long ob_shash;
int ob_sstate;
char ob_sval[1];
} strobject;
static int
string_contains(strobject *a, strobject *el)
{
 const char *lhs, *rhs, *end;
 int size;

 size = (((el))->ob_size);
 rhs = (((el))->ob_sval);
 lhs = (((a))->ob_sval);

 if (size == 1)
  return memchr(lhs, *rhs, (((a))->ob_size)) != ((void *)0);

 end = lhs + a))->ob_size) - size);
 while (lhs <= end) {
  const char *t = lhs+1;
  if (memcmp(lhs, rhs, size) == 0)
   return 1;
  lhs = t;
 }
 return 0;
}
int
main(void)
{
 char* s1 = "aa";
 char* s2 = "aa";
 strobject *obj1;
 strobject *obj2;
 obj1 = calloc(1, sizeof (*obj1) + 64);
 obj2 = calloc(1, sizeof (*obj2) + 64);
 obj1->ob_size = strlen(s1);
 obj2->ob_size = strlen(s2);
 memcpy(&obj1->ob_sval[0], s1, obj1->ob_size);
 memcpy(&obj2->ob_sval[0], s2, obj2->ob_size);
 printf("'%*s' in '%*s' = %d\n",
obj2->ob_size, obj2->ob_sval,
obj1->ob_size, obj1->ob_sval,
string_contains(obj1, obj2));
 return 0;
}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.3.3 3.4.0 4.0.0
  Known to work||3.2.3
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 22:15:27
   date||
Summary|Inlined memcmp makes one|[3.3/3.4/4.0 Regression]
   |argument null on entry  |Inlined memcmp makes one
   ||argument null on entry
   Target Milestone|--- |3.4.4


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

[Bug tree-optimization/20127] wrong code for volatile struct members?

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
22:19 ---
Hmm, SRA creates new variables and then goes and makes them renamed which seems 
wrong.

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed||1
  GCC build triplet|ppc-apple-darwin7.8 |
   GCC host triplet|ppc-apple-darwin7.8 |
 GCC target triplet|avr-unknown-unknown |
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 22:19:24
   date||
   Target Milestone|--- |4.0.0


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

[Bug other/20128] New: ice on valid code / mudflap + profile generate

[pluto at pld-linux dot org]

# cat tmp.c  
int main() { }  
 
# LANG=C gcc -std=gnu9x -O2 -fmudflap -c -lmudflap -fprofile-generate tmp.c 
tmp.c: In function '_GLOBAL__I_1_main': 
tmp.c:1: internal compiler error: Segmentation fault 
 
# gcc -v  
Reading specs from /usr/lib/gcc/i686-pld-linux/4.0.0/specs  
Target: i686-pld-linux  
Configured with: ../configure --prefix=/usr --libdir=/usr/lib  
--libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man  
--enable-shared --enable-threads=posix --enable-__cxa_atexit  
--enable-languages=c,c++,ada --enable-c99 --enable-long-long  
--disable-multilib --enable-nls --with-gnu-as --with-gnu-ld  
--with-demangler-in-ld --with-system-zlib --with-slibdir=/lib --without-x  
--enable-cmath i686-pld-linux  
Thread model: posix  
gcc version 4.0.0 20050220 (experimental) (PLD Linux)

-- 
   Summary: ice on valid code / mudflap + profile generate
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pld-linux
  GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux


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

[Bug other/20128] ice with mudflap + profile generate

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
22:33 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 22:33:12
   date||
Summary|ice on valid code / mudflap |ice with mudflap + profile
   |+ profile generate  |generate


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

[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

[neil at daikokuya dot co dot uk]

--- Additional Comments From neil at daikokuya dot co dot uk  2005-02-21 
23:00 ---
Subject: Re:  UCNs not recognized in identifiers (c++/c99)

jsm28 at gcc dot gnu dot org wrote:-

> * The greedy algorithm applies for lexing UCNs: for example,
> a\U000z is three preprocessing tokens {a}{\}{U000z} (and
> shouldn't get a diagnostic on lexing, presuming macros are defined
> such that the eventual token sequence is valid).

I'm not sure I agree with this: it would seem to be unnecessary
extra work; further I suspect the user would benefit from it being
pointed out he entered an ill-formed UCN rather than something random
from the front end complaining about an unexpected backslash.

The only case where you wouldn't get a syntax error from the
front end, or an invalid escape in a literal, is with -E.  I'm
not sure lexing to the letter of the standard is worthwhile in
this case, as the standard doesn't discuss -E.

If you have an example where a compiled program is acceptable
with multiple lexing tokens then I would agree with you.

> * The spelling of UCNs is preserved for the # and ## operators.

This is very hard with CPP's current implementation - it assumes
it can deduce the spelling of an identifier from its hash table
entry.  IMO the proper way to fix this to use a different approach
entirely, rather than kludge it in the existing implementation
(which would bloat some common datastructures) but that's some work.

> * I think the only reasonable interpretation of the lexing rules in
> the context of forbidden characters is that first identifiers are
> lexed (allowing any UCNs) then bad characters yield an error (rather
> than stopping the identifier before the bad character and treating it
> as not a UCN).

Agreed - as I say above I don't see why this shouldn't apply for
partial UCNs too, even with -E.
 
The rest seems reasonable.

Neil.


-- 


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

[Bug c/20129] New: ICE when compiling glibc-2.3.4/math/s_fmax.c

[molletts at yahoo dot com]

When cross-compiling glibc-2.3.4, gcc bails out with an ICE while attempting to 
compile math/s_fmax.c: 
 
arm-unknown-linux-gnu-gcc ../sysdeps/generic/s_fmax.c -c -std=gnu99 -Os -Wall 
-Winline -Wstrict-prototypes -Wwrite-strings -march=armv3 -pipe   -g0 -O99 
-fomit-frame-pointer -D__USE_STRING_INLINES   -Wno-uninitialized 
-D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -DNO_LONG_DOUBLE 
-D_Mlong_double_=double -I../include -I. -I/home/stephen/build/math -I.. 
-I../libio  -I/home/stephen/build -I../sysdeps/arm/elf 
-I../linuxthreads/sysdeps/unix/sysv/linux/arm 
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread 
-I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv 
-I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/arm 
-I../sysdeps/unix/sysv/linux/arm -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu 
-I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet 
-I../sysdeps/unix/sysv -I../sysdeps/unix/arm -I../sysdeps/unix 
-I../sysdeps/posix -I../sysdeps/arm/fpu -I../sysdeps/arm 
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf 
-I../sysdeps/generic  -D_LIBC_REENTRANT -include ../include/libc-symbols.h   
-DNOT_IN_libc=1 -DIS_IN_libm=1-o /home/stephen/build/math/s_fmax.o -MD -MP 
-MF /home/stephen/build/math/s_fmax.o.dt -MT /home/stephen/build/math/s_fmax.o 
../sysdeps/generic/s_fmax.c: In function `__fmax': 
../sysdeps/generic/s_fmax.c:28: internal compiler error: in elim_reg_cond, at 
flow.c:3257 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See http://gcc.gnu.org/bugs.html> for instructions. 
 
Preprocessed source (s_fmax.i) follows: 
 
# 1 "../sysdeps/generic/s_fmax.c" 
# 1 "" 
# 1 "" 
# 10 "" 
# 1 "./../include/libc-symbols.h" 1 
# 56 "./../include/libc-symbols.h" 
# 1 "/home/stephen/build/config.h" 1 
# 57 "./../include/libc-symbols.h" 2 
# 874 "./../include/libc-symbols.h" 
# 1 "../sysdeps/wordsize-32/symbol-hacks.h" 1 
# 875 "./../include/libc-symbols.h" 2 
# 11 "" 2 
# 1 "../sysdeps/generic/s_fmax.c" 
# 21 "../sysdeps/generic/s_fmax.c" 
# 1 "../include/math.h" 1 
 
 
# 1 "../math/math.h" 1 
# 27 "../math/math.h" 
# 1 "../include/features.h" 1 
# 308 "../include/features.h" 
# 1 "../include/sys/cdefs.h" 1 
 
 
# 1 "../misc/sys/cdefs.h" 1 
# 4 "../include/sys/cdefs.h" 2 
 
extern void __chk_fail (void) __attribute__ ((__noreturn__)); 
 
 
# 309 "../include/features.h" 2 
# 331 "../include/features.h" 
# 1 "../include/gnu/stubs.h" 1 
# 332 "../include/features.h" 2 
# 28 "../math/math.h" 2 
 
 
 
 
 
# 1 "../sysdeps/arm/bits/huge_val.h" 1 
# 34 "../math/math.h" 2 
 
# 1 "../sysdeps/ieee754/bits/huge_valf.h" 1 
# 36 "../math/math.h" 2 
# 1 "../sysdeps/generic/bits/huge_vall.h" 1 
# 37 "../math/math.h" 2 
 
 
# 1 "../sysdeps/ieee754/bits/inf.h" 1 
# 40 "../math/math.h" 2 
 
 
# 1 "../sysdeps/ieee754/bits/nan.h" 1 
# 43 "../math/math.h" 2 
 
 
 
# 1 "../sysdeps/arm/fpu/bits/mathdef.h" 1 
# 27 "../sysdeps/arm/fpu/bits/mathdef.h" 
typedef float float_t; 
 
typedef double double_t; 
# 47 "../math/math.h" 2 
# 70 "../math/math.h" 
# 1 "../include/bits/mathcalls.h" 1 
# 1 "../math/bits/mathcalls.h" 1 
# 53 "../math/bits/mathcalls.h" 
 
 
extern double acos (double __x) __attribute__ ((__nothrow__)); extern double 
__acos (double __x) __attribute__ ((__nothrow__)); 
 
extern double asin (double __x) __attribute__ ((__nothrow__)); extern double 
__asin (double __x) __attribute__ ((__nothrow__)); 
 
extern double atan (double __x) __attribute__ ((__nothrow__)); extern double 
__atan (double __x) __attribute__ ((__nothrow__)); 
 
extern double atan2 (double __y, double __x) __attribute__ ((__nothrow__)); 
extern double __atan2 (double __y, double __x) __attribute__ ((__nothrow__)); 
 
 
extern double cos (double __x) __attribute__ ((__nothrow__)); extern double 
__cos (double __x) __attribute__ ((__nothrow__)); 
 
extern double sin (double __x) __attribute__ ((__nothrow__)); extern double 
__sin (double __x) __attribute__ ((__nothrow__)); 
 
extern double tan (double __x) __attribute__ ((__nothrow__)); extern double 
__tan (double __x) __attribute__ ((__nothrow__)); 
 
 
 
 
extern double cosh (double __x) __attribute__ ((__nothrow__)); extern double 
__cosh (double __x) __attribute__ ((__nothrow__)); 
 
extern double sinh (double __x) __attribute__ ((__nothrow__)); extern double 
__sinh (double __x) __attribute__ ((__nothrow__)); 
 
extern double tanh (double __x) __attribute__ ((__nothrow__)); extern double 
__tanh (double __x) __attribute__ ((__nothrow__)); 
 
 
 
 
extern void sincos (double __x, double *__sinx, double *__cosx) __attribute__ 
((__nothrow__)); extern void __sincos (double __x, double *__sinx, double 
*__cosx) __attribute__ ((__nothrow__)); 
 
 
 
 
 
 
extern double acosh (double __x) __attribute__ ((__nothrow__)); extern double 
__acosh (double __x) __attribute__ ((__nothrow__)); 
 
extern double asinh (double __x) __attribute__ (

[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux

[wilson at specifixinc dot com]

--- Additional Comments From wilson at specifixinc dot com  2005-02-21 
23:11 ---
Subject: Re:  gcc.dg/transparent-union-* fail on ia64-hpux

giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it  2005-02-20 
> 13:03 ---
> Jim, these are transparent unions, I thought that they were passed using the 
> convention of the first element in the union.

Yes, they are.  And yes, MEMBER_TYPE_FORCES_BLK is causing the problem. 
  Look at handle_transparent_union_attribute, and note the mode checks 
it is performing.


-- 


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

[Bug c++/6628] cannot typedef const functions

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-21 
23:12 ---
Subject: Bug 6628

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-21 23:12:28

Modified files:
gcc/cp : ChangeLog cp-tree.h decl.c decl2.c error.c pt.c 
 tree.c typeck.c 

Log message:
2005-02-21  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/19076
PR c++/6628
* cp-tree.h (cp_apply_type_quals_to_decl): Declared.
* decl.c (grokdeclarator): Pedwarn about qualifying a function
type.
Add qualifiers when declaring a typedef of a function type.
Member function pointers pick up the qualifiers of the typedef
used to declare them.
Don't complain about creating cv-qualified function types.
Complain about qualified function typedefs that are used to
declare non-static member functions or free functions.
Use cp_apply_type_quals_to_decl.
(start_preparsed_function): Use cp_apply_type_quals_to_decl.
(grokclassfn): Use cp_apply_type_quals_to_decl.
* error.c (dump_type_suffix): Print qualifiers for function
types.
* pt.c (tsubst_decl): Use cp_apply_type_quals_to_decl.
(tsubst): When substituting a function type into a member
pointer type, pass along the qualifiers.
(unify): Unify member pointers to member function pointers.
* tree.c (cp_build_qualified_type_real): Function types may be
qualified. This includes restrict qualifiers.
* typeck.c (cp_apply_type_quals_to_decl): New function to replace
use of c_apply_type_quals_to_decl. Drops qualifiers that are being
added to function types.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4639&r2=1.4640
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1104&r2=1.1105
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1366&r2=1.1367
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.767&r2=1.768
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&r1=1.275&r2=1.276
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.977&r2=1.978
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.426&r2=1.427
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.614&r2=1.615



-- 


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

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-21 
23:12 ---
Subject: Bug 19076

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-21 23:12:28

Modified files:
gcc/cp : ChangeLog cp-tree.h decl.c decl2.c error.c pt.c 
 tree.c typeck.c 

Log message:
2005-02-21  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/19076
PR c++/6628
* cp-tree.h (cp_apply_type_quals_to_decl): Declared.
* decl.c (grokdeclarator): Pedwarn about qualifying a function
type.
Add qualifiers when declaring a typedef of a function type.
Member function pointers pick up the qualifiers of the typedef
used to declare them.
Don't complain about creating cv-qualified function types.
Complain about qualified function typedefs that are used to
declare non-static member functions or free functions.
Use cp_apply_type_quals_to_decl.
(start_preparsed_function): Use cp_apply_type_quals_to_decl.
(grokclassfn): Use cp_apply_type_quals_to_decl.
* error.c (dump_type_suffix): Print qualifiers for function
types.
* pt.c (tsubst_decl): Use cp_apply_type_quals_to_decl.
(tsubst): When substituting a function type into a member
pointer type, pass along the qualifiers.
(unify): Unify member pointers to member function pointers.
* tree.c (cp_build_qualified_type_real): Function types may be
qualified. This includes restrict qualifiers.
* typeck.c (cp_apply_type_quals_to_decl): New function to replace
use of c_apply_type_quals_to_decl. Drops qualifiers that are being
added to function types.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4639&r2=1.4640
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1104&r2=1.1105
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1366&r2=1.1367
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.767&r2=1.768
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&r1=1.275&r2=1.276
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.977&r2=1.978
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.426&r2=1.427
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.614&r2=1.615



-- 


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

[Bug rtl-optimization/20129] ICE when compiling glibc-2.3.4/math/s_fmax.c

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |rtl-optimization
   Keywords||ice-on-valid-code


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

[Bug rtl-optimization/15068] ICE in elim_reg_cond

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
23:17 ---
*** Bug 20129 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||molletts at yahoo dot com


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

[Bug rtl-optimization/20129] ICE when compiling glibc-2.3.4/math/s_fmax.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
23:17 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux

[wilson at specifixinc dot com]

--- Additional Comments From wilson at specifixinc dot com  2005-02-21 
23:19 ---
Subject: Re:  gcc.dg/transparent-union-* fail on ia64-hpux

giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it  2005-02-20 
> 13:03 ---
> Jim, these are transparent unions, I thought that they were passed using the 
> convention of the first element in the union.

By the way, I probably wasn't clear about this, but I haven't made any 
attempt to debug or analyze the problem.  I'm just trying to point 
people at the cause of the first error, which was obvious to me just 
from reading the bug report.  And that is MEMBER_TYPE_FORCES_BLK.  There 
may also be other problems here.


-- 


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

[Bug tree-optimization/20130] New: Fold a * -1 - 1 into ~a;

[kazu at cs dot umass dot edu]

Consider

int
foo (int a)
{
  return a * -1 - 1;
}

CSE folds a * -1 into -a;
combine folds -a - 1 into ~a;

Obviously, we should do both of these in tree.

-- 
   Summary: Fold a * -1 - 1 into ~a;
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 19721
 nThis:


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

[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

  BugsThisDependsOn||20130


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

[Bug tree-optimization/20130] Fold a * -1 - 1 into ~a;

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||19986
  nThis||


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

[Bug tree-optimization/20130] Fold a * -1 - 1 into ~a;

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-21 
23:35 ---
Confirmed.

PR 15784 is the PR about -a - 1 turning into ~a.

-- 
   What|Removed |Added

  BugsThisDependsOn||15784
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-21 23:35:04
   date||


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

[Bug c++/6628] cannot typedef const functions

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-02-21 23:39 
---
Fixed for 4.0.

-- 
   What|Removed |Added

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


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

[Bug fortran/20131] New: gfortan - incorrectly reads beyond the end of line.

[dir at lanl dot gov]

I finally realized that this is actually the source of most of the data reading
problems that I have had. If you look at the hex dump of the file, the first
line has extra padding blanks and reads correctly. The second line has no
padding and gfortran reads past the end of line and takes data from the third
line and prints it.


[dir:~/tests/gfortran] dir% gfortran -o fread03 fread03.f
[dir:~/tests/gfortran] dir% fread03 < fread03.dat
10
12
STOP 0
[dir:~/tests/gfortran] dir% cat fread03.f
  program main
  do 10 j=1,2 
  read(5,1010)  nload,npr2
  write(6,1010) nload,npr2
   10 continue
 1010 format (16i5)
  stop
  end

[dir:~/tests/gfortran] dir% cat fread03.dat
1  
1
2
[dir:~/tests/gfortran] dir% dump -i fread03.dat

   File name: fread03.dat   Block number: 0   Byte number: 0

  20 20 20 20 31 20 20 20  20 20 20 20 20 20 20 0a  1   .
0010  20 20 20 20 31 0a 20 20  20 20 32 0a 00 00 00 00  1. 2.
EOF encountered. Do you want to continue ? n

-- 
   Summary: gfortan - incorrectly reads beyond the end of line.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-apple-darwin7.8.0


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

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

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-02-21 23:50 
---
Fixed for 4.0.

-- 
   What|Removed |Added

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


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

[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

  BugsThisDependsOn||20132


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

[Bug tree-optimization/20132] New: Pessimization of induction variable and missed hoisting opportunity

[kazu at cs dot umass dot edu]

Consider:

int
foo (int length, const char *fmt)
{
  int i;
  for (i = length; i >= 0; i--)
{
  switch (fmt[i])
{
case 48:
  break;
default:
  return 1;
}
}
  return 0;
}

I get:

foo (length, fmt)
{
  unsigned int D.1180;
  unsigned int ivtmp.5;
  int D.1146;

:
  if (length >= 0) goto ; else goto ;

:;
  ivtmp.5 = 0;

:;
  D.1180 = (unsigned int) length;
  switch (*((const char *) ivtmp.5 + fmt + (const char *) D.1180))
{
  case 48: goto ;
  default : goto ;
}

:;
  D.1146 = 1;
  goto  ();

:;
  ivtmp.5 = ivtmp.5 - 1;
  if (ivtmp.5 != D.1180 * 0 + 0) goto ; else goto ;

:;
  D.1146 = 0;

:;
  return D.1146;

}

The following should be hoisted out of the loop.

  D.1180 = (unsigned int) length;

This

  D.1180 * 0 + 0

should be folded to

  ~D.1180

and of course hoisted out of the loop.

The folding part is also mentioned in PR 20130.

RTL optimizers hoist ~D.1180 out of the loop.

Having said all this, the induction variable should be counting down toward 0.

That is, instead of

  ivtmp.5 = 0;
  :
  :
  switch (*((const char *) ivtmp.5 + fmt + (const char *) D.1180))
  :
  :
  ivtmp.5 = ivtmp.5 - 1;
  if (ivtmp.5 != D.1180 * 0 + 0) goto ; else goto ;

we should be doing

  ivtmp.5 = (unsigned int) D.1180;
  :
  :
  switch (*((const char *) ivtmp.5 + fmt))
  :
  :
  ivtmp.5 = ivtmp.5 - 1;
  if (ivtmp.5 >= 0) goto ; else goto ;

This way, we don't have to keep D.1180 in the loop.
And we can compare against 0 at the end.

-- 
   Summary: Pessimization of induction variable and missed hoisting
opportunity
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 19721
 nThis:


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

[Bug c++/20133] New: internal compiler error: in import_export_decl, at cp/decl2.c:1726

[jean-marc dot valin at usherbrooke dot ca]

I'm getting this ICE with the gcc-4.0-20050213 snapshot. This is a
Debian (unstable) machine with a 2.6.10 kernel running on a Pentium M.

% g++ -c net_types.cpp
net_types.cc:179: internal compiler error: in import_export_decl, at
cp/decl2.c:1726
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: internal compiler error: in import_export_decl, at
cp/decl2.c:1726
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P1
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jean-marc dot valin at usherbrooke dot ca
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20133] internal compiler error: in import_export_decl, at cp/decl2.c:1726

[jean-marc dot valin at usherbrooke dot ca]

--- Additional Comments From jean-marc dot valin at usherbrooke dot ca  
2005-02-22 00:10 ---
Created an attachment (id=8248)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8248&action=view)
Preprocessed source

This is the preprocessed source for reproducing the ICE

-- 


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