Re: Performing inter-procedural dataflow analysis
Hi,
On Thu, Feb 18 2021, Shuai Wang via Gcc wrote:
> Hello,
>
> I am doing interprocedural dataflow analysis and countered the following
> issue. Suppose I have an GIMPLE IR code as follows, which is after the
> "simdclone" pass while before my own SIMPLE IPA pass:
>
>
> foo (int a, int b)
> {
> int c;
> int d;
> int D.2425;
> int _5;
>
>:
> * c_4 = a_2(D) + b_3(D); *
> * _5 = c_4;*
>
>
> As you can see, while propagating certain dataflow facts among local
> variables are smooth (e.g., from c_4 --> c_4 --> _5), I can hardly somehow
> "link" function parameter "a" (or "b") with its first local usage "a_2(D)"
> or "b_3(D)".
are you perhaps looking for function ssa_default_def (defined in tree-dfa.c)?
>
> So my question is, when traversing the GIMPLE statements and encounter SSA
> variables like "a_2(D)" or "b_3(D)", how do I know they originate from
> parameter "a" and "b"?
You check that SSA_NAME_IS_DEFAULT_DEF is true (and that their
SSA_NAME_VAR is the PARM_DECL you are after).
Martin
Re: using undeclared function returning bool results in wrong return value
* Jonathan Wakely via Gcc: > Declare your functions. Don't ignore warnings. It's actually a GCC bug that this isn't an error. However, too many configure scripts would still break if we changed the default. So either use -Werror=implicit-function-declaration or C++ for the time being. Thanks, Florian
Re: Copyright Assignment Form
Sent off list. - David On Wed, Feb 17, 2021 at 11:28 PM Akshat Agarwal via Gcc wrote: > > Hey, > I would like to contribute some patches to the gccrs project > (https://github.com/Rust-GCC/gccrs/) and I'd like to get a copyright > assignment form as per the guidelines outlined at > https://gcc.gnu.org/contribute.html. > Do let me know if there are any more steps involved. > > Thanks, > Akshat Agarwal
Re: using undeclared function returning bool results in wrong return value
On 18/02/2021 13:31, Florian Weimer via Gcc wrote: > * Jonathan Wakely via Gcc: > >> Declare your functions. Don't ignore warnings. > > It's actually a GCC bug that this isn't an error. However, too many > configure scripts would still break if we changed the default. > People have had 22 years to fix them. Implicit function declarations were a terrible idea from day 1, and banned outright in C99. It was reasonable for them to be accepted when the default C standard for gcc was "gnu90" - they should have never been acceptable in any later standards without needing an explicit flag. Since gcc 5 they have given a warning by default - surely it is time for them to be a hard error? > So either use -Werror=implicit-function-declaration or C++ for the time > being. > > Thanks, > Florian > >
Ideas for changes in GCC development
Sir, I have checked your website and I guess that we could do some changes such as 1 background colour to make website look better and attractive 2 we could add some images to indicate more clearly what we are saying to other eg arrow for directions But sir being a 1st year student i am unable to go so long can you help me in these although there are more code to look Even my exam are going to held from 20 Feb - 30 March 2021 so I am kind of busy in that so pls allow me some more time to go through Pls reply if you like any idea Thanking you DIVYANSHU JAMLOKI
GCC generates non-compliant MIPS relocation data? Obscure GNU extension?
Hi GCC folks, We were working on a decompilation project for a Nintendo 64 title and attempting to enable support for using GCC instead of the emulated IRIX compiler and we ran into a big problem with how GCC generates relocations for the MIPS target which appears to show that GCC is generating non-compliant relocation data for MIPS target. In summary: the Nintendo 64 title has a limited amount of RAM (4MB, 8MB if you add Expansion Pak, which our ROM target uses for debug reasons); in order to accomplish this, the codebase packs actors/objects into overlays which the game determines need to be loaded per room/system transition. Once loaded into RAM, the game applies the overlay's relocations generated at compile time to the code to move the data and code correctly and make sure the jumps and loads get recalculated correctly. Unfortunately.. there's a problem. Here's the function that applies the relocs to MIPS: https://github.com/zeldaret/oot/blob/master/src/code/relocation.c While enabling overlays to be recompiled with GCC instead of the IDO compiler, we have found the relocs generated did not guarantee 0x45/0x46 (Hi/lo pairs) pairs to be 1:1, and GCC would share any possible hi/lo in O2 mode. While O0 and O1 gcc overlays will work, or even Og, this is not a solution for an N64 ROM due to limited RAM and space will quickly run out since memory is so tight. While investigating why gcc will optimize relocs, we have found the following: The MIPS ABI specified at https://refspecs.linuxfoundation.org/elf/mipsabi.pdf on pages 79-80 (page 82 regarding the GP caveat) demands that hi/los be in pairs). Thus, we have found that the reloc data generated erroneously applies the relocation twice. Several LOs following a HI seems to be in a spec, but several HIs following a LO does not. This is causing issues for our relocation due to the relocs being applied incorrectly as a result of non-compliant relocation data. It turned out this reloc optimization is caused by an unmentioned, undocumented GNU extension. We have found the GNU extension was ONLY ever mentioned here: https://people.freebsd.org/~adrian/mips/20160819-mips-elf-reloc-gcc-5.3-3.diff Here is the file we compiled: https://github.com/zeldaret/oot/blob/master/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c This is the line we used to compile it: mips-linux-gnu-gcc -c -O2 -c -G 0 -nostdinc -Iinclude -Isrc -Iassets -Ibuild -I. -DNON_MATCHING=1 -DNON_EQUIVALENT=1 -DAVOID_UB=1 -mno-shared -march=vr4300 -mfix4300 -mabi=32 -mhard-float -mdivide-breaks -fno-stack-protector -fno-common -fno-zero-initialized-in-bss -mno-abicalls -fno-strict-aliasing -fno-inline-functions -fno-inline-small-functions -fno-toplevel-reorder -ffreestanding -fwrapv -Wall -Wextra -g -fno-gcse -fno-cse-follow-jumps -mno-load-store-pairs -mno-explicit-relocs -fno-peephole2 -mips3 -o build/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.o src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c To note, we have tried with and without explicit relocs and with and without peephole2 and with and without mips2/3 and it didnt make a difference: the relocs were still noncompliant per the PDF posted earlier. We need a way to turn this undocumented GNU extension off because it is causing relocs when optimized to not be processed correctly. To note, our use case is attempting to compile this repo with GCC (this file is a test case) but if you were to compile the ROM with the Heishi4 file being compiled as GCC using the above call (make any Makefile alterations to force the object to be GCC), spawn on the SPOT00 map at the start of the game and go inside the castle town area and observe the crash which takes like 60 seconds. This is ultimately what we're trying to fix which following this rabbit hole leads us to this GNU extension in a haystack hunt. Can you guys help us resolve this? v/r, Revo
Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension?
On Thu, Feb 18, 2021 at 12:15 PM Project Revolution via Gcc wrote: > > Hi GCC folks, > > We were working on a decompilation project for a Nintendo 64 title and > attempting to enable support for using GCC instead of the emulated IRIX > compiler and we ran into a big problem with how GCC generates relocations for > the MIPS target which appears to show that GCC is generating non-compliant > relocation data for MIPS target. Try compiling with -fno-section-anchors . https://gcc.gnu.org/legacy-ml/gcc-help/2009-07/msg00455.html Thanks, Andrew > > In summary: the Nintendo 64 title has a limited amount of RAM (4MB, 8MB if > you add Expansion Pak, which our ROM target uses for debug reasons); in order > to accomplish this, the codebase packs actors/objects into overlays which the > game determines need to be loaded per room/system transition. Once loaded > into RAM, the game applies the overlay's relocations generated at compile > time to the code to move the data and code correctly and make sure the jumps > and loads get recalculated correctly. > > Unfortunately.. there's a problem. Here's the function that applies the > relocs to MIPS: > https://github.com/zeldaret/oot/blob/master/src/code/relocation.c > > While enabling overlays to be recompiled with GCC instead of the IDO > compiler, we have found the relocs generated did not guarantee 0x45/0x46 > (Hi/lo pairs) pairs to be 1:1, and GCC would share any possible hi/lo in O2 > mode. While O0 and O1 gcc overlays will work, or even Og, this is not a > solution for an N64 ROM due to limited RAM and space will quickly run out > since memory is so tight. While investigating why gcc will optimize relocs, > we have found the following: > > The MIPS ABI specified at > https://refspecs.linuxfoundation.org/elf/mipsabi.pdf on pages 79-80 (page 82 > regarding the GP caveat) demands that hi/los be in pairs). Thus, we have > found that the reloc data generated erroneously applies the relocation twice. > Several LOs following a HI seems to be in a spec, but several HIs following a > LO does not. This is causing issues for our relocation due to the relocs > being applied incorrectly as a result of non-compliant relocation data. It > turned out this reloc optimization is caused by an unmentioned, undocumented > GNU extension. > > We have found the GNU extension was ONLY ever mentioned here: > https://people.freebsd.org/~adrian/mips/20160819-mips-elf-reloc-gcc-5.3-3.diff > > Here is the file we compiled: > https://github.com/zeldaret/oot/blob/master/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c > > This is the line we used to compile it: > > mips-linux-gnu-gcc -c -O2 -c -G 0 -nostdinc -Iinclude -Isrc -Iassets -Ibuild > -I. -DNON_MATCHING=1 -DNON_EQUIVALENT=1 -DAVOID_UB=1 -mno-shared > -march=vr4300 -mfix4300 -mabi=32 -mhard-float -mdivide-breaks > -fno-stack-protector -fno-common -fno-zero-initialized-in-bss -mno-abicalls > -fno-strict-aliasing -fno-inline-functions -fno-inline-small-functions > -fno-toplevel-reorder -ffreestanding -fwrapv -Wall -Wextra -g -fno-gcse > -fno-cse-follow-jumps -mno-load-store-pairs -mno-explicit-relocs > -fno-peephole2 -mips3 -o > build/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.o > src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c > > To note, we have tried with and without explicit relocs and with and without > peephole2 and with and without mips2/3 and it didnt make a difference: the > relocs were still noncompliant per the PDF posted earlier. We need a way to > turn this undocumented GNU extension off because it is causing relocs when > optimized to not be processed correctly. To note, our use case is attempting > to compile this repo with GCC (this file is a test case) but if you were to > compile the ROM with the Heishi4 file being compiled as GCC using the above > call (make any Makefile alterations to force the object to be GCC), spawn on > the SPOT00 map at the start of the game and go inside the castle town area > and observe the crash which takes like 60 seconds. This is ultimately what > we're trying to fix which following this rabbit hole leads us to this GNU > extension in a haystack hunt. Can you guys help us resolve this? > > v/r, > Revo >
gcc-8-20210218 is now available
Snapshot gcc-8-20210218 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20210218/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision b834f34600d1afd3a71aa730c0dac2dd4c4106d5 You'll find: gcc-8-20210218.tar.xzComplete GCC SHA256=b7c941bda95426a5283b4e9fbcc8f36276be60a45ff80647cdf113eddef7904d SHA1=119015bed160631bdf672e4c463e4ba4851d8874 Diffs from 8-20210211 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension?
Gentlemen: this was fixed, although it's a bit of an odd solution. We had to combine both -mno-explicit-relocs and -mno-split-addresses, even though per the MIPS compiler documentation explicit relocs supersedes the split addresses one. Neither of these options on their own work, and it appears as though they're same result individually until you enable both of these. It's really odd, but we're not questioning it since it resolved our issue. From: Andrew Pinski Sent: Thursday, February 18, 2021 3:28 PM To: Project Revolution Cc: gcc@gcc.gnu.org ; kenixwhisperw...@gmail.com Subject: Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension? On Thu, Feb 18, 2021 at 12:15 PM Project Revolution via Gcc wrote: > > Hi GCC folks, > > We were working on a decompilation project for a Nintendo 64 title and > attempting to enable support for using GCC instead of the emulated IRIX > compiler and we ran into a big problem with how GCC generates relocations for > the MIPS target which appears to show that GCC is generating non-compliant > relocation data for MIPS target. Try compiling with -fno-section-anchors . https://gcc.gnu.org/legacy-ml/gcc-help/2009-07/msg00455.html Thanks, Andrew > > In summary: the Nintendo 64 title has a limited amount of RAM (4MB, 8MB if > you add Expansion Pak, which our ROM target uses for debug reasons); in order > to accomplish this, the codebase packs actors/objects into overlays which the > game determines need to be loaded per room/system transition. Once loaded > into RAM, the game applies the overlay's relocations generated at compile > time to the code to move the data and code correctly and make sure the jumps > and loads get recalculated correctly. > > Unfortunately.. there's a problem. Here's the function that applies the > relocs to MIPS: > https://github.com/zeldaret/oot/blob/master/src/code/relocation.c > > While enabling overlays to be recompiled with GCC instead of the IDO > compiler, we have found the relocs generated did not guarantee 0x45/0x46 > (Hi/lo pairs) pairs to be 1:1, and GCC would share any possible hi/lo in O2 > mode. While O0 and O1 gcc overlays will work, or even Og, this is not a > solution for an N64 ROM due to limited RAM and space will quickly run out > since memory is so tight. While investigating why gcc will optimize relocs, > we have found the following: > > The MIPS ABI specified at > https://refspecs.linuxfoundation.org/elf/mipsabi.pdf on pages 79-80 (page 82 > regarding the GP caveat) demands that hi/los be in pairs). Thus, we have > found that the reloc data generated erroneously applies the relocation twice. > Several LOs following a HI seems to be in a spec, but several HIs following a > LO does not. This is causing issues for our relocation due to the relocs > being applied incorrectly as a result of non-compliant relocation data. It > turned out this reloc optimization is caused by an unmentioned, undocumented > GNU extension. > > We have found the GNU extension was ONLY ever mentioned here: > https://people.freebsd.org/~adrian/mips/20160819-mips-elf-reloc-gcc-5.3-3.diff > > Here is the file we compiled: > https://github.com/zeldaret/oot/blob/master/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c > > This is the line we used to compile it: > > mips-linux-gnu-gcc -c -O2 -c -G 0 -nostdinc -Iinclude -Isrc -Iassets -Ibuild > -I. -DNON_MATCHING=1 -DNON_EQUIVALENT=1 -DAVOID_UB=1 -mno-shared > -march=vr4300 -mfix4300 -mabi=32 -mhard-float -mdivide-breaks > -fno-stack-protector -fno-common -fno-zero-initialized-in-bss -mno-abicalls > -fno-strict-aliasing -fno-inline-functions -fno-inline-small-functions > -fno-toplevel-reorder -ffreestanding -fwrapv -Wall -Wextra -g -fno-gcse > -fno-cse-follow-jumps -mno-load-store-pairs -mno-explicit-relocs > -fno-peephole2 -mips3 -o > build/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.o > src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c > > To note, we have tried with and without explicit relocs and with and without > peephole2 and with and without mips2/3 and it didnt make a difference: the > relocs were still noncompliant per the PDF posted earlier. We need a way to > turn this undocumented GNU extension off because it is causing relocs when > optimized to not be processed correctly. To note, our use case is attempting > to compile this repo with GCC (this file is a test case) but if you were to > compile the ROM with the Heishi4 file being compiled as GCC using the above > call (make any Makefile alterations to force the object to be GCC), spawn on > the SPOT00 map at the start of the game and go inside the castle town area > and observe the crash which takes like 60 seconds. This is ultimately what > we're trying to fix which following this rabbit hole leads us to this GNU > extension in a haystack hunt. Can you guys help us resolve this? > > v/r, > Revo >
How to decide the what type is currently being used in tree_node?
Hello, I noticed that tree_node is implemented as a union ( https://code.woboq.org/gcc/gcc/tree-core.h.html#tree_node). However, I cannot find a way of checking whether the current tree_node is really a base or type. For instance, currently when I am using: is_gimple_constant(v) Given `v` as a tree type but NOT base type, the above statement would crash. I am thinking there should be a method like: is_tree_base(v) == false or something like this; however, I couldn't find one. Can anyone shed some lights on this? Thank you very much! best, Shuai
