Re: GCC version bikeshedding

sense to anybody who is not an > active GCC developer. I also disagree with the last assertion (for example Sun did that for Solaris) but that's probably too much bikeshedding at this point. -- Eric Botcazou

Re: selective linking of floating point support for *printf / *scanf

E are the implementation, we should use the namespace reserved for us, namely __printf_float. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature

Re: selective linking of floating point support for *printf / *scanf

he implementation is all double underscores, and all single underscore followed by a capital. Single underscore followed by a lower case is NOT reserved for the implementation, and is therefore free for use by the user, and therefore the implementation must not interfere with the user's use o

Re: selective linking of floating point support for *printf / *scanf

On 08/29/2014 10:03 AM, Eric Blake wrote: > On 08/29/2014 09:51 AM, Grissiom wrote: >>> Yes, it does. The namespace reserved for the implementation is _[_A-Z]. >>> The namespace _[a-z] is still available for the user. Which means the >>> user can declare their own

Re: -Wstack-usage and alloca in loops

oving the stack usage computation into its own analysis phase which has > access to VRP bounds and such would be a a significant improvement and > one which I think would be quite useful. Yes, provided the outcome is still guaranteed to be conservatively correct. -- Eric Botcazou

Re: MIPS Maintainers

Congratulations guys! -eric On Fri, Sep 26, 2014 at 1:01 PM, Jeff Law wrote: > > Sorry this has taken so long, the delays have been totally mine in not > following-up to get votes, then tally them from the steering committee. > > I'm pleased to announce that Catherine Moore

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

But perhaps I'm alone with this. IMO that's the sort of things some of us were afraid of when the C++ switch was being discussed and IIRC we were told this would not happen... -- Eric Botcazou

Re: Support for architectures without hardware interlocks

-specific pass that runs at the end of the RTL pipeline. -- Eric Botcazou

Re: Support for architectures without hardware interlocks

h shortening. The new Visium port does that for all instructions (see visium_reorg). -- Eric Botcazou

Re: [ping] Re: proper name of i386/x86-64/etc targets

> Ping? Any thoughts? x86 for the family and x86-32/x86-64 for the 2 architectures? -- Eric Botcazou

Re: How to update reg_dead notes

> Could you give me some advice on correct usage of df or even more preferred > point me to a comprehensible documentation of df which is more complete than > in df-core.c? Take a look at the c6x and mep ports. -- Eric Botcazou

Re: Ada: %(cc1_options) missing from default specs file

" thing) and cc1_options doesn't do it. That being said, there are enough common bits as to deserve a factorization. -- Eric Botcazou

Re: Ada: %(cc1_options) missing from default specs file

Yes, defining a common set of base options would be welcome. -- Eric Botcazou

Re: Ada: %(cc1_options) missing from default specs file

e_options only to the Ada front-end. -- Eric Botcazou

Re: gcc -S vs clang -S

#x27;s your point exactly here? You cannot expect different compilers to generate exactly the same code on a given testcase for non-toy architectures. Note that this kind of discussion is more appropriate for gcc-h...@gcc.gnu.org -- Eric Botcazou

Re: warning: conversion from ‘int’ to ‘char’ may change value

On 9/20/18, Martin Sebor wrote: > On 09/20/2018 08:08 AM, Vincent Lefevre wrote: >> On 2018-09-17 10:03:48 -0600, Martin Sebor wrote: >>> On 09/17/2018 06:00 AM, Umesh Kalappa wrote: Hi All, When we try to compile the below case from trunk gcc we get the below warning (-Wconver

Re: movmem pattern and missed alignment

OK for every language on strict-alignment platforms. This was changed only because of SSE on x86. -- Eric Botcazou

Re: movmem pattern and missed alignment

ween gcc-4.5 and gcc-4.6) Possibly indeed, I remembered GCC 4.5 as being the turning point. -- Eric Botcazou

Re: movmem pattern and missed alignment

t would fix the simple testcase > that was presented here. OK, I keep forgetting it and that would be a good compromise indeed. -- Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

8-10/msg02312.html So we have an additional ACATS failure (ce2104c) in 8.2.1 over the previous releases? Feel free to open a PR about it if you have a couple of minutes. Thanks for testing the Ada compiler! -- Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

> About the Ada compiler: it doesn't build on i686-w64-mingw32. It is > the reason why MSYS2 is stuck with 7.3 for 32 bits. Why doesn't it build? Because of PR ada/81878? -- Eric Botcazou

