Collect2 issue

[Gary Oblock via Gcc]

I'm running my new optimization (LTO with one partition)
on a SPEC17 test.

I got the mysterious message
  "collect2: error: ld returned 1 exit status"

Now, first off, with my debugging on at full tilt and it's
clear my optimization bailed out after analyzing
the code without doing anything.

Second, this is a canned test not modified by
me or anybody else for that matter so, it's
not a user error.

Finally, reading various blogs it seems that
old object files hanging around can make
collect2 to go bonkers. Therefore, I used
specmake to clean the build and it didn't
help, not that this makes any sense with one
partition.

By the way, for those of you that get upset
at the very notion of invoking LTO as one partition,
it's actually not that bad. I can compiler gcc
that way on a laptop in about 50 minuets using
only 4.7% of my memory!

Any ideas?? What's happening, how to diagnose
what's happening, how to work around it, etc...

Thanks,

Gary



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Collect2 issue

[Martin Liška]

On 2/11/21 9:40 AM, Gary Oblock via Gcc wrote:

I'm running my new optimization (LTO with one partition)
on a SPEC17 test.

I got the mysterious message
   "collect2: error: ld returned 1 exit status"


Hello.

Can you please post full build log done with --verbose GCC argument?

Thanks,
Martin



Now, first off, with my debugging on at full tilt and it's
clear my optimization bailed out after analyzing
the code without doing anything.

Second, this is a canned test not modified by
me or anybody else for that matter so, it's
not a user error.

Finally, reading various blogs it seems that
old object files hanging around can make
collect2 to go bonkers. Therefore, I used
specmake to clean the build and it didn't
help, not that this makes any sense with one
partition.

By the way, for those of you that get upset
at the very notion of invoking LTO as one partition,
it's actually not that bad. I can compiler gcc
that way on a laptop in about 50 minuets using
only 4.7% of my memory!

Any ideas?? What's happening, how to diagnose
what's happening, how to work around it, etc...

Thanks,

Gary



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

[RISCV] RISC-V GNU Toolchain Biweekly Sync-up: Mar 11, 2021

[吴伟]

Hi all,

My name is Wei Wu. I am the project director of PLCT Lab, which is an
engineering team focusing on compilers, simulators, and virtual machines
(runtimes). The PLCT Lab is actively working on RISC-V toolchains,
including GNU Toolchain and Clang/LLVM. Recently, the PLCT Lab joined the
RISC-V international as a group contributor[1]. We are working on
implementing GCC/Binutils for a few draft ISA extensions like Zfinx, Krypto
Scalar, and P-extension.

I've noticed that there was no periodically sync-up meeting for RISC-V
backend, and I think it might be good to have one[2][3]. I invite everyone
who is interested in RISC-V to join and have discussions, making the GNU
Toolchain doing better on RISC-V.

So the first sync-up meeting would happen on March 11, the agenda will be
posted before the meeting:

Topic: RISC-V GNU Toolchain Biweekly Sync-up
Time: Mar 11, 2021 11:00 PM Beijing, Shanghai

LOS ANGELES, United States, California
7:00a Thu, Mar 11 2021

BEIJING, China
11:00p Thu, Mar 11 2021

LONDON, United Kingdom, England
3:00p Thu, Mar 11 2021


Join Zoom Meeting
https://zoom.com.cn/j/82900185885?pwd=Ym9mRHNkU2RDQ1VGOXVWMGJRR3Y3Zz09

Meeting ID: 829 0018 5885
Passcode: 908375

All are welcome!


Besides, for the developers living in East Asia, there is another
time-friendly sync-up meeting mainly talking in Chinese:


== Feb 25, 3pm - 4pm, CST ==

Topic: RISC-V GNU Toolchain Biweekly Sync-up (East Asia, Talking in Chinese)
Time: Feb 25, 2021 03:00 PM Beijing, Shanghai

LOS ANGELES, United States, California
11:00p Wed, Feb 24 2021

BEIJING, China
3:00p Thu, Feb 25 2021

LONDON, United Kingdom, England
7:00a Thu, Feb 25 2021

Join Zoom Meeting
https://zoom.com.cn/j/89274258913?pwd=cnFzSnVuMGxSeWwzTHNVeGUwbTN1UT09

Meeting ID: 892 7425 8913
Passcode: 484200


== Mar 11, 3pm - 4pm, CST ==

Topic: RISC-V GNU Toolchain Biweekly Sync-up (East Asia, Talking in Chinese)
Time: Mar 11, 2021 03:00 PM Beijing, Shanghai

Join Zoom Meeting
https://zoom.com.cn/j/83727837910?pwd=dTltRmVTRjB6ZGhaWTJaYkFVZGttdz09

Meeting ID: 837 2783 7910
Passcode: 389540

Happy Lunar New Year!


[1] PLCT Lab is part of the Institute of Software, Chinese Academy of
Sciences. So you may see that we are using the name CAS/PLCT in the RISC-V
community.
[2] Although the RISC-V community has its own task groups for ISA
extension, the discussion of the implementation details of specific
compilers are not encouraged.
[3] Thank Jeremy Bennett for this suggestion.





-- 
Best wishes,
Wei Wu (吴伟)
PLCT Lab

Re: GCC GSoC 2021 - Static analyzer project

[Adharsh Kamath via Gcc]

Hi David,

> Building GCC from source and stepping through it in the
> debugger would be good next steps.  You'll need plenty of disk space.
>  "run_checkers" is a good breakpoint to set if you're looking for the
> entrypoint to the analyzer.
>

I tried this and I understood the control flow in the analyzer.

