--- Comment #6 from baldrick at gcc dot gnu dot org 2010-07-07 15:25
---
Fixed in commits 161918 (mainline) and 161919 (gcc-4.5 branch).
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from baldrick at gcc dot gnu dot org 2010-07-06 08:23
---
Even better, it actually works! :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41355
--- Comment #1 from baldrick at gcc dot gnu dot org 2010-07-05 18:43
---
It turns out that the problem is that when build_function_type_skip_args
creates
the new type, TYPE_POINTER_TO for the new type is still pointing to the old
type.
When gimple_call_set_fndecl is used to change
--- Comment #3 from baldrick at gcc dot gnu dot org 2010-07-05 19:14
---
Hi Honza, my original patch was silly, I'm trying this instead:
@@ -7216,7 +7216,7 @@
if (TREE_CODE (orig_type) != METHOD_TYPE
|| !bitmap_bit_p (args_to_skip, 0))
{
- new_type = copy_node
--- Comment #5 from baldrick at gcc dot gnu dot org 2010-06-28 11:13
---
I'm hitting the same thing when building LLVM. It needs -fPIC and -O3 to fire
on
my x86-64 linux box:
$ g++-4.6 -fPIC -O3 DwarfException.ii
DwarfException.ii:56:89: internal compiler error
--- Comment #6 from baldrick at gcc dot gnu dot org 2010-06-28 11:14
---
Created an attachment (id=21024)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21024action=view)
Reduced testcase
--
baldrick at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from baldrick at gcc dot gnu dot org 2010-05-10 13:17
---
This bug fires when trying to build LLVM using trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44017
No_Task_Hierarchy, but should
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC build
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux
--- Comment #9 from baldrick at gcc dot gnu dot org 2010-02-28 11:18
---
Yes, that did the trick. Thanks for fixing this!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
--- Comment #3 from baldrick at gcc dot gnu dot org 2010-02-26 09:47
---
The reason I occasionally use a thin pointer is because they can be stored
atomically. This is sometimes useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
--- Comment #5 from baldrick at gcc dot gnu dot org 2010-02-26 17:24
---
I was also surprised, because I couldn't see the relevance. To double check I
rebuilt one commit before (no crash) and at that commit (crash). That seems
pretty conclusive, especially as the testcase seems
--- Comment #1 from baldrick at gcc dot gnu dot org 2010-02-25 19:56
---
The regression was introduced by the following commit (found by bisection):
r133011 | ebotcazou | 2008-03-07 18:12:28 +0100 (Fri, 07 Mar 2008) | 33 lines
* decl.c (MAX_FIXED_MODE_SIZE): Define
with -flto
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC build triplet: x86_64
--- Comment #2 from baldrick at gcc dot gnu dot org 2010-02-11 16:42
---
Sorry, small bug in the testcase, should have been:
extern const char LinkVar;
__attribute__((used)) static const char *const LinkObj = LinkVar;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038
--- Comment #2 from baldrick at gcc dot gnu dot org 2010-02-06 17:50
---
Compiling the GCC testsuite with -flto and -g, it turns out that
g++.dg/debug/dwarf2/pr41063.C already shows this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42653
ReportedBy: baldrick at gcc dot gnu dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42987
--- Comment #2 from baldrick at gcc dot gnu dot org 2010-02-06 20:13
---
These are the only testcases I found that crash the compiler. If I come across
any more, I won't report them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42987
--- Comment #3 from baldrick at gcc dot gnu dot org 2010-01-07 14:22
---
I added version.h to the list of installed headers in commit 155692.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
both flags to crash)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC build triplet
--- Comment #2 from baldrick at gcc dot gnu dot org 2009-02-17 13:36
---
If I unsupress checks in System.Regexp.Compile.Create_Secondary_Table,
then I get
raised CONSTRAINT_ERROR : s-regexp.adb:1161 index check failed
here:
1160for Column in 0 .. Alphabet_Size loop
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux
--- Comment #54 from baldrick at gcc dot gnu dot org 2008-03-30 14:14
---
Here's a test that VRP is not eliminating
validity checks. abort should be called
if either X or Y is = 0. With Richard's
latest patch (from the gcc mailing list)
applied, everything is fine: the tests
--- Comment #55 from baldrick at gcc dot gnu dot org 2008-03-30 14:18
---
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 is failing
to generate checks at all!
function Overflow (X
--- Comment #13 from baldrick at gcc dot gnu dot org 2008-03-28 14:30
---
This has been fixed.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #45 from baldrick at gcc dot gnu dot org 2008-03-28 14:58
---
The recent VRP improvements made no difference to this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #8 from baldrick at gcc dot gnu dot org 2008-01-10 18:25
---
Your solution seems to be somewhat complex though. Can't we get away with
an iterative propagation algorithm for the DECL_NO_STATIC_CHAIN flag?
Yes, but it is less efficient: in the worst case the number
--- Comment #4 from baldrick at gcc dot gnu dot org 2007-12-08 09:53
---
This is fixed on trunk.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from baldrick at gcc dot gnu dot org 2007-12-08 09:42
---
I don't see any valgrind messages or other failure using svn head,
when compiling at -O0 or -O2.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
: sees Ada f-e
unconstrained_array_type node
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick
--- Comment #11 from baldrick at gcc dot gnu dot org 2007-06-08 18:46
---
Thank you both for your explanation to a newbie having no experience with
valgrind tool. I have come up with a simpler version which similar to
Laurent's. Here it goes.
Thanks - but how is it supposed to work
--- Comment #7 from baldrick at gcc dot gnu dot org 2007-06-07 07:07
---
Valgrind is helful only if there is a crash (segmentation fault).
This is completely wrong. Valgrind detects problems that *may*
cause a crash. The fact that crashes occur rarely doesn't mean
there isn't
--- Comment #9 from baldrick at gcc dot gnu dot org 2007-06-07 20:12
---
Here is a test case that's likely to fail: I just allocate a non zero filled
record of the right size before filling the map.
Good idea - thanks for doing this!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick 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
--- Comment #2 from baldrick at gcc dot gnu dot org 2007-06-06 18:35
---
Why shouldn't it happen in a small program?
It can cause a segfault also in small programs.
However, memory areas often start out containing
all zeros, so until the program has dirtied a bunch
of memory
--- Comment #4 from baldrick at gcc dot gnu dot org 2007-06-06 20:59
---
You have to run it under valgrind to see the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
--- Comment #4 from baldrick at gcc dot gnu dot org 2007-05-10 10:11
---
I'm reopening this as an enhancement request. I agree that the
code currently produced is correct, i.e. executes as required
by the RM. However it is suboptimal and in my opinion (and
apparently in Eric's
dot org
ReportedBy: baldrick 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=31877
--- Comment #3 from baldrick at gcc dot gnu dot org 2007-05-09 14:42
---
The code is as intended here, and GCC notion of aliasing is not sufficient
to fullfill Ada needs in this case.
Are you sure? gcc got more sophisticated wrt aliasing in the gcc 4 series.
What exactly does Ada
--- Comment #6 from baldrick at gcc dot gnu dot org 2007-05-02 10:14
---
The problem still occurs. I tested with gcc version 4.3.0 20070425
(experimental), i.e. after all your patches went in.
--
baldrick at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from baldrick at gcc dot gnu dot org 2007-03-15 14:49
---
Created an attachment (id=13208)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13208action=view)
Proposed fix
Bootstraps with all languages including Ada. Does not introduce any new
testsuite failures. I'd
--- Comment #6 from baldrick at gcc dot gnu dot org 2007-03-15 19:45
---
(In reply to comment #1)
Try this: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01201.html
I don't think you need to consider FDESC_EXPR when constructing
the callgraph. It seems only to be used for vtables
--- Comment #25 from baldrick at gcc dot gnu dot org 2007-03-08 09:56
---
I can't help feeling that VIEW_CONVERT_EXPR is not the right tool
for implementing 'Valid. I think an intrinsic would be better,
eg int __builtin_nop(int) which is defined to return its
argument unchanged
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
--- Comment #6 from baldrick at gcc dot gnu dot org 2007-02-22 17:41
---
Bonus points if you can reduce this to a C test case ;-)
Starting with the gimple dumps, this is usually not hard to do.
It can't be reduced because it relies on integer types with restricted ranges,
i.e
--- Comment #8 from baldrick at gcc dot gnu dot org 2007-02-22 18:14
---
Can you walk me through some of the checks and why they can be removed? I see
(.004.gimple dump):
...
I assume all of the above is gimplified from just
if Source_Last Source_First
--- Comment #9 from baldrick at gcc dot gnu dot org 2007-02-22 18:18
---
(In reply to comment #7)
Do not work too hard on this, there is code in the AdaCore tree to disable
VRP in more cases, lest language-mandated checks are erroneously removed.
For example PR ada/26797
--- Comment #11 from baldrick at gcc dot gnu dot org 2007-02-22 22:54
---
Please do not overwrite changes, thanks.
Sorry about that - it wasn't on purpose: your comment
and mine collided. I actually checked the two bugs
after getting the message that I'd manage to wipe out
your
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC host triplet: i486-linux-gnu
--- Comment #1 from baldrick at gcc dot gnu dot org 2007-02-21 15:17
---
I've tried and failed to attach the source code (bugzilla problem), so here it
is inline (you can extract it using gnatchop):
with Join_Equal;
with JS;
procedure J is new Join_Equal (
Source_Type = JS.S
--- Comment #2 from baldrick at gcc dot gnu dot org 2006-12-01 08:08
---
Fixed in current version. FI: this was ACT bug E103-008.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from baldrick at gcc dot gnu dot org 2006-12-01 08:31
---
None of the examples provided in this bug report generate
an overlapping memcpy with current gcc.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from baldrick at gcc dot gnu dot org 2006-12-01 08:38
---
Does not occur with current gcc.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 08:43
---
Does not happen with current gcc.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 09:07
---
While this doesn't happen with GNAT-GPL 2006 or GNAT Pro 5.05w (20060118),
that's not surprising because they are compiled with --disable-checking.
Here are the details of the compiler for which I get this ICE
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 15:24
---
The uninitialized bytes are normal: the Unit_Type structure is 16 bytes long:
type Unit_Type is
record
Position : Natural := 19;
String_Value : String (1..9) := (others
sem_util.adb:1033
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
GCC build triplet: i686
--- Comment #7 from baldrick at gcc dot gnu dot org 2006-11-29 16:00
---
Subject: Bug 23744
Author: baldrick
Date: Wed Nov 29 16:00:07 2006
New Revision: 119320
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119320
Log:
PR tree-optimization/23744
* tree-vrp.c
61 matches
Mail list logo
