--- 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.
--
baldri
signedTo: unassigned at gcc dot gnu dot org
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 #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
--- 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
is cloned
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
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=18577&action=view)
New checking patch; frees memory allocated by the checking code
--
baldrick at free dot fr
--- 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 sa
--- 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=18566&action=view)
Debugging patch that shows the problem
You need to build with checking enable. You need to define VERIFY_LOCA
Summary: Variables can occur 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
Repo
--- 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 Ove
--- 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
--- 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. Instea
--- 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.
>
--- 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
--- 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 (sub); (3)
>
> where VR
--- 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 fa
--- 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 fa
--- 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 m
--- 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
>
--- 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* i
--- 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 t
--- 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" fu
--- 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 (y) > 5)
> abort();
>
> th
--- 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 expressi
--- 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 optimiz
--- 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) t
--- 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
--- 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
--- 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 diff
--- 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 programmer
--- 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_
--- 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 is
--- 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_CON
--- 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
--- 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] (FIXM
--- 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
--- 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
--- 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 sti
--- 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
if
--- 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=11281&action=view)
correct vrp_meet of VR_RANGEs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23744
--- 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)
{
re
--- 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
--- 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
--- 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.t
--- 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
--- 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
ty: 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-pc
--- 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 g
--- 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, struc
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
GCC targe
nent: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19415
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 t
--- 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
ised value)
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 do
rmal
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19412
wrong code (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 f
Summary: 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 f
--- 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-
--- 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 val
--- 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 s
ick 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-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
> an
-reference type wrongly considered 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
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 build triplet: i686-pc-linux-gnu
66 matches
Mail list logo
