Re: Kernel build cc1: error: code model kernel does not support 32 bit mode

Hello, problem is solved wrong build, target was defined. Best regards Damian

Kernel build cc1: error: code model kernel does not support 32 bit mode

Hello together, I dont know if i am on the right mailing list. When i build my custom kernel 4.19+ with gcc 9 (actual svn snapshot) i got the following Error: cc1: error: code model kernel does not support 32 bit. I use ubuntu 18.10 With gcc 8.2 no problems. Any suggestion for this problem

Re: Cannot compile using cc1.

On 10/06/2018 06:07 AM, Tejas Joshi wrote: I have gcc source code, stage1-build and test directories as siblings and I've been trying to compile test.c in test/ using: ../stage1-build/gcc/cc1 test.c That isn't expected to work. You need to use the compiler driver, which is call

Cannot compile using cc1.

I have gcc source code, stage1-build and test directories as siblings and I've been trying to compile test.c in test/ using: ../stage1-build/gcc/cc1 test.c but getting error as: In file included from test.c:1: /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such fi

Re: [BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

On Tue, 2017-03-21 08:46:50 -0600, Jeff Law wrote: > On 02/12/2017 03:57 PM, Jan-Benedict Glaw wrote: > > When building a cross-gcc using config_list.mk using r245361 (as both, > > a freshly built `build' compiler and as sources for the > > cross-compiler), my build robot fails (see > > http://too

Re: [BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

On 02/12/2017 03:57 PM, Jan-Benedict Glaw wrote: Hi! When building a cross-gcc using config_list.mk using r245361 (as both, a freshly built `build' compiler and as sources for the cross-compiler), my build robot fails (see http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565). S

[BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

test=/home/jbglaw/repos-configlist_mk/gcc/gcc/testsuite/selftests cc1: internal compiler error: Segmentation fault 0xaf7fdf crash_signal /home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:333 0x6739b3 lookup_page_table_entry /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:635 0x6739b3 ggc_set

Re: Build problem msg: xgcc: error trying to exec 'cc1': execvp: No such file or directory

-Z0-9_]*\).*/\1/p' \    3532  -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \    3533   sort -u > tmp-macro_list    3534 xgcc: error trying to exec 'cc1': execvp: No such file or directory    3535 /bin/bash ../../gcc/gcc/../move-if-change tmp-macro_list macro

Re: Build problem msg: xgcc: error trying to exec 'cc1': execvp: No such file or directory

On 08/20/2013 05:22 AM, George R Goffe wrote: I keep getting this error message while building gcc checked out of the repository. Could I get a little help with resolving this problem please? You need to provide more details, like the host and target system and a dozen or so lines leading up t

Build problem msg: xgcc: error trying to exec 'cc1': execvp: No such file or directory

Hi, I keep getting this error message while building gcc checked out of the repository. Could I get a little help with resolving this problem please? Regards, George... xgcc: error trying to exec 'cc1': execvp: No such file or directory

Re: GCC Plugins - CC1 - Multiple processes on PLUGIN_FINISH_TYPE

. The content type claimed text/plain.) On Wed, Apr 25, 2012 at 7:23 AM, Diego Novillo wrote: > [ Please do not send html mail.  It will be rejected by the list server. ] > > On Wed, Apr 25, 2012 at 10:16, wrote: > >> That much I understand. But it's cc1 that is in two p

Re: GCC Plugins - CC1 - Multiple processes on PLUGIN_FINISH_TYPE

On Wed, Apr 25, 2012 at 4:23 PM, Diego Novillo wrote: > [ Please do not send html mail.  It will be rejected by the list server. ] > > On Wed, Apr 25, 2012 at 10:16, wrote: > >> That much I understand. But it's cc1 that is in two processes, and gcc -v >> only shows i

Re: GCC Plugins - CC1 - Multiple processes on PLUGIN_FINISH_TYPE

[ Please do not send html mail. It will be rejected by the list server. ] On Wed, Apr 25, 2012 at 10:16, wrote: > That much I understand. But it's cc1 that is in two processes, and gcc -v > only shows it being invoked once. Finally the output on stderr is only from > one of the

Re: GCC Plugins - CC1 - Multiple processes on PLUGIN_FINISH_TYPE