Re: GCC 6 branch is now closed

arate classpath out into its own bug database. That way the bug creation process could be made one step shorter, since the "First, you must pick a product on which to enter a bug" page would then no longer be necessary, since classpath would no longer be a choice, so there'd only be one product left (gcc). Eric

Re: Regarding projects and begineer guide.

On 12/5/18, David Malcolm wrote: > On Wed, 2018-12-05 at 22:48 +0530, Durgesh Kumar wrote: >> Dear sir/mam >> I am durgesh kumar from ABES engineering collenge,ghaziabad,uttar >> pradesh,india. >> >> I am currently in 2nd year of my graduation(Btech CSE ) >> >> I want to contribute in some of your

Re: Enabling vectorization at -O2 for x86 generic, core and zen tuning

gt; cost models. ; Alias to enable both -ftree-loop-vectorize and -ftree-slp-vectorize. ftree-vectorize Common Report Optimization Enable vectorization on trees. -- Eric Botcazou

Re: Strange executable text files in the repository

upstream and > sanitizer_common_interceptors_ioctl.inc isn't executable there. No objections for the couple of Ada files. -- Eric Botcazou

Re: RTEMS Ada build problem on trunk

ANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. This would suggest that bldtools/oscons/xoscons is miscompiled by the trunk native compiler. How did you configure this latter compiler? -- Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

e efficient than the former mechanism." I presume that the problem occurs during stage #2, i.e. that the gnat1 at stake has been built by the base compiler, right? -- Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

> Ah, that makes sense since the 32-bit SEH is different from the 64-bit one, > explains why the 64-bit builds work. Which EH mechanism does the base compiler use? The default one? We know that this works with the DWARF-2 mechanism (--disable-sjlj-exceptions). -- Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

so, can you lower it to -O1 or -O0? -- Eric Botcazou

Re: testsuite result updates for x86_64-w64-mingw32

int size = dwarf_reg_size_table[__builtin_dwarf_sp_column ()]; if (size == sizeof(_Unwind_Ptr)) tmp_sp->ptr = (_Unwind_Ptr) cfa; else { gcc_assert (size == sizeof(_Unwind_Word)); tmp_sp->word = (_Unwind_Ptr) cfa; } which is quite unexpected. -- Eric Botcazou

Re: GCC missing -flto optimizations? SPEC lbm benchmark

es of GNAT is to be compatible with C by default as much as possible. But we started to do some reordering recently when the records don't have (direct) equivalents in C. -- Eric Botcazou

Re: GSoC Project Ideas

On 3/3/19, Patrick Palka wrote: > Hi everyone, > > I am very interested in working on GCC as part of GSoC this year. A few > years > ago I was a somewhat active code contributor[1] and unfortunately my > contributing waned once I went back to school, but I'm excited to > potentially > have the op

Re: Warning for C Parameter Name Mismatch

On 3/8/19, David Brown wrote: > On 09/03/2019 00:06, Joseph Myers wrote: >> On Fri, 8 Mar 2019, Joel Sherrill wrote: >> >>> Can gcc report when the parameter name in a C prototype >>> does not match that used in the implementation? >>> >>> int f(int x); >>> >>> int f(int y) {...} >> >> I think thi

Re: [RFC] split of i386.c

e1. > > Thoughts? > > Thanks, > Martin > I'm not a maintainer, but just as an onlooker I highly support this move; i386.c is way too long as it is. 7 pieces sounds like a good number of new files to split it into, too. Eric

Re: How to add %' into gfc_fatal_error

On 3/11/19, Martin Sebor wrote: > On 3/11/19 8:18 AM, Martin Liška wrote: >> Hi. >> >> I would like to add %' into __gcc_gfc__ in order to handle: >> >> ./xgcc -B. /tmp/module.ii -Wformat -c >> /home/marxin/Programming/gcc/gcc/fortran/module.c: In function ‘void >> dump_module(const char*, int)’:

Re: Function pointers to a nested function / contained procedure

back-ends to support this (look for trampolines/descriptors in the manual and the source code). This should essentially work out of the box for any language front-end. -- Eric Botcazou

Re: Warning for C Parameter Name Mismatch

On 3/8/19, Joel Sherrill wrote: > Hi > > This may be just an ignorant user question on my part. > > Can gcc report when the parameter name in a C prototype > does not match that used in the implementation? > > int f(int x); > > int f(int y) {...} > > We try to fix every warning gcc reports but thi

