[Bug pch/20673] C PCH testsuite assembly comparison failure

[christian dot joensson at gmail dot com]

--- Additional Comments From christian dot joensson at gmail dot com  
2005-03-29 07:49 ---
This also happens on 4.0 branch, see testreport at
http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01946.html

-- 


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

[Bug libfortran/20660] INQUIRE incorrectly reports the existence of UNITS

[pinskia at physics dot uc dot edu]

--- Additional Comments From pinskia at physics dot uc dot edu  2005-03-29 
07:24 ---
Subject: Re:  INQUIRE incorrectly reports the existence of UNITS


On Mar 29, 2005, at 2:13 AM, fxcoudert at gcc dot gnu dot org wrote:

> -*ioparm.exist = (u != NULL);
> +*ioparm.exist = (u != NULL ? 1 : 0);

This change does nothing.

-- Pinski



-- 


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

Re: [Bug libfortran/20660] INQUIRE incorrectly reports the existence of UNITS

[Andrew Pinski]

On Mar 29, 2005, at 2:13 AM, fxcoudert at gcc dot gnu dot org wrote:
-*ioparm.exist = (u != NULL);
+*ioparm.exist = (u != NULL ? 1 : 0);
This change does nothing.
-- Pinski

[Bug c++/20678] [3.4/4.0/4.1 Regression] Make process stopped

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
07:21 ---
The code is invalid, reduced to:
struct a
{
  a(const a&);
};
struct b
{
  a aa __attribute__((packed));
};
struct c
{
  b bb;
  c(const b& __a): bb(__a) {}
};

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   GCC host triplet|MinGW 3.7, Windows vlada-xp |
   |5.1 SP2 x86 |
   |Intel_x86_Family15_Model|
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2005-03-29 07:21:59
   date||
Summary|Make process stopped|[3.4/4.0/4.1 Regression]
   ||Make process stopped
   Target Milestone|--- |4.0.1


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

[Bug libfortran/20660] INQUIRE incorrectly reports the existence of UNITS

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-03-29 
07:12 ---
I don't have time to test it and submit it correctly, but I think the following
should work. I someone has time to do it before I do, please feel free to
test/comment/apply.


Index: inquire.c
===
RCS file: /cvsroot/gcc/gcc/libgfortran/io/inquire.c,v
retrieving revision 1.9
diff -p -u -r1.9 inquire.c
--- inquire.c   30 Jan 2005 13:16:19 -  1.9
+++ inquire.c   29 Mar 2005 07:10:57 -
@@ -46,7 +46,7 @@ inquire_via_unit (gfc_unit * u)
   const char *p;
 
   if (ioparm.exist != NULL)
-*ioparm.exist = (u != NULL);
+*ioparm.exist = (u != NULL ? 1 : 0);
 
   if (ioparm.opened != NULL)
 *ioparm.opened = (u != NULL);

-- 
   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Keywords||patch
   Last reconfirmed|2005-03-27 21:59:44 |2005-03-29 07:12:59
   date||


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

[Bug c++/20678] Make process stopped

[vladakk at abanka dot co dot yu]

-- 
   What|Removed |Added

   GCC host triplet|Windows vlada-xp 5.1 SP2 x86|MinGW 3.7, Windows vlada-xp
   |Intel_x86_Family15_Model2_St|5.1 SP2 x86
   |epping9 |Intel_x86_Family15_Model
   Keywords|ice-on-invalid-code |


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

[Bug c++/20678] Make process stopped

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
07:03 ---
The code is invalid, reducing, this is most likely related to an undefined type 
or something like that and 
a packed structure (which you cannot take the address of a field any more).

-- 
   What|Removed |Added

   Keywords||ice-on-invalid-code


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

[Bug c++/20678] Make process stopped

[vladakk at abanka dot co dot yu]

--- Additional Comments From vladakk at abanka dot co dot yu  2005-03-29 
06:55 ---
Created an attachment (id=8479)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8479&action=view)
Environment info


-- 


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

[Bug c++/20678] New: Make process stopped

[vladakk at abanka dot co dot yu]

g++ compiler stopped without any warning or error message. Preprocessor file is 
OK
but assembler file is incomplete.

-- 
   Summary: Make process stopped
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vladakk at abanka dot co dot yu
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: Windows vlada-xp 5.1 SP2 x86
Intel_x86_Family15_Model2_Stepping9


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

[Bug middle-end/20674] unexpected result from floating compare

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-03-29 
04:58 ---
Subject: Re:  unexpected result from floating compare

On Mon, 2005-03-28 at 23:05 +, piaget at us dot ibm dot com wrote:
> --- Additional Comments From piaget at us dot ibm dot com  2005-03-28 
> 23:05 ---
> 323 compares 2 values across a function call ... somthing a programmer can 
> reasonably consider. My problem occurs with 2 successive lines of code 
> admittedly with 2 compares per line). I don't have a problem that the value 
> of 
> the variable changes after precision truncation ... but it seems like a bug 
> that the compiler uses a full precision value for the 1st test and a 
> truncated 
> value for the 2nd test (the 2nd test being the next line of C++ code).

Except, the value could have been spilled and reloaded from registers
between those two source lines, which on x86, is where the problem comes
from.
The problem is no different simply because the *source* lines happen to
be right next to each other.




-- 


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

Re: [Bug middle-end/20674] unexpected result from floating compare

[Daniel Berlin]

On Mon, 2005-03-28 at 23:05 +, piaget at us dot ibm dot com wrote:
> --- Additional Comments From piaget at us dot ibm dot com  2005-03-28 
> 23:05 ---
> 323 compares 2 values across a function call ... somthing a programmer can 
> reasonably consider. My problem occurs with 2 successive lines of code 
> admittedly with 2 compares per line). I don't have a problem that the value 
> of 
> the variable changes after precision truncation ... but it seems like a bug 
> that the compiler uses a full precision value for the 1st test and a 
> truncated 
> value for the 2nd test (the 2nd test being the next line of C++ code).

Except, the value could have been spilled and reloaded from registers
between those two source lines, which on x86, is where the problem comes
from.
The problem is no different simply because the *source* lines happen to
be right next to each other.

[Bug middle-end/20635] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node

[gschafer at zip dot com dot au]