That much I understand. But it's cc1 that is in two processes, and gcc -v only shows it being invoked once. Finally the output on stderr is only from one of the two processes. Remove the finish type register and suddenly cc1 runs (as expected) and the logfiles PID and the console PID

Re: GCC Plugins - CC1 - Multiple processes on PLUGIN_FINISH_TYPE

rrect. All plugin events are emitted from cc1/cc1plus/f951/jc1/lto1. These binaries are the actual compiler. 'gcc' is a driver process that calls the compiler, the assembler, the linker, etc. Other plugin events do not appear to cause this behaviour. They should. All events are

GCC Plugins - CC1 - Multiple processes on PLUGIN_FINISH_TYPE

1) INFO src/plugin/gcc_core.c:0092 plugin_init CINS silencing console now. The console says: CINS silencing console now. 31D1 and 31CD are different PIDs. 001E is the identifier indicating the log count (i.e. there were 0x1E prints that came before

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

On Tue, Mar 20, 2012 at 12:47 PM, Ludovic Courtès wrote: > Hi Richard, > > Richard Guenther skribis: > >> 2012/3/19 Ludovic Courtès : > > [...] > >>> In the example of name mangling, I’d just have wrapped in ‘extern "C"’ >>> all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in.  The >>>

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

Hi Richard, Richard Guenther skribis: > 2012/3/19 Ludovic Courtès : [...] >> In the example of name mangling, I’d just have wrapped in ‘extern "C"’ >> all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in.  The >> rationale is that it simplifies plug-in maintenance, while not impeding

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

On Mon, Mar 19, 2012 at 10:36 AM, Ludovic Courtès wrote: > Perhaps a more incremental approach could be taken.  For instance, I > would argue that changes to the tree and GIMPLE APIs could be made > conservatively, on the grounds that they are most likely used by > plug-ins out there. Hmm, this

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

2012/3/19 Ludovic Courtès : > Hi, > > Richard Guenther skribis: > >> But no, I'm not volunteering (I'm volunteering to do the review work). >> The above has the same issue as the "we-want-to-be-more-like-LLVM" >> stuff - it lacks the people to actually implement it, and GCC at its >> present state

Re: GCC 4.7.0RC: Mangled names in cc1

Hello, For the interested reader, I eventually solved the nested function issue by using either nested functions or C++11 lambdas, depending on whether g++ is being used [0]. This is abstracted away by these (surprisingly not-too-ugly) macros to define a local function, and declare a function par

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

Hi, Richard Guenther skribis: > But no, I'm not volunteering (I'm volunteering to do the review work). > The above has the same issue as the "we-want-to-be-more-like-LLVM" > stuff - it lacks the people to actually implement it, and GCC at its > present state still has to evolve, we can't and do

Re: GCC 4.7.0RC: Mangled names in cc1

On Mon, Mar 19, 2012 at 4:57 AM, Ludovic Courtès wrote: > Hi, > > Gabriel Dos Reis skribis: > >> On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès >> wrote: > > [...] > >>> What about writing it in C++?  Function objects could be passed around >>> to achieve a similar result, at the expense of co

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

On Fri, Mar 16, 2012 at 6:19 PM, David Malcolm wrote: > It seems that GCC has provided an API for registering plugins, but no > API for the plugins to then actually use...  Perhaps the C++ move would > be alleviated by having an actually C API for plugins to use?  I started > writing a possible A

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Gabriel Dos Reis skribis: > On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès > wrote: [...] >> What about writing it in C++?  Function objects could be passed around >> to achieve a similar result, at the expense of conciseness and >> interoperability with C. > > Does not compute. If you

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

On 16 March 2012 17:19, David Malcolm wrote: > > What I'm really hoping for from GCC is a move towards a collection of > libraries that can be embedded in (license-compatible) apps: LLVM is > gaining ground for the use case of programs that need JIT-compilation > (e.g. the X server, or a JVM).  I a

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

On Fri, 16 Mar 2012, David Malcolm wrote: > Proposed outcome [...] > Current architectural issues [...] Not many people commented on the architectural goals document Diego and I posted at . Many of your ideas seem potentially useful additions to

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

