[Bug tree-optimization/41355] Type of ADDR_EXPR in CALL_EXPR not rebuilt when function is cloned
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41355
[Bug tree-optimization/41355] Type of ADDR_EXPR in CALL_EXPR not rebuilt when function is cloned
--- 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
[Bug tree-optimization/41355] Type of ADDR_EXPR in CALL_EXPR not rebuilt when function is cloned
--- 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 the fndecl to one with less
arguments, an ADDR_EXPR is built. The type of the ADDR_EXPR is obtained from
the
TYPE_POINTER_TO field of the new type, and thus has type pointer-to-old-type
rather than pointer-to-new-type. I'm testing the following patch. The idea
here is that calling copy_node has no advantage. In spite of the comment,
build_distinct_type_copy preserves attributes etc too, so it might as well
be used always. [I think the comment refers to some earlier logic, since
the change introducing build_distinct_type_copy post-dates it].
Index: gcc-4.5/gcc/tree.c
===
--- gcc-4.5.orig/gcc/tree.c 2010-07-05 20:26:21.349376337 +0200
+++ gcc-4.5/gcc/tree.c 2010-07-05 20:29:11.582730610 +0200
@@ -7208,24 +7208,10 @@
new_reversed = void_list_node;
}
- /* Use copy_node to preserve as much as possible from original type
- (debug info, attribute lists etc.)
- Exception is METHOD_TYPEs must have THIS argument.
- When we are asked to remove it, we need to build new FUNCTION_TYPE
- instead. */
- if (TREE_CODE (orig_type) != METHOD_TYPE
- || !bitmap_bit_p (args_to_skip, 0))
-{
- new_type = copy_node (orig_type);
- TYPE_ARG_TYPES (new_type) = new_reversed;
-}
- else
-{
- new_type
-= build_distinct_type_copy (build_function_type (TREE_TYPE
(orig_type),
-new_reversed));
- TYPE_CONTEXT (new_type) = TYPE_CONTEXT (orig_type);
-}
+ new_type
+= build_distinct_type_copy (build_function_type (TREE_TYPE (orig_type),
+ new_reversed));
+ TYPE_CONTEXT (new_type) = TYPE_CONTEXT (orig_type);
/* This is a new type, not a copy of an old type. Need to reassociate
variants. We can handle everything except the main variant lazily. */
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-07-05 18:43:39
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41355
[Bug tree-optimization/41355] Type of ADDR_EXPR in CALL_EXPR not rebuilt when function is cloned
--- 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 (orig_type);
+ new_type = build_distinct_type_copy (orig_type);
TYPE_ARG_TYPES (new_type) = new_reversed;
}
else
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41355
[Bug tree-optimization/44357] [4.6 Regression] internal compiler error: in cgraph_decide_inlining_of_small_functions
--- 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: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1047 I reduced a 56 line test case using delta (will attach in a moment). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44357
[Bug tree-optimization/44357] [4.6 Regression] internal compiler error: in cgraph_decide_inlining_of_small_functions
--- 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 |Added Attachment #20788|0 |1 is obsolete|| Attachment #20789|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44357
[Bug c++/44017] [4.6 regression] ICE with template hierarchy
--- 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
[Bug ada/44058] New: The No_Tasking restriction does not imply No_Task_Hierarchy, but should
Build_Class_Wide_Master in exp_ch3.adb starts with this check: -- Nothing to do if there is no task hierarchy if Restriction_Active (No_Task_Hierarchy) then return; end if; This early return should obviously also occur if tasking is not allowed, for example if the restriction No_Tasking is in force, but it doesn't. This can cause the tasking runtime to be pulled in for programs using tagged types in funky ways even in the presence of pragma Restrictions (No_Tasking); -- Summary: The No_Tasking restriction does not imply 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 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=44058
[Bug ada/43993] New: Foreign thread results in Task_Alternate_Stack being used unitialized on linux
Noticed with valgrind. Suppose a foreign thread calls Ada code. This results in Register_Foreign_Thread being called, which creates an ATCB. At the end of this routine, Enter_Task is called. Enter_Task is defined in s-taprop-linux.adb on linux. It contains this code that causes Task_Alternate_Stack to be registered as the signal stack: if Use_Alternate_Stack then declare Stack : aliased stack_t; Result : Interfaces.C.int; begin Stack.ss_sp:= Self_ID.Common.Task_Alternate_Stack; Stack.ss_size := Alternate_Stack_Size; Stack.ss_flags := 0; Result := sigaltstack (Stack'Access, null); pragma Assert (Result = 0); end; end if; But where was Task_Alternate_Stack initialized? Answer: it wasn't. Normally it would be initialized in Task_Wrapper, but of course Task_Wrapper is not called for foreign threads. Using a random uninitialized address for the signal stack results in much unpleasantness if the signal stack is ever used. -- Summary: Foreign thread results in Task_Alternate_Stack being used unitialized on linux 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-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=43993
[Bug ada/42253] [4.4/4.5 regression] run time crash on null for thin pointers
--- 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
[Bug ada/42253] [4.4/4.5 regression] run time crash on null for thin pointers
--- 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
[Bug ada/42253] [4.4/4.5 regression] run time crash on null for thin pointers
--- 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 to fail deterministically. I can investigate further if you like. By the way, if you update gcc to that commit, or somewhere nearby, then it will not build due to a mistake in tree-ssa-ccp.c that causes a miscompile of gcc itself. You need to revert commit 132991 (pinskia). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
[Bug ada/42253] Wrong handling of null for fat pointers forced thin by size clause
--- 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 if not already defined. (gnat_to_gnu_entity) E_Record_Type: Try to get a smaller form of the component for packing, if possible, as well as if a component size clause is specified. E_Record_Subtype: For an array type used to implement a packed array, get the component type from the original array type. Try to get a smaller form of the component for packing, if possible, as well as if a component size clause is specified. (round_up_to_align): New function. (make_packable_type): Add in_record parameter. For a padding record, preserve the size. If not in_record and the size is too large for an integral mode, attempt to shrink the size by lowering the alignment. Ditch the padding bits of the last component. Compute sizes and mode manually, and propagate the RM size. Return a BLKmode record type if its size has shrunk. (maybe_pad_type): Use MAX_FIXED_MODE_SIZE instead of BIGGEST_ALIGNMENT. Use Original_Array_Type to retrieve the type in case of an error. Adjust call to make_packable_type. (gnat_to_gnu_field): Likewise. (concat_id_with_name): Minor tweak. * trans.c (larger_record_type_p): New predicate. (call_to_gnu): Compute the nominal type of the object only if the parameter is by-reference. Do the conversion actual type - nominal type if the nominal type is a larger record. (gnat_to_gnu): Do not require integral modes on the source type to avoid the conversion for types with identical names. (addressable_p): Add gnu_type parameter. If it is specified, do not return true if the expression is not addressable in gnu_type. Adjust recursive calls. * utils.c (finish_record_type): Remove dead code. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
[Bug lto/43038] New: DECL_PRESERVE_P static globals not completely preserved with -flto
The fact that LinkObj is initialized with LinkVar does not seem to be preserved when using -flto: extern const char LinkVar; __attribute__((used)) static const char *const LinkObj = LinkVar; -- Summary: DECL_PRESERVE_P static globals not completely preserved 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-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=43038
[Bug lto/43038] DECL_PRESERVE_P static globals not completely preserved with -flto
--- 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
[Bug lto/42653] ICE with -g and -flto (requires both flags to crash)
--- 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
[Bug lto/42987] New: Testcases local1-a.cc and local1.C cause ICE when compiled with -flto -g
Compiling g++.dg/abi/local1-a.cc and g++.dg/abi/local1.C from the testsuite with -flto -g results in an ICE (the same ICE for both testcases): $ gcc-4.5 -c -g -flto local1.C local1.C:22:1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:21168 -- Summary: Testcases local1-a.cc and local1.C cause ICE when compiled with -flto -g 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-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
[Bug lto/42987] Testcases local1-a.cc and local1.C cause ICE when compiled with -flto -g
--- 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
[Bug other/42541] [PATCH] install except.h libfuncs.h version.h (plugin headers)
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42541
[Bug lto/42653] New: ICE with -g and -flto (requires both flags to crash)
$ g++ -c -flto -g fltog.ii
fltog.ii: In member function MCIListener:
fltog.ii:25:3: internal compiler error: tree check: expected class type, have
declaration (function_decl) in gen_type_die_with_usage, at dwarf2out.c:18747
Occurs with top-of-tree g++-4.5.
Testcase fltog.ii:
namespace llvm
{
class Function;
class MachineCodeInfo;
class ExecutionEngine
{
};
class JIT:public ExecutionEngine
{
void runJITOnFunction (Function * F, MachineCodeInfo * MCI = 0);
};
class JITEventListener
{
public:JITEventListener ()
{
} virtual ~JITEventListener ();
};
}
using namespace llvm;
void
JIT::runJITOnFunction (Function * F, MachineCodeInfo * MCI)
{
class MCIListener:public JITEventListener
{
MachineCodeInfo *const MCI;
public: MCIListener (MachineCodeInfo * mci):MCI (mci)
{
}};
}
--
Summary: ICE with -g and -flto (requires 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: 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=42653
[Bug ada/36785] Segmentation fault in Gnat.Regexp
--- 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 1161 Meta_States (Nb_State + 1) := (others = False); -- Here 1162 Temp_State_Not_Null := False; The reason is that Nb_State + 1 is beyond Meta_States'Last. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36785
[Bug ada/37796] New: Globals and functions private to generic body exported when instantiated in a spec
When compiling h.ads, the global variable Global and function Subroutine should be eliminated. They are not, because they have TREE_PUBLIC set (corresponds to Is_Public in the Ada f-e) even though they are internal to the body of the generic package G. This seems to be because G is instantiated in a package spec. The result is that Global and Subroutine are marked as external symbols. Reproduce as follows: gcc -S -O1 h.ads -o - | grep h__gi__ There should be no output. -- testcase -- generic package G is pragma Elaborate_Body; end; package body G is Global : Integer; procedure Subroutine is begin null; end; end; with G; package H is package GI is new G; end; -- Summary: Globals and functions private to generic body exported when instantiated in a spec Product: gcc Version: 4.4.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-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=37796
[Bug ada/36785] New: Segmentation fault in Gnat.Regexp
$ gnatmake rtest.adb gcc -c rtest.adb gnatbind -x rtest.ali gnatlink rtest.ali $ ./rtest raised STORAGE_ERROR : stack overflow (or erroneous memory access) Also occurs with GNAT GPL 2008. -- chop here -- with Gnat.Regexp; procedure RTest is R : constant Gnat.Regexp.Regexp := Gnat.Regexp.Compile (Pattern = .*AB.*|.*XYZ.*|.*0123456.*); B : Boolean; begin B := Gnat.Regexp.Match(A, R); end; -- Summary: Segmentation fault in Gnat.Regexp Product: gcc Version: 4.4.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-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=36785
[Bug ada/36764] New: ICE with -gnatn inlining and stream attributes
$ gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc.fsf.master/configure --prefix=/usr/local/gnat-fsf --enable-languages=ada,c,c++ --disable-bootstrap --disable-multilib --enable-checking Thread model: posix gcc version 4.4.0 20080630 (experimental) (GCC) $ gcc -c -O2 -gnatn b.ads +===GNAT BUG DETECTED==+ | 4.4.0 20080630 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure einfo.adb:2439| | Error detected at b.ads:1:6 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. b.ads d.ads c.ads list may be incomplete compilation abandoned -- cut here -- with D; package B is end; with C; procedure D is new C(Integer'Write); with Ada.Streams; generic with procedure Write_Type ( Stream : not null access Ada.Streams.Root_Stream_Type'Class; Item : Integer ); procedure C; pragma Inline (C); -- Summary: ICE with -gnatn inlining and stream attributes Product: gcc Version: 4.4.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-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=36764
[Bug ada/36678] New: GNAT from svn uses up infinite amount of memory on twisty generic+tagged testcase
$ gcc -c p-c.adb +===GNAT BUG DETECTED==+ | 4.4.0 20080630 (experimental) (x86_64-unknown-linux-gnu) Storage_Error heap exhausted| | Error detected at p-c.adb:1:1| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. p-c.adb p-c.ads p.ads f.ads g.ads compilation abandoned $ gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc.fsf.master/configure --prefix=/usr/local/gnat-fsf --enable-languages=ada,c,c++ --disable-bootstrap --disable-multilib --enable-checking Thread model: posix gcc version 4.4.0 20080630 (experimental) (GCC) gcc built from svn as of this morning. -- chop here -- with G; generic type T is private; package F is type R () is tagged private; function C return R; private package GI is new G (T); type R is new GI.R with null record; end; generic type T is private; package G is type R is tagged null record; procedure P (X : R; Y : T); end; package P is end; with F; package P.C is private type New_Integer is new Integer; package FI is new F (New_Integer); type R is new FI.R with null record; function C return R; end; package body P.C is end; -- Summary: GNAT from svn uses up infinite amount of memory on twisty generic+tagged testcase Product: gcc Version: 4.4.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-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=36678
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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 are still done. procedure Valid (X : Positive) is procedure Abrt; pragma Import(C, Abrt, abort); Y : Positive; begin if not X'Valid then Abrt; end if; if not Y'Valid then Abrt; end if; end; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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 : Positive) return Integer is Y : Positive; A : array (Positive) of Integer; pragma Import (Ada, A); begin return A (X) + A (Y); end; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- 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 of node visits goes up by a factor of the nesting depth. Since this depth is sure to be fairly small (typically 2 or 3) this probably is of no consequence. I am now working on a revised patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug ada/32286] [4.2/4.3 Regression] ICE in dwarf2out with -g: sees Ada f-e unconstrained_array_type node
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32286
[Bug ada/19409] ACATS c460010 - valgrind detects wrong code
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19409
[Bug ada/32286] New: ICE in dwarf2out with -g: sees Ada f-e unconstrained_array_type node
The following occurs with svn head and GNAT GPL 2007. $ gcc -c -g -gnat05 e.adb +===GNAT BUG DETECTED==+ | 4.3.0 20070611 (experimental) (i686-pc-linux-gnu) GCC error: | | in gen_type_die_with_usage, at dwarf2out.c:12921 | | Error detected around e.adb:8| ... This occurs because a node type that should be internal to the Ada f-e (unconstrained_array_type) has made its way as far as gen_type_die_with_usage in dwarf2out.c. Testcase: package E is type T (S : access String) is null record; procedure P (X : T); end; package body E is procedure P (X : T) is S : String renames X.S.all; F : String (S'Range); for F'Address use S (S'First)'Address; begin null; end; end; -- Summary: ICE in dwarf2out with -g: 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 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=32286
[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of
--- 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? You didn't dirty memory like Laurent did (new+free), so Item will contain null and you'll get a constraint error in Item.all'Valid. [If you are very lucky Item will contain a non-zero value and you will get a segmentation fault]. I just ran your example a few thousand times and never saw anything besides constraint error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- 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 something wrong. I already explained that you can't expect to get a segmentation fault on a small program. So for a testcase I either had to provide the large (300k/loc) original program which showed the segmentation fault systematically, or a small program which basically never shows a segmentation fault. i.e. testcases become less and less deterministic as you make them smaller. However there is a way to keep things deterministic: run under a tool such as valgrind. Valgrind detects the same problem every time no matter how big or small the testcase. This makes it feasible to submit a minimal testcase which captures the essential problem, even though when run normally (i.e. not under valgrind) it executes fine. In fact you will never get a segmentation fault with the testcase I submitted because it doesn't ever dereference the uninitialized pointer - but that doesn't matter because valgrind notices that it contains an uninitialized value when the if compares it with null. i.e. the testcase is good enough for debugging the compiler problem. Let me say it again: when run on the small testcase valgrind shows the presence of an uninitialized value that doesn't cause any problems when the small testcase is run - it causes problems on the large program from which this testcase was reduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of
--- 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?id=32234
[Bug ada/32234] New: Default pointer initialization not occuring - due to the use of
I see this problem with mainline and with GNAT GPL 2007. A pointer is not being default initialized to NULL in Ada.Containers.Hashed_Maps. This causes segmentation faults on large programs. On the small testcase (see end of message) you need valgrind to see it, since almost always you get NULL by accident. This problem seems awfully similar to ACT bug EA23-003. Note that in Ada.Containers.Hashed_Maps.Insert.New_Node there is return new Node_Type'(Key = Key, Element = , Next= Next); If I get rid of the then the problem goes away. $ gnatmake -gnat05 p gcc -c -gnat05 p.adb gnatbind -x p.ali gnatlink p.ali $ valgrind --tool=memcheck ./p ... ==25467== Conditional jump or move depends on uninitialised value(s) ==25467==at 0x804AA2F: _ada_p (in /home/duncan/Programming/Bugs/bug_103/p) ==25467==by 0x80497F6: main (in /home/duncan/Programming/Bugs/bug_103/p) Testcase: --chop here-- with Ada.Containers.Hashed_Maps; procedure P is function H (I : Integer) return Ada.Containers.Hash_Type is begin return Ada.Containers.Hash_Type'Mod (I); end; type Item_Pointer is access Boolean; package M is new Ada.Containers.Hashed_Maps (Integer, Item_Pointer, H, =); Z : M.Map; Position : M.Cursor; Inserted : Boolean; Item : Item_Pointer; begin M.Insert (Z, 2, Position, Inserted); -- default initialization for new item Item := M.Element (Position); if Item = null then -- Item contains a random value here Item := new Boolean; end if; end; -- Summary: Default pointer initialization not occuring - due to the use of 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-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=32234
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- 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 uninitialized variables tend to contain zero by accident. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- 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
[Bug ada/31877] Imported variables marked volatile in Ada
--- 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 opinion too) the code quality can be improved in gcc 4 with reasonable effort. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31877
[Bug ada/31877] New: Imported variables marked volatile in Ada
In this testcase, A is for some reason considered volatile, so the first write is not removed: procedure Vol is A : Integer; pragma Import (C, A); begin A := 1; A := 2; end; $ gcc -S -O2 vol.adb $ grep mov vol.s movl%esp, %ebp movl$1, a movl$2, a This is because of the following in ada/decl.c: /* Make a volatile version of this object's type if we are to make the object volatile. Note that 13.3(19) says that we should treat other types of objects as volatile as well. */ if ((Treat_As_Volatile (gnat_entity) || Is_Exported (gnat_entity) || Is_Imported (gnat_entity)) !TYPE_VOLATILE (gnu_type)) gnu_type = build_qualified_type (gnu_type, (TYPE_QUALS (gnu_type) | TYPE_QUAL_VOLATILE)); What does 13.3(19) actually say? If the Address of an object is specified, or it is imported or exported, then the implementation should not perform optimizations based on assumptions of no aliases. So it looks like volatile is a hack to get the effect of no aliasing. Surely this can be done right nowadays? -- Summary: Imported variables marked volatile in Ada 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-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
[Bug ada/31877] Imported variables marked volatile in Ada
--- 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 need that gcc cannot provide? Just to clarify a little: it's a (questionable) implementation choice, the GCC 4 aliasing machinery would now make it possible to get rid of the hack. That was my impression too, but perhaps Arnaud has a tricky example for which it doesn't suffice. Volatile really pessimizes code - so better to get rid of it if possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31877
[Bug ada/19409] ACATS c460010 - valgrind detects wrong code
--- 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 |Added Last reconfirmed|2005-01-25 20:59:21 |2007-05-02 10:14:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19409
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- 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 appreciate it if the ACT people could pass it through their regression test suite. I don't know if this interacts correctly with OMP because I don't understand OMP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- 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; and since none of the rest of tree-nested checks for it, I guess either the rest of tree-nested is wrong or it's not needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- 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. Then 'Valid can be implemented as something like: x'Valid - 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 to the identity function *after* the tree optimizers have run. One annoyance is that presumably intrinsics would be needed for all integer and float precisions, eg __builtin_nop8, __builtin_nop16, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug tree-optimization/30927] New: tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
If a nested subroutine calls another nested subroutine that follows it
lexically, then convert_all_function_calls will force the called function to
take a static chain even though it may not need one. The most trivial example
of this is a recursive nested subroutine, as in example n1.c:
void n1(void) { void a(void) { a(); } }
$ gcc -c n1.c -fdump-tree-nested
$ grep chain n1.c.*nested
a () [static-chain: CHAIN.1];
A pointless static chain has been created.
Here's an example n2.c in which the caller and callee disagree about whether a
static chain is needed or not: the caller thinks it is needed, the callee does
not.
void n2(void) {
auto void a(void);
void b(void) { a(); }
void a(void) {}
}
This might seem fairly harmless, but can become expensive when trampolines are
needlessly created. Example n3.c:
void n3(void) {
auto void a(void *);
void b(void) { a(b); }
void a(void *f) {}
}
$ gcc -c n3.c -fdump-tree-nested
$ grep trampoline n3.c.*nested
struct __builtin_trampoline * D.1631;
D.1632 = __builtin_adjust_trampoline (D.1631);
__builtin_init_trampoline (FRAME.0.b, b, FRAME.0);
In Ada, nested subroutines are widely used, and unneeded static chains are
frequently being created by gcc: I first noticed this problem while
bootstrapping the compiler with a patch that happened to print a warning in
case n2.c: the warning fired hundreds of times during the Ada build. The most
common reason for this seems to be due to the instantiation of generic packages
inside library level procedures.
--
Summary: tree-nested creates pointless static chains and
trampolines when the callgraph is non-trivial
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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. TYPE_MIN_VALUE and/or TYPE_MAX_VALUE different from what you'd get from TYPE_PRECISION and the signedness. Adding some kind of attribute to C so that you can create similar types there would be helpful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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 then if Target_First = Target_Type'First then raise Constraint_Error; end if; Target_Last := Target_Type'Pred (Target_First); return; Yes. Amazing, isn't it ;) The important thing to keep in mind is that all target variables must be in the range 10..20, and all source variables in the range 0..100 (see the definitions type S is range 0 .. 100; -- S corresponds to Source_Type in Join_Equal type T is range 10 .. 20; -- T corresponds to Target_Type in Join_Equal ). What does must be in the range mean? Firstly, the program behaviour is undefined if a variable is outside its range. This is the same as for signed overflow. It's just that here overflow starts at 100 or at 20, not at INT_MAX! Secondly, the language requires the compiler to check at the point of the call that the values passed to the Join_Equal subprogram are in the right ranges. If not, an exception is raised. Likewise, at points where you do arithmetic like adding or subtracting 1, the compiler inserts checks that the result will not go out of range. If not, an exception is raised. That's where all this code is coming from. Anyway, the practical upshot is that VRP is allowed to assume that source_first and source_last have values in the range 0..100, and target_first and target_last have values in the range 10..20. Using this, it should be able to eliminate all of the compiler inserted range checking. ? So in essence VRP should somehow be able to see that Target_Type'Pred (Target_First) cannot be out of bounds because Target_First is not Target_Type'First, correct? Exactly. But given the gimplified form above we also need to prove Target_First is not 128 (where does that come from? It cannot be 128 because it is in the range 10..20. As to why the compiler inserted 128, good question! Probably it has placed target in an unsigned variable with 8-bit precision, and is checking that some computation it is about to do in that variable will not overflow. It looks like __gnat_rcheck_12 is not a noreturn function?). It is a noreturn function. It just raises a language defined exception. We also need to prove that (js__TtB) Target_First is 10 (that looks doable from the != 10 range we can extract from the first range check). But where does the check against 21 come from? It seems to be another pointless check the compiler has inserted. It can be removed because iftmp.4 is in the range 11..20. The 2nd check for 128 looks redundant and indeed we remove it in VRP1. Yes. I need to look closer at what js__TtB actually is looking like, but this is at least a useful testcase. Probably this is the base type for the type js__T (aka JS.T) in the original source. The idea of a base type is that that's the type that has the full range you would expect from the precision. Most likely type T, with range 10..20, has been assigned 8 bit precision by the compiler, and has a base type js__TtB with range -128..127, i.e. a normal C signed byte. The compiler systematically converts to the base type before doing arithmetic. After the arithmetic, it checks whether the result is in the range of the original type (10..20). If not, it raises an exception (__gnat_rcheck_12), and otherwise it it put the result back in the type T variable. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|26797 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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. That is quite a different issue. Eliminating the checks in this example is perfectly valid and useful. I certainly hope that you are not planning to turn off VRP permanently, since it is particularly important for Ada. I can understand that you have to be careful with validity checks (which is what VIEW_CONVERT_EXPR is for) but that's orthogonal to this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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 change, and the relationship between 26797 and 30911 that you'd set up still seemed to be there. So I guess bugzilla is too subtle for me... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] New: VRP fails to eliminate range checks in Ada code
All of the range checks can in theory be eliminated, except for the first one (a call to __gnat_rcheck_04, unlike the others which are calls to __gnat_rcheck_04), but they are not: $ gcc -c -O2 -fdump-tree-all j.ads $ grep __gnat_rcheck_12 j.ads.118t.final_cleanup __gnat_rcheck_12 (join_equal.adb, 14); __gnat_rcheck_12 (join_equal.adb, 14); __gnat_rcheck_12 (join_equal.adb, 29); __gnat_rcheck_12 (join_equal.adb, 29); __gnat_rcheck_12 (join_equal.adb, 39); __gnat_rcheck_12 (join_equal.adb, 39); -- Summary: VRP fails to eliminate range checks in Ada code 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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, Equal = JS.E, Target_Type = JS.T, Move= JS.M ); package JS is type S is range 0 .. 100; type T is range 10 .. 20; function E (L, R : S) return Boolean; procedure M ( First, Last : S; Destination : T ); end JS; generic type Source_Type is (); with function Equal (Left, Right : Source_Type) return Boolean; type Target_Type is (); with procedure Move ( First, Last : Source_Type; Destination : Target_Type ); procedure Join_Equal ( Source_First : in Source_Type; Source_Last : in out Source_Type; -- returns last read Target_First : in Target_Type; Target_Last :out Target_Type -- returns last written ); pragma Pure (Join_Equal); procedure Join_Equal ( Source_First : in Source_Type; Source_Last : in out Source_Type; Target_First : in Target_Type; Target_Last :out Target_Type ) is Source : Source_Type := Source_First; Target : Target_Type := Target_First; begin if Source_Last Source_First then if Target_First = Target_Type'First then raise Constraint_Error; end if; Target_Last := Target_Type'Pred (Target_First); return; end if; loop declare Start : constant Source_Type := Source; Prev : Source_Type := Source; begin loop if Source = Source_Last then Move (Start, Source, Target); Target_Last := Target; return; end if; Source := Source_Type'Succ (Source); exit when not Equal (Prev, Source); Prev := Source; end loop; Move (Start, Prev, Target); if Target = Target_Type'Last then Source_Last := Prev; Target_Last := Target; return; end if; Target := Target_Type'Succ (Target); end; end loop; end Join_Equal; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug ada/19219] ICE on legal (?) code: deriving from tagged type with unknown discriminants
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19219
[Bug middle-end/19410] Overlapping memcpy with big struct copies
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410
[Bug ada/19413] ACATS c761010 - valgrind detects wrong code (Conditional jump or move depends on uninitialised value)
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19413
[Bug ada/19415] ACATS c953001 - valgrind detects wrong code (invalid read)
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19415
[Bug ada/30036] ICE using interfaces: Assert_Failure sem_util.adb:1033
--- 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: $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr/gnat-fsf --enable-languages=all,ada --enable-threads=posix Thread model: posix gcc version 4.3.0 20061128 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30036
[Bug ada/19416] ACATS cxa9001, cxa9002 - valgrind detects wrong code (unitialized data passed to syscall)
--- 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 = 'X'); end record; but only 13 of the bytes are used. The 3 trailing bytes are not initialized. This seems to be GNAT policy. The uninitialized bytes are written to the file when Unit_Type is. Valgrind complains about this, and indeed it is a security leak. However I don't think it can be described as a compiler bug. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19416
[Bug ada/30036] New: ICE using interfaces: Assert_Failure sem_util.adb:1033
$ gcc -c e.ads +===GNAT BUG DETECTED==+ | 4.3.0 20061128 (experimental) (i686-pc-linux-gnu) Assert_Failure sem_util.adb:1033| | Error detected at d.ads:3:9 [e.ads:3:1] | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. e.ads c.ads b.ads d.ads compilation abandoned -- chop here -- package B is type I is interface; procedure P (X : I) is abstract; end; with B; package C is type J is new B.I with private; overriding procedure P (X : J); private type J is new B.I with null record; end; with C; generic type G is new C.J with private; package D is type H is new G with null record; end; with C; with D; package E is new D (C.J); -- Summary: ICE using interfaces: Assert_Failure 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-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=30036
[Bug tree-optimization/23744] VRP does not merge discontinuous ranges of PHIs
--- 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 (vrp_meet): do not require ranges to intersect. * testsuite/gcc.dg/tree-ssa/pr23744.c: new test. * testsuite/gcc.dg/tree-ssa/update-threading.c: xfail. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23744.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/update-threading.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23744