> There's an example plugin in that patch.  The kernel source tree
> already has some plugins, so hopefully, those together give some
> pointers on how to write a "hello world" analyzer plugin that runs as
> part of the kernel build, which would be another next step, I guess.
>

I implemented a very simple hello world plugin here -
https://github.com/adharshkamath/Hello-world-plugin.

It just prints a Hello message while building the Linux Kernel, if the
-fanalyzer option is enabled. I referred to the example plugin in the
static analyzer
and the plugins in the kernel source to do this.

> See::
>   * "How to write system-specific, static checkers in Metal" (Benjamin
> Chelf, Dawson R Engler, Seth Hallem), from 2002
>   * "Checking system rules using system-specific, programmer-written
> compiler extensions" Proceedings of Operating Systems Design and
> Implementation (OSDI), September 2000. D. Engler, B. Chelf, A. Chou,
> and S. Hallem.
>   * "Using Programmer-Written Compiler Extensions to Catch Security
> Holes" (Ken Ashcraft, Dawson Engler) from 2002
>

These were useful and interesting to read. Thank you for suggesting them.
Adharsh

Re: GCC GSoC 2021 - Static analyzer project

[David Malcolm via Gcc]

On Thu, 2021-02-11 at 22:35 +0530, Adharsh Kamath wrote:
> Hi David,
> 
> > Building GCC from source and stepping through it in the
> > debugger would be good next steps.  You'll need plenty of disk
> > space.
> >  "run_checkers" is a good breakpoint to set if you're looking for
> > the
> > entrypoint to the analyzer.
> > 
> 
> I tried this and I understood the control flow in the analyzer.
> 
> > There's an example plugin in that patch.  The kernel source tree
> > already has some plugins, so hopefully, those together give some
> > pointers on how to write a "hello world" analyzer plugin that runs
> > as
> > part of the kernel build, which would be another next step, I
> > guess.
> > 
> 
> I implemented a very simple hello world plugin here -
> https://github.com/adharshkamath/Hello-world-plugin.
> 
> It just prints a Hello message while building the Linux Kernel, if
> the
> -fanalyzer option is enabled. I referred to the example plugin in the
> static analyzer
> and the plugins in the kernel source to do this.

Excellent.

> > See::
> >   * "How to write system-specific, static checkers in Metal"
> > (Benjamin
> > Chelf, Dawson R Engler, Seth Hallem), from 2002
> >   * "Checking system rules using system-specific, programmer-
> > written
> > compiler extensions" Proceedings of Operating Systems Design and
> > Implementation (OSDI), September 2000. D. Engler, B. Chelf, A.
> > Chou,
> > and S. Hallem.
> >   * "Using Programmer-Written Compiler Extensions to Catch Security
> > Holes" (Ken Ashcraft, Dawson Engler) from 2002
> > 
> 
> These were useful and interesting to read. Thank you for suggesting
> them.
> Adharsh

Great.

I believe you're in a position to write a strong application to GSoC
for yourself for this project; you're well ahead of the timeline, as I
understand it:
  https://summerofcode.withgoogle.com/how-it-works/#timeline

Dave

Re: Extending static analysis GSoC

[Martin Jambor]

Hi,

I am CCing the GCC mailing list again because you are much more likely
to get advice from the people on the list than just from me.

On Wed, Feb 10 2021, Ravi Kumar wrote:
> First of all thanks for the reply. I have few questions:
> 1.How can I improve my proposal?

First and foremost, we need you to demonstrate that you have the skills
necessary to work on the project and that you have a somewhat good idea
what and how you want to accomplish.

> 2.How much I have to contribute before the application period( minimum no.
> of pull request merged)?

We do not have any such hard requirement but candidates who can
demonstrate that they can make some (even very basic) thing work are
much more likely to be accepted.  On the other hand, in the past we have
accepted students who only got something working in the summer.

> 3.Should I have some extra skill other than project requirements?

The unusual requirement for extending the static analyzer in GCC - in
the sense that it is not needed for our other project - is understanding
some basic theory of static analysis in general.

> 4.How can I know in depth about the static analyzer project(C++ support).

I suppose the main source is the source code of the static analysis pass
and various blog posts and presentations that David Malcolm, its author,
has published over the last year or so.  They should not be hard to
Google for.

Please note that you also should choose what extension of the static
analysis pass you'd like to work on.  The page
https://gcc.gnu.org/wiki/SummerOfCode lists four suggestions, you are of
course welcome to come up with your own.

>
> Till now I grabbed very few knowledge of the project. I am trying hard to
> get something out of it but I find it very difficult. I need someone's help
> who can make me understand the project completely.

I completely understand it is very hard, but there is no alternative to
sitting down, reading the source code and playing and experimenting with
it.  The analyzer lives in the gcc/analyzer subdirectory in the GCC
sources and the entry point, as far as I understand it (i.e. not very
much) is run_checkers() in gcc/analyzer/engine.cc.

You are very welcome to ask questions - even beginner's questions
but specific questions - on the mailing list and/or on our IRC channel.
Everyone is busy of course, but we try to answer such questions as much
as possible.

Good luck,

Martin

gcc-8-20210211 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20210211 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20210211/
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 c7a6c4a68cb6fe38820273b5784a1ab6449cb6bd

You'll find:

 gcc-8-20210211.tar.xzComplete GCC

  SHA256=68bba40567c5bf502008b5bc1ded8748c28deb4bad9b708222e2e7d006235518
  SHA1=9e50917a7cfd45350935eac2151c584eec3fb6cc

Diffs from 8-20210204 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.