On Fri, Mar 16, 2012 at 12:19 PM, David Malcolm wrote: > C++ is likely to make it more difficult to embed GCC into such apps > (e.g. nasty ordering issues for globals with non-empty constructors; If you were going to write an API in C and you have no globals that require a dynamic initialization

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

On Fri, Mar 16, 2012 at 13:19, David Malcolm wrote: > Hope this is constructive. It is. Parts of your proposal are instances of the modularity effort that has been going on for some time. It also touches on some of the same topics discussed in http://gcc.gnu.org/wiki/ImprovementProjects. It w

GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

On Fri, 2012-03-16 at 16:17 +0100, Ludovic Courtès wrote: > Hello, > > Richard Guenther skribis: > > > 2012/3/16 Ludovic Courtès : > > [...] > > > Well, if you invent new paradigms > > Hmm, I didn’t invent anything here. > > > in your plugin that are not used by GCC itself but use GCC intern

Re: GCC 4.7.0RC: Mangled names in cc1

On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès wrote: > Right, but the nice thing with GCC plug-ins is they can be implemented > using all GNU extensions. at the risk of having this very discussion. [...] > What about writing it in C++?  Function objects could be passed around > to achieve a

Re: GCC 4.7.0RC: Mangled names in cc1

On Fri, Mar 16, 2012 at 6:03 AM, Ludovic Courtès wrote: > Hi, > > After writing an Autoconf macro that determines whether to build > plug-ins with gcc or g++ [0], I realized that nested functions, which my > plug-in uses extensively, are not supported in C++. > > Any suggestions on how to address

Re: GCC 4.7.0RC: Mangled names in cc1

Hello, Richard Guenther skribis: > 2012/3/16 Ludovic Courtès : [...] > Well, if you invent new paradigms Hmm, I didn’t invent anything here. > in your plugin that are not used by GCC itself but use GCC internals > (which all plugins have to do ...) then I know where the problem lies > ;) I s

Re: GCC 4.7.0RC: Mangled names in cc1

On Fri, Mar 16, 2012 at 02:04:38PM +0100, Ludovic Courtès wrote: > > What about writing it in C++? Function objects could be passed around > to achieve a similar result, at the expense of conciseness and > interoperability with C. Well, if your plugin is compiled with C++ and all of GCC is also

Re: GCC 4.7.0RC: Mangled names in cc1

2012/3/16 Ludovic Courtès : > Hi, > > Richard Guenther skribis: > >> 2012/3/16 Ludovic Courtès : >>> Hi, >>> >>> After writing an Autoconf macro that determines whether to build >>> plug-ins with gcc or g++ [0], I realized that nested functions, which my >>> plug-in uses extensively, are not suppo

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Richard Guenther skribis: > 2012/3/16 Ludovic Courtès : >> Hi, >> >> After writing an Autoconf macro that determines whether to build >> plug-ins with gcc or g++ [0], I realized that nested functions, which my >> plug-in uses extensively, are not supported in C++. >> >> Any suggestions on ho

Re: GCC 4.7.0RC: Mangled names in cc1

2012/3/16 Ludovic Courtès : > Hi, > > After writing an Autoconf macro that determines whether to build > plug-ins with gcc or g++ [0], I realized that nested functions, which my > plug-in uses extensively, are not supported in C++. > > Any suggestions on how to address this? Don't use nested funct

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, After writing an Autoconf macro that determines whether to build plug-ins with gcc or g++ [0], I realized that nested functions, which my plug-in uses extensively, are not supported in C++. Any suggestions on how to address this? Thanks, Ludo’. [0] https://gforge.inria.fr/scm/viewvc.php/tr

Re: GCC 4.7.0RC: Mangled names in cc1

On Mon, Mar 12, 2012 at 7:10 AM, Richard Guenther wrote: >> In 4.7, finding out whether gcc or g++ should be used is left as an >> exercise to the plug-in writer, which is inconvenient at best. > > Well, that is what you get for having plugins without a proper plugin API ;) > It's not going to ch

Re: GCC 4.7.0RC: Mangled names in cc1

On Mon, Mar 12, 2012 at 3:56 AM, Ludovic Courtès wrote: > Symbols declared in are mangled, for instance.  I’m not sure > whether is considered internal or not, but I can hardly see > what kind of plug-in could be written without using it. tree.h is internal. -- Gaby

Re: GCC 4.7.0RC: Mangled names in cc1

2012/3/12 Ludovic Courtès : > Hi, > > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >> >>> Ian Lance Taylor skribis: >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> Ian Lance Taylor skribis: >> >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >>> Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> However, thi

