Re: Automatically generated ChangeLog files - script
Hello Martin, First, thank you for your work on this new ChangeLog workflow. :-) I’d like to report a “regression”: I can’t push the attached patch: remote: *** ChangeLog format failed: remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_ch4.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_ch7.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_ch8.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_elab.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_type.adb" remote: ERR: changed file not mentioned in a ChangeLog:"gcc/ada/sem_util.adb" remote: remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs remote: remote: error: hook declined to update refs/heads/master It looks like the hook does not accept multi-line ChangeLog entries affecting multiple files: * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb, sem_ch4.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb, sem_type.adb, sem_util.adb: Reuse Is_Package_Or_Generic_Package where possible (similarly, reuse Is_Concurrent_Type if it was possible in the same expressions). Would it be possible to enhance the hook to support that? Thanks! -- Pierre-Marie de Rodat >From 557b268fdeb0980a17411f458eee333f55c6 Mon Sep 17 00:00:00 2001 From: Piotr Trojanek Date: Thu, 12 Dec 2019 11:45:24 +0100 Subject: [PATCH] [Ada] Reuse Is_Package_Or_Generic_Package where possible 2020-05-26 Piotr Trojanek gcc/ada/ * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb, sem_ch4.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb, sem_type.adb, sem_util.adb: Reuse Is_Package_Or_Generic_Package where possible (similarly, reuse Is_Concurrent_Type if it was possible in the same expressions). --- gcc/ada/contracts.adb | 2 +- gcc/ada/einfo.adb | 22 +++--- gcc/ada/exp_ch9.adb | 2 +- gcc/ada/sem_ch12.adb | 2 +- gcc/ada/sem_ch4.adb | 2 +- gcc/ada/sem_ch7.adb | 6 +++--- gcc/ada/sem_ch8.adb | 6 +++--- gcc/ada/sem_elab.adb | 2 +- gcc/ada/sem_type.adb | 2 +- gcc/ada/sem_util.adb | 6 +++--- 10 files changed, 26 insertions(+), 26 deletions(-) diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb index 981bb91..d58f136 100644 --- a/gcc/ada/contracts.adb +++ b/gcc/ada/contracts.adb @@ -213,7 +213,7 @@ package body Contracts is --Initializes --Part_Of (instantiation only) - elsif Ekind_In (Id, E_Generic_Package, E_Package) then + elsif Is_Package_Or_Generic_Package (Id) then if Nam_In (Prag_Nam, Name_Abstract_State, Name_Initial_Condition, Name_Initializes) diff --git a/gcc/ada/einfo.adb b/gcc/ada/einfo.adb index 98b508f..1df8ed0 100644 --- a/gcc/ada/einfo.adb +++ b/gcc/ada/einfo.adb @@ -713,7 +713,7 @@ package body Einfo is function Abstract_States (Id : E) return L is begin - pragma Assert (Ekind_In (Id, E_Generic_Package, E_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); return Elist25 (Id); end Abstract_States; @@ -837,7 +837,7 @@ package body Einfo is function Body_Entity (Id : E) return E is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); return Node19 (Id); end Body_Entity; @@ -1424,8 +1424,8 @@ package body Einfo is function First_Private_Entity (Id : E) return E is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package) - or else Ekind (Id) in Concurrent_Kind); + pragma Assert (Is_Package_Or_Generic_Package (Id) + or else Is_Concurrent_Type (Id)); return Node16 (Id); end First_Private_Entity; @@ -3044,7 +3044,7 @@ package body Einfo is function Package_Instantiation (Id : E) return N is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); return Node26 (Id); end Package_Instantiation; @@ -3883,7 +3883,7 @@ package body Einfo is procedure Set_Abstract_States (Id : E; V : L) is begin - pragma Assert (Ekind_In (Id, E_Generic_Package, E_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); Set_Elist25 (Id, V); end Set_Abstract_States; @@ -4006,7 +4006,7 @@ package body Einfo is procedure Set_Body_Entity (Id : E; V : E) is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package)); + pragma Assert (Is_Package_Or_Generic_Package (Id)); Set_Node19 (Id, V); end Set_Body_Entity; @@ -4593,8 +4593,8 @@ package body Einfo is procedure Set_First_Private_Entity (Id : E; V : E) is begin - pragma Assert (Ekind_In (Id, E_Package, E_Generic_Package
Re: Automatically generated ChangeLog files - script
On 26/05/2020 15:09, Martin Liška wrote: I see, but as mentioned it makes the parsing of the list files much more complicated. Feel free to provide a patch that will support multi-line entries. Thanks! As long as there is no objection to support this, I have no problem giving it a try. :-) I just sent two patches on gcc-patches@. By the way, is there a delay between the time the gcc-changelog scripts are updated and the time they are used in pre-commit hooks? -- Pierre-Marie de Rodat
Uninitialized registers handling in the REE pass
Hello,
The attached reproducer[1] seems to trigger a code generation issue at
least on x86_64-linux:
$ gnatmake -q p -O3 -gnatn
$ ./p
raised PROGRAM_ERROR : p.adb:9 explicit raise
The bottom line is that when Success is False in Q.Get (q.adb, around
line 40) its value is clobbered during return. If we build with
-fno-ree, we can see in the assembly code (near the return point for
q__get) the following sequence:
movzwl (%rax), %epb
...
somelabel:
...
movzwl %bp, %ebp
...
salq$16, %rax
orq %rbp, %rax
However, without the -fno-ree switch the instruction:
movzwl %bp, %ebp
is merged with its definition (the first movzwl instruction) by the REE
pass. This is wrong since the definition does _not_ dominate this
zero-extension: the first movzwl instruction can be by-passed through
"somelabel".
I started to investigate this issue: the REE pass is currently not aware
of this by-pass code path because it is reached by no proper definition
(it brings an uninitialized %rbp register to the zero-extension). This
happens in ree.c:get_defs; in our case (insn=second movzwl, reg=BP)
DF_REF_CHAIN contains only one definition: the movzwl instruction.
Given the "somelabel" code path, I would rather expect DF_REF_CHAIN to
hold a NULL reference to materialize the lack of initialization in one
path. I found the DF_LR_IN/DF_LR_OUT macros from df.h: they provide
information about uninitialized variables but the associated comment
says they should not be used ("This intolerance should eventually be
fixed."). Besides, they provide a basic-block-level information whereas
we are rather interested in instruction-level information in REE.
I was thinking that REE may not be the only optimization pass needing
this kind of information but I found no other one, so I'm not sure how
this ought to be handled. Can anybody confirm my intuition about the
NULL reference in DF_REF_CHAIN? I'm willing to implement it but I prefer
first to be sure this is the right approach.
Thanks in advance!
[1] It's in Ada. I tried to translate it into C but any change in
register allocation makes the issue disappear...
--
Pierre-Marie de Rodat
with Q; use Q;
procedure P is
B : Boolean;
E : Enum;
begin
Get ("four", E, B);
if B = True then
raise Program_Error;
end if;
Get ("three", E, B);
if B = False then
raise Program_Error;
end if;
declare
A : Enum_Boolean_Array (One .. E) := (others => True);
begin
Set (A);
end;
end;
with Ada.Characters.Handling;
with Ada.Containers;
with Ada.Containers.Indefinite_Hashed_Maps;
with Ada.Strings.Hash;
package body Q is
type Enum_Name is array (Enum) of access constant String;
Enum_Name_Table : constant Enum_Name := (
One => new String'("one"),
Two => new String'("two"),
Three => new String'("three"));
package String_To_Enum_Map is new Ada.Containers.Indefinite_Hashed_Maps
(Key_Type => String, Element_Type => Enum,
Hash => Ada.Strings.Hash, Equivalent_Keys => "=");
function Fill_Hashed_Map return String_To_Enum_Map.Map is
Res : String_To_Enum_Map.Map;
use String_To_Enum_Map;
begin
for I in Enum_Name_Table'Range loop
declare
Kind : constant String := Enum_Name_Table (I).all;
begin
Res.Insert(Key => Kind, New_Item => I);
end;
end loop;
return Res;
end;
String_To_Enum : constant String_To_Enum_Map.Map := Fill_Hashed_Map;
procedure Get (Kind : String; Result : out Enum; Success : out Boolean) is
X : constant String := Ada.Characters.Handling.To_Lower (Kind);
use String_To_Enum_Map;
Curs : constant Cursor := String_To_Enum.Find (X);
begin
Success := Curs /= No_Element;
if Success then
Result := Element(Curs);
end if;
end;
procedure Set (A : Enum_Boolean_Array) is null;
end Q;
package Q is
type Enum is (One, Two, Three);
for Enum'Size use 16;
type Enum_Boolean_Array is array (Enum range <>) of Boolean;
procedure Get (Kind : String; Result : out Enum; Success : out Boolean);
procedure Set (A : Enum_Boolean_Array);
end Q;
Re: Uninitialized registers handling in the REE pass
On 07/07/2015 05:02 PM, Jeff Law wrote: Can you please file this as a bug in bugzilla so that can get tracked? http://gcc.gnu.org/bugzilla Sure, it's there: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790>. -- Pierre-Marie de Rodat
Re: GCC 6 Status Report (2015-10-16)
Hi Richard, On 10/16/2015 05:09 AM, Richard Biener wrote: This means it is time to get things you want to have in GCC 6 finalized and reviewed. As usual there may be exceptions to late reviewed features but don't count on that. Likewise target specific features can sneak in during Stage 3 if maintainers ok them. This is just to point out I have series of DWARF-related patches awaiting reviews for several months. I plan to rebase against trunk, retest and resubmit them shortly but here’s an overview: * The patch series for transition to standard DWARF for Ada (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01857.html). There are 8 patches, each one depending on the previous one, except the 6/8 one (https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01361.html) which could go on its own. * Fix DW_AT_static_link generation in DWARF (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01855.html). The corresponding support in GDB is in the development branch. * Track indirect calls as call site information in DWARF (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01856.html). * Materialize subprogram renamings in Ada as imported declarations in DWARF (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01854.html). The corresponding support in GDB is in the development branch. If there is anything I should do to ease the review process, please let me know. :-) Thank you in advance! -- Pierre-Marie de Rodat
Re: GCC 6 Status Report (2015-10-16)
On 10/20/2015 12:01 PM, Jeff Law wrote: * The patch series for transition to standard DWARF for Ada (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01857.html). There are 8 patches, each one depending on the previous one, except the 6/8 one (https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01361.html) which could go on its own. * Track indirect calls as call site information in DWARF (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01856.html). I've been leaving all that stuff to Jason & Jakub. My knowledge of dwarf, both the specs and our implementation is so limited that my review would be worthless. Thank you for your quick answer! Regarding the long standard DWARF patch series, Jakup told me in July that he would not have time to review dwarf2out patches and advised me to ping Jason and Cary instead (which I did since then ;-)). On the indirect calls tracking side (affecting both dwarf2out and var-tracking), Richard told me in August that he’s not the correct person to ping for dwarf2out patches, so I did ping you for the var-tracking part and Jason for the dwarf2out part afterwards. -- Pierre-Marie de Rodat
Trouble trying to test GCC on a simulator
Hello, I would like to test a GCC patch on the platform it is supposed to affect (PowerPC). In order to to this, I'm using the following documentation: https://gcc.gnu.org/simtest-howto.html However, after fresh CVS checkouts (even without my changes on the GCC tree) and the corresponding combined tree creation, I cannot manage to get a build: $ ../combined/configure --prefix=$TOP/install --enable-languages=c,c++ --target=powerpc-eabisim --build=i686-pc-linux-gnu --enable-checking [runs fine] $ make [...] make[4]: Entering directory `/.../build/binutils' gcc -DHAVE_CONFIG_H -I. -I../../combined/binutils -I. -I../../combined/binutils -I../bfd -I../../combined/binutils/../bfd -I../../combined/binutils/../include -DLOCALEDIR="\"/.../install/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT bucomm.o -MD -MP -MF .deps/bucomm.Tpo -c -o bucomm.o ../../combined/binutils/bucomm.c ../../combined/binutils/bucomm.c:130:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'VPARAMS' ../../combined/binutils/bucomm.c:141:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'VPARAMS' make[4]: *** [bucomm.o] Error 1 The use of an undefined macro (VPARAMS) looks quite strange to me: is it a known issue? Or maybe is the documentation obsolete? Thanks in advance! -- Pierre-Marie de Rodat
Re: Trouble trying to test GCC on a simulator
On 09/08/2014 12:26 PM, Tristan Gingold wrote: CVS ? Binutils (and gdb) are now using git: Huh! I knew this, but not being a daily CVS user, I though the commands in the documentation would get a binutils version that was somehow tailored for GCC's needs. Anyway, here is what I just tried instead: # Get newlib and the simulator cvs -d :pserver:anon...@sourceware.org:/cvs/src co newlib sim # Get binutils git clone git://sourceware.org/git/binutils-gdb.git # Create the combined tree rm -rf combined mkdir combined cd src && find . -print | cpio -pdlm ../combined && cd .. cd binutils-gdb && find . -print | cpio -pdlmu ../combined && cd .. cd gcc && find . -print | cpio -pdlmu ../combined && cd .. # Same build/test procedure... It seems to work fine! (I'm running tests, now...) So thank you very much, Tristan. I'm going to submit a website patch to update the documentation according to this. -- Pierre-Marie de Rodat
Re: Pierre-Marie de Rodat appointed Ada co-maintainer
On 09/15/2017 07:22 PM, David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has appointed Pierre-Marie de Rodat as Ada co-maintainer. Please join me in congratulating Pierre-Marie on his new role. P-M, please update your listing in the MAINTAINERS file. Thank you for your trust! I just committed the following as r252902 and r252903: 2017-09-18 Pierre-Marie de Rodat * MAINTAINERS: Add myself as a maintainer for the Ada front end. diff --git a/ChangeLog b/ChangeLog index c58444c74ad..e4a8d0184d6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2017-09-18 Pierre-Marie de Rodat + + * MAINTAINERS: Add myself as a maintainer for the Ada front end. + 2017-09-15 Nathan Sidwell * MAINTAINERS: Remove myself as a vxworks maintainer. diff --git a/MAINTAINERS b/MAINTAINERS index 8a69787ed21..99babdc3ab7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -142,6 +142,7 @@ cygwin, mingw-w64 Jonathan Yong <10wa...@gmail.com> C front end/ISO C99Joseph Myers Ada front end Arnaud Charlet Ada front end Eric Botcazou +Ada front end Pierre-Marie de Rodat BRIG (HSAIL) front end Pekka Jääskeläinen BRIG (HSAIL) front end Martin Jambor c++Jason Merrill -- Pierre-Marie de Rodat
