Re: Suspicion of regression in uninitialized value detection
On 06/12/2011 20:33, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/06/11 12:21, Ian Lance Taylor wrote: While using the optimizers to improve the quality of uninitialized warnings does have some benefits, those benefits are outweighed by the drawbacks. We need to completely reimplement this warning, either in the C/C++ common frontend, or before any optimization passes run. Run it just after going into SSA; mark everything that has an uninitialized use. For those who want the larger, much more stable set of warnings this is going to meet their needs much better. That's what my patch from a few years ago did. IIRC the only outstanding issue was what should the default be. Would it be possible then to have switches for different levels, such as is done with the strict aliasing warnings? In theory we could go ahead and translate into SSA when not optimizing which would remove the dependency on -O, at the expense of compile-time performance. Do people often intentionally run gcc without any optimisations these days? The compiler speed on -O1, relative to the speed of host computers, means there are rarely compile speed reasons to turn off optimisations. And for debugging, -O1 is often much easier to work with than -O0, as the generated assembly makes more sense (more use of registers and less blind use of the stack). If that is the case, then it may be legitimate to always enable the basic analysis passes that are needed for uninitialised warnings. Then we can rename the existing warning to -Wunpredictable-uninitialized and take it out of -Wall. I'd tend to think this would be a mistake. We'd be changing -Wall in a very very visible way and I suspect the number of developers complaining would be huge. Ideally we'd just nuke -Wall and have everyone use the -W options they care about, but sadly that's just a pipe dream. In my opinion, we should nuke -Wall - these warning options should all be enabled unless explicitly /disabled/ with the -W options. And -Werror should be enabled by default too. Just think how many bugs would be found in existing software if developers were pushed into using their tools effectively! jeff
Re: RFC - GCC Architectural Goals
Hi Diego, > For the time being, however, it is easier for me to edit the document > online. The document is at > https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4 I am looking at "Developer tools - Patch submission and review". I have been working on QEMU for a while and sent a few trivial patches to QEMU. QEMU has volunteers for reviewing patches considered to be *trivial* and has a separate mailing list for trivial patches. This kind of patches includes typo fixes, document improvement and simple code improvement. I think this approach can encourage more people to involve in helping GCC better. What do you think? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: building unwind-sjlj.o with / without -fexceptions
Quoting Richard Henderson : I can fix this in libgcc/config/epiphany/t-epiphany with: unwind-sjlj.o : CFLAGS += -fno-exceptions unwind-sjlj.o : c_flags := $(filter-out -fexceptions,$(cflags)) Is that the right way to do it? Or should we more generally remove -fexceptions from the build rules for the exception handling runtime? No. In general removing -fexceptions from the unwind routines will cause the unwind routines to fail. Is this something where dwarf2 unwinding diverges from sjlj exception handling? Or can you show a testcase where -fexceptions is needed for unwind-sjlj.o ? The above patch makes hundreds of failures in the g++ and libstdc++-v3 testsuite go away, with no unwind related failures remaining.
Re: building unwind-sjlj.o with / without -fexceptions
2011/12/7 Joern Rennecke : > Quoting Richard Henderson : > >>> I can fix this in libgcc/config/epiphany/t-epiphany with: >>> >>> unwind-sjlj.o : CFLAGS += -fno-exceptions >>> unwind-sjlj.o : c_flags := $(filter-out -fexceptions,$(cflags)) >>> >>> Is that the right way to do it? Or should we more generally remove >>> -fexceptions >>> from the build rules for the exception handling runtime? >> >> >> No. In general removing -fexceptions from the unwind routines will cause >> the unwind routines to fail. > > > Is this something where dwarf2 unwinding diverges from sjlj exception > handling? > Or can you show a testcase where -fexceptions is needed for > unwind-sjlj.o ? > The above patch makes hundreds of failures in the g++ and libstdc++-v3 > testsuite go away, with no unwind related failures remaining. Well, actually it seems that 32-bit Windows target using SjLj has here the same issues. Even by reverting any extension done for this target on i386 still let c++ throw/catch simply fail.
Re: RFC - GCC Architectural Goals
Diego Novillo a écrit: > https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4 3. Debugging. [...] the compiler would show a stuck dump [...] Maybe you meant a stack dump? -- Dodji
Re: crtbegin not building?
On 12/06/11 18:37, Ian Lance Taylor wrote: Lawrence Crowl writes: It appears that "cd gcc; make" now fails to build crtbegin.o. An additional "make all-install" seems to be needed. Was this change intentional? It moved to libgcc. Look in TARGET/libgcc in your build directory. The problem here is that a 'make clean' in /gcc is removing it, so if it's not going to be re-built by 'make all' inside /gcc, then it should certainly not be removed by 'make clean'. Diego.
Re: building unwind-sjlj.o with / without -fexceptions
On 12/07/2011 01:00 AM, Joern Rennecke wrote: > Quoting Richard Henderson : > >>> I can fix this in libgcc/config/epiphany/t-epiphany with: >>> >>> unwind-sjlj.o : CFLAGS += -fno-exceptions >>> unwind-sjlj.o : c_flags := $(filter-out -fexceptions,$(cflags)) >>> >>> Is that the right way to do it? Or should we more generally remove >>> -fexceptions >>> from the build rules for the exception handling runtime? >> >> No. In general removing -fexceptions from the unwind routines will cause >> the unwind routines to fail. > > Is this something where dwarf2 unwinding diverges from sjlj exception > handling? > Or can you show a testcase where -fexceptions is needed for > unwind-sjlj.o ? > The above patch makes hundreds of failures in the g++ and libstdc++-v3 > testsuite go away, with no unwind related failures remaining. Hum, it's probably true that sjlj doesn't actually need -fexceptions here. But I really hate to add makefile hackery to work around a compiler that is clearly broken. r~
Re: RFC - GCC Architectural Goals
On 12/07/11 04:39, Dodji Seketeli wrote: Diego Novillo a écrit: https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4 3. Debugging. [...] the compiler would show a stuck dump [...] Maybe you meant a stack dump? Thanks. I fixed this yesterday. Reload?
Re: RFC - GCC Architectural Goals
On 12/07/11 03:52, 陳韋任 wrote: Hi Diego, For the time being, however, it is easier for me to edit the document online. The document is at https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4 I am looking at "Developer tools - Patch submission and review". I have been working on QEMU for a while and sent a few trivial patches to QEMU. QEMU has volunteers for reviewing patches considered to be *trivial* and has a separate mailing list for trivial patches. This kind of patches includes typo fixes, document improvement and simple code improvement. I think this approach can encourage more people to involve in helping GCC better. What do you think? We have a rule for "obviously correct" patches that do not even need review. Typo, grammar and other stylistic patches fall under that category. However, it is true that some patches are not in that category. In general, we prefer to keep patch traffic in a single place (gcc-patches@), but we use message tagging extensively. How about '[trivial]'? Now, this does not solve the review issue. We currently have several very active reviewers, but never enough. We do not have a good handle on how many patches go unreviewed and for how long (no patch tracking). One could measure the number of patch-pings vs patch-submissions, I guess. Diego.
Re: Suspicion of regression in uninitialized value detection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/11 01:19, David Brown wrote: > > Would it be possible then to have switches for different levels, > such as is done with the strict aliasing warnings? Well, there's two obvious levels... Not sure if there's a good way to get something in between. > Do people often intentionally run gcc without any optimisations > these days? Certainly. Compile speed and debugging being the primary reasons. However, as was mentioned we're always going into SSA (as a result of the SSA->RTL expansion path), so that issue is gone. >> > > In my opinion, we should nuke -Wall - these warning options should > all be enabled unless explicitly /disabled/ with the -W options. > And -Werror should be enabled by default too. Just think how many > bugs would be found in existing software if developers were pushed > into using their tools effectively! Well, lots of folks would disagree with that suggestion. And that's the root of the problem with this kind of issue -- different developers have different needs. Any significant change we make in this space is probably going to make equal numbers of developers happy and mad at the same time. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO36rjAAoJEBRtltQi2kC7VbgIAIUBoB5BoQnP8EcPsak0h3A/ h5KgxrcQIji2tPDthshbXbL9vVf0PpLzn6SFC4ZUt37sMQu5CLNqyqfMgpHgukic zTumkTZRlbVxt9/UVE/NDNN3DQtyzOE4QBj7a9Bp7kYDZEVEhCHFFyvSurv+1JJa jixT3+okGZSsuhFzeSWiNo8s3mqAaZ+FAmDhsv95Z1y13nOw4WDPqynnUmGZ76ri TBPUCtqOuJ69ZOVmzdsudw9o9BDuBTCQ2rgljVrbkT+fKlxyVuuiRmdWAte/7D21 u2EsuqMvEpYucX/2mBL/FoAi6T4LsEGxEJPzJS6p0cEbQFZXbygpP+RZtkRmbYI= =nE95 -END PGP SIGNATURE-
Call for Papers: Environmental Management & Technologies Conference!
Dear Colleagues, You are invited to join the Environmental Management & Technologies Working Group (EMTCWG 2012), Third Annual Environmental Management & Technologies Conference focused on creating and maintaining a sustainable environment which is one of the most pressing issues facing the world today. Increasing energy consumption, finite energy supplies, inappropriate production methods, environmental pollution, water scarcities, soil degradation, declining land productivity and dwindling resources are resulting in major environmental crises in many parts of the world. These critical global challenges have led to an increasing demand to mitigate environmental issues and move towards sustainability. The Environmental Management & Technologies Working Group (EMTCWG 2012) will bring together an international and interdisciplinary audience to address many of the issues connected with environmental management including waste management, environmental pollution and control, natural resource management and environmental policy, auditing and risk assessment. The conference welcomes papers that discuss the latest developments in environmental management research and application. The aim of the conference is to present results of research and innovated technologies related to environmental problems which pose a threat to the environment and the quality of life on earth. The EMTC 2012 provides a forum for scholars, researchers, academicians and practitioners to examine and discuss solution-oriented methods for environmental management and engineering; to share and exchange experiences and research findings; to stimulate more ideas and useful insights regarding current best-practices and future directions in environmental management and the legal, social, and political components related to it; and to debate their views on future research and developments. Topic Areas: Abstracts must be submitted online fewer than one of the following categories; if your topic doesn't fit easily into one of these categories (or if it fits into multiple categories) please choose the closest match below. Waste Management Sludge Management Solid Waste Management Industrial and Hazardous Waste Management Medical Waste Management Life Cycle Assessment of Wastes Waste and Recycling. Natural Resources Management Water Resources Management Air Quality Management Land Management Clean Fuel and Clean Energy Cultural Heritage and Ecotourism Biodiversity Conservation GIS and Remote Sensing Carbon Sequestrations Renewable Energy Environmental Modelling Climate & Environmental Change. Industrial Ecology & Environmental Policy Cleaner Production Industrial Symbiosis Life Cycle Assessment Green Design Risk Assessment Environmental Auditing and Compliance Environmental Monitoring Environmental Assessment Site Assessment and Characterization Environmental Impact Assessment Environmental Economics Environmental Laws and Regulations Sustainable Development Environmental Awareness and Education. Environmental Pollution and Control Pollution Prevention & Recycling Pollution Control Technologies Environmental Pollution & Health Air Pollution Water Pollution Marine Pollution Land Contamination Noise Pollution Radioactive Pollution Thermal Pollution Visibility Pollution Proposal Submission: Interested presenters should submit an abstract of less than 500 words of text summarizing the proposed presentation and a short bio (100 words, email: confere...@emtcwg.org or fax on:+447005921254 on or before 20th December,2011. Deadline for notification of acceptance is 20th December,2011. Conference Registration: All presenters are expected to register online by 10th January, 2012. Registration is free of charge for delegates from developing countries. Also free flight ticket, travel insurance, visa fees and per diem to be provided for all paper presenters and participating delegates. Important dates: 20th December,2011 Deadline for abstract submission 10th January ,2012 Notification of acceptance/Full paper Submissions 24-28 January,2012 Conference Dates We look forward to seeing you at the conference. Dr.David Baker, Conference Committee Environmental Management & Technologies Conference Working Group-Julco House 26-28 Great Portland St, London W1W 8QT,United Kingdom. Ph:+447011136420
Re: Suspicion of regression in uninitialized value detection
On 12/7/2011 1:05 PM, Jeff Law wrote: Do people often intentionally run gcc without any optimisations these days? Certainly. Compile speed and debugging being the primary reasons. Actually speaking for myself, I run the compiler at -O0 much *more* than I used to do. Why? Because gdb simply doesn't work at all for me at -O1. With earlier versions of gcc, working on the GNAT front end, I could always debug satisfactorily at -O1, so it was a reasonable compromise. Now the debugging at -O1 is hopeless (even parameters routinely disappear), and so I am forced to do everything at -O0.
Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h
I am trying to build gcc trunk on cygwin (with the snapshot of 20111207) and get this: /usr/local/src/trunk/objdir.withada/./prev-gcc/g++ -B/usr/local/src/trunk/objdir.withada/./prev-gcc/ -B/usr/i686-pc-cygwin/bin/ -nostdinc++ -B/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/src/.libs -B/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/libsupc++/.libs -I/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/include -I/usr/local/src/trunk/gcc/libstdc++-v3/libsupc++ -L/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/src/.libs -L/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -Wno-error -DHAVE_CONFIG_H -I. -Iada -I/usr/local/src/trunk/gcc/gcc -I/usr/local/src/trunk/gcc/gcc/ada -I/usr/local/src/trunk/gcc/gcc/../include -I/usr/local/src/trunk/gcc/gcc/../libcpp/include -I/usr/include -I/usr/include -I/usr/local/src/trunk/gcc/gcc/../libdecnumber -I/usr/local/src/trunk/gcc/gcc/../libdecnumber/bid -I../libdecnumber /usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o In file included from /usr/local/src/trunk/gcc/gcc/system.h:346:0, from /usr/local/src/trunk/gcc/gcc/ada/adaint.c:107: /usr/include/sys/wait.h: In function 'int __wait_status_to_int(const wait&)': /usr/include/sys/wait.h:77:61: error: declaration of C function 'int __wait_status_to_int(const wait&)' conflicts with /usr/include/sys/wait.h:75:12: error: previous declaration 'int __wait_status_to_int(int)' here /usr/include/sys/wait.h: In function 'pid_t wait(wait*)': /usr/include/sys/wait.h:81:40: error: declaration of C function 'pid_t wait(wait*)' conflicts with /usr/include/sys/wait.h:37:7: error: previous declaration 'pid_t wait(__wait_status_ptr_t)' here /usr/include/sys/wait.h: In function 'pid_t waitpid(pid_t, wait*, int)': /usr/include/sys/wait.h:83:71: error: declaration of C function 'pid_t waitpid(pid_t, wait*, int)' conflicts with /usr/include/sys/wait.h:38:7: error: previous declaration 'pid_t waitpid(pid_t, __wait_status_ptr_t, int)' here /usr/include/sys/wait.h: In function 'pid_t wait3(wait*, int, rusage*)': /usr/include/sys/wait.h:85:81: error: declaration of C function 'pid_t wait3(wait*, int, rusage*)' conflicts with /usr/include/sys/wait.h:39:7: error: previous declaration 'pid_t wait3(__wait_status_ptr_t, int, rusage*)' here /usr/include/sys/wait.h: In function 'pid_t wait4(pid_t, wait*, int, rusage*)': /usr/include/sys/wait.h:87:94: error: declaration of C function 'pid_t wait4(pid_t, wait*, int, rusage*)' conflicts with /usr/include/sys/wait.h:40:7: error: previous declaration 'pid_t wait4(pid_t, __wait_status_ptr_t, int, rusage*)' here Makefile:1054: recipe for target `ada/adaint.o' failed make[3]: *** [ada/adaint.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir.withada/gcc' Makefile:4140: recipe for target `all-stage2-gcc' failed make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir.withada' Makefile:18046: recipe for target `stage2-bubble' failed make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir.withada' Makefile:898: recipe for target `all' failed make: *** [all] Error 2 $ /usr/local/src/trunk/objdir.withada/prev-gcc/xgcc.exe -v Using built-in specs. COLLECT_GCC=/usr/local/src/trunk/objdir.withada/prev-gcc/xgcc Target: i686-pc-cygwin Configured with: /usr/local/src/trunk/gcc/configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-graphite --enable-lto --disable-symvers --program-suffix=-4 --enable-libgomp --enable-libssp --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libada CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind --enablelanguages=c,ada,c++,fortran,lto,objc,objc++ Thread model: posix gcc version 4.7.0 20111207 (experimental) [trunk revision 182082] (GCC) $ uname -a CYGWIN_NT-6.1-WOW64 LI004043 1.7.10s(0.255/5/3) 20111207 03:08:14 i686 Cygwin Does this symptom ring a bell for anyone? -- Cheers, /ChJ
Re: Suspicion of regression in uninitialized value detection
On 07/12/11 19:05, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/11 01:19, David Brown wrote: Would it be possible then to have switches for different levels, such as is done with the strict aliasing warnings? Well, there's two obvious levels... Not sure if there's a good way to get something in between. Do people often intentionally run gcc without any optimisations these days? Certainly. Compile speed and debugging being the primary reasons. I guess experiences vary. As I said, I find debugging easier with -O1 - but maybe that's because most of my work is on embedded targets, which usually means RISC cpus with plenty of registers. The unoptimised code for these is usually totally incomprehensible, and the target speed is several times slower, because of all the extra work done moving data onto and off from the stack. However, as was mentioned we're always going into SSA (as a result of the SSA->RTL expansion path), so that issue is gone. In my opinion, we should nuke -Wall - these warning options should all be enabled unless explicitly /disabled/ with the -W options. And -Werror should be enabled by default too. Just think how many bugs would be found in existing software if developers were pushed into using their tools effectively! Well, lots of folks would disagree with that suggestion. And that's the root of the problem with this kind of issue -- different developers have different needs. Any significant change we make in this space is probably going to make equal numbers of developers happy and mad at the same time. Obviously /my/ way of programming is /the/ correct way, and everyone should be forced to follow the same rules :-) mvh., David jeff
Re: Suspicion of regression in uninitialized value detection
On 12/7/2011 2:36 PM, David Brown wrote: \ I guess experiences vary. As I said, I find debugging easier with -O1 - but maybe that's because most of my work is on embedded targets, which usually means RISC cpus with plenty of registers. The unoptimised code for these is usually totally incomprehensible, and the target speed is several times slower, because of all the extra work done moving data onto and off from the stack. Sure, if you are memory constrained, then -O0 is a big problem, and I agree that reading -O1 machine code is much easier than reading -O0 code, but if you are just doing source level debugging in an environment with lots of space and CPU power to spare, -O0 is much more convenient. The worst thing for me about -O1 is arguments disappearing in the trace back, that's really a deal breaker.
Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h
On 07/12/2011 19:14, Christian Joensson wrote:
> I am trying to build gcc trunk on cygwin (with the snapshot of
> 20111207) and get this:
> /usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o
> In file included from /usr/local/src/trunk/gcc/gcc/system.h:346:0,
> from /usr/local/src/trunk/gcc/gcc/ada/adaint.c:107:
> /usr/include/sys/wait.h: In function 'int __wait_status_to_int(const wait&)':
> /usr/include/sys/wait.h:77:61: error: declaration of C function 'int
> __wait_status_to_int(const wait&)' conflicts with
> /usr/include/sys/wait.h:75:12: error: previous declaration 'int
> __wait_status_to_int(int)' here
> make[3]: *** [ada/adaint.o] Error 1
> Does this symptom ring a bell for anyone?
Ah, I didn't see it because I'm not using the snapshot (and I haven't been
testing C++ builds recently either).
> #ifdef __cplusplus
>
> inline int __wait_status_to_int (int __status)
> { return __status; }
> inline int __wait_status_to_int (const union wait & __status)
> { return __status.w_status; }
I can see why it happens: when adaint.c #includes sys/wait.h, it's already
one level deep inside extern "C" { ... } nesting. So those new overloads in
sys/wait.h (snapshot version) can't be name-mangled.
Any lurking standards lawyers out there? Is it valid to #include a C
standard header inside an extern "C" block? Should the Cygwin header use
extern "C++" on those declarations even though they're inside #ifdef
__cplusplus, or should adaint.c not #include things inside extern "C"?
cheers,
DaveK
Re: Suspicion of regression in uninitialized value detection
> "Robert" == Robert Dewar writes: Robert> Now the debugging at -O1 is hopeless (even parameters routinely Robert> disappear), and so I am forced to do everything at -O0. There's been a lot of work on gcc in this area. Please file bugs for cases you find. Tom
Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h
On Wednesday, 7 December 2011, Dave Korn wrote:
> On 07/12/2011 19:14, Christian Joensson wrote:
>> I am trying to build gcc trunk on cygwin (with the snapshot of
>> 20111207) and get this:
>
>> /usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o
>> In file included from /usr/local/src/trunk/gcc/gcc/system.h:346:0,
>> from /usr/local/src/trunk/gcc/gcc/ada/adaint.c:107:
>> /usr/include/sys/wait.h: In function 'int __wait_status_to_int(const wait&)':
>> /usr/include/sys/wait.h:77:61: error: declaration of C function 'int
>> __wait_status_to_int(const wait&)' conflicts with
>> /usr/include/sys/wait.h:75:12: error: previous declaration 'int
>> __wait_status_to_int(int)' here
>
>> make[3]: *** [ada/adaint.o] Error 1
>
>> Does thisy symptom ring a bell for anyone?
>
> Ah, I didn't see it because I'm not using the snapshot (and I haven't been
> testing C++ builds recently either).
>
>> #ifdef __cplusplus
>>
>> inline int __wait_status_to_int (int __status)
>> { return __status; }
>> inline int __wait_status_to_int (const union wait & __status)
>> { return __status.w_status; }
>
> I can see why it happens: when adaint.c #includes sys/wait.h, it's already
> one level deep inside extern "C" { ... } nesting. So those new overloads in
> sys/wait.h (snapshot version) can't be name-mangled.
>
> Any lurking standards lawyers out there? Is it valid to #include a C
> standard header inside an extern "C" block?
it's valid, but prevents overloading.
> Should the Cygwin header use
> extern "C++" on those declarations even though they're inside #ifdef
> __cplusplus, or should adaint.c not #include things inside extern "C"?
You could surround them in extern "C++", linkage specifications nest.
>
Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h
Jonathan Wakely writes: >> Should the Cygwin header use >> extern "C++" on those declarations even though they're inside #ifdef >> __cplusplus, or should adaint.c not #include things inside extern "C"? > > You could surround them in extern "C++", linkage specifications nest. ...but I think it would be better for adaint.c to not #include system header files inside extern "C". Ian
Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h
On 8 December 2011 01:09, Ian Lance Taylor wrote: > Jonathan Wakely writes: > >>> Should the Cygwin header use >>> extern "C++" on those declarations even though they're inside #ifdef >>> __cplusplus, or should adaint.c not #include things inside extern "C"? >> >> You could surround them in extern "C++", linkage specifications nest. > > ...but I think it would be better for adaint.c to not #include system > header files inside extern "C". Indeed, I sent a follow up message which the gcc list rejected because the android gmail app refuses to send plain text email. Here's what I said: Oh sorry, I missed that the question was about a /standard/ header. Not sure about that. I think it's invalid, the standard says: "Whether a name from the C standard library declared with external linkage has extern "C" or extern "C++" linkage is implementation-defined." It shouldn't be needed unless the header is quite broken, and might cause problems, as it has here. A well behaved header will put explicit extern "C++" around anything that need "C++" language linkage, to protect against such questionable behaviour from users.
Re: RFC - GCC Architectural Goals
> However, it is true that some patches are not in that category. In > general, we prefer to keep patch traffic in a single place > (gcc-patches@), but we use message tagging extensively. How about > '[trivial]'? If reviwer can pick up trivial patches easily by this way, I have no objection. :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: Suspicion of regression in uninitialized value detection
Robert Dewar writes: > The worst thing for me about -O1 is arguments disappearing in the trace > back, that's really a deal breaker. Wasn't Alexandre Oliva's "VTA" work supposed to help this kind of thing...? Did that ever get merged? -miles -- Joy, n. An emotion variously excited, but in its highest degree arising from the contemplation of grief in another.
Re: Suspicion of regression in uninitialized value detection
Miles Bader writes: > Robert Dewar writes: >> The worst thing for me about -O1 is arguments disappearing in the trace >> back, that's really a deal breaker. > > Wasn't Alexandre Oliva's "VTA" work supposed to help this kind of > thing...? Did that ever get merged? It did get merged. My sense from using it is that before VTA, debugging optimized code would sometimes show the wrong value for a function argument. With VTA, the debugger is much more reliable about reporting that it does not know the value of a function argument. So while this is clearly an incremental improvement, I haven't noticed that gcc and gdb have gotten much better at actually knowing the value. Ian