Re: GCC 4.7.0RC: Mangled names in cc1

On Fri, 2012-03-09 at 11:41 +0100, Ludovic Courtès wrote: > Hi, > > Andrew Pinski skribis: > > > 2012/3/9 Ludovic Courtès : > > > >> I believe this is not intentional, right? > > > > No, this is intentional. We bootstrap the compiler using the C++ > > front-end now. We build stage1 with the C

Re: GCC 4.7.0RC: Mangled names in cc1

ludovic.cour...@inria.fr (Ludovic Courtès) writes: > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >> >>> Ian Lance Taylor skribis: >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: > However, this means that plug-ins must now be built with

Re: GCC 4.7.0RC: Mangled names in cc1

Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> Ian Lance Taylor skribis: >> >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >>> However, this means that plug-ins must now be built with g++, except when GCC was configured with --disable-build-

Re: GCC 4.7.0RC: Mangled names in cc1

ludovic.cour...@inria.fr (Ludovic Courtès) writes: > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >> >>> However, this means that plug-ins must now be built with g++, except >>> when GCC was configured with --disable-build-poststage1-with-cxx. This >>> seems

Re: GCC 4.7.0RC: Mangled names in cc1

Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> However, this means that plug-ins must now be built with g++, except >> when GCC was configured with --disable-build-poststage1-with-cxx. This >> seems difficult to deal with, for plug-in writers. > > This is an

Re: GCC 4.7.0RC: Mangled names in cc1

ludovic.cour...@inria.fr (Ludovic Courtès) writes: > However, this means that plug-ins must now be built with g++, except > when GCC was configured with --disable-build-poststage1-with-cxx. This > seems difficult to deal with, for plug-in writers. This is an unfortunate truth during our transiti

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, I believe this is not intentional, right? No, this is intentional. We bootstrap the compiler using the C++ front-end now. We build stage1 with the C compiler and then build stages 2 and 3 with the C++ compiler. OK. However, this means that plug-ins must now be built with g++, except w

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, ludovic.cour...@inria.fr (Ludovic Courtès) skribis: > Andrew Pinski skribis: > >> 2012/3/9 Ludovic Courtès : >> >>> I believe this is not intentional, right? >> >> No, this is intentional. We bootstrap the compiler using the C++ >> front-end now. We build stage1 with the C compiler and the

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Andrew Pinski skribis: > 2012/3/9 Ludovic Courtès : > >> I believe this is not intentional, right? > > No, this is intentional. We bootstrap the compiler using the C++ > front-end now. We build stage1 with the C compiler and then build > stages 2 and 3 with the C++ compiler. OK. However,

Re: GCC 4.7.0RC: Mangled names in cc1

On Fri, Mar 09, 2012 at 01:53:52AM -0800, Andrew Pinski wrote: > 2012/3/9 Ludovic Courtès : > > > I believe this is not intentional, right? > > No, this is intentional. We bootstrap the compiler using the C++ > front-end now. We build stage1 with the C compiler and then build > stages 2 and 3 w

Re: GCC 4.7.0RC: Mangled names in cc1

2012/3/9 Ludovic Courtès : > I believe this is not intentional, right? No, this is intentional. We bootstrap the compiler using the C++ front-end now. We build stage1 with the C compiler and then build stages 2 and 3 with the C++ compiler. This is a documented change too. Thanks, Andrew Pinsk

GCC 4.7.0RC: Mangled names in cc1

Hi, In a build of GCC 4.7.0-RC-20120302 with --enable-languages=c,c++ [0], I’m seeing C++-mangled name for common functions, like: $ objdump -T cc1 | grep build1_stat_loc 00640a00 gDF .text 007a Base _Z20fold_build1_stat_locj9tree_codeP9tree_nodeS1_ Indeed

Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

Den 11 november 2011 16:30 skrev Jason Merrill: > On 11/11/2011 07:02 AM, Christian Jönsson wrote: >> >> revision r181278 gives me a bootstrap/build error on cygwin for gcc >> trunk like this > > I've now conditioned those functions on the macro being defined.  Does that > fix it for you? yup, tha

Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

On 11/11/2011 07:02 AM, Christian Jönsson wrote: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk like this I've now conditioned those functions on the macro being defined. Does that fix it for you? Jason

Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

> Just to make sure nobody is midled by th subject of your message: > your bootstrap problem obviously has nothing to do with the warning itself. > The latter has been discussed already on these mailing lists, is absolutely > bening. I have open pr51094 for this bootstrap failure. Note that it is

Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

Hi, > revision r181278 gives me a bootstrap/build error on cygwin for gcc > trunk like this Just to make sure nobody is midled by th subject of your message: your bootstrap problem obviously has nothing to do with the warning itself. The latter has been discussed already on these mailing lists,

revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

II_DATA_ASM_OP' undeclared (first use in this function) ../../gcc/gcc/varasm.c:7601:31: error: expected ')' before string constant ../../gcc/gcc/varasm.c:7601:31: error: too few arguments to function 'fputs' ../../gcc/gcc/varasm.c:7604:13: error: 'ELF_ASCII_ESCAPES'

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

Andreas Schwab writes: > Jason Merrill writes: > >> No, it's accepted by the C front end too, it just has no effect. It's >> listed as a C option in c.opt. But during builds cc1 warns about it >> sometimes and not others. It's very odd. > >

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

Jason Merrill writes: > No, it's accepted by the C front end too, it just has no effect. It's > listed as a C option in c.opt. But during builds cc1 warns about it > sometimes and not others. It's very odd. $ gcc -Wno-narrowing -c hello.c $ gcc -Wno-narrowing -c he

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

Hi, > On 11/08/2011 03:22 PM, Paolo Carlini wrote: >> I believe that the core issue is pretty clear: -Wno-narrowing disables a C++ >> only warning but somehow we are passing it also in a few C compiler >> invocations, thus the driver warns. > > No, it's accepted by the C front end too, it just

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

ffect. It's listed as a C option in c.opt. But during builds cc1 warns about it sometimes and not others. It's very odd. Jason

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

Hi, > I saw it on a native build, possibly netbsd, but I ignored it as I was > in the middle of something. Will keep an eye out for it again. I believe that the core issue is pretty clear: -Wno-narrowing disables a C++ only warning but somehow we are passing it also in a few C compiler invocat

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

On 11/08/2011 03:08 PM, Jonathan Wakely wrote: I saw it on a native build, possibly netbsd, but I ignored it as I was in the middle of something. Will keep an eye out for it again. I see it occasionally too, but haven't been able to reproduce it when calling the compiler directly. Very odd.

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

On 8 November 2011 19:29, Michael Meissner wrote: > On Sun, Nov 06, 2011 at 07:18:52AM +0100, Ralf Corsepius wrote: >> Hi, >> >> Since recently, I am facing several of the warnings above when >> building GCC-trunk cross for RTEMS targets. >> >> So far, not much clues about what is going on, except

Re: cc1: warning: unrecognized command line option "-Wno-narrowing"

On Sun, Nov 06, 2011 at 07:18:52AM +0100, Ralf Corsepius wrote: > Hi, > > Since recently, I am facing several of the warnings above when > building GCC-trunk cross for RTEMS targets. > > So far, not much clues about what is going on, except that I see > -Wno-narrowing were recently added to > gcc

cc1: warning: unrecognized command line option "-Wno-narrowing"

Hi, Since recently, I am facing several of the warnings above when building GCC-trunk cross for RTEMS targets. So far, not much clues about what is going on, except that I see -Wno-narrowing were recently added to gcc/configure.ac and libcpp/configure.ac. Ralf

Re: cc1.exe: warnings being treated as errors

Jonathan Wakely wrote, On 26/09/11 09:57: [.] Feel free to request a new option in Bugzilla to suppress the note, that's the right place for this discussion. Good point. I've created a ticket: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50643 Regards, Jon

Re: cc1.exe: warnings being treated as errors

On 09/26/2011 05:11 PM, Ian Lance Taylor wrote: > Andrew Haley writes: > >> On 09/19/2011 06:59 PM, Jon Grant wrote: >> >>> >>> I noticed that when compiling C files with GCC and using the -Werror >>> option, I see this additional output: >

Re: cc1.exe: warnings being treated as errors

Andrew Haley writes: > On 09/19/2011 06:59 PM, Jon Grant wrote: > >> >> I noticed that when compiling C files with GCC and using the -Werror >> option, I see this additional output: >> >> cc1.exe: warnings being treated as errors >> ./src/main.c:

