gcc-8-20200813 is now available

2020-08-13 Thread GCC Administrator via Gcc
Snapshot gcc-8-20200813 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200813/ 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

Re: Unused libgcc symbol reference

2020-08-13 Thread Tobias Wölfel via Gcc
On Thu Aug 13, 2020 at 2:50 PM CEST, Jakub Jelinek wrote: > And unfortunately the functions that add the .globl directives for the > calls > are done at expansion time rather than only based on what calls survive > through the RTL optimizations. Thanks a lot Jakub for the explanation! > Or why we

Re: Request to join development team

2020-08-13 Thread Jonathan Wakely via Gcc
On Thu, 13 Aug 2020 at 14:57, Dnyaneshwar Gomsale via Gcc wrote: > > I am Dnyaneshwar Gomsale. I want to be the part of the your development > team. Great! We have a wiki page describing how to get started; https://gcc.gnu.org/wiki/GettingStarted

Request to join development team

2020-08-13 Thread Dnyaneshwar Gomsale via Gcc
I am Dnyaneshwar Gomsale. I want to be the part of the your development team.

Re: Unused libgcc symbol reference

2020-08-13 Thread Jakub Jelinek via Gcc
On Thu, Aug 13, 2020 at 02:33:50PM +0200, Tobias Wölfel via Gcc wrote: > I observed that in some ELF files there is code present which is not used. > It originates from integer arithmetics. > The following snipped should help to demonstrate the problem. It is there because the division in this ca

Unused libgcc symbol reference

2020-08-13 Thread Tobias Wölfel via Gcc
Hi, I observed that in some ELF files there is code present which is not used. It originates from integer arithmetics. The following snipped should help to demonstrate the problem. I have the function in the file foo.c: ``` unsigned long long foo(unsigned long a, unsigned long b) { retur

GCC Plugins and global_options

2020-08-13 Thread Jakub Jelinek via Gcc
Hi! Any time somebody adds or removes an option in some *.opt file (which e.g. on the 10 branch after branching off 11 happened 5 times already), many offsets in global_options variable change. It is true we don't guarantee ABI stability for plugins, but we change the most often used data structu

Re: C:\Program Files (x86)\Dev-Cpp\MinGW64\x86_64-w64-mingw32\lib32\libmingw32.a(lib32_libmingw32_a-crt0_c.o) In function `main': 18 C:\crossdev\src\mingw-w64-v3-git\mingw-w64-crt\crt\crt0_c.c undefin

2020-08-13 Thread Jonathan Wakely via Gcc
This is the wrong mailing list for your question, please read https://gcc.gnu.org/lists.html (and don't put your entire email in the Subject: line please). The MinGW compiler can be used to create console applications or GUI applications. The default is -mconsole, which means the linker looks for

Re: Coding style for C++ constructs going forward

2020-08-13 Thread Jonathan Wakely via Gcc
On Thu, 13 Aug 2020 at 08:52, Metzger, Markus T wrote: > > Hello, > > > It seems like common sense to me. "Almost always use auto" is a silly > > guideline. I can't stand seeing nonsense like: > > > > auto main() -> int > > { ... } > > I personally do not like auto for reasons like the above or >

Re: Coding style for C++ constructs going forward

2020-08-13 Thread Jonathan Wakely via Gcc
On Thu, 13 Aug 2020 at 07:46, Liu Hao via Gcc wrote: > > 在 2020/8/13 上午2:40, David Blaikie 写道: > > > > Then use of `auto*` would make it easier for you to spot use of plain > > pointers in your projects & scrutinize them further? > > > > My point is that `auto*` conveys no more information than `a

RE: Coding style for C++ constructs going forward

2020-08-13 Thread Metzger, Markus T via Gcc
Hello, > It seems like common sense to me. "Almost always use auto" is a silly > guideline. I can't stand seeing nonsense like: > > auto main() -> int > { ... } I personally do not like auto for reasons like the above or auto foo = bar->foo (); I find this very hard to read and I also thin