Re: Reporting lto bugs
On Fri, Sep 24, 2021 at 3:45 AM Eugene Rozenfeld via Gcc wrote: > > I ran into a bug with lto: no line number info gets emitted when building my > project with -flto and -g (with gcc 8.2). I'd like to provide a repro in the > bug report but I don't know if there is an easy way to collect everything. > The instructions at https://gcc.gnu.org/bugs/ seem to cover non-lto > compilations. > For MSVC there is an easy way to collect linker repro files for ltcg: > https://docs.microsoft.com/en-us/cpp/overview/how-to-report-a-problem-with-the-visual-cpp-toolset?view=msvc-160#link-repros > Is there something similar for GCC? We generally prefer preprocessed sources here as with other bugs - for LTO that might mean including quite a bunch of files but there's instructions on the wiki on how to reduce LTO testcases: https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs Note that for mingw and cygwin you likely run into the issue that LTO does not support -g there (sic), see a similar issue for darwin (PR82005), there must be a bug for mingw/cygwin as well but I can't find it right now. Richard. > Thanks, > > Eugene
Can gcc.dg/torture/pr67828.c be an infinite loop?
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0; c++)
{
BODY:
a = d;
d = 0;
if (b)
{
xprintf (0);
if (j)
xprintf (0);
}
}
xprintf (d);
exit (0);
}
On the false edge out of if(b) we thread directly to BODY, eliding the
loop conditional, because we know that c>=0 because it could never overflow.
Since B is globally initialized to 0, this has the effect of turning the
test into an infinite loop.
Is this correct, or did I miss something?
Aldy
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On Fri, Sep 24, 2021 at 10:04 AM Aldy Hernandez via Gcc wrote:
>
> Hi folks.
>
> My upcoming threading improvements turn the test below into an infinite
> runtime loop:
>
> int a, b;
> short c;
>
> int
> main ()
> {
>int j, d = 1;
>for (; c >= 0; c++)
> {
> BODY:
>a = d;
>d = 0;
>if (b)
> {
> xprintf (0);
> if (j)
> xprintf (0);
> }
> }
>xprintf (d);
>exit (0);
> }
>
> On the false edge out of if(b) we thread directly to BODY, eliding the
> loop conditional, because we know that c>=0 because it could never overflow.
>
> Since B is globally initialized to 0, this has the effect of turning the
> test into an infinite loop.
>
> Is this correct, or did I miss something?
Yes, 'c' will wrap to negative SHORT_MIN and terminate the loop via
the c>=0 test.
Mind c++ is really (short)(((int)c)++) and signed integer truncation
is implementation
defined.
Richard.
> Aldy
>
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On 9/24/21 10:08 AM, Richard Biener wrote:
On Fri, Sep 24, 2021 at 10:04 AM Aldy Hernandez via Gcc wrote:
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0; c++)
{
BODY:
a = d;
d = 0;
if (b)
{
xprintf (0);
if (j)
xprintf (0);
}
}
xprintf (d);
exit (0);
}
On the false edge out of if(b) we thread directly to BODY, eliding the
loop conditional, because we know that c>=0 because it could never overflow.
Since B is globally initialized to 0, this has the effect of turning the
test into an infinite loop.
Is this correct, or did I miss something?
Yes, 'c' will wrap to negative SHORT_MIN and terminate the loop via
the c>=0 test.
Huh, so SHORT_MAX + 1 = SHORT_MIN? I thought that was an overflow, and
therefore undefined.
Aldy
Mind c++ is really (short)(((int)c)++) and signed integer truncation
is implementation
defined.
Richard.
Aldy
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc wrote:
>
> Hi folks.
>
> My upcoming threading improvements turn the test below into an infinite
> runtime loop:
>
> int a, b;
> short c;
>
> int
> main ()
> {
>int j, d = 1;
>for (; c >= 0; c++)
> {
> BODY:
>a = d;
>d = 0;
>if (b)
> {
> xprintf (0);
> if (j)
> xprintf (0);
> }
> }
>xprintf (d);
>exit (0);
> }
>
> On the false edge out of if(b) we thread directly to BODY, eliding the
> loop conditional, because we know that c>=0 because it could never overflow.
Huh about c>=0 being always true? the expression, "c++" is really c=
(short)(((int)c)+1). So it will definitely wrap over when c is
SHRT_MAX.
Thanks,
Andrew Pinski
>
> Since B is globally initialized to 0, this has the effect of turning the
> test into an infinite loop.
>
> Is this correct, or did I miss something?
> Aldy
>
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On 9/24/21 11:29 AM, Andrew Pinski wrote:
On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc wrote:
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0; c++)
{
BODY:
a = d;
d = 0;
if (b)
{
xprintf (0);
if (j)
xprintf (0);
}
}
xprintf (d);
exit (0);
}
On the false edge out of if(b) we thread directly to BODY, eliding the
loop conditional, because we know that c>=0 because it could never overflow.
Huh about c>=0 being always true? the expression, "c++" is really c=
(short)(((int)c)+1). So it will definitely wrap over when c is
SHRT_MAX.
I see.
Is this only for C++ or does it affect C as well?
Aldy
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On Fri, Sep 24, 2021 at 2:35 AM Aldy Hernandez wrote:
>
>
>
> On 9/24/21 11:29 AM, Andrew Pinski wrote:
> > On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc
> > wrote:
> >>
> >> Hi folks.
> >>
> >> My upcoming threading improvements turn the test below into an infinite
> >> runtime loop:
> >>
> >> int a, b;
> >> short c;
> >>
> >> int
> >> main ()
> >> {
> >> int j, d = 1;
> >> for (; c >= 0; c++)
> >> {
> >> BODY:
> >> a = d;
> >> d = 0;
> >> if (b)
> >> {
> >>xprintf (0);
> >>if (j)
> >> xprintf (0);
> >> }
> >> }
> >> xprintf (d);
> >> exit (0);
> >> }
> >>
> >> On the false edge out of if(b) we thread directly to BODY, eliding the
> >> loop conditional, because we know that c>=0 because it could never
> >> overflow.
> >
> > Huh about c>=0 being always true? the expression, "c++" is really c=
> > (short)(((int)c)+1). So it will definitely wrap over when c is
> > SHRT_MAX.
>
> I see.
>
> Is this only for C++ or does it affect C as well?
This is standard C code; promotion rules; that is if a type is less
than int, it will be promoted to int if all of the values fit into
int; otherwise it will be promoted to unsigned int.
Thanks,
Andrew Pinski
>
> Aldy
>
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On 9/24/21 11:38 AM, Andrew Pinski wrote:
On Fri, Sep 24, 2021 at 2:35 AM Aldy Hernandez wrote:
On 9/24/21 11:29 AM, Andrew Pinski wrote:
On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc wrote:
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0; c++)
{
BODY:
a = d;
d = 0;
if (b)
{
xprintf (0);
if (j)
xprintf (0);
}
}
xprintf (d);
exit (0);
}
On the false edge out of if(b) we thread directly to BODY, eliding the
loop conditional, because we know that c>=0 because it could never overflow.
Huh about c>=0 being always true? the expression, "c++" is really c=
(short)(((int)c)+1). So it will definitely wrap over when c is
SHRT_MAX.
I see.
Is this only for C++ or does it affect C as well?
This is standard C code; promotion rules; that is if a type is less
than int, it will be promoted to int if all of the values fit into
int; otherwise it will be promoted to unsigned int.
Well, *that* was embarrassing.
Thanks, and sorry for the noise.
Aldy
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On 24/09/2021 10:29, Andrew Pinski via Gcc wrote:
On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc wrote:
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0; c++)
{
BODY:
a = d;
d = 0;
if (b)
{
xprintf (0);
if (j)
xprintf (0);
}
}
xprintf (d);
exit (0);
}
On the false edge out of if(b) we thread directly to BODY, eliding the
loop conditional, because we know that c>=0 because it could never overflow.
Huh about c>=0 being always true? the expression, "c++" is really c=
(short)(((int)c)+1). So it will definitely wrap over when c is
SHRT_MAX.
Except when sizeof(short) == sizeof (int), at which point the 'int'
expression will overflow and we get UB again.
R.
Thanks,
Andrew Pinski
Since B is globally initialized to 0, this has the effect of turning the
test into an infinite loop.
Is this correct, or did I miss something?
Aldy
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On 24/09/2021 10:59, Aldy Hernandez via Gcc wrote: > > > On 9/24/21 10:08 AM, Richard Biener wrote: >> On Fri, Sep 24, 2021 at 10:04 AM Aldy Hernandez via Gcc >> wrote: >>> >>> Is this correct, or did I miss something? >> >> Yes, 'c' will wrap to negative SHORT_MIN and terminate the loop via >> the c>=0 test. > > Huh, so SHORT_MAX + 1 = SHORT_MIN? I thought that was an overflow, and > therefore undefined. > C and C++ don't do arithmetic on "short" (or "char"). They are immediately promoted to "int" (or "unsigned int", as appropriate). So if short is smaller than int, the code behaviour is well defined (as Richard described below). If short is the same size as int (such as on the 16-bit mspgcc port of gcc), however, then SHORT_MAX + 1 /would/ be an overflow and the compiler can assume it does not happen - thus giving you an infinite loop. With more common 32-bit int and 16-bit short, the loop should execute 32768 times. (At least, that is my understanding.) > >> >> Mind c++ is really (short)(((int)c)++) and signed integer truncation >> is implementation >> defined. >> >> Richard. >> >>> Aldy >>> >> > >
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On 24/09/2021 11:38, Andrew Pinski via Gcc wrote: > On Fri, Sep 24, 2021 at 2:35 AM Aldy Hernandez wrote: >> >> >> >> On 9/24/21 11:29 AM, Andrew Pinski wrote: >>> On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc >>> wrote: >>> Huh about c>=0 being always true? the expression, "c++" is really c= >>> (short)(((int)c)+1). So it will definitely wrap over when c is >>> SHRT_MAX. >> >> I see. >> >> Is this only for C++ or does it affect C as well? > > This is standard C code; promotion rules; that is if a type is less > than int, it will be promoted to int if all of the values fit into > int; otherwise it will be promoted to unsigned int. > But remember that for some gcc targets (msp430, AVR, and others), int is 16-bit and the same size as short. The short still gets promoted to int, but it will not longer wrap as SHORT_MAX + 1 is an int overflow. (I've no idea if this is relevant to the code in question, or if that code is only used on specific targets where short is smaller than int.)
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On 24/09/2021 10:03, Aldy Hernandez via Gcc wrote:
> Hi folks.
>
> My upcoming threading improvements turn the test below into an infinite
> runtime loop:
>
> int a, b;
> short c;
>
> int
> main ()
> {
> int j, d = 1;
> for (; c >= 0; c++)
> {
> BODY:
> a = d;
> d = 0;
> if (b)
> {
> xprintf (0);
> if (j)
> xprintf (0);
> }
> }
> xprintf (d);
> exit (0);
> }
>
> On the false edge out of if(b) we thread directly to BODY, eliding the
> loop conditional, because we know that c>=0 because it could never
> overflow.
>
> Since B is globally initialized to 0, this has the effect of turning the
> test into an infinite loop.
>
> Is this correct, or did I miss something?
> Aldy
>
>
I am wondering about the claim that you can use "b" being 0 to optimise
the conditional. If the compiler knows that this is the complete
program, that is fair enough. But since "b" is not static, another
compilation unit could modify "b" before "main" is called. (In C, it is
legal for another part of the code to call main() - perhaps the
implementation of xprintf does so. And in C++, a global constructor
could change "b" before main() starts.)
mvh.,
David
Re: Can gcc.dg/torture/pr67828.c be an infinite loop?
On 9/24/21 1:37 PM, David Brown wrote:
On 24/09/2021 10:03, Aldy Hernandez via Gcc wrote:
Hi folks.
My upcoming threading improvements turn the test below into an infinite
runtime loop:
int a, b;
short c;
int
main ()
{
int j, d = 1;
for (; c >= 0; c++)
{
BODY:
a = d;
d = 0;
if (b)
{
xprintf (0);
if (j)
xprintf (0);
}
}
xprintf (d);
exit (0);
}
On the false edge out of if(b) we thread directly to BODY, eliding the
loop conditional, because we know that c>=0 because it could never
overflow.
Since B is globally initialized to 0, this has the effect of turning the
test into an infinite loop.
Is this correct, or did I miss something?
Aldy
I am wondering about the claim that you can use "b" being 0 to optimise
the conditional. If the compiler knows that this is the complete
program, that is fair enough. But since "b" is not static, another
compilation unit could modify "b" before "main" is called. (In C, it is
legal for another part of the code to call main() - perhaps the
implementation of xprintf does so. And in C++, a global constructor
could change "b" before main() starts.)
In this case, it was on a thread where we knew we came through the c>=0
conditional and we hadn't left the function.
Be that as it may, this was something else entirely. The problem was a
typo in the path solver that was causing it to use an incorrect range,
which was then causing the elision. It had nothing to do with promotion
rules. My bad.
Aldy
Re: Development request
Hello, On Sun, Sep 19 2021, Mohamed Atef via Gcc wrote: > Hello there, > We are 6 students from Egypt and now We are in our last year and We need to > build a project as a graduation project. > And We are interested in the area of runtime systems, operating systems and > compilers. > We are going to work 40-60 hrs a week > Can We help in some tool you need as a graduation project given that We > have a professor to mentor us. > If not can you suggest some tool you need to build and We will work on it. > The project take one academic year > GNU tools miss an implementation of OMPD, an interface for third-party tools to examine and debug programs using OpenMP API for multiprocessing. For complete formal description see chapter 5 (and other relevant bits) in https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5-1.pdf The project would be a larger one and from the more difficult kind, but 6 students interested in the areas you described should be well able to complete it within a year and even enjoy it. I believe most of the work is needed within libgomp run-time library supporting OpenMP programs, but everything in this area is very closely related to both core operating system primitives, compilers and debuggers. Feel free to ask for more information on the gcc mailing list if you are interested. Good luck with your project, Martin
gcc-10-20210924 is now available
Snapshot gcc-10-20210924 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20210924/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision d74bca30a21196b55f3d443a4722347c78213bf8 You'll find: gcc-10-20210924.tar.xz Complete GCC SHA256=fa2b7f3343c1eb0bc510fc5e87a388185bf492fb68f4c0e72ffbecf675ad58b4 SHA1=6b4344044af23ad4da4712708caf2b8ed3a1f950 Diffs from 10-20210917 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 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: [EXTERNAL] Re: Reporting lto bugs
My scenario is not cygwin. It's linux cross-compile x86_64 to aarch64 in an Ubuntu vm so I believe this should produce line info with -flto -g yet I see "No Line Number Statements" after Directory Table and File Name Table in the output of objdump -g. DWARF Version is 4. I verified that I get line numbers if I don't specify -flto. I have all the lto1 commands and I'd like to try to debug this myself first. Do you have any tips on how to debug this? Thanks, Eugene -Original Message- From: Richard Biener Sent: Friday, September 24, 2021 12:36 AM To: Eugene Rozenfeld Cc: gcc@gcc.gnu.org Subject: [EXTERNAL] Re: Reporting lto bugs On Fri, Sep 24, 2021 at 3:45 AM Eugene Rozenfeld via Gcc wrote: > > I ran into a bug with lto: no line number info gets emitted when building my > project with -flto and -g (with gcc 8.2). I'd like to provide a repro in the > bug report but I don't know if there is an easy way to collect everything. > The instructions at > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugs%2F&data=04%7C01%7CEugene.Rozenfeld%40microsoft.com%7Cb7b3ef43536943c30e3108d97f2df355%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637680657602091864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yGG5QtNDKjD0z4Q%2FcNmuwx5CZV8cElqGetmfmYzAwjA%3D&reserved=0 > seem to cover non-lto compilations. > For MSVC there is an easy way to collect linker repro files for ltcg: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > .microsoft.com%2Fen-us%2Fcpp%2Foverview%2Fhow-to-report-a-problem-with > -the-visual-cpp-toolset%3Fview%3Dmsvc-160%23link-repros&data=04%7C > 01%7CEugene.Rozenfeld%40microsoft.com%7Cb7b3ef43536943c30e3108d97f2df3 > 55%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637680657602101859%7CU > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLCJXVCI6Mn0%3D%7C1000&sdata=WhtAKrM1LoveH1Jbi3Ulhrp7hUdXJ46hgh1 > osT%2BB1nc%3D&reserved=0 > Is there something similar for GCC? We generally prefer preprocessed sources here as with other bugs - for LTO that might mean including quite a bunch of files but there's instructions on the wiki on how to reduce LTO testcases: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fwiki%2FA_guide_to_testcase_reduction%23Reducing_LTO_bugs&data=04%7C01%7CEugene.Rozenfeld%40microsoft.com%7Cb7b3ef43536943c30e3108d97f2df355%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637680657602101859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GExhyUNJvSQgMPrSGccVj8woBTLahYVAjI%2FBvQ79QMo%3D&reserved=0 Note that for mingw and cygwin you likely run into the issue that LTO does not support -g there (sic), see a similar issue for darwin (PR82005), there must be a bug for mingw/cygwin as well but I can't find it right now. Richard. > Thanks, > > Eugene