Re: cc1.exe: warnings being treated as errors

On 09/19/2011 06:59 PM, Jon Grant wrote: > > I noticed that when compiling C files with GCC and using the -Werror > option, I see this additional output: > > cc1.exe: warnings being treated as errors > ./src/main.c: In function 'main': > ./src/main.c:41:15

Re: cc1.exe: warnings being treated as errors

On 26 September 2011 09:33, Jon Grant wrote: > For example: -Wall means I see "control reaches end of non-void function" > messages, but doesn't output "cc1.exe: all warnings turned on" But it does tell you which option that warning came from: [-Wreturn-type] So if

Re: cc1.exe: warnings being treated as errors

f non-void function" messages, but doesn't output "cc1.exe: all warnings turned on" I'd thought because the previous line of output said "gcc -Werror -Wall -o main main.c", the options clear. Not if you run "make" and it doesn't echo the com

Re: cc1.exe: warnings being treated as errors

On Sat, Sep 24, 2011 at 03:55:10PM +0100, Jonathan Wakely wrote: > On 24 September 2011 15:40, Jon Grant wrote: > > It's kind of re-iterating the command line options, that the user will > > choose to be aware of already. I don't recall seeing that text output before > > about ~1 year ago. > > It

Re: cc1.exe: warnings being treated as errors

On 24 September 2011 15:40, Jon Grant wrote: > It's kind of re-iterating the command line options, that the user will > choose to be aware of already. I don't recall seeing that text output before > about ~1 year ago. It was there in GCC 4.1, maybe earlier, I didn't check. > I'd thought because t

Re: cc1.exe: warnings being treated as errors

Jonathan Wakely wrote, On 19/09/11 19:40: On 19 September 2011 18:59, Jon Grant wrote: Hello I noticed that when compiling C files with GCC and using the -Werror option, I see this additional output: cc1.exe: warnings being treated as errors ./src/main.c: In function 'main': ./src

Re: cc1.exe: warnings being treated as errors

On 19 September 2011 18:59, Jon Grant wrote: > Hello > > I noticed that when compiling C files with GCC and using the -Werror > option, I see this additional output: > > cc1.exe: warnings being treated as errors > ./src/main.c: In function 'main': > ./src/ma

cc1.exe: warnings being treated as errors

Hello I noticed that when compiling C files with GCC and using the -Werror option, I see this additional output: cc1.exe: warnings being treated as errors ./src/main.c: In function 'main': ./src/main.c:41:15: error: unused variable 'hello' Is the "cc1" line outpu

Re: hash signature of cc1 etc....?

I'm not quite sure what checksums you want. >> >> Suppose you just do >> >> md5sum `gcc --print-file-name=cc1` >> >> ? >> >> That will give you a checksum without gcc going to the trouble of >> generating it. > > > What about the

Re: hash signature of cc1 etc....?

On Fri, 22 Jul 2011 15:12:36 -0700 Ian Lance Taylor wrote: > Basile Starynkevitch writes: > > > Should we add an option to the gcc driver which would print such checksums? > > I'm not quite sure what checksums you want. > > Suppose you just do > >

Re: hash signature of cc1 etc....?

Basile Starynkevitch writes: > Should we add an option to the gcc driver which would print such checksums? I'm not quite sure what checksums you want. Suppose you just do md5sum `gcc --print-file-name=cc1` ? That will give you a checksum without gcc going to the trouble of gener

hash signature of cc1 etc....?

use a shell script using the output of gcc -print-file-name=cc1 etc, but I was imagining something simpler, like eg an hypothetical option gcc -print-internal-checksums Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8

Unused variables and functions and missing const decls in cc1 binary

Hi, I do not have time to poke too much about this, but with whole-program build it is easy to see what functions ends up being unused in final cc1 binary. Not all of those are unnecesary (and some are for future use, for debugging or used by other binaries), but it might serve as guideline to

Re: libiberty should be a shared library when cc1 has plugin enabled.

amp; plugins. Can plugins use all of libiberty or should they use only functions already called by cc1? [I am not able to propose a patch about this libiberty point because I do not understand all the portability issues] Regards. PS. I hope that my RTLD_GLOBAL patch http://gcc.gnu.org/ml/gcc-

Re: libiberty should be a shared library when cc1 has plugin enabled.

* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST: > While Ralf's point about static data is valid, the functions likely to > be in libiberty on any platform supporting plugins should not suffer > from this problem. Solaris 9 and IRIX 6.5 support dlopen; gnulib documents them as mi

Re: libiberty should be a shared library when cc1 has plugin enabled.

Daniel Jacobowitz wrote: On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote: Daniel Jacobowitz wrote: On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote: In simpler words, *.so have to be compiled with -fPIC, and libiberty is not compiled with

Re: libiberty should be a shared library when cc1 has plugin enabled.

On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote: > Daniel Jacobowitz wrote: > >On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote: > >>In simpler words, *.so have to be compiled with -fPIC, and libiberty > >>is not compiled with -fPIC. > > > >We build a PIC li

Re: libiberty should be a shared library when cc1 has plugin enabled.

Daniel Jacobowitz wrote: On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote: In simpler words, *.so have to be compiled with -fPIC, and libiberty is not compiled with -fPIC. We build a PIC libiberty already. Thanks! Where and how is it built? I cannot find any

Re: libiberty should be a shared library when cc1 has plugin enabled.

On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote: > In simpler words, *.so have to be compiled with -fPIC, and libiberty > is not compiled with -fPIC. We build a PIC libiberty already. While Ralf's point about static data is valid, the functions likely to be in libiberty on an

Re: libiberty should be a shared library when cc1 has plugin enabled.

* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 02:50:04PM CEST: > On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote: > > But it seems to me that a plugin can call a libliberty function only if that > > function is already referenced (e.g. called) from cc1.

Re: libiberty should be a shared library when cc1 has plugin enabled.

Daniel Jacobowitz wrote: On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote: But it seems to me that a plugin can call a libliberty function only if that function is already referenced (e.g. called) from cc1. This is not the case of all libiberty functions. So

Re: libiberty should be a shared library when cc1 has plugin enabled.

On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote: > But it seems to me that a plugin can call a libliberty function only if that > function is already referenced (e.g. called) from cc1. This is not the case > of all libiberty functions. So... link libiberty into yo

Re: libiberty should be a shared library when cc1 has plugin enabled.

Dave Korn wrote: Basile STARYNKEVITCH wrote: Dave Korn wrote: We might also artificially add a reference to each libiberty function from cc1. Or link it into cc1 et al. using "--whole-archive". Sorry, I am not aware of this option. And are we sur

Re: libiberty should be a shared library when cc1 has plugin enabled.

Basile STARYNKEVITCH wrote: > Dave Korn wrote: >> >>> We might also artificially add a reference to each libiberty function >>> from >>> cc1. >> >> Or link it into cc1 et al. using "--whole-archive". >> >> > So

Re: libiberty should be a shared library when cc1 has plugin enabled.

Dave Korn wrote: We might also artificially add a reference to each libiberty function from cc1. Or link it into cc1 et al. using "--whole-archive". Sorry, I am not aware of this option. And are we sure it works on all the systems GCC is supposed to run on? If w

Re: libiberty should be a shared library when cc1 has plugin enabled.

Basile Starynkevitch wrote: > Hello All, > > Perhaps libiberty should be a shared library, not a static one, linked from > cc1, when GCC has plugin enabled. > We might also artificially add a reference to each libiberty function from > cc1. Or link it into cc1 et al. usin

libiberty should be a shared library when cc1 has plugin enabled.

Hello All, Perhaps libiberty should be a shared library, not a static one, linked from cc1, when GCC has plugin enabled. I noticed the following in the MELT branch (while trying to build MELT as a GCC-Trunk plugin). Some functions of libiberty.h are not linked in cc1 (because cc1 don't

Q: how to sometimes forcebly invoke cc1 thru gcc even without any input files?

Hello All On the MELT branch, I need sometimes that cc1 be run even if there is no input files. This is an unusual mode, but sometimes needed (This actually is needed to have MELT lisp files translated into C; for reasons not explained here, this is a special mode of my ./cc1 which does that

Re: cc1

On Feb 16, 2008 12:38 PM, Dasarath Weeratunge <[EMAIL PROTECTED]> wrote: > When I use cc1 directly it outputs a whole lot of text like: > is there an option to surpress this? -quiet . -- Pinski

  1   2   >