--- Comment #2 from baldrick at free dot fr 2010-01-06 11:46 ---
I've modified dragonegg so it only needs version.h and not except.h or
libfuncs.h.
When I implement exception handling support it will probably need except.h, but
it is unlikely to ever need libfuncs.h.
--
baldrick
ReportedBy: baldrick at free dot fr
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=42253
--- Comment #69 from baldrick at free dot fr 2009-11-17 11:04 ---
It seems that variables produced by the Ada front-end no longer have any
non-trivial range information associated with them. Without knowing the
range information
type S is range 0 .. 100;
type T is range 10 .. 20
--- Comment #73 from baldrick at free dot fr 2009-11-17 16:56 ---
Can someone please close this bug as WONTFIX then (I don't know how to do
this myself).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41355
--- Comment #4 from baldrick at free dot fr 2009-09-13 07:43 ---
Created an attachment (id=18577)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18577action=view)
New checking patch; frees memory allocated by the checking code
--
baldrick at free dot fr changed:
What
--- Comment #3 from baldrick at free dot fr 2009-09-12 19:52 ---
I just updated to top-of-tree, and the same problem is present.
I think the variable is the RESULT_DECL from function f. Here's
a dump of the repeated variable (notice how the next variable
on the chain is the same
multiple times in cfun-local_decls
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
GCC
--- Comment #1 from baldrick at free dot fr 2009-09-11 21:05 ---
Created an attachment (id=18566)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18566action=view)
Debugging patch that shows the problem
You need to build with checking enable. You need to define VERIFY_LOCAL_DECLS
--- Comment #56 from baldrick at free dot fr 2008-03-30 14:26 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
What does must be in the range mean? Firstly, the program behaviour is
undefined if a variable is outside its range.
That's not true. The reference
--- Comment #61 from baldrick at free dot fr 2008-03-30 15:16 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
And here's a testcase that was supposed to check that
VRP is not removing checks that array accesses are in
range. Instead it shows that the Ada f-e
--- Comment #64 from baldrick at free dot fr 2008-03-30 16:02 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
But there are no checks on the array access. It looks like the f-e
doesn't generate them in the first place (as opposed to fold or gigi
making
--- Comment #67 from baldrick at free dot fr 2008-03-30 17:03 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
Try first to compile it. :-)
I did! I didn't notice the compile error
after the -gnatG output. Indeed, when fixed
thusly
procedure Overflow (X : Positive
--- Comment #50 from baldrick at free dot fr 2008-03-28 22:42 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
T' sub;
T x;
x = sub; (1)
sub = (T')x; (2)
x = VIEW_CONVERT_EXPR T(sub); (3)
where VRP for the simple copy (1) does not restrict x
--- Comment #51 from baldrick at free dot fr 2008-03-28 22:48 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
This is fold simplifying (js__TtB) target_first == -128 to
target_first == 128 via fold_sign_changed_comparison.
Right, that was my instant guess. The Ada
--- Comment #4 from baldrick at free dot fr 2007-03-15 15:16 ---
Subject: Re: tree-nested creates pointless static chains and trampolines when
the callgraph is non-trivial
Bootstraps with all languages including Ada. Does not introduce any new
testsuite failures. I'd appreciate
--- Comment #5 from baldrick at free dot fr 2007-03-15 15:34 ---
Subject: Re: tree-nested creates pointless static chains and trampolines when
the callgraph is non-trivial
Bootstraps with all languages including Ada. Does not introduce any new
testsuite failures. I'd appreciate
--- Comment #42 from baldrick at free dot fr 2007-03-13 10:30 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
It is not possible for a pointer value to be uninitialized. The language
requires all pointers to be default initialized to null.
I mean the thing that pointer
--- Comment #29 from baldrick at free dot fr 2007-03-09 10:41 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
Sure, it's just that overloading V_C_E like this feels somehow wrong to me.
Why? It's not overloading. V_C_E of an expression E of type X to
type Y means
--- Comment #32 from baldrick at free dot fr 2007-03-09 11:34 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
Well, the only problem with V_C_E is that if you assert on the range of the
base type like
if (V_C_E X'Base (y) 5)
abort();
that you still want VRP
--- Comment #33 from baldrick at free dot fr 2007-03-09 11:50 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
My suggested use of a builtin would allow multiple redundant validity checks
to be safely eliminated, because the builtin would be a pure function.
This is presumably
--- Comment #37 from baldrick at free dot fr 2007-03-09 22:44 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
Think of a range check being done in a subscript reference in the LHS of
an assignment. A bounded error is not allowed to cause a memory store
outside the bounds
--- Comment #38 from baldrick at free dot fr 2007-03-09 23:10 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
All the mess would be way easier if the FE would not expose the subtypes to
the middle-end...
I don't see how giving *additional* information could be bad
--- Comment #40 from baldrick at free dot fr 2007-03-09 23:41 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
On Saturday 10 March 2007 00:13:27 kenner at vlsi1 dot ultra dot nyu dot edu
wrote:
--- Comment #39 from kenner at vlsi1 dot ultra dot nyu dot edu
2007-03-09
--- Comment #27 from baldrick at free dot fr 2007-03-08 16:06 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
y = __builtin_nop(x); valid = (y=lower_bound y =upper_bound);
The point is that the intrinsic would be opaque to the optimizers,
and would only be lowered
--- Comment #42 from baldrick at free dot fr 2007-03-02 09:16 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
Thaks for the detective work! I sort of expected the fold patch to be weird
or
have no effect - but it was needed only (for the testcase) to get rid
--- Comment #38 from baldrick at free dot fr 2007-03-01 08:18 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
... The problem
is that the value of arg1, a constant, is not in the
range of its own type! ...
It seemed clear to me last night why this is a problem
--- Comment #40 from baldrick at free dot fr 2007-03-01 23:07 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
The problem is in this transformation:
/* Fold (X C) op (Y C) as (X ^ Y) C op 0, and symmetries. */
X^Y may not be in the range of the type
--- Comment #37 from baldrick at free dot fr 2007-02-28 23:30 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
With bootstrapping the compiler and then checking you get
FAIL: c35507j
FAIL: cd92001
FAIL: cxh1001
I get a slightly different set (i486-linux
--- Comment #14 from baldrick at free dot fr 2007-02-23 09:39 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
On Friday 23 February 2007 06:50:48 ebotcazou at gcc dot gnu dot org wrote:
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-23 05:50
--- Comment #15 from baldrick at free dot fr 2007-02-23 10:03 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
On Friday 23 February 2007 10:22:15 rguenth at gcc dot gnu dot org wrote:
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-02-23 09:22
--- Comment #18 from baldrick at free dot fr 2007-02-23 12:36 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
The attached patch removes all checks (from the first half of the testcase).
Thanks for the patch!
+ Make sure to preserve ~[a, a] (FIXME: why
--- Comment #20 from baldrick at free dot fr 2007-02-23 13:04 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
!POINTER_TYPE_P
I'm testing with INTEGRAL_TYPE_P.
By the way, I see a lot a anti-range canonicalization going
on in C code. A lot of code where u
--- Comment #23 from baldrick at free dot fr 2007-02-23 15:40 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
if not To'Valid then
I'm pretty sure that this is an example of PR26797:
the front-end should generate 'Valid by doing a
VIEW_CONVERT_EXPR
--- Comment #25 from baldrick at free dot fr 2007-02-23 15:59 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
There seems to be an additional C testsuite failure: loadpre1.c
Also, some of the acats failures look interesting, for example
the first one c34004a
--- Comment #26 from baldrick at free dot fr 2007-02-23 16:01 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
Of course in this case I would have expected VRP or whatever to optimize away
if not To'Valid then
raise Constraint_Error;
end
--- Comment #29 from baldrick at free dot fr 2007-02-23 17:09 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
BTW, this is not a bug, but a possible enhancement, and a very tricky one at
that, since removing too many checks will hurt much more Ada programmers than
--- Comment #6 from baldrick at free dot fr 2006-05-01 10:09 ---
Re comment #5:
so we have [1,1] UNION [2, +INF] and we just get ~[0,0] bogus
and it also means this is PR 23744.
This is more than PR 23744: with the fix for PR 23744 applied,
__builtin_abort () is still not eliminated
--- Comment #3 from baldrick at free dot fr 2006-04-16 20:35 ---
Created an attachment (id=11281)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11281action=view)
correct vrp_meet of VR_RANGEs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23744
--- Comment #4 from baldrick at free dot fr 2006-04-16 20:50 ---
Does this patch fix it for you? It looks more complicated
than it is (most of the patch is comment tweaks and white
space changes due to indentation change). The real change
is to remove the check
--- Comment #3 from baldrick at free dot fr 2006-03-23 13:19 ---
I've had a look at c35507m. I think it's a front-end bug. The problem occurs
in this type support subprogram:
C35507M.CHARRP (A, F)
{
if ((system__unsigned_types__unsigned) A - 4 = 1)
{
return (integer
--- Comment #6 from baldrick at free dot fr 2005-10-03 08:54 ---
Subject: Re: ICE on legal (?) code: with type ... is access + variable of the
access type
with type is a GNAT extension that has been superseded by the
limited with clause introduced in the new Ada 0Y language revision
--- Additional Comments From baldrick at free dot fr 2005-07-19 12:22
---
The same problem is still present if the array bounds are not static.
The following test case gives
$ ./u
Expected 20, found 30
Expected 30, found 40
Expected 40, found -1076635688
with Ada.Text_IO
--- Additional Comments From baldrick at free dot fr 2005-01-20 12:15
---
Here is a simpler example:
with Ada.Text_IO; use Ada.Text_IO;
procedure T is
type Index_Type is range 0 .. 4; -- does not fail if lower bound is 1
type Unconstrained_Array_Type is array
--- Additional Comments From baldrick at free dot fr 2005-01-15 12:27
---
Subject: Re: ACATS CXA4009, CXA4020 - valgrind detects bad code (overlapping
memcpy)
Confirmed, the problem is in gimplify_modify_expr_to_memcpy (but this is not
a regression even
though this is a middle
--- Additional Comments From baldrick at free dot fr 2005-01-14 08:59
---
Subject: Re: New: ACATS CXA4009, CXA4020 - valgrind detects bad code
(overlapping memcpy)
Here is a much simplified version:
gnatmake -s -g -O2 tt
valgrind --tool=memcheck ./tt
==10048== Memcheck, a memory
--- Additional Comments From baldrick at free dot fr 2005-01-14 23:23
---
Subject: Re: ACATS CXA4009, CXA4020 - valgrind detects bad code (overlapping
memcpy)
The problem seems to be in the front-end, since the memcpy is already present
in the generic tree dump, ss.adb.t03.generic
--- Additional Comments From baldrick at free dot fr 2005-01-13 10:47
---
Subject: Re: Overlapping memcpy with big struct copies (ACATS c64106a)
Would you like me to file a separate report for them? Here is cxa4009 by
the way:
Yes please because this is a related issue but I
--- Additional Comments From baldrick at free dot fr 2005-01-12 22:41
---
valgrind thinks there is wrong code:
RUN c37402a
==11202== Memcheck, a memory error detector for x86-linux.
==11202== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==11202== Using valgrind
--- Additional Comments From baldrick at free dot fr 2005-01-12 22:43
---
valgrind detects wrong code:
RUN c43214c
==21414== Memcheck, a memory error detector for x86-linux.
==21414== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==21414== Using valgrind-2.3.0
: ACATS c460010 - valgrind detects wrong code
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
(overlapping
memcpy)
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
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=19412
)
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC
--- Additional Comments From baldrick at free dot fr 2005-01-12 23:12
---
ACATS tests C95087A, CXA4009 and CXA4020 show similar failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
dot org
ReportedBy: baldrick at free dot fr
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=19415
: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
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
--- Additional Comments From baldrick at free dot fr 2005-01-12 23:52
---
Subject: Re: Overlapping memcpy with big struct copies (ACATS c64106a)
This can be reproduced with the following C example:
struct A
{
int a[1024];
};
void g(struct A *a, struct A *b)
{
*a = *b
--- Additional Comments From baldrick at free dot fr 2005-01-13 00:08
---
Subject: Re: Overlapping memcpy with big struct copies (ACATS c64106a)
On Thursday 13 January 2005 00:57, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
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
at free dot fr
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=19237
--- Additional Comments From baldrick at free dot fr 2005-01-03 10:07
---
Subject: Re: ICE on legal (?) code: with type ... is access + variable of the
access type
with type is an obsolete construct, which is replaced by limited with in
Ada 05, and already supported by GNAT
--- Additional Comments From baldrick at free dot fr 2005-01-02 14:26
---
(In reply to comment #1)
D.351 = (system__address *) (SIGNED_32) D.359;
Confirmed, looks like a front-end problem, it should have made a temprary
variable to hold the value
and then taken the address
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host
return-by-
copy (regression)
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at free dot
66 matches
Mail list logo