--- Additional Comments From gschafer at zip dot com dot au  2005-03-29 
04:53 ---
I just hit this trying to compile psmisc-21.6 with snapshot gcc-4.0-20050326:

pstree.c: In function 'dump_tree':
pstree.c:539: internal compiler error: in cgraph_mark_reachable_node, at
cgraph.c:477

I'll apply the patch and report back later if it fixes the problem. Would be
nice to get this applied on the 4.0 branch. Thanks.



-- 
   What|Removed |Added

 CC||gschafer at zip dot com dot
   ||au


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

[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-03-29 03:42 
---
Subject: Re:  Small targets without 64 bit long long
 support are can't bootstrap GCC.

>   Static debug data should be based on it's required encoding specification,
>   and have nothing to do with a target's run-time unwind implementation.
> 
>   (I'll take a closer look to try to figure out why one is affecting the
>other. However just to double check, is there any reason that a target
>needs to support a data type size that it never references, although
>is statically encoded by the linker into it's debug data section?)

- what appears to be happening is unrelated to the unwind word size; the
  stabs data section size is changing when the target's long long size is
  reduced to the size of a long, thereby requiring less bytes to represent
  leb128 encoded min/max signed/unsigned long long date definitions for the
  target; which seems correct; and not related to reducing small target's
  unwind word size which should not effect it's dwarf compliance.

  (so all seems ok)



  




-- 


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

[Bug c++/20677] bad warning

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
03:18 ---
Enums are specials in C++ as outside of the range of the enum is undefined.
Anyways this is fixed in 3.4.2.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |3.4.2


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

[Bug c++/20677] New: bad warning

[igodard at pacbell dot net]

In:

enum A {b = -1, c, d};
bool foo(A a) { return a < b || a > d; }

you get:

foo.cc: In function `bool foo(A)':
foo.cc:2: warning: comparison is always false due to limited range of data type

If an enum is always necessarily an unsigned type then the initialization of b
should get a warning or error. If it has the range of its assigned values (which
I think is what the standard says, though I'm not sure) and hence is a signed
type if any of the assigned values is negative then the issued warning is 
incorrect.

Ivan

-- 
   Summary: bad warning
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20676] ICE (segv)

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-29 02:14 
---
Thought it might be a dup but wasn't sure.

Ivan


-- 


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

[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-03-29 02:09 
---
Subject: Re:  Small targets without 64 bit long long
 support are can't bootstrap GCC.

>> Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked
>> (I think it is defined by the dwarf-2 standard).
> 
> - From the best I can tell reviewing the standard, it seems fully compatible
>   to limit the target's unwind data type size, to the largest data type it
>   supports; as although a 64-bit data type is defined by the standard,
>   neither a host application or target could validly send, request data
>   sized larger than the largest type defined as supported by the target;
>   nor are large data types required for communicating smaller data type
>   values, as data access is byte not unwind-word offset/size oriented.
> 
>   (so it seems fully compatible from the best I can tell?)

- Actually there may be a problem, as I did notice that the stabs data
  section size was affected by this change, which wouldn't have guessed
  to be affected by the size of the target's run-time unwind word data
  size?

  It seems that GCC may be presuming that the static debug data (which is
  for debugger reference) is using the target's unwind word size; which is
  wrong they are unrelated to each other, although may be the same.

  Static debug data should be based on it's required encoding specification,
  and have nothing to do with a target's run-time unwind implementation.

  (I'll take a closer look to try to figure out why one is affecting the
   other. However just to double check, is there any reason that a target
   needs to support a data type size that it never references, although
   is statically encoded by the linker into it's debug data section?)




-- 


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

[Bug rtl-optimization/13355] Suboptimal code generated with global register variables

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
01:55 ---
Some of this is already fixed.

-- 


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

[Bug c++/16168] -Weffc++ item 14 improvements

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed|2004-12-28 01:41:09 |2005-03-29 01:49:04
   date||


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

[Bug other/19165] (Natural) language independent error / warning classification

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
01:46 ---
What about changing the IDEs so they understand the natural language 
warning/error/note 
classification instead?

-- 


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

[Bug c++/20669] Template candidates not listed in error message.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
01:39 ---
Confirmed, I could sware I saw this before.

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-29 01:39:11
   date||


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

[Bug c++/20668] [3.4/4.0/4.1 Regression] ICE on invalid code, value dependent but invalid wise

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
01:33 ---
*** Bug 20676 has been marked as a duplicate of this bug. ***

-- 


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

[Bug c++/20676] ICE (segv)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
01:33 ---
Reduces to the same problem as PR 20668.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/20676] ICE (segv)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug c++/20676] ICE (segv)

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-29 01:14 
---
Created an attachment (id=8478)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8478&action=view)
source code (-save-temps, compressed)


-- 


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

[Bug c++/20676] ICE (segv)

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-29 01:14 
---
Created an attachment (id=8477)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8477&action=view)
compiler output (-v)


-- 


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

[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-03-29 01:14 
---
Subject: Re:  Small targets without 64 bit long long
 support are can't bootstrap GCC.

> Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked
> (I think it is defined by the dwarf-2 standard).

- From the best I can tell reviewing the standard, it seems fully compatible
  to limit the target's unwind data type size, to the largest data type it
  supports; as although a 64-bit data type is defined by the standard,
  neither a host application or target could validly send, request data
  sized larger than the largest type defined as supported by the target;
  nor are large data types required for communicating smaller data type
  values, as data access is byte not unwind-word offset/size oriented.

  (so it seems fully compatible from the best I can tell?)




-- 


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

[Bug c++/20676] New: ICE (segv)

[igodard at pacbell dot net]

 

-- 
   Summary: ICE (segv)
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20669] Template candidates not listed in error message.

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||diagnostic


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

[Bug target/20286] [3.3 only] gcc panic with __thread attribute

[wilson at gcc dot gnu dot org]

--- Additional Comments From wilson at gcc dot gnu dot org  2005-03-29 
00:33 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|3.4.0 4.0.0 |3.4.0 4.0.0 3.3.6
 Resolution||FIXED


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

[Bug target/20286] [3.3 only] gcc panic with __thread attribute

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-29 
00:32 ---
Subject: Bug 20286

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED]   2005-03-29 00:32:03

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

Log message:
Fix problem with redefining extern __thread as static __thread.
PR target/20286.
* config/ia64/ia64.c (ia64_encode_section_info): Only abort if encoding
or symbol_str[1] is 's'.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1061&r2=1.16114.2.1062
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.198.2.24&r2=1.198.2.25



-- 


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

[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-03-29 00:28 
---
Subject: Re:  Small targets without 64 bit long long
 support are can't bootstrap GCC.

> Note all patches should always goto gcc-patches

ok, just sent.




-- 


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

[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
00:26 ---
Also note that the dwarf-2 unwinder needs to be 64bit the last time I looked (I 
think it is defined by the 
dwarf-2 standard).

-- 


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

[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 
00:25 ---
Note all patches should always goto [EMAIL PROTECTED]

-- 
   What|Removed |Added

   Severity|normal  |enhancement
  Component|bootstrap   |middle-end


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

[Bug bootstrap/20675] Small targets without 64 bit long long support are can't bootstrap GCC.

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-03-28 23:52 
---
Created an attachment (id=8476)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8476&action=view)
proposed patch

The following patch enables small targets which don't support a 64 bit
long long type to build, by conditionally defining smaller unwind and
refining determination of long long support requirement within libgcc2:

(please see attached patch)


-- 


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

[Bug bootstrap/20675] New: Small targets without 64 bit long long support are can't bootstrap GCC.

[schlie at comcast dot net]

(as both unwind and libgcc2 unnecessarily presume 64 bit support, patch follows)

-- 
   Summary: Small targets without 64 bit long long support are can't
bootstrap GCC.
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20671] Poor bit-field code generation

[dave at synergy dot org]

--- Additional Comments From dave at synergy dot org  2005-03-28 23:34 
---
gnatmake -O3 bit_test
objdump --disassemble -r bit_test.o

-- 


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

[Bug target/19890] gcc.dg/20020219-1.c execution test fails on ia64-hpux with -milp32

[sje at cup dot hp dot com]

--- Additional Comments From sje at cup dot hp dot com  2005-03-28 23:21 
---
Fixed by not running the test on IA64 HP-UX in ILP32 mode.

-- 
   What|Removed |Added

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


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

[Bug middle-end/20674] unexpected result from floating compare

[piaget at us dot ibm dot com]

--- Additional Comments From piaget at us dot ibm dot com  2005-03-28 23:05 
---
323 compares 2 values across a function call ... somthing a programmer can 
reasonably consider. My problem occurs with 2 successive lines of code 
admittedly with 2 compares per line). I don't have a problem that the value of 
the variable changes after precision truncation ... but it seems like a bug 
that the compiler uses a full precision value for the 1st test and a truncated 
value for the 2nd test (the 2nd test being the next line of C++ code).

-- 


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

[Bug middle-end/20671] Poor bit-field code generation

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
22:52 ---
Don't worry about it, I can reproduce it on PPC:
lwz r0,0(r12)
rlwinm r3,r0,0,1,31
mr r4,r3
stw r3,0(r12)
rlwimi r4,r0,0,1,1
mr r5,r4
stw r4,0(r12)


Trying to find an equivalent C testcase. Though it is hard.

-- 
   What|Removed |Added

OtherBugsDependingO||19466
  nThis||
 Status|UNCONFIRMED |NEW
  Component|ada |middle-end
 Ever Confirmed||1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2005-03-28 22:52:30
   date||


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

[Bug middle-end/20674] unexpected result from floating compare

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
22:49 ---
(In reply to comment #6)
> I tried this on a 64-bit system, and noticed I needed to compile -m32 to get 
> the error (this was on an older gcc level, though. 3.2.3)

Well considering x86_64 uses the sse register math by default and not x87, I 
really doubt that it would 
be effect that.  I would try it on a sane target first like say PPC where you 
have no excusive precission.

Oh the reason is because one checks before the precission is truncated and the 
next one is after. Look 
at the example of 323 to give you an idea where this can happen.

-- 


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

[Bug middle-end/20674] unexpected result from floating compare

[piaget at us dot ibm dot com]

--- Additional Comments From piaget at us dot ibm dot com  2005-03-28 22:46 
---
my mistake in the previous post

how can both if-checks be false?
val <= 1.0
and
val > 1.0


-- 


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

[Bug middle-end/20674] unexpected result from floating compare

[piaget at us dot ibm dot com]

--- Additional Comments From piaget at us dot ibm dot com  2005-03-28 22:44 
---
I tried this on a 64-bit system, and noticed I needed to compile -m32 to get 
the error (this was on an older gcc level, though. 3.2.3)

I don't understand how this can be a precision problem. How can both if checks 
be true?
val <= 1.0
and
val > 1.0



-- 


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

[Bug ada/20671] Poor bit-field code generation

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
22:40 ---
What options did you use to get the x86 asm?

-- 


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

[Bug target/20286] [3.3 only] gcc panic with __thread attribute

[wilson at gcc dot gnu dot org]

--- Additional Comments From wilson at gcc dot gnu dot org  2005-03-28 
22:40 ---
The patch passed testing, and has been submitted to gcc-patches here:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02542.html


-- 


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

[Bug middle-end/20674] unexpected result from floating compare

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
22:34 ---
If you write the function like so:
enum myRC doSomeMath
(
 int i1,
 float *f1,
 float* f2,
 float* f3,
 float* f4
)
{
  int i;
  float f5=0.0;
  float f6=0.0;
  float f7=0.0;

  for(i=0; i=-1.0)&&(*f4<=1.0))return(mySuccess);
  if((*f4>1.0)&&(*f4<1.01)){
*f4=1.0;
return(mySuccess);
  }
  if((*f4<-1.0)&&(*f4>-1.01)){
*f4=-1.0;
return(mySuccess);
  }
  if ( chkWithEqual == 1 ) {
if((*f4>=1.0)&&(*f4<1.01)){
  *f4=1.0;
  return(mySuccess);
}
if((*f4<=-1.0)&&(*f4>-1.01)){
  *f4=-1.0;
  return(mySuccess);
}
  }
  printf("%f is out of range -1.0 to 1.0\n",*f4);
  return(myFailure);
}

You still get the fail even with the C front-end in 3.4.0.

Note this does not fail in 4.0.0 and above (though there might be a way get a 
simlar failure if you have 
time to fiind one.  But I think this is still a precission problem.

-- 
   What|Removed |Added

  Component|c++ |middle-end
   Keywords||wrong-code


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

[Bug middle-end/20648] [4.0/4.1 regression] ICE in cfg_layout_redirect_edge_and_branch_force

[steven at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
  Known to fail||4.0.0 4.1.0
  Known to work||3.4.0
   Last reconfirmed|2005-03-28 21:57:03 |2005-03-28 22:24:25
   date||
Summary|[4.1 regression] ICE in |[4.0/4.1 regression] ICE in
   |cfg_layout_redirect_edge_and|cfg_layout_redirect_edge_and
   |_branch_force   |_branch_force


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

[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-03-28 22:11 
---
Subject: Re: [PR middle-end/20491] combine generates bad subregs

On Thu, Mar 24, 2005 at 07:45:44AM -0300, Alexandre Oliva wrote:
>   * combine.c (subst): Make sure we don't create invalid subregs.

Ok.


r~


-- 


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

[Bug c++/20674] unexpected result from floating compare

[piaget at us dot ibm dot com]

--- Additional Comments From piaget at us dot ibm dot com  2005-03-28 22:09 
---
I do not think this is a precision problem. Although -ffloat-store resolves the 
problem, I feel this has changed the behavior of the program sufficiently to 
avoid the problem ... I should not have mentioned that -ffloat-store resolved 
the problem in my earlier note

// following is pseudocode ... run actual testcase to see problem
float i=1.0; // actually, a bunch of math that = 1.0
if ( i <= 1.0 ) return 0;
if ( ( i > 1.0 ) && ( i < 1.0001 ) ) return 0;
return 1;

I should never get a 1 for a return code. Change 1.0001 in my testcase to 1.1, 
you still see the problem.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug middle-end/20648] [4.1 regression] ICE in cfg_layout_redirect_edge_and_branch_force

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-03-28 
21:57 ---
Test case, thanks to Tom Tromey: 
 
T.java: 
public class T 
{ 
  int field; 
  public void test(int f) { 
synchronized (this) { 
  if (field != 0) 
throw new IllegalStateException(); 
  field = f; 
} 
  } 
} 
 
./gcj -B. -B../ia64-unknown-linux-gnu/libjava/ 
-fclasspath=../ia64-unknown-linux-gnu/libjava/ -C T.java 
./gcj -B. -B../ia64-unknown-linux-gnu/libjava/ 
-fclasspath=../ia64-unknown-linux-gnu/libjava/ -c -g -O2 -findirect-dispatch 
T.class 
 
 

-- 
   What|Removed |Added

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


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

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
21:53 ---
*** Bug 20674 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||piaget at us dot ibm dot com


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

[Bug c++/20674] unexpected result from floating compare

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
21:53 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/20674] unexpected result from floating compare

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|unexpected result from  |unexpected result from
   |floating compare|floating compare


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

[Bug c++/20674] New: unexpected result from floating compare

[piaget at us dot ibm dot com]

Small .C program shows a problem where a value of 1.0 is calculated, but that 
value falls through 2 if-checks ... one checks for "if (val <= 1.0)" , the next 
checks for "if (val > 1.0)" ... one of these if checks must be true but neither 
true leg is taken.

problem surfaces at optimization level -O1 (also tested -O2 and -O3 ... same 
problem)
problem goes away with -ffloat-store , although I feel this is a logic problem 
and not a precision problem.
problem goes away if compiled as .c (with pass-by-reference removed)

g++ -v -save-temps -O1 -o tmp1 tmp1.C

This is my first bug ... I am going to committ ... may add attachments later if 
not given the opportunity now

-- 
   Summary: unexpected result from floating compare
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piaget at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i586-mandrake-linux-gnu
GCC target triplet: i586-mandrake-linux-gnu


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

[Bug tree-optimization/20470] Branching sequence generated for ABS(x-y)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/20470] Branching sequence generated for ABS(x-y)

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-03-28 21:31 
---
patch committed

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/19108] [4.0/4.1 regression] ICE initializing arrays

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-03-28 
21:04 ---
Indeed I do not have time to work on this.  I should have unassigned 
this bug long ago, sorry about that. 
 

-- 
   What|Removed |Added

 AssignedTo|steven at gcc dot gnu dot   |rth at gcc dot gnu dot org
   |org |


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

[Bug pch/20673] C PCH testsuite assembly comparison failure

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |pch


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

[Bug c/20673] C PCH testsuite assembly comparison failure

[christian dot joensson at gmail dot com]

-- 
   What|Removed |Added

Summary|C PCH assembly comparison   |C PCH testsuite assembly
   |failure |comparison failure


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

[Bug c/20673] New: C PCH assembly comparison failure

[christian dot joensson at gmail dot com]

Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u:

binutils-2.15.92.0.2-5.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.2-6.fc3.sparc
gcc4-4.0.0-0.8sparc.sparc
glibc-2.3.3-99.sparc64
glibc-2.3.3-99.sparcv9
glibc-devel-2.3.3-99.sparc
glibc-devel-2.3.3-99.sparc64
glibc-headers-2.3.3-99.sparc64
glibc-headers-2.3.3-99.sparc
glibc-kernheaders-2.6-20sparc.sparc
gmp-4.1.4-3sparc.sparc
gmp-4.1.4-3sparc.sparc64
gmp-devel-4.1.4-3sparc.sparc
gmp-devel-4.1.4-3sparc.sparc64
kernel-2.6.11-1.1166sp1.sparc64
package kernel-devel is not installed
package kernel-smp is not installed
libgcc-3.4.2-6.fc3.sparc
libgcc-3.4.2-6.fc3.sparc64
libstdc++-3.4.2-6.fc3.sparc64
libstdc++-3.4.2-6.fc3.sparc
libstdc++-devel-3.4.2-6.fc3.sparc64
libstdc++-devel-3.4.2-6.fc3.sparc
make-3.80-5.sparc
nptl-devel-2.3.3-99.sparcv9
tcl-8.4.7-2.sparc

LAST_UPDATED: Mon Mar 28 07:44:16 UTC 2005

Native configuration is sparc64-unknown-linux-gnu

Compiler version: 4.1.0 20050328 (experimental) 
Platform: sparc64-unknown-linux-gnu
configure flags: sparc64-linux --enable-__cxa_atexit --disable-multilib --
enable-shared --enable-languages=c,c++

I get these C PCH failures:

FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/static-1.c  -O0  assembly comparison
FAIL: gcc.dg/pch/static-1.c  -O1  assembly comparison
FAIL: gcc.dg/pch/static-2.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/static-2.c  -O0  assembly comparison
FAIL: gcc.dg/pch/static-2.c  -O1  assembly comparison
FAIL: gcc.dg/pch/static-3.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/static-3.c  -O0  assembly comparison
FAIL: gcc.dg/pch/static-3.c  -O1  assembly comparison

and the log file says... 

Executing on host: /usr/local/src/trunk/objdir64/gcc/xgcc -
B/usr/local/src/trunk/objdir64/gcc/ /usr/local/src/trunk/gcc/gcc/testsuite/gcc.
dg/pch/static-1.c  -O0 -g -I. -S  -o static-1.s(timeout = 300)
PASS: gcc.dg/pch/static-1.c -O0 -g (test for excess errors)
line #47
<   save%sp, -192, %sp
>   .register   %g2, #scratch
line #48
< .LLCFI1:
>   .register   %g3, #scratch
line #49
<   .loc 2 5 0
>   save%sp, -192, %sp
line #50
<   sethi   %hi(counter.1102), %g1
> .LLCFI1:
line #51
<   or  %g1, %lo(counter.1102), %g1
>   .loc 2 5 0
line #52
<   ld  [%g1], %g1
>   sethi   %hi(counter.1102), %g1
line #53
<   mov %g1, %g3
>   or  %g1, %lo(counter.1102), %g1
line #54
<   add %g1, 1, %g2
>   ld  [%g1], %g1
line #55
<   sethi   %hi(counter.1102), %g1
>   mov %g1, %g3
line #56
<   or  %g1, %lo(counter.1102), %g1
>   add %g1, 1, %g2
line #57
<   st  %g2, [%g1]
>   sethi   %hi(counter.1102), %g1
line #58
<   sra %g3, 0, %g1
>   or  %g1, %lo(counter.1102), %g1
line #59
<   .loc 2 6 0
>   st  %g2, [%g1]
line #60
<   mov %g1, %i0
>   sra %g3, 0, %g1
line #61
<   return  %i7+8
>   .loc 2 6 0
line #62
<nop
>   mov %g1, %i0
line #63
< .LLFE3:
>   return  %i7+8
line #64
<   .size   bar, .-bar
>nop
line #65
<   .section".debug_frame"
> .LLFE3:
line #66
< .LLframe0:
>   .size   bar, .-bar
line #67
<   .uaword .LLECIE0-.LLSCIE0
>   .section".debug_frame"
line #68
< .LLSCIE0:
> .LLframe0:
line #69
<   .uaword 0x
>   .uaword .LLECIE0-.LLSCIE0
line #70
<   .byte   0x1
> .LLSCIE0:
line #71
<   .asciz  ""
>   .uaword 0x
line #72
<   .uleb128 0x1
>   .byte   0x1
line #73
<   .sleb128 -8
>   .asciz  ""
line #74
<   .byte   0xf
>   .uleb128 0x1
line #75
<   .byte   0xc
>   .sleb128 -8
line #76
<   .uleb128 0xe
>   .byte   0xf
line #77
<   .uleb128 0x7ff
>   .byte   0xc
line #78
<   .align 8
>   .uleb128 0xe
line #79
< .LLECIE0:
>   .uleb128 0x7ff
line #80
< .LLSFDE0:
>   .align 8
line #81
<   .uaword .LLEFDE0-.LLASFDE0
> .LLECIE0:
line #82
< .LLASFDE0:
> .LLSFDE0:
line #83
<   .uaword .LLframe0
>   .uaword .LLEFDE0-.LLASFDE0
line #84
<   .uaxword.LLFB2
> .LLASFDE0:
line #85
<   .uaxword.LLFE2-.LLFB2
>   .uaword .LLframe0
line #86
<   .byte   0x4
>   .uaxword.LLFB2
line #87
<   .uaword .LLCFI0-.LLFB2
>   .uaxword.LLFE2-.LLFB2
line #88
<   .byte   0xd
>   .byte   0x4
line #89
<   .uleb128 0x1e
>   .uaword .LLCFI0-.LLFB2
line #90
<   .byte   0x2d
>   .byte   0xd
line #91
<   .byte   0x9
>   .uleb128 0x1e
line #92
<   .uleb128 0xf
>   .byte   0x2d
line #93
<   .uleb128 0x1

[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
20:48 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c/20672] [4.1 Regression] New C parser doesn't check whether functions that end files are closed properly

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org, jsm28 at gcc dot gnu
   ||dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2005-03-28 19:35:45
   date||
Summary|New C parser doesn't check  |[4.1 Regression] New C
   |whether functions that end  |parser doesn't check whether
   |files are closed properly   |functions that end files are
   ||closed properly
   Target Milestone|--- |4.1.0


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

[Bug c/20672] New: New C parser doesn't check whether functions that end files are closed properly

[dberlin at gcc dot gnu dot org]

The following will compile fine:

int main(void)
{
int a;



(Note the lack of closing brace)

-- 
   Summary: New C parser doesn't check whether functions that end
files are closed properly
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dberlin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug ada/20671] New: Poor bit-field code generation

[dave at synergy dot org]

This test simulates the process of clearing the "present" bit
in an x86 page table entry.  The code *should* load the PTE,
clear the present bit, and store the PTE.  On x86, it is
possible to perform these 3 steps in a single instruction, i.e.
AND memory with immediate operand.  The code should also be
preceede with a null check for the access object.

package Bit_Test is

  type Page_Frame_Number is
mod 2 ** 20;

  type Page_Table_Entry is
record
  P   : Boolean;
  RW  : Boolean;
  U   : Boolean;
  PWT : Boolean;
  PCD : Boolean;
  A   : Boolean;
  D   : Boolean;
  PSE : Boolean;
  G   : Boolean;
  PFN : Page_Frame_Number;
end record;

  for Page_Table_Entry use
record
  P   at 0 range  0 ..  0;
  RW  at 0 range  1 ..  1;
  U   at 0 range  2 ..  2;
  PWT at 0 range  3 ..  3;
  PCD at 0 range  4 ..  4;
  A   at 0 range  5 ..  5;
  D   at 0 range  6 ..  6;
  PSE at 0 range  7 ..  7;
  G   at 0 range  8 ..  8;
  PFN at 0 range 12 .. 31;
end record;

  type Page_Table_Entry_Access is
access Page_Table_Entry;

  procedure Invalidate_PTE (
PTE : in Page_Table_Entry_Access
);

end Bit_Test;

package body Bit_Test is

  procedure Invalidate_PTE (
PTE : in Page_Table_Entry_Access
) is
  begin
PTE.all := (
  P   => False,
  RW  => PTE.RW,
  U   => PTE.U,
  PWT => PTE.PWT,
  PCD => PTE.PCD,
  A   => PTE.A,
  D   => PTE.D,
  PSE => PTE.PSE,
  G   => PTE.G,
  PFN => PTE.PFN
);
  end Invalidate_PTE;

end Bit_Test;

Code generated for Invalidate_PTR:

00a0 :
  a0:   55  push   %ebp
  a1:   89 e5   mov%esp,%ebp
  a3:   57  push   %edi
  a4:   56  push   %esi
  a5:   53  push   %ebx
  a6:   83 ec 1csub$0x1c,%esp
  a9:   8b 7d 08mov0x8(%ebp),%edi
  ac:   85 ff   test   %edi,%edi
  ae:   0f 84 e0 00 00 00   je 194 
  b4:   0f b6 07movzbl (%edi),%eax
  b7:   88 c2   mov%al,%dl
  b9:   88 c1   mov%al,%cl
  bb:   d0 ea   shr%dl
  bd:   88 c3   mov%al,%bl
  bf:   80 e2 01and$0x1,%dl
  c2:   88 55 ebmov%dl,0xffeb(%ebp)
  c5:   88 c2   mov%al,%dl
  c7:   c0 ea 04shr$0x4,%dl
  ca:   80 e2 01and$0x1,%dl
  cd:   88 55 efmov%dl,0xffef(%ebp)
  d0:   88 c2   mov%al,%dl
  d2:   c0 ea 05shr$0x5,%dl
  d5:   80 e2 01and$0x1,%dl
  d8:   88 55 f0mov%dl,0xfff0(%ebp)
  db:   88 c2   mov%al,%dl
  dd:   c0 ea 06shr$0x6,%dl
  e0:   80 e2 01and$0x1,%dl
  e3:   88 55 f1mov%dl,0xfff1(%ebp)
  e6:   88 c2   mov%al,%dl
  e8:   24 fe   and$0xfe,%al
  ea:   c0 ea 07shr$0x7,%dl
  ed:   88 55 f2mov%dl,0xfff2(%ebp)
  f0:   c0 e9 02shr$0x2,%cl
  f3:   0f b6 57 01 movzbl 0x1(%edi),%edx
  f7:   80 e1 01and$0x1,%cl
  fa:   c0 eb 03shr$0x3,%bl
  fd:   80 e3 01and$0x1,%bl
 100:   80 e2 01and$0x1,%dl
 103:   88 55 f3mov%dl,0xfff3(%ebp)
 106:   8b 37   mov(%edi),%esi
 108:   88 07   mov%al,(%edi)
 10a:   0f b6 55 eb movzbl 0xffeb(%ebp),%edx
 10e:   8b 07   mov(%edi),%eax
 110:   01 d2   add%edx,%edx
 112:   83 e0 fdand$0xfffd,%eax
 115:   09 d0   or %edx,%eax
 117:   0f b6 d1movzbl %cl,%edx
 11a:   89 07   mov%eax,(%edi)
 11c:   c1 e2 02shl$0x2,%edx
 11f:   83 e0 fband$0xfffb,%eax
 122:   09 d0   or %edx,%eax
 124:   0f b6 d3movzbl %bl,%edx
 127:   89 07   mov%eax,(%edi)
 129:   c1 e2 03shl$0x3,%edx
 12c:   83 e0 f7and$0xfff7,%eax
 12f:   09 d0   or %edx,%eax
 131:   89 07   mov%eax,(%edi)
 133:   83 e0 efand$0xffef,%eax
 136:   0f b6 55 ef movzbl 0xffef(%ebp),%edx
 13a:   c1 e2 04shl$0x4,%edx
 13d:   09 d0   or %edx,%eax
 13f:   89 07   mov%eax,(%edi)
 141:   83 e0 dfand$0xffdf,%eax
 144:   0f b6 55 f0 movzbl 0xfff0(%ebp),%edx
 148:   c1 e2 05shl$0x5,%edx
 14b:   09 d0   or %edx,%eax
 14d:   89 07

[Bug tree-optimization/19108] [4.0/4.1 regression] ICE initializing arrays

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-03-28 19:13 
---
Indeed, SRA *does* need to be updated to handle the RANGE_EXPR.  And not in the
hash routine at all -- it needs to happen before that.  Consider the following
modified test case:

struct A
{
int i[6];
A () : i(1) {}
};

struct B
{
A a;
B(const A& x) : a(x) {}
};

B b=A();

int main()
{
  return b.a.i[0] == 1 ? 0 : 1;
}

Steven, if you don't have time to work on this, reassign the bug to me.

-- 


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

[Bug target/20670] IA-64 exception mechanism erase $f29

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
  Component|other   |target
   Keywords||wrong-code


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

[Bug other/20670] IA-64 exception mechanism erase $f29

[ochem at gnat dot com]

-- 
   What|Removed |Added

   GCC host triplet|3.4.4   |ia-64


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

[Bug target/19890] gcc.dg/20020219-1.c execution test fails on ia64-hpux with -milp32

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-28 
18:19 ---
Subject: Bug 19890

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-28 18:19:13

Modified files:
gcc/testsuite  : ChangeLog 
gcc/testsuite/gcc.dg: 20020219-1.c 

Log message:
PR target/19890
* gcc.dg/20020219-1.c: Skip on IA64 HP-UX in ILP32 mode.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5226&r2=1.5227
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20020219-1.c.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


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

[Bug other/20670] New: IA-64 exception mechanism erase $f29

[ochem at gnat dot com]

There is some strange behavihour about the register f29 (and may be the next 
floating registers) when an exception is raised. Its value is not properly 
loaded. Going into the sources of gcc, I found sth interresting there : 
 
unwind-ia64.c:2298:"(p7) ldf.fill f29 = [r27]  \n\t" 
 
before this assingment, $f29 has the right value. Since it hasn't be used (ie 
it wasn't saved by anything), as far as I understand, it shouldn't be modified 
here, but it is. My belief is that there is sth wrong with r27. Here is a 
little extract of the few lines above : 
 
2258: "ld8 r22 = [r20], 8 \n\t" 
2259: "(p6) ldf.fill f18 = [r24]  \n\t" 
2260: "cmp.ne p7, p0 = r0, r25\n\t" 
2261: ";; \n\t" 
2262: "ld8 r23 = [r20], 8 \n\t" 
2263: "(p7) ldf.fill f19 = [r25]  \n\t" 
2264: "cmp.ne p6, p0 = r0, r26\n\t" 
2265: ";; \n\t" 
2266: "ld8 r24 = [r20], 8 \n\t" 
2267: "(p6) ldf.fill f20 = [r26]  \n\t" 
2268: "cmp.ne p7, p0 = r0, r27\n\t" 
2269: ";; \n\t" 
2270: "ld8 r25 = [r20], 8 \n\t" 
2271: "(p7) ldf.fill f21 = [r27]  \n\t" 
2272: "cmp.ne p6, p0 = r0, r28\n\t" 
2273: ";; \n\t" 
2274: "ld8 r26 = [r20], 8 \n\t" 
2275: "(p6) ldf.fill f22 = [r28]  \n\t" 
2276: "cmp.ne p7, p0 = r0, r29\n\t" 
2277: ";; \n\t" 
2278: "ld8 r28 = [r20], 8 \n\t" 
2279: "(p7) ldf.fill f23 = [r29]  \n\t" 
2280: "cmp.ne p6, p0 = r0, r22\n\t" 
2281: ";; \n\t" 
2282: "ld8 r29 = [r20], 8 \n\t" 
2283: "(p6) ldf.fill f24 = [r22]  \n\t" 
2284: "cmp.ne p7, p0 = r0, r23\n\t" 
2285: ";; \n\t" 
2286: "(p7) ldf.fill f25 = [r23]  \n\t" 
2287: "cmp.ne p6, p0 = r0, r24\n\t" 
2288: "cmp.ne p7, p0 = r0, r25\n\t" 
2289: ";; \n\t" 
2290: "(p6) ldf.fill f26 = [r24]  \n\t" 
2291: "(p7) ldf.fill f27 = [r25]  \n\t" 
2292: "cmp.ne p6, p0 = r0, r26\n\t" 
2293: ";; \n\t" 
2294: "(p6) ldf.fill f28 = [r26]  \n\t" 
2295: "cmp.ne p7, p0 = r0, r27\n\t" 
2296: "cmp.ne p6, p0 = r0, r28\n\t" 
2297: ";; \n\t" 
2298: "(p7) ldf.fill f29 = [r27]  \n\t" 
 
As you see, r27 is used to fill the value of f21. Like r26 for f20, r25 for f19 
etc. But, while r25, r26, r28 and so are reloaded before filling the last float 
registers, r27 seems to be missing, so its value for f29 is the same as the one 
used for f21. The fix seems to be quite light, just add the proper load for r27 
at the right place.

-- 
   Summary: IA-64 exception mechanism erase $f29
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ochem at gnat dot com
CC: gcc-bugs at gcc dot gnu dot org,ochem at gnat dot com
 GCC build triplet: 3.4.4
  GCC host triplet: 3.4.4
GCC target triplet: 3.4.4


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

[Bug target/19888] g++.old-deja/g++.eh/badalloc1.C execution test fails on ia64-hpux

[sje at cup dot hp dot com]

--- Additional Comments From sje at cup dot hp dot com  2005-03-28 18:11 
---
Fixed by increasing arena_size on HP-UX.

-- 
   What|Removed |Added

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


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

[Bug target/20095] gcc.dg/cleanup-5.c fails on ia64-hpux

[sje at cup dot hp dot com]

--- Additional Comments From sje at cup dot hp dot com  2005-03-28 18:08 
---
Fixed by skipping the test on IA64 HP-UX.

-- 
   What|Removed |Added

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


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

[Bug libfortran/20661] End of record not detected

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-03-28 17:48 
---
To clarify this:
! End of record is not detected
!on second READ
! iostats should be 0, 0, -2, -1

The standard says:
"Execution of an input/output statement containing the IOSTAT= specifier causes
the variable specified in the IOSTAT= specifier to become defined
(1) With a zero value if neither an error condition, and end-of-file condition,
nor an end-of-record condition occurs,
(2) With a processor-dependent positive integer value if an error condition 
occurs,
(3) With a processor-dependent negative integer value if an end-of-ile condition
occurs and no error condition occurs, or
(4) With a processor-dependent negative integer value different from the
end-of-file value if and end-of-record condition occurs and no error condition
or end-of-file condition occurs.

Current output from gfortran:
 iostat   0
 iostat   0 x
 iostat   0
 iostat  -1

-- 


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

[Bug c++/20669] New: Template candidates not listed in error message.

[wwieser at gmx dot de]

When compiling the following (incorrect) code:  
 
-- 
// Wolfgang Wieser, 03/2005 
 
class A 
{ 
 templatevoid B(int,T1) {} 
 void B(int,int) {} 
}; 
 
void foo() 
{ 
 A a; 
 a.B(1,2,3); 
} 
--- 
 
GCC (gcc (GCC) 4.1.0 20050312 (experimental)) will write the following error:  
 
--- 
// test.cc: In function 'void foo()': 
// test.cc:12: error: no matching function for call to 'A::B(int, int, int)' 
// test.cc:6: note: candidates are: void A::B(int, int) 
--- 
 
Everything is fine except that the template version of B() is not  
listed among the candidates.  
 
I think it's not a feature but a (low-prio) bug (?)

-- 
   Summary: Template candidates not listed in error message.
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wwieser at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu


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

[Bug c++/20665] poor diagnostic for missing semicolon at end of template struct declaration

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-03-28 15:06 
---
Yes, there are multiple PRs in the database about diagnostics when people 
forget the semicolon at the end of a struct or class declaration. There are 
also examples in these PRs that show why this case is so hard for the  
parser to handle gracefully. 
 
W. 

-- 
   What|Removed |Added

   Keywords||diagnostic
Summary|poor diagnostic |poor diagnostic for missing
   ||semicolon at end of template
   ||struct declaration


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

[Bug middle-end/20635] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-28 
14:10 ---
Subject: Bug 20635

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-28 14:10:05

Modified files:
gcc: ChangeLog varasm.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: 20050328-1.c 

Log message:
PR middle-end/20635
* varasm.c (mark_decl_referenced): Do not mark extern inline functions
as needed.

* compile/gcc.c-torture/compile/20050328-1.c: New testcase made
by Jakub Jelinek.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8005&r2=2.8006
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.485&r2=1.486
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5225&r2=1.5226
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050328-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/20668] [3.4/4.0/4.1 Regression] ICE on invalid code, value dependent but invalid wise

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
14:05 ---
Confirmed, reduced testcase:
template  struct f
{
  typedef int reference;
};
template struct bitset
{
  static const E lwb;
  static const long bitCount = int(lwb) + 1;
  typename f::reference operator[](int e);
};
bitset _gBitset;


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords|error-recovery  |
  Known to work||3.3.3
   Last reconfirmed|-00-00 00:00:00 |2005-03-28 14:05:03
   date||
Summary|ICE (segv)  |[3.4/4.0/4.1 Regression] ICE
   ||on invalid code, value
   ||dependent but invalid wise
   Target Milestone|--- |4.0.1


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

[Bug middle-end/20667] [4.1 Regression] Incorrect code with -Os

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
13:47 ---
Closing as fixed then.  Next time take please use a more up todate compiler to 
report bugs with if you 
are going to use the mainline.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/20667] [4.1 Regression] Incorrect code with -Os

[m dot calderbank at iname dot com]

--- Additional Comments From m dot calderbank at iname dot com  2005-03-28 
13:44 ---
(In reply to comment #2)
> I cannot reproduce this with "4.1.0 20050327".
> I think this was fixed with the patch for PR 20542.

Yes, please accept my apologies. It turns out I was still using 20050321, and
didn't find PR 20542 as I forgot to include resolved bugs in my query...

Sorry for wasting your time,
Mark

-- 


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

[Bug c++/20668] ICE (segv)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.1.0 3.4.0


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

[Bug middle-end/20667] [4.1 Regression] Incorrect code with -Os

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
13:15 ---
I cannot reproduce this with "4.1.0 20050327".
I think this was fixed with the patch for PR 20542.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING
Summary|Incorrect code with -Os |[4.1 Regression] Incorrect
   ||code with -Os
   Target Milestone|--- |4.1.0


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

[Bug c++/20668] ICE (segv)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug c++/20668] ICE (segv)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug middle-end/20667] Incorrect code with -Os

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c++ |middle-end
   Keywords||wrong-code


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

[Bug c++/20667] Incorrect code with -Os

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-28 
13:04 ---
can you give the full version of 4.1?  I thought this was fixed in a later 
version of 4.1.0 already.

-- 


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

[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity

[aaronavay62 at aaronwl dot com]

--- Additional Comments From aaronavay62 at aaronwl dot com  2005-03-28 
12:42 ---
Thanks Danny.  So there is already machinery to fix this; it just needs to be
adapted to be case-insensitive.  I'm working on a patch.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aaronavay62 at aaronwl dot
   |dot org |com
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-03-27 13:01:38 |2005-03-28 12:42:10
   date||


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

[Bug c++/20668] ICE (segv)

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-28 12:23 
---
Created an attachment (id=8472)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8472&action=view)
source code (-save-temps, compressed)


-- 


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

[Bug c++/20668] ICE (segv)

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-03-28 12:22 
---
Created an attachment (id=8471)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8471&action=view)
compiler output (-v)


-- 


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

[Bug c++/20668] New: ICE (segv)

[igodard at pacbell dot net]

 

-- 
   Summary: ICE (segv)
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/20666] SPARC builtins should be folded if possible

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-03-28 
11:57 ---
Confirmed.


-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-28 11:57:08
   date||


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

[Bug c++/20667] New: Incorrect code with -Os

[m dot calderbank at iname dot com]

CVS g++ produces incorrect code when compiling the following file with -Os.
There does not appear to be a problem with gcc 4.0.

--- Begin op_test.cpp
#include 
using namespace std;

class Pair { protected: int a; int b;
public:
Pair(){}
Pair(int x, int y) : a(x), b(y) {}
int Product() const { return a*b; }
};

class PairSet {
public: class Iter; friend class Iter;

protected:
class List { public: Pair mPair; List* mNext; List(){} };
List* mPairs;

public:
PairSet() : mPairs(NULL) {}
class Iter {
public:
Iter(List* aPairList) : mCurrent(aPairList) {}
Iter& operator++() {
List* next = mCurrent->mNext;
mCurrent = next;
return *this; }

const Pair* operator->() const {
return &mCurrent->mPair; }

int operator!=(const Iter& aIter) const {
return mCurrent != aIter.mCurrent; }

protected: List* mCurrent;
};

Iter First() const { return Iter(mPairs); }
Iter Last()  const { return Iter(NULL); }
void Add(const Pair& aElement);
};

void PairSet::Add(const Pair& aElement) {
List *list = new List();
list->mNext = mPairs; list->mPair = aElement;
mPairs = list;
}

int main() {
int result = 0;
PairSet ps; ps.Add(Pair(2,3)); ps.Add(Pair(4,5));

PairSet::Iter last = ps.Last();
for(PairSet::Iter iter = ps.First(); iter != last; ++iter)
  result += iter->Product();
cout << result << endl; return 0;
}
--- End op_test.cpp

class Pairset::Iter allows a loop to step through a list of pointers to Pair
objects using operator++, and provides access to the Pair objects through
operator->. The program should output 26 (the sum of both products, 2*3 + 4*5).

With -Os, inspection of the assembly shows that in main() the compiler is
"caching" the value of iter-> without realising that calls to ++iter may change
it. As a result, Pair::Product() is called on the (4,5) pair twice, giving
output of 40.

For information, the bug appears in Mozilla, function Instantiation::Hash in
file ./content/xul/templates/src/nsRuleNetwork.cpp.

-- 
   Summary: Incorrect code with -Os
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot calderbank at iname dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2005-03-28 08:38 ---
See also PR20160 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160

-- 


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