Re: GSOC Proposal

On 3/29/19, nick wrote: > > > On 2019-03-29 10:28 a.m., nick wrote: >> >> >> On 2019-03-29 5:08 a.m., Richard Biener wrote: >>> On Thu, 28 Mar 2019, nick wrote: >>> On 2019-03-28 4:59 a.m., Richard Biener wrote: > On Wed, Mar 27, 2019 at 6:31 PM nick wrote: >> >> Greeti

Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets

On 4/2/19, Ulrich Weigand wrote: > Hello, > > the spu-elf target in GCC supports generating code for the SPU processors > of the Cell Broadband Engine; it has been part of upstream GCC since 2008. > > However, at this point I believe this target is no longer in use: > - There is no supported Cell/

Re: is re-running bootstrap after a change safe?

ers and that isn't what happens. Instead the compiler of each stage is updated in isolation. -- Eric Botcazou

Re: Iain Sandoe appointed Darwin co-maintainer

Congrats Iain on having your "de facto" maintainer status upgraded to being official! On 4/19/19, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Iain Sandoe as Darwin co-maintainer. > > Please join me in congratulating Iain on his new

Re: A bug in vrp_meet?

the attached Ada testcase at -O: Program received signal SIGSEGV, Segmentation fault. 0x0102173c in set_value_range ( vr=0x17747a0 , t=VR_RANGE, min=0x76c3df78, max=, equiv=0x0) at /home/eric/svn/gcc-8-branch/gcc/tree-vrp.c:298 298 vr->type = t; on x86-64 at least. Ma

Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .

if (!TARGET_VXWORKS || TARGET_VXWORKS_RTP) return true; /* The loader neither creates the glue code sequence that loads r12 nor uses the local entry point for the sibcall's target in the ELFv2 ABI. */ return DEFAULT_ABI != ABI_ELFv2; } -- Eric Botcazou

Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .

> Thank you Eric for the suggestion and say that we support in the loader > part ,can you please point on elfv2 reference that says implementation for > this specific case. I don't think there is a reference to this specific case in the ABI, only the general stuff about local an

Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .

olves the remaining relocations. None of them plays the usual dance with the local and global entry points implied by the ELFv2 ABI. -- Eric Botcazou

Re: On-Demand range technology [3/5] - The Prototype

> While I agree that symbolic ranges are a complication and that most > cases it currently handles are not "value-range" things I do not agree > with the idea that we can simply remove handling them and deal > with the fallout in some later point in the future. Eric may also

Re: About GSOC.

On 5/31/19, Nathan Sidwell wrote: > On 5/30/19 5:38 PM, Segher Boessenkool wrote: >> On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote: >>> Interesting, I was also puzzled for a moment. But notice that: >>> >>> int main () >>> { >>> _Float128 x = 18446744073709551617.5f128; >>>

Re: Testsuite not passing and problem with xgcc executable

; from the build folder without installing it? You need to pass -B where contains the compiler cc1. -- Eric Botcazou

Re: Testsuite not passing and problem with xgcc executable

> https://gcc.gnu.org/ml/gcc-testresults/2019-06/msg00810.html > results have been produced or there is something I am not aware of. You need to issue a third command: make mail-report.log -- Eric Botcazou

Re: Enabling Ctags Tree Wide for GCC

On 9/11/19, Nicholas Krause wrote: > Greetings, > > I was wondering what is the easiest way to allow source tree wide ctags. > There doesn't > > seem to be a make x command for it nor any real documentation online and > it would > > be nice to have. > ISTR this topic coming up 2 years ago: https:

Re: Moving to C++11

On 9/26/19, Nicholas Krause wrote: > Greetings, > > I asked about moving to C/C++ 11 as it would make it easier to > > allow multithreading support due to having a memory model > > alongside other features. Jason Merill mentioned due to it > > being so common it may be a good time to. > > Moving

Re: GCC selftest improvements

re going full C++11. So, GCC 10 would be C++98 + -Wnarrowing, and then GCC 11 could be full C++11. Plus then the GCC version numbers would also line up with the version of C++ being used. Eric

Re: GCC selftest improvements

On 10/31/19, Pedro Alves wrote: > On 10/26/19 11:46 PM, Eric Gallager wrote: > >> Nicholas Krause was also wanting to move to C++11 recently: >> https://gcc.gnu.org/ml/gcc/2019-10/msg00110.html (this month) >> https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html (last mon

Re: [RFC] Characters per line: from punch card (80) to line printer (132)

On 12/5/19, Andrew Stubbs wrote: > On 05/12/2019 16:17, Joseph Myers wrote: >> Longer lines mean less space for multiple terminal / editor windows >> side-by-side to look at different pieces of code. I don't think that's >> an >> improvement. > > Here's a data-point > > My 1920 pixel-wide sc

Could I obtain the forms needed to make a contribution?

I want to add a compiler warning, if it will get accepted. It's a -Wlines warning. My employer bans the __LINE__ macro as well as the ones warned by the -Wdate-time warning, because there is a consensus that the addition of whitespace or comments should not yield different binary output for our pro

Re: C2X Proposal, merge '.' and '->' C operators

On 12/16/19, J Decker wrote: > Here's the gist of what I would propose... > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da > > In C, there are two operators . and -> used to access members of struct and > union types. These operators are specified such that they are always paired >

Re: C2X Proposal, merge '.' and '->' C operators

> For what it's worth, that is how Go works. The '.' operator is used > for struct fields regardless of whether the left hand operand is a > struct or a pointer to a struct. Likewise in Ada. -- Eric Botcazou

Re: Could I obtain the forms needed to make a contribution?

t; > Best Regards, > Dmitry Grinberg > > > On Mon, Dec 16, 2019 at 3:51 AM Eric Curtin wrote: > >> I want to add a compiler warning, if it will get accepted. It's a >> -Wlines warning. My employer bans the __LINE__ macro as well as the >> ones warned by t

Re: [RFC] Further LRA subreg handling issues

> I'll run testing for at least x86_64, MIPS and another > WORD_REGISTER_OPERATIONS target and try to get this committed in the next > couple of days so it can get into everyone's testing well before release. I'm going to give it a try on SPARC. -- Eric Botcazou

Re: [RFC] Further LRA subreg handling issues

> I'll run testing for at least x86_64, MIPS and another > WORD_REGISTER_OPERATIONS target and try to get this committed in the next > couple of days so it can get into everyone's testing well before release. No issues found on SPARC. -- Eric Botcazou

Re: [RFC] Further LRA subreg handling issues

gister and let the insn do the different-sized accesses. This is doubly true if WORD_REGISTER_OPERATIONS. In this case eliminate_regs has left non-paradoxical subregs for push_reload to see. Make sure it does by forcing the reload. -- Eric Botcazou

Re: [RFC] Further LRA subreg handling issues

hecks for WORD_REGISTER_OPERATIONS, BYTES_BIG_ENDIAN, etc. > Eric: I see you recently had to modify the code I'm talking about in the > post below. Out of interest... was this another issue brought to light by > the improvements to zero extension elimination? Nope, there were a couple of other, unr

Re: [RFD] Simplifying subregs in LRA

e, MEM_ALIGN (reg) > return true; > > *curr_id->operand_loc[nop] = operand; > > > The change will affect at least arc,mips,rx,sh,sparc though I haven't > checked which of these default on for LRA just that they can turn on LRA. Only MIPS and SPARC (see https://gcc.gnu.org/backends.html). -- Eric Botcazou

Re: [RFD] Simplifying subregs in LRA

You can send me the patch(es) in advance, I'll give it a try on SPARC. -- Eric Botcazou

Re: __sync_-builtins cause undefined references on some sparc targets

s on how to start? I'm not sure backtrace support has much interest on embedded platforms and I don't think implementing atomic operations makes any sense on LEON2, so the best thing to do is probably to kludge around it in libgfortran. -- Eric Botcazou

Re: __sync_-builtins cause undefined references on some sparc targets

s HPUX. -- Eric Botcazou

Re: __sync_-builtins cause undefined references on some sparc targets

> Is libbacktrace excluded from the build, or is it build but broken? Neither, it's presumably falls back to __atomic. No big deal in any case, since you'll presumably never use libbacktrace in practice. -- Eric Botcazou

Re: Right way to represent flag-setting arithmetic instructions in MD files

e transformations it wants. Why do you want to use the compare-elimination pass exactly if the flags are exposed before reload, as is the case on Aarch64 I think? The combiner is supposed to do the same job instead for these targets. -- Eric Botcazou

Re: Doxygen for GCC

On 6/8/17, Martin Liška wrote: > On 04/28/2017 02:32 PM, Martin Liška wrote: >> I'm planning to periodically build it and rsync to a public website. >> I guess, sometimes it can be handy. > > Done that (it's weekly updated): > > http://gcc.opensuse.org/gcc-doxygen/ > > Martin > Clicking on the fi

Re: try_finally_expr wrong source location info

mple_set_location (x, tf_loc); + gimple_set_location (x, finally_loc); gimple_seq_add_stmt (&switch_body, x); } -- Eric Botcazou

Re: Read-only *.ali files in adalib installation?

; -rw-r--r-- 1 sebastian_h domain users 16076716 Jun 12 14:30 libgnat.a > > [...] > > This is unlike the lib*.a files, which are user writeable. Its this > intentional? Yes for the ALI files, but no for the libraries (it doesn't matter for them). -- Eric Botcazou

Re: Missing warning opportunity - code after break;

On 6/19/17, Soul Studios wrote: > Just noticed this: > while(something) > { > // stuff > > if (num_elements == 0) > { > break; > --current_group; > } > } > > doesn't trigger a warning in GCC 5.1, 6.3 and 7.1. The line after > "break;" is unused,

Re: GCC 6.4 Release Candidate available from gcc.gnu.org

er/79562 > * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry-pick > upstream r294806. > > > this was also pushed to the GCC 5 branch. Yes, it's again PR sanitizer/63958 I guess. -- Eric Botcazou

Re: GCC 6.4 Release Candidate available from gcc.gnu.org

64/Linux. -- Eric Botcazou

Re: timeouts/malloc failures in ada tests?

iler should really consider enabling it (and it's a very good testbed). -- Eric Botcazou

Re: Could preprocessor warn for unsafe macros and side-effects?

On 7/12/17, Martin Sebor wrote: > On 07/11/2017 11:50 PM, sa...@hederstierna.com wrote: >> Hi >> >> Reading about macro pitfalls and eg duplication side-effects >> https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html#Macro-Pitfalls >> >> would it be possible to let the preprocessor generate warn

Re: Killing old dead bugs

On 7/18/17, Yuri Gribov wrote: > On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor wrote: >> On 07/17/2017 02:25 PM, Yuri Gribov wrote: >>> >>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor wrote: On 07/17/2017 02:14 AM, Yuri Gribov wrote: > > > Hi Mikhail, > > On Sun,

Re: Killing old dead bugs

On 7/19/17, Yuri Gribov wrote: > On Wed, Jul 19, 2017 at 7:15 PM, Eric Gallager > wrote: >> On 7/18/17, Yuri Gribov wrote: >>> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor wrote: >>>> On 07/17/2017 02:25 PM, Yuri Gribov wrote: >>>>> >

Re: Volatile Memory accesses in Branch Delay Slots

ion where allowing volatile memory accesses in branch delay slots > leads to problems. Am I missing a case? Or are negative effects limited > to other architectures? Delay slot filling is a code movement optimization and such optimizations are not valid for volatile memory accesses in the

Re: Overwhelmed by GCC frustration

On 8/1/17, Richard Biener wrote: > On Mon, Jul 31, 2017 at 7:08 PM, Andrew Haley wrote: >> On 31/07/17 17:12, Oleg Endo wrote: >>> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote: Around 2010, someone who used a code snipped that I published in a wiki, reported that the code d

Re: Overwhelmed by GCC frustration

On 8/1/17, Jakub Jelinek wrote: > On Tue, Aug 01, 2017 at 07:08:41AM -0400, Eric Gallager wrote: >> > Heh. I suspect -Os would benefit from a separate compilation pipeline >> > such as -Og. Nowadays the early optimization pipeline is what you >> > want (mostly s

Re: Overwhelmed by GCC frustration

deprecation of cc0 is futile, > the voices that support cc0 deprecation are more and usefulness > of cc0 is not recognized. cc0 is just obsolete and inferior compared to the new representation. -- Eric Botcazou

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On 8/15/17, Jonathan Wakely wrote: > On 15 August 2017 at 04:10, Martin Sebor wrote: >> On 08/14/2017 04:22 PM, Eric Gallager wrote: >>> >>> I'm emailing this manually to the list because Bugzilla is down and I >>> can't file a bug on Bugzilla ab

Re: Optimization breaks inline asm code w/ptrs

On 8/14/17, Alan Modra wrote: > On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote: >> On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote: >> > Using "m"(*pStr) as an (unused) input parameter has no effect. >> >> Use "m" (*(const void *)pStr) and ignore the warning, or use >> "

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

On 8/25/17, Szabolcs Nagy wrote: > On 16/08/17 18:38, Joseph Myers wrote: >> On Wed, 16 Aug 2017, Eric Gallager wrote: >>> I see Richi redid all his 7.2 release changes; does that imply that >>> the server restore is now complete? >> >> No, there'

Re: Byte swapping support

ng the code simple and > maintainable. How do you discriminate scalars stored in native order and scalars stored in reverse order though? That's the main difficulty of the implementation. -- Eric Botcazou

Re: Byte swapping support

time performance. This is not what the attribute was designed for, although we added the -fsso-struct switch at some point. -- Eric Botcazou

Re: Byte swapping support

s any easier than > fixing the application. Note that WRS' Diab compiler has got something equivalent to what GCC has got now, i.e. a way to tag a particular component in a structure as BE or LE. -- Eric Botcazou

Re: Byte swapping support

structures..." with the same limitation as GCC about taking the address: "It is not possible to take the address of a byte-swapped member." -- Eric Botcazou

Re: Byte swapping support

ere is some interest though. -- Eric Botcazou

Re: Byte swapping support

> handle_pragma_scalar_storage_order does not check c_dialect_cxx, so it > will not issue a warning for C++ even though the pragma is effectively > ignored. Indeed, unlike for the attribute, will fix, thanks. -- Eric Botcazou

Re: Weird warning when building gcc

On Sat, Sep 23, 2017 at 12:34 PM, nick wrote: > > > On 2017-09-23 12:05 PM, Jeff Law wrote: >> On 09/22/2017 08:25 PM, nick wrote: >>> Greetings All, >>> >>> I am wondering if this is a warning worth looking into or is it just >>> another false postive: >>> >>> /home/nick/gcc/gcc/combine.c:1316:8

Re: Weird warning when building gcc

On Sat, Sep 23, 2017 at 12:34 PM, nick wrote: > If your able to just tell me where the functions are located or how do you > enable ctags for all of > gcc? That would just save me asking stupid questions. Is there a global > setting like make ctags for > doing this or you I have to do it manuall

Re: Weird warning when building gcc

On Mon, Sep 25, 2017 at 11:17 AM, nick wrote: > > > On 2017-09-24 10:10 AM, Eric Gallager wrote: >> On Sat, Sep 23, 2017 at 12:34 PM, nick wrote: >>> If your able to just tell me where the functions are located or how do you >>> enable ctags for all of >&g

Re: RFC: Update top level libtool files

On Tue, Oct 10, 2017 at 11:20 AM, Nick Clifton wrote: > Hi Joseph, > >> As per previous discussions on the issue: it's necessary to revert libtool >> commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c, see >> . > > OK - thanks for that pointer

Re: Feature request: -Wno-unknown-warnings to silently ignore unknown warning control flags.

On Thu, Oct 12, 2017 at 4:46 AM, Oren Ben-Kiki wrote: > Motivation/Use case: > > * Since gcc/g++ intentionally does not have `-Weverything`, there is a > number of explicit `-W...` flags one might wish to specify explicitly. Fair > enough. > > * Additional `-W...` flags are introduced in new gcc/g

Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)

On 11/20/17, Yao Qi wrote: > > Hi, > I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some > -Werror=stringop-overflow= and -Werror=stringop-truncation warnings. > Some of them are not necessary to me, > > 1. ../../binutils-gdb/gdb/python/py-gdb-readline.c:79:15: error: ‘char* >

Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)

On 11/20/17, Eric Gallager wrote: > On 11/20/17, Yao Qi wrote: >> >> Hi, >> I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some >> -Werror=stringop-overflow= and -Werror=stringop-truncation warnings. >> Some of them are not necessary to me

Re: Dropping ChangeLogs

e git has specific counter-measures against them, but that's useful at least with Subversion. -- Eric Botcazou

Re: Possbile patch for compilation errors re possibly uninitialized variables at -Og

On 12/29/17, Louis Krupp wrote: > I tried to build the trunk using: > > BOOT_CFLAGS='-g -Og' CFLAGS_FOR_TARGET='-g -Og' CFLAGS_FOR_BUILD='-g -Og' > > I got a number of compilation warnings -- promoted to errors -- about > possibly uninitialized variables. > > I have what I believe is a decent patc

<    1   2   3   4   5   6   7   8   9   10   >