gcc 6.3.0 compiling as user gives permission denied
compiling gcc as a part of toolchain (linux from scratch) gives me the
following error when compiling as user
but compiles fine when compiling as root:
--prefix=/tools \
--target=x86_64-lfs-linux-gnu \
--with-sysroot=/media/usbdisk \
--with-glib-version=2.25 \
--with-newlib \
--without-headers \
--with-local-prefix=/tools\
--with-native-system-header-dir=/tools/include \
--disable-nls \
--disable-shared \
--disable-multilib \
--disable-decimal-float \
--disable-threads \
--disable-libatomic \
--disable-libgomp \
--disable-libitm \
--disable-libquadmath \
--disable-libssp \
--disable-libvtv \
--disable-nls \
--with-system-zlib \
--with-gxx-include-dir=/tools/x86_64-lfs-linux-gnu/include/c++/6.3.0 \
--disable-libmpx \
--enable-languages=c,c++ \
--disable-libstdcxx"
configure: error: in
`/run/media/void/minnow/build/gcc-6.3.0/x86_64-lfs-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [Makefile:11601: configure-target-libgcc] Error 1
configure:3462: /run/media/void/minnow/build/gcc-6.3.0/./gcc/xgcc
-B/run/media/void/minnow/build/gcc-6.3.0/./gcc/
-B/tools/x86_64-lfs-linux-gnu/bin/ -B/tools/x86_64-lfs-linux-gnu/lib/
-isystem /tools/x86_64-lfs-linux-gnu/include -isystem
/tools/x86_64-lfs-linux-gnu/sys-include-o conftest -g -O2
conftest.c >&5
cc1: error: /tools/x86_64-lfs-linux-gnu/include: Permission denied
cc1: error: /tools/x86_64-lfs-linux-gnu/sys-include: Permission denied
configure:3465: $? = 1
configure:3653: checking for suffix of object files
configure:3675: /run/media/void/minnow/build/gcc-6.3.0/./gcc/xgcc
-B/run/media/void/minnow/build/gcc-6.3.0/./gcc/
-B/tools/x86_64-lfs-linux-gnu/bin/ -B/tools/x86_64-lfs-linux-gnu/lib/
-isystem /tools/x86_64-lfs-linux-gnu/include -isystem
/tools/x86_64-lfs-linux-gnu/sys-include-c -g -O2 conftest.c >&5
cc1: error: /tools/x86_64-lfs-linux-gnu/include: Permission denied
cc1: error: /tools/x86_64-lfs-linux-gnu/sys-include: Permission denied
configure:3679: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3693: error: in
`/run/media/void/minnow/build/gcc-6.3.0/x86_64-lfs-linux-gnu/libgcc':
configure:3695: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Marek
gcc 7.2.0 error: no include path in which to search for stdc-predef.h
Hi, while compiling 7.2.0 im getting the following: cc1: error: no include path in which to search for stdc-predef.h cc1: note: self-tests are not enabled in this build In file included from ./../gcc/config.h:6:0, from /run/media/void/minnow/src/gcc-7.2.0/libcc1/libcc1plugin.cc:27: ./../gcc/auto-host.h:779:0: warning: "HAVE_DECL_BASENAME" redefined #define HAVE_DECL_BASENAME 0 In file included from /run/media/void/minnow/src/gcc-7.2.0/libcc1/libcc1plugin.cc:20:0: ./cc1plugin-config.h:6:0: note: this is the location of the previous definition #define HAVE_DECL_BASENAME 1 In file included from ./../gcc/config.h:6:0, from /run/media/void/minnow/src/gcc-7.2.0/libcc1/libcp1plugin.cc:28: ./../gcc/auto-host.h:779:0: warning: "HAVE_DECL_BASENAME" redefined #define HAVE_DECL_BASENAME 0 In file included from /run/media/void/minnow/src/gcc-7.2.0/libcc1/libcp1plugin.cc:21:0: ./cc1plugin-config.h:6:0: note: this is the location of the previous definition #define HAVE_DECL_BASENAME 1 configure: error: in `/run/media/void/minnow/build/gcc-7.2.0/x86_64-lfs-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [Makefile:12068: configure-target-libgcc] Error 1 make: *** [Makefile:880: all] Error 2 If gcc is able to recognize between sources in one dir and objects in another dir Does a patch exist to fix this? thanks, Marek
Re: gcc 7.2.0 error: no include path in which to search for stdc-predef.h
It seems the last error preceeding the "suffix" error is "no include path in which to search for stdc-predef.h" "This error message is quite misleading and frequently the problem has nothing to do with the message. You have to check the file 'config.log' in the directory where the error occurred. In the example above, you would have to check the 'config.log' file in the directory '/home/manu/gcc/gcc/i686-pc-linux-gnu/libgcc'. There might be several test programs that failed during the configuration, but some of these failures are non-critical. Check for the last error entry in the file. I wonder where to find stdc-predef.h or whether it's generated by gcc during compile time. I'm also compiling against musl. Marek On Tue, Nov 28, 2017 at 12:19 AM, Jonathan Wakely wrote: > N.B. the gcc@gcc.gnu.org mailing list is not for support. For help > building or using GCC use the gcc-h...@gcc.gnu.org mailing list (see > https://gcc.gnu.org/lists.html for information on the lists and what's > on-topic). > > On 27 November 2017 at 20:23, Jim Wilson wrote: >> On 11/26/2017 11:09 PM, Marek wrote: >>> >>> Hi, >>> >>> while compiling 7.2.0 im getting the following: >>> >>> cc1: error: no include path in which to search for stdc-predef.h >>> cc1: note: self-tests are not enabled in this build >> >> >> This doesn't appear to be a build error. Configure runs the compiler to >> check for features, and if a check fails, then the feature is disabled. This >> is normal, and nothing to worry about. Though the message is unusual. If >> the compiler is the one you just built, there might be something wrong with >> it. Or there might be a minor configure script bug. >> >>> configure: error: in >>> `/run/media/void/minnow/build/gcc-7.2.0/x86_64-lfs-linux-gnu/libgcc': >>> configure: error: cannot compute suffix of object files: cannot compile >>> See `config.log' for more details. >>> make[1]: *** [Makefile:12068: configure-target-libgcc] Error 1 >>> make: *** [Makefile:880: all] Error 2 >> >> >> This is the real build error. You need to look at the config.log file in >> the directory where configure failed to see what the problem is. This is >> usually a build environment problem of some sort. > > There's a FAQ entry about this error, please read it: > https://gcc.gnu.org/wiki/FAQ#configure_suffix > >>> If gcc is able to recognize between sources in one dir and objects in >>> another dir >> >> >> Yes. The usual way to configure gcc is something like >> mkdir build >> cd build >> ../gcc/configure > > See https://gcc.gnu.org/wiki/InstallingGCC for more information, > including how to avoid the error above.
Fwd: gcc 7.2.0 error: no include path in which to search for stdc-predef.h
looking at config.log i see theses errors:
configure:5941: checking for isl 0.15 or later
configure:5954: gcc -o conftest -g -O2 -I$$r/$(HOST_SUBDIR)/gmp
-I$$s/gmp -I$$r/$(HOST_SUBDIR)/mpfr/src -I$$s/mpfr/src -I$$s/mpc/src
-lisl -L$$r/$(HOST_SUBDIR)/gmp/.libs
-L$$r/$(HOST_SUBDIR)/mpfr/src/.libs -L$$r/$(HOST_SUBDIR)/mpc/src/.libs
-lmpc -lmpfr -lgmp conftest.c -lisl -lgmp >&5
conftest.c: In function 'main':
conftest.c:14:1: warning: implicit declaration of function
'isl_options_set_schedule_serialize_sccs'; did you mean
'isl_options_set_schedule_split_scaled'?
[-Wimplicit-function-declaration]
isl_options_set_schedule_serialize_sccs (NULL, 0);
^~~
isl_options_set_schedule_split_scaled
/tmp/ccmCcjMj.o: In function `main':
/run/media/void/minnow/build/gcc-7.2.0/conftest.c:14: undefined
reference to `isl_options_set_schedule_serialize_sccs'
collect2: error: ld returned 1 exit status
configure:5954: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define LT_OBJDIR ".libs/"
| /* end confdefs.h. */
| #include
| int
| main ()
| {
| isl_options_set_schedule_serialize_sccs (NULL, 0);
| ;
| return 0;
| }
configure:5961: result: no
configure:5965: result: required isl version is 0.15 or later
configure:4314: $? = 0
configure:4303: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-musl/7.2.0/lto-wrapper
Target: x86_64-linux-musl
Configured with: /builddir/gcc-7.2.0/configure
--build=x86_64-linux-musl --enable-fast-character
--disable-libsanitizer --disable-symvers libat_cv_have_ifunc=no
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--libexecdir=/usr/lib --libdir=/usr/lib --enable-threads=posix
--enable-__cxa_atexit --disable-multilib --with-system-zlib
--enable-shared --enable-lto --enable-vtable-verify
--enable-linker-build-id --enable-serial-configure --disable-werror
--disable-nls --enable-default-pie --enable-default-ssp
--enable-checking=release --disable-libstdcxx-pch --with-isl
--with-linker-hash-style=gnu --disable-libunwind-exceptions
--disable-target-libiberty
--with-default-libstdcxx-abi=gcc4-compatible
--enable-languages=c,c++,objc,obj-c++,fortran,lto
Thread model: posix
gcc version 7.2.0 (GCC)
configure:4314: $? = 0
configure:4303: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:4314: $? = 1
configure:4303: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean
'--version'?
gcc: fatal error: no input files
compilation terminated.
configure:4887: $? = 0
configure:4876: g++ -v >&5
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-musl/7.2.0/lto-wrapper
Target: x86_64-linux-musl
Configured with: /builddir/gcc-7.2.0/configure
--build=x86_64-linux-musl --enable-fast-character
--disable-libsanitizer --disable-symvers libat_cv_have_ifunc=no
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--libexecdir=/usr/lib --libdir=/usr/lib --enable-threads=posix
--enable-__cxa_atexit --disable-multilib --with-system-zlib
--enable-shared --enable-lto --enable-vtable-verify
--enable-linker-build-id --enable-serial-configure --disable-werror
--disable-nls --enable-default-pie --enable-default-ssp
--enable-checking=release --disable-libstdcxx-pch --with-isl
--with-linker-hash-style=gnu --disable-libunwind-exceptions
--disable-target-libiberty
--with-default-libstdcxx-abi=gcc4-compatible
--enable-languages=c,c++,objc,obj-c++,fortran,lto
Thread model: posix
gcc version 7.2.0 (GCC)
configure:4887: $? = 0
configure:4876: g++ -V >&5
g++: error: unrecognized command line option '-V'
g++: fatal error: no input files
compilation terminated.
configure:4887: $? = 1
configure:4876: g++ -qversion >&5
g++: error: unrecognized command line option '-qversion'; did you mean
'--version'?
g++: fatal error: no input files
compilation terminated.
On Fri, Dec 1, 2017 at 11:23 AM, Kai Ruottu wrote:
> Kai Ruottu kirjoitti 1.12.2017 klo 12:02:
>>
>> Marek kirjoitti 1.12.2017 klo 10:51:
>>>
>>> It seems the last error preceeding the "suffix" error is "no include
>>> path in which to search for stdc-predef.h"
>>> I wonder where to find stdc-predef.h or whether it's generated by gcc
>>> during compile time.
>>
>>
>> This file comes with newer glibc versions. For instance glibc-2.17 coming
>> with CentOS 7
>> has it in its '/usr/include'. Older glibc versions don
AVR indirect_jump addresses limited to 16 bits
Hello, I'm looking into adding support for ATmega256x and larger devices to the AVR port. This means that program memory addresses no longer fit in 16 bits - and I'm looking how to avoid making pointers larger. Jumps and function calls are no problem as long as they use labels (constant addresses). Indirect jumps and calls (address in a register) are a problem. For function calls, it seems easy - generate each function in two parts, placed by linker script in different sections: - jump to function body - function body and locate the jumps below 128K (64K words), while the function body can be anywhere in the address space. If you need to take a 16-bit address of the function, simply take the address of the jump. The added runtime overhead of the jump is a small price to pay compared to making pointers 3 or 4 bytes long (instead of 2 bytes) on the AVR. But, now there is the "indirect_jump" pattern - mandatory, even though I haven't yet seen it actually used in real applications on the AVR. The question is, how to make sure that if indirect_jump ever happens to be used, its target address is guaranteed to fit in 16 bits? Where do these pointers come from? (Like function pointers come from taking the address of a function, and this may be solved as described above.) Looking at the source, I've found one use of indirect_jump so far - returning from a function with some data still on the stack. I suspect this may not work properly on the AVR anyway, because return address is stored on the stack in the wrong byte order - big endian, even though the AVR is little endian. Anything else? Thanks, Marek
Re: AVR indirect_jump addresses limited to 16 bits
On Sat, Mar 19, 2005 at 01:51:05PM -0500, Paul Schlie wrote: > - Fully agree, just can't keep from wondering if this may be most > efficiency accomplish by simply requiring the alignment of all > function entry points to be two instruction word aligned. Thereby This only doubles the available address space, and I'd rather not do it all again (this time with 4-word alignment) if 512K chips appear. Supporting the maximum possible address space on the AVR would require 64-word function alignment, and shifting the word address by 6. But function entry points are not the only problem - indirect jumps are another (as you can see in the subject of my message), they can point somewhere within a function (so function alignment may not help here). On the other hand, indirect_jump is rarely seen, so it must be correct but doesn't have to be very efficient (OK if it costs even a few more instructions to stay in the low 64K words). So, I'm trying to figure out when the indirect_jump pattern can actually be generated on the AVR (haven't yet seen it in any real application), and where does the pointer comes from (to see if the jump target can be moved to the low 64K words somehow). Marek
Re: AVR indirect_jump addresses limited to 16 bits
On Sat, Mar 19, 2005 at 04:38:28PM -0500, Paul Schlie wrote: > - understood, however unlikely; observing it will likely take Atmel at > least 2-3 years to stabilize production of the 256K devices, and larger > device volume potential vs. competitive offerings couldn't likely justify > their development (as just an opinion). I thought the same about 128K devices, and then 256K devices appeared :) > - Sorry, I'm confused; can you give me an example of legal C expression > specifying an indirect jump to an arbitrary location within a function? Good question - I can't. On the other hand, the manual says: `indirect_jump' An instruction to jump to an address which is operand zero. *This pattern name is mandatory on all machines.* Why would it be mandatory if it was not truly needed? If the manual is correct, it seems this pattern is truly needed (not just an optional optimization like some other patterns). If it is impossible on the AVR, it could be implemented with invalid assembler output (so we get an error if "impossible" ever happens). But I'd like to be sure if this is really the case. GCC is not only a C compiler, perhaps indirect_jump is needed for some other language? Thanks, Marek
Re: AVR indirect_jump addresses limited to 16 bits
On Sat, Mar 19, 2005 at 06:37:54PM -0500, Paul Schlie wrote: > - or possibly GCC may try to be clever by jumping to no-return attribute > function calls? Such "trying to be clever" would most likely be optional. Again, why is indirect_jump _mandatory_ on all machines? Please, don't try to be too clever :) - just look at the GCC source and try to figure out exactly what is indirect_jump used for, and how much of this (if anything) matters for the AVR port. If the address of a label is loaded into a register, then we have to switch to a different section around that label: /* ... */ jmp label .section .text_low,"ax",@progbits label: jmp 1f .text 1: /* ... */ then it will be safe to load the address of the label into a register, no need to do anything with the highest bits as pm_hh8(label) == 0: ldi r30,pm_lo8(label) ldi r31,pm_hi8(label) /* ... */ ijmp; PC <- 0:r31:r30 Note that this adds two jumps around the label, so we only want to do it infrequently - if the address of the label is loaded into a register (not if the only users of the label are direct jumps). Thanks, Marek
Re: AVR indirect_jump addresses limited to 16 bits
On Sun, Mar 20, 2005 at 02:58:29AM +0100, Giovanni Bajo wrote:
> It is possible in GNU C at least:
>
> int foo(int dest)
> {
>__label__ l1, l2, l3;
>void *lb[] = { &&l1, &&l2, &&l3 };
>int x = 0;
>
>goto *lb[dest];
>
> l1:
>x += 1;
> l2:
>x += 1;
> l3:
>x += 1;
>return x;
> }
Thanks for explaining this. So yes, unfortunately we have to support
indirect_jump properly (I was hoping it was only for something like
trampolines, which can't work on the AVR anyway).
I was wrong about needing two jumps - just one for each label should
be enough, because switching to .text_low and back to .text doesn't
disrupt the normal flow of instructions in .text. So, it's not that
bad, really the same thing for indirect jumps and calls (using function
pointers), each affected label needs to be output like this:
.section .text_low,"ax",@progbits
label:
jmp 1f
.text
1:
This includes all global labels (visible to other object files, like
function entry points), and local labels referenced by anything other
than direct jumps or calls).
On the other hand, branches within the same function should avoid the
extra jump and go to "1:" directly. If the same label is used in both
ways (direct jump/branch, and address taken), two separate labels (at
the same address) should be output for both of these uses, but I'm not
sure how to do this in GCC. Any suggestions?
(The problem can be seen by adding something like "if (dest > 2) goto l3;"
above the goto in the original example: in the assembler output, there is
only one label corresponding to l3 which is both 1. referenced with pm()
and 2. target of a branch for which .text_low would be out of range.)
Marek
Re: AVR indirect_jump addresses limited to 16 bits
On Sun, Mar 20, 2005 at 04:29:01PM -0800, Richard Henderson wrote: > The easiest way is to do this in the linker instead of the compiler. > See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This > has the distinct advantage that you do not commit to the creation of > an indirect jump until you discover that the target label is outside > the low 64k. Looks perfect to me. So we are not the first architecture needing such tricks... AVR would need 3 new relocs, used like this: .word pm16(label) ldi r30,pm16_lo8(label) ldi r31,pm16_hi8(label) and the linker can do the rest of the magic (add jumps in a section below 64K words if the label is above). Cc: to Denis, as I may need help actually implementing these changes (you know binutils internals much better than I do). Thanks, Marek
specification for gcc compilers on sparc and powerpc
Hello I appreciate your work and do not want to bother you, but I hope, that somebody will send me some helpful answer on my question. Is anyone can send me his 'specs' file (contains configuration for working compiler) ?? (this is standard localization: " /usr/lib/gcc-lib/name_of_compiler/lib/version/specs " this is, in example, on my computer: " /gcc/lib/gcc/sparc-elf-linux/3.4.3/specs " ) I didn't mention I am looking for versions created on SPARC and PowerPC processors. I especially desire compiler compiled for sparclite86x and IBM's PowerPC (but that is not indespensable condition) In advance, thank you very much for any help !!! I enclosure (for certainty) my mail address, please send me - [EMAIL PROTECTED] -- Startuj z INTERIA.PL! >>> http://link.interia.pl/f186c
specs file
I as sorry I repeat my appeal, but if really nobody works on Sparc or PowerPC processors and nobody wants to send me 'specs' file from directory > " /usr/lib/gcc-lib/name_of_compiler/lib/version/specs " or similar ??? One more time, thank you for help! Nie dzwon do Londynu... zanim nie sprawdzisz HALO.interia.pl Tutaj: http://link.interia.pl/f1870
Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions
On Wed, Jan 22, 2020 at 04:05:37PM +, Richard Sandiford wrote: > "Richard Earnshaw (lists)" writes: > > On 21/01/2020 17:20, Jason Merrill wrote: > >> On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: > >>> On 21/01/2020 15:39, Jakub Jelinek wrote: > >>>> On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) > >>>> wrote: > >>>>>> Some examples would be useful I'd say, e.g. it is unclear in what > >>>>>> way you > >>>>>> want the PR number to be appended, shall it be > >>>>>> something: whatever words describe it PR12345 > >>>>>> or > >>>>>> something: whatever words describe it (PR12345) > >>>>>> or > >>>>>> something: whatever words describe it: PR12345 > >>>>>> or > >>>>>> something: whatever words describe it [PR12345] > >>>>>> or something else? > >>>>> > >>>>> Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, > >>>>> I'm not > >>>>> too worried. I'd be happy with [PR #], but if folk want > >>>>> something else, > >>>>> please say so quickly... > >>>> > >>>> [PR 12345] or [PR #12345] is bad, because the bugzilla won't > >>>> underline it, > >>>> it needs to be either PR12345 word, or PR component/12345 . > >>> > >>> ok, lets go with [PR] then. > >> > >> Doesn't this use of [] have the same problem with git am? > > > > No, because only 'leading' [] blocks are removed - git mailinfo --help > > > >> > >> My summaries are often describing the bug I'm fixing, i.e. > >> > >> [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs. > >> > >> which is also the first line of my ChangeLog entry. I think you are > >> proposing > >> > >> [COMMITTED] c++: Fix anon-namespace reference temp clash between TUs > >> (PR91476) > >> > >> which can no longer be shared with the ChangeLog. > >> > > > > I was trying to unify this with glibc. They specify the bug number at > > the end of the line. > > > > We can diverge if it's generally felt to be important, but details like > > this create needless friction for folk working in both communities. > > +1 for "component: Summary [PRn]" FWIW. > > PR bz-component/n works well for C++. The problem is that so many > other PRs come under tree-optimization and rtl-optimization, which > eat up a lot of subject line characters without narrowing things down > very much. "cselib: ... [PRn]" is both shorter and more descriptive > than "PR rtl-optimization/n - ", etc. Yeah, the cselib version definitely looks preferable to me. What if a patch touches more than just the C++ FE, do we want "c,c++:"? Though kernel uses net: sched: act_ctinfo: fix memory leak locking/rwsem: Fix kernel crash when spinning on RWSEM_OWNER_UNKNOWN If a patch touches various spots in the optimizers, maybe we can just go with "tree-opt:" or "rtl:"? Further, I suppose multiple PRs fixed by a single patch would look like: c++: Implement DR 666 [PR57, PR12345] Marek
Re: Warning on move and dereference of unique_ptr in the same expression
On Mon, Feb 03, 2020 at 09:26:40PM +0100, Allan Sandfeld Jensen wrote: > Hello gcc > > I have now twice hit obscure bugs in Chromium that crashed on some compilers > but not on others, and didn't produce any warnings on any compiler. I would > like to know if this code is as undefined as I think it is, and if it would > make sense to have gcc warn about it. > > Both cases basically has this form: > > std::unique_ptr a; > > a->b->callMethod(something, bind(callback, std::move(a))); > > This crashed with MSVC and gcc 5, but not with newer gcc or with clang. You mean the application itself, not the compiler, presumably. > When it crashes it is because the arguments and the move therein have been > evaluated before a->b is resolved. > > I assume this is undefined behavior? So why isn't the warning for using and > modifying in the same expression triggered? This should be defined in C++17, with P0145 in particular: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf which says that the expression that names the function is sequenced before every argument expression and every default argument. Marek
Re: How do we write unused arguments?
On Thu, Nov 05, 2015 at 10:32:11AM +0100, Bernd Schmidt wrote: > When reviewing patches I'm never quite sure which of the following we should > be using: > > some_target_hook (tree decl, machine_mode mode ATTRIBUTE_UNUSED) > > some_target_hook (tree decl, machine_mode ARG_UNUSED (mode)) > > some_target_hook (tree decl, machine_mode /* mode */) > > some_target_hook (tree decl, machine_mode) > > Any opinions? I'm leaning towards the last version since it's idiomatic in > the language we're using and has the least amount of visual clutter. If no > one comments, I'll start enforcing that in patch reviews. Currently no one > seems sure and everything is getting totally inconsistent. FWIW, I also like the last version best. Marek
Re: Extraneous newline emitted between error messages in GCC 6
On Mon, Dec 21, 2015 at 01:12:33PM -0500, Patrick Palka wrote: > GCC 6, compared to GCC 5, now emits an extra newline between error > messages. Is this intended? > > $ cat error.c > int x = a; > int y = b; > $ gcc-5 error.c > error.c:1:9: error: ‘a’ undeclared here (not in a function) > int x = a; > ^ > error.c:2:9: error: ‘b’ undeclared here (not in a function) > int y = b; > ^ > $ gcc-6 error.c > error.c:1:9: error: ‘a’ undeclared here (not in a function) > int x = a; > ^ > > error.c:2:9: error: ‘b’ undeclared here (not in a function) > int y = b; > ^ > > $ Started with r229884: Reimplement diagnostic_show_locus, introducing rich_location classes. I think it is a bug and should be fixed. Marek
Re: void* vs void *
On Fri, Jan 29, 2016 at 07:13:00PM +0100, Magnus Fromreide wrote:
> I just noticed that the C and C++ compiler output pointer types differently:
>
> Consider
>
> int i;
> printf("%p", &i);
>
> When compiled as C that gives the warning
>
> format '%p' expects argument of type 'void *', but argument 2 has type 'int *'
>
> but when compiled as C++ it gives the warning
>
> format '%p' expects argument of type 'void*', but argument 2 has type 'int*'
>
> Why are they different?
So, C and C++ have different printers (C has c_tree_printer and C++
cp_printer). But in this case the difference comes from format_type_warning:
2657 p = (char *) alloca (pointer_count + 2);
2658 if (pointer_count == 0)
2659 p[0] = 0;
2660 else if (c_dialect_cxx ())
2661 {
2662 memset (p, '*', pointer_count);
2663 p[pointer_count] = 0;
2664 }
2665 else
2666 {
2667 p[0] = ' ';
2668 memset (p + 1, '*', pointer_count);
2669 p[pointer_count + 1] = 0;
2670 }
So the C FE gets the space but the C++ FE does not. The reason for this is
probably to keep in sync with the C++ printer which doesn't put space before
'*'; in dump_type_prefix we have
741 if (TYPE_PTR_P (t))
742 pp_star (pp);
so there's no pp_cxx_whitespace before '*'.
I like the version with space more; maybe we could change this in the next
stage1.
Marek
Re: nonnull, -Wnonnull, and do/while
On Tue, Feb 16, 2016 at 10:43:08AM +0100, Stefan Sobernig wrote: > Under a recent gcc 6 [*], we run into -Wnonnull warnings using the > nonnull attribute: Yes, this warning has been enhanced for GCC 6. > test.c: In function 'f': > test.c:16:14: warning: nonnull argument 's' compared to NULL [-Wnonnull] >} while (s != NULL); > > Am I missing sth.? Is this a false positive? Well, it's just that "s" has the nonnull attribute so the compiler thinks it should never be null in which case comparing it to null should be redundant. Doesn't seem like a false positive to me, but maybe someone else feels otherwise. Marek
Re: nonnull, -Wnonnull, and do/while
On Tue, Feb 16, 2016 at 11:11:21AM +0100, Jakub Jelinek wrote: > On Tue, Feb 16, 2016 at 11:04:38AM +0100, Marek Polacek wrote: > > On Tue, Feb 16, 2016 at 10:43:08AM +0100, Stefan Sobernig wrote: > > > Under a recent gcc 6 [*], we run into -Wnonnull warnings using the > > > nonnull attribute: > > > > Yes, this warning has been enhanced for GCC 6. > > > > > test.c: In function 'f': > > > test.c:16:14: warning: nonnull argument 's' compared to NULL [-Wnonnull] > > >} while (s != NULL); > > > > > > Am I missing sth.? Is this a false positive? > > > > Well, it's just that "s" has the nonnull attribute so the compiler thinks it > > should never be null in which case comparing it to null should be redundant. > > Doesn't seem like a false positive to me, but maybe someone else feels > > otherwise. > > The nonnull attribute should be solely about the value that is passed to the > function, it doesn't tell anything about the value of the argument after > it is changed. So IMHO this warning change should be reverted and instead > we should warn somewhere soon after going into SSA, only when > the SSA_NAME_IS_DEFAULT_DEF of the PARM_DECL which has non-NULL attribute > is compared to NULL. In that case I take back what I wrote, sorry. Marek
Re: increase alignment of global structs in increase_alignment pass
On Tue, Feb 23, 2016 at 09:49:37PM +0530, Prathamesh Kulkarni wrote:
> diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
> index 2b25b45..a6af535 100644
> --- a/gcc/tree-vectorizer.c
> +++ b/gcc/tree-vectorizer.c
> @@ -794,6 +794,75 @@ make_pass_slp_vectorize (gcc::context *ctxt)
> This should involve global alignment analysis and in the future also
> array padding. */
>
> +static unsigned get_vec_alignment_for_decl (tree);
Why the forward decl? Better to topologically sort the functions.
Also, the functions are missing comments.
> +static unsigned
> +get_vec_alignment_for_array_decl (tree array_decl)
> +{
> + tree type = TREE_TYPE (array_decl);
> + gcc_assert (TREE_CODE (type) == ARRAY_TYPE);
> +
> + tree vectype = get_vectype_for_scalar_type (strip_array_types (type));
> + return (vectype) ? TYPE_ALIGN (vectype) : 0;
> +}
> +
> +static unsigned
> +get_vec_alignment_for_record_decl (tree record_decl)
> +{
> + tree type = TREE_TYPE (record_decl);
> + gcc_assert (TREE_CODE (type) == RECORD_TYPE);
> + unsigned max_align = 0, alignment;
> + HOST_WIDE_INT offset;
> +
> + if (DECL_ARTIFICIAL (record_decl) || TYPE_PACKED (type))
> +return 0;
> +
> + for (tree field = first_field (type);
> + field != NULL_TREE;
> + field = DECL_CHAIN (field))
> +{
> + /* C++FE puts node "._0" of code TYPE_DECL. skip that. */
> + if (TREE_CODE (field) != FIELD_DECL)
> + continue;
> +
> + offset = int_byte_position (field);
> + alignment = get_vec_alignment_for_decl (field);
> + if (alignment
> + && (offset % (alignment / BITS_PER_UNIT) == 0)
> + && (alignment > max_align))
> + max_align = alignment;
> +}
> +
> + return max_align;
> +}
> +
> +static unsigned
> +get_vec_alignment_for_decl (tree decl)
> +{
> + if (decl == NULL_TREE)
> +return 0;
> +
> + gcc_assert (DECL_P (decl));
> +
> + static unsigned alignment = 0;
> + tree type = TREE_TYPE (decl);
> +
> + switch (TREE_CODE (type))
> +{
> + case ARRAY_TYPE:
> + alignment = get_vec_alignment_for_array_decl (decl);
> + break;
> + case RECORD_TYPE:
> + alignment = get_vec_alignment_for_record_decl (decl);
> + break;
> + default:
> + alignment = 0;
> + break;
> +}
> +
> + return (alignment > DECL_ALIGN (decl)) ? alignment : 0;
> +}
> +
> static unsigned int
> increase_alignment (void)
> {
> @@ -804,23 +873,14 @@ increase_alignment (void)
>/* Increase the alignment of all global arrays for vectorization. */
>FOR_EACH_DEFINED_VARIABLE (vnode)
> {
> - tree vectype, decl = vnode->decl;
> - tree t;
> + tree decl = vnode->decl;
>unsigned int alignment;
>
> - t = TREE_TYPE (decl);
> - if (TREE_CODE (t) != ARRAY_TYPE)
> -continue;
> - vectype = get_vectype_for_scalar_type (strip_array_types (t));
> - if (!vectype)
> -continue;
> - alignment = TYPE_ALIGN (vectype);
> - if (DECL_ALIGN (decl) >= alignment)
> -continue;
> + alignment = get_vec_alignment_for_decl (decl);
>
> - if (vect_can_force_dr_alignment_p (decl, alignment))
> + if (alignment && vect_can_force_dr_alignment_p (decl, alignment))
> {
> - vnode->increase_alignment (TYPE_ALIGN (vectype));
> + vnode->increase_alignment (alignment);
>dump_printf (MSG_NOTE, "Increasing alignment of decl: ");
>dump_generic_expr (MSG_NOTE, TDF_SLIM, decl);
>dump_printf (MSG_NOTE, "\n");
Marek
Re: Additional BOFs for the GNU Cauldron?
On Fri, Sep 02, 2016 at 11:19:54AM +0200, Richard Biener wrote: > > There seems to be plenty of slots available on the 2nd track to > schedule additional BOFs. So I'd gather if there is interest > in discussing > > A) Unit testing (GIMPLE FE, RTL FE, the existing unit-testing), > basically how people feel about moving forward here and how > this would affect the current testsuite structure > > B) GIMPLE evolution. With LTO early debug we could finally remove > some tree slack at some point in the compilation. There is > also increasing need to somehow represent multiple outputs > from a GIMPLE stmt (we've used complex types as a workaround > in some cases) -- esp. if we would consider moving GIMPLE further > into the backend area by lowering it and for example performing > instruction selection on GIMPLE (we'd need to represent flag > registers, etc.) > > C) Vectorizer. There's no vectorizer specific talk yet, the usual > suspects would be an update from the we-rewrite-the-vectorizer > folks and ideas about how to improve cost modeling. > > If there's no strong interest in any of the above we can schedule > stuf as needed at the Cauldron itself as well. I'd be interested in all of them. Marek
Re: tree-prof parallel make check failures
On Tue, Sep 20, 2016 at 05:29:03PM -0600, Martin Sebor wrote: > I'm seeing a number of failures in different tests in the tree-prof > directory when I run make check in parallel none of which are > reproducible with -j1. I don't see anything about in Bugzilla or > in recent test results. Has anyone noticed this or am I missing > something? I'm seeing those too and it's very bothering. I think Andi Kleen had some patches to fix these, but seems it needs to be fixed more. Marek
Re: Problem with 447.dealII in spec2006 because of r240707
On Tue, Oct 04, 2016 at 08:38:00AM -0700, Andrew Pinski wrote: > On Tue, Oct 4, 2016 at 8:33 AM, Bill Seurer wrote: > > parameter_handler.cc: In member function 'double > > ParameterHandler::get_double(const string&) const': > > parameter_handler.cc:777:28: error: ISO C++ forbids comparison between > > pointer and integer [-fpermissive] > >AssertThrow ((s.c_str()!='\0') || (*endptr == '\0'), > > ^ > > With the recent revision r240707 comparing a pointer with \0 became an > > error. Unfortunately this is used in several spots in the test case > > 447.dealII in spec2006 (one example above). There doesn't appear to be a > > way to disable this error check and we're not supposed to change the spec > > test cases. Any ideas on how to work around this? > > Did you try -fpermissive ? Because that seems like it was listed ... -fpermissive ought to help, but really best would be to use NULL instead of '\0'... Marek
Re: History of GCC
I think you can learn a lot if you follow the Changes pages, so e.g.
<https://gcc.gnu.org/gcc-6/changes.html>, and go back down the history until
you reach the ancient <https://gcc.gnu.org/gcc-3.1/changes.html>.
Marek
Re: [PATCH] tell gcc optimizer to never introduce new data races
On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote: > On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote: > > +# Tell gcc to never replace conditional load with a non-conditional one > > +KBUILD_CFLAGS += $(call cc-option,--param allow-store-data-races=0) > > + > > Why do we not want: -fmemory-model=safe? And should we not at the very > least also disable packed-store-data-races? Note that the option does not exist, even though it is mentioned in the documentation. Marek
Re: Got this one back (too large: 6.4 Mb) from gcc-results:
On Thu, Jul 03, 2014 at 07:06:29PM +0200, Toon Moene wrote: > Compiler version: 4.10.0 20140702 (experimental) (GCC) > Platform: x86_64-unknown-linux-gnu > configure flags: --prefix=/home/toon/compilers/install --with-gnu-as > --with-gnu-ld --with-build-config=bootstrap-ubsan --enable-languages=all > --disable-multilib --disable-nls --with-arch=core-avx2 --with-tune=core-avx2 > > Note: --with-build-config=bootstrap-ubsan > > Apparently, the bugs went wild ... I suspect that's because: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01549.html which will go away if/when we fix: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01624.html But I'm only guessing. Marek
Re: GCC version bikeshedding
On Sun, Jul 20, 2014 at 07:01:46PM +0200, Jakub Jelinek wrote:
> Ian/Jason, is that your understanding too? In any case, we should mention
> it on gcc.gnu.org/index.html, in develop.html and perhaps a few other spots.
Also it'd be nice to create htdocs/gcc-5.0/changes.html, so we can
start adding new features there. Gerald?
Marek
Re: C as intermediate language, signed integer overflow and -ftrapv
On Wed, Jul 23, 2014 at 04:56:06PM +0200, Thomas Mertes wrote: > A sanitizer such as ubsan is good as tool to find errors in C > programs. But I don't think that ubsan is well suited to do overflow > detection with maximum performance. Is just not the goal of this > tool. That's true. But if you only use -fsanitize=signed-integer-overflow, then the overhead shouldn't be that bad, especially on x86_64 where we try to make use of jo (jump if overflow) instruction. Perhaps use that option together with -fsanitize-undefined-trap-on-error, so it doesn't call libubsan routines at all. Marek
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 09:42:23AM +0200, Jakub Jelinek wrote: > On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: > > > What do you propose that we do? > > > > Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. > > That was my preference too. FWIW, me too. This way we'll get in a few years to 10.0 that was also suggested. So please, can we finally settle on something? :) Marek
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: > On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek wrote: > > - libstdc++ ABI changes (it is a significant user visible change, > > if you rebuild everything, no extra effort is needed, but otherwise > > if you want some C++ code built with older compilers work together > > with code built with newer compilers, it might require source code > > changes (the abi_tag attribute additions where needed and warning > > suggest to put those at), at least that is my current understanding > > of the plans > > But that's only with -std=c++11? Which had no compatibility > guarantees before? > > > - likely libgfortran ABI changes (different array descriptors) > > Let's wait and see ... > > We'll find a good reason to bump the major with every release. > Like for 4.9 LTO defaults to slim-objects, or C++ rejecting even more > invalid code, or libstdc++ header re-orgs, or defaulting to dwarf4+ > (or even support for it), or VTA, or ... > > Where do we set the barrier? GCC isn't a C++ (or Fortran) compiler > only. > > So if we change to 5.1 (please not .0) then let's switch the default > optimization level to -O2! _That's_ a user-visible change across > the board. I'm planning to move the default C standard from gnu90 to gnu11 (Currently it's blocked on the -Wc90-c99-compat warning). That's a pretty big user-visible change as well, I suppose. Marek
Re: Turning a single warning into an error in dejagnu test
On Wed, Aug 27, 2014 at 10:59:40AM +0100, Dominik Vogt wrote:
> I'm writing a dejagnu test and encounter this warning at one place:
>
> warning: passing argument 1 of '...' makes integer from pointer
> without a cast [enabled by default]
>
> Now, I have a "{ dg-error ... }" comment in that line. The line
> is generated from a script among hundreds of others that are all
> expected to produce errors, not warnings. It would be very
> inconvenient (= lots of work) to change the script to make an
> exception just for that single line (because there's no easy way
> to identify lines that produce the warning instead of an error).
>
> So the question is: Is it possible to turn only this one warning
> into an error inside a dejagnu test? As I understand it, there
> are no -W... switches for "enabled by default" options, and I
> cannot use -Werror because that would break other tests in the
> file.
For C, I recently added the -Wint-conversion option, so with recent
enough GCC you should be able to use -Werror=int-conversion.
Marek
Re: GCC 4.9 internal compiler error
On Mon, Sep 29, 2014 at 11:43:47AM +0400, Игорь Пашев wrote: > Hi all! > > It was found that OA fails to build with GCC 4.9 on amd64 [1] > I can confirm this with r3094 on bare metal too. > > # gcc --version > gcc-4.9.real (Debian 4.9.1-14) 4.9.1 > Copyright (C) 2014 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > I can imaging that this is a bug in OpenAxiom, but GCC should not crash. > > GCC complains on this line > https://sourceforge.net/p/open-axiom/code/HEAD/tree/trunk/src/include/storage.H#l273 Please provide a preprocessed source and file a bug. https://gcc.gnu.org/bugs/ Marek
Towards GNU11
Hi!
I'd like to kick off a discussion about moving the default standard
for C from gnu89 to gnu11.
This really shouldn't be much of a surprise: the docs mention that
gnu11 is intended future default for a year now. I would presume now
is a good time to make this move: together with the new naming scheme
this should make GCC more modern (C89 really is as old as the hills).
And we're still in stage1.
Prerequisites should be largely complete at this point:
- we have -Wc90-c99-compat option that warns about features not present
in ISO C90, but present in ISO C99,
- we have -Wc99-c11-compat option that warns about features not present
in ISO C99, but present in ISO C11,
- the testsuite has been adjusted so all the test that pass with gnu89
default should pass with gnu11 default as well (see my recent batch
of cleanup patches). This unfortunately isn't correct for all archs,
I just don't have enough resources to test everything. But generally
the fallout from moving to gnu11 is easy to fix: just add proper decls
and return types (to fix defaulting to int), or for inline stuff use
-fgnu89-inline/gnu_inline attribute. I'd appreciate testing on other
architectures than x86_64/ppc64.
The things I had to fix in the testsuite nicely reflect what we can expect
in the real life: mostly bunch of new warnings about missing declarations
and defaulting to int (this is probably going to be a pain with -Werror,
but I feel that people really should write proper declarations), different
inline semantics (in C99 semantics, the TU has to have the body of the inline
function etc.), new "return with no value, in function returning non-void"
warnings. Different rules for constant expressions, the fact that in C90
non-lvalue arrays do not decay to pointers, slightly different rules for
compatible types (?) might come in game as well.
In turn, you can use all C99 and C11 features even with -pedantic.
Comments?
Regtested/bootstrapped on powerpc64-linux and x86_64-linux.
2014-10-07 Marek Polacek
* doc/invoke.texi: Update to reflect that GNU11 is the default
mode for C.
* c-common.h (c_language_kind): Update comment.
c-family/
* c-opts.c (c_common_init_options): Make -std=gnu11 the default for C.
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index 1e3477f..a895084 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -445,7 +445,7 @@ struct GTY(()) sorted_fields_type {
typedef enum c_language_kind
{
- clk_c= 0,/* C90, C94 or C99 */
+ clk_c= 0,/* C90, C94, C99 or C11 */
clk_objc = 1,/* clk_c with ObjC features. */
clk_cxx = 2,/* ANSI/ISO C++ */
clk_objcxx = 3 /* clk_cxx with ObjC features. */
diff --git gcc/c-family/c-opts.c gcc/c-family/c-opts.c
index 3f295d8..eb078e3 100644
--- gcc/c-family/c-opts.c
+++ gcc/c-family/c-opts.c
@@ -250,6 +250,9 @@ c_common_init_options (unsigned int decoded_options_count,
if (c_language == clk_c)
{
+ /* The default for C is gnu11. */
+ set_std_c11 (false /* ISO */);
+
/* If preprocessing assembly language, accept any of the C-family
front end options since the driver may pass them through. */
for (i = 1; i < decoded_options_count; i++)
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 5fe7e15..fa84ed4 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -1692,8 +1692,7 @@ interfaces) and L (Analyzability). The name @samp{c1x}
is deprecated.
@item gnu90
@itemx gnu89
-GNU dialect of ISO C90 (including some C99 features). This
-is the default for C code.
+GNU dialect of ISO C90 (including some C99 features).
@item gnu99
@itemx gnu9x
@@ -1701,8 +1700,8 @@ GNU dialect of ISO C99. The name @samp{gnu9x} is
deprecated.
@item gnu11
@itemx gnu1x
-GNU dialect of ISO C11. This is intended to become the default in a
-future release of GCC. The name @samp{gnu1x} is deprecated.
+GNU dialect of ISO C11. This is the default for C code.
+The name @samp{gnu1x} is deprecated.
@item c++98
@itemx c++03
Marek
Re: Towards GNU11
On Wed, Oct 08, 2014 at 09:16:18AM +0200, Richard Biener wrote: > I think it makes sense to do this (and I expect C++ will follow > with defaulting to -std=c++11 once the ABI stuff has settled). Thanks. Moving to -std=c++11 would be cool! > Of course it would be nice to look at the actual fallout in > a whole-distribution rebuild... Yeah, I'm worried about that. Many packages are using -std=gnu99 (e.g. glibc, elfutils, maybe emacs) and these won't be affected at all. But e.g. gdb/binutils use the default standard I think. I wonder about Linux kernel. And of course, C++ packages should be out of the picture here. Marek
Re: Towards GNU11
On Wed, Oct 08, 2014 at 08:39:40PM -0600, Jeff Law wrote: > I like it. And one could reasonably argue that now is the time to change > since that maximizes the time for folks to find broken code. Yep, this is definitely stage1 stuff. We still have a few weeks, but I wouldn't want to rush such a change in the nick of time. > I'd go so far as to conditionally approve -- if other maintainers don't > shout out in the next week or so against, then I feel this should go > forward. Thanks. I will wait at least until the end of next week. I'd like to hear from Joseph ;). > I know it's really early, but a "porting to ..." document ought to be > started and have something in it about these changes. Both how to fix the > broken code or how to go back to c89. Absolutely. I'll start something up once it's in. I feel that especially the inline semantics change should be addressed therein. Marek
Re: Towards GNU11
On Thu, Oct 09, 2014 at 02:34:51PM -0700, Mike Stump wrote: > On Oct 7, 2014, at 2:07 PM, Marek Polacek wrote: > > I'd like to kick off a discussion about moving the default standard > > for C from gnu89 to gnu11. > > I endorse the change of default. Thanks for chiming in. > A wiki page that has the types of changes people hit in real code with how to > fix it, would be useful, helpful. Might be nice to have this in the > document, but, don’t know if people want to do that much work. The wiki site > is nice, as if others do world builds, then can add what ever they hit in > easily, which then makes that even more complete. This is a nice to have, I > don’t think the work going in should be gated on this. Yeah. I plan to write something into the "porting to" document. > Two comment: > > Thank you for all your hard work. > > Yes please. Thank you very much! Marek
Re: Towards GNU11
On Tue, Oct 07, 2014 at 11:07:56PM +0200, Marek Polacek wrote:
> I'd like to kick off a discussion about moving the default standard
> for C from gnu89 to gnu11.
The consensus seems to be to go forward with this change. I will
commit the patch in 24 hours unless I hear objections.
Thanks,
Marek
Re: Towards GNU11
On Tue, Oct 14, 2014 at 09:23:29AM +0200, Marek Polacek wrote:
> The consensus seems to be to go forward with this change. I will
> commit the patch in 24 hours unless I hear objections.
I made the change. Please report any fallout to me.
Enjoy.
Marek
Re: Towards GNU11
On Wed, Oct 15, 2014 at 11:05:45PM +0200, Jakub Jelinek wrote: > On Wed, Oct 15, 2014 at 09:28:09PM +0200, Uros Bizjak wrote: > > i686-linux-gnu testsuite trivially regressed [1]: Thanks for the log Uros. > I have half of that already in patch form, will test and send either later > tonight or tomorrow. Please don't force yourself into doing that, it's more up to me to fix my fallout ;). Feel free to send me the partial patch and I will finish it tomorrow mornings (reproducing is easy with --target_board=unix/-m32). In any case, thanks. Marek
Re: Towards GNU11
On Wed, Oct 15, 2014 at 09:28:09PM +0200, Uros Bizjak wrote: > Hello! > > >> The consensus seems to be to go forward with this change. I will > >> commit the patch in 24 hours unless I hear objections. > > > > I made the change. Please report any fallout to me. > > i686-linux-gnu testsuite trivially regressed [1]: > > FAIL: gcc.dg/20020122-2.c (test for excess errors) > FAIL: gcc.dg/builtin-apply4.c (test for excess errors) > FAIL: gcc.dg/ia64-sync-1.c (test for excess errors) > FAIL: gcc.dg/ia64-sync-2.c (test for excess errors) > FAIL: gcc.dg/ia64-sync-3.c (test for excess errors) > FAIL: gcc.dg/pr32176.c (test for excess errors) > FAIL: gcc.dg/sync-2.c (test for excess errors) > FAIL: gcc.dg/sync-3.c (test for excess errors) > FAIL: gcc.target/i386/20060125-1.c (test for excess errors) > FAIL: gcc.target/i386/20060125-2.c (test for excess errors) > FAIL: gcc.target/i386/980312-1.c (test for excess errors) > FAIL: gcc.target/i386/980313-1.c (test for excess errors) > FAIL: gcc.target/i386/990524-1.c (test for excess errors) > FAIL: gcc.target/i386/avx512f-pr57233.c (test for excess errors) > FAIL: gcc.target/i386/avx512f-typecast-1.c (test for excess errors) > FAIL: gcc.target/i386/builtin-apply-mmx.c (test for excess errors) > FAIL: gcc.target/i386/crc32-2.c (test for excess errors) > FAIL: gcc.target/i386/crc32-3.c (test for excess errors) > FAIL: gcc.target/i386/intrinsics_3.c (test for excess errors) > FAIL: gcc.target/i386/loop-1.c (test for excess errors) > FAIL: gcc.target/i386/memcpy-1.c (test for excess errors) > FAIL: gcc.target/i386/pr26826.c (test for excess errors) > FAIL: gcc.target/i386/pr37184.c (test for excess errors) > FAIL: gcc.target/i386/pr40934.c (test for excess errors) > FAIL: gcc.target/i386/pr44948-2a.c (test for excess errors) > FAIL: gcc.target/i386/pr47564.c (test for excess errors) > FAIL: gcc.target/i386/pr50712.c (test for excess errors) > FAIL: gcc.target/i386/sse-5.c (test for excess errors) > FAIL: gcc.target/i386/stackalign/asm-1.c -mno-stackrealign (test for > excess errors) > FAIL: gcc.target/i386/stackalign/asm-1.c -mstackrealign (test for excess > errors) > FAIL: gcc.target/i386/stackalign/return-2.c -mno-stackrealign (test > for excess errors) > FAIL: gcc.target/i386/stackalign/return-2.c -mstackrealign (test for > excess errors) > FAIL: gcc.target/i386/vectorize4.c (test for excess errors) Sorry about these, should be fixed now. Marek
Re: Contributing to GCC
On Fri, Oct 17, 2014 at 09:55:28AM +0200, Krzesimir Nowak wrote: > I was asking, because, in the beginning at least, somebody will have > to commit the patch to trunk for me. I don't know if svn understands > git patches. No worries about that, we'll just apply the patch manually. Marek
Re: [RFC] Detect most integer overflows.
Hi, On Tue, Apr 22, 2014 at 01:58:00PM +0200, Hannes Frederic Sowa wrote: > I'll play around and will post a new patch in the not too distant > future. ;) Are you still planning on posting the revised patch? Perhaps I could take and finish the patch, but I don't think I can do that because you don't have a copyright assignment with FSF. Marek
Re: Enabling -fextended-identifiers by default
On Mon, Nov 03, 2014 at 04:24:21PM +, Joseph Myers wrote:
> I propose enabling -fextended-identifiers by default for the appropriate
> standard versions (i.e. all C++ versions, C99 and above for C - so enabled
> by default for C now the default C version is gnu11). Any comments or
> objections?
Sounds good to me.
Marek
Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign
On Fri, Nov 07, 2014 at 10:01:45PM +0100, Richard Biener wrote: > Just a comment as these patches flow by - I think this is a huge step > backwards from "enforcing" s1/s2 being a gimple_assign inside > gimple_assign_rhs1 to this as_a boilerplate at _each_ callsite! FWIW, I feel the same way. More to type, worse readability, a lot more of line-wrapping. Sorry, Marek
Re: [RFC] UBSan unsafely uses VRP
On Wed, Nov 12, 2014 at 11:42:39AM +0300, Yury Gribov wrote: > On 11/11/2014 05:15 PM, Jakub Jelinek wrote: > >>There are also some unsafe code in functions > >>ubsan_expand_si_overflow_addsub_check, ubsan_expand_si_overflow_mul_check > >>which uses get_range_info to reduce checks number. As seen before vrp usage > >>for sanitizers may decrease quality of error detection. > > > >Using VRP is completely intentional there, we don't want to generate too > >slow code if you decide you want to optimize your code (for -O0 VRP isn't > >performed of course). > > On the other hand detection quality is probably more important than > important regardless of optimization level. When I use a checker, I don't > want it to miss bugs due to overly aggressive optimization. Yes, but as said above, VRP is only run with >-O2 and -Os. > I wish we had some test to check that sanitizer optimizations are indeed > conservative. I think most of the tests we have are tested with various optimization levels. Marek
Re: [RFC] UBSan unsafely uses VRP
On Wed, Nov 12, 2014 at 01:04:58PM +0300, Marat Zakirov wrote: > > On 11/12/2014 11:45 AM, Marek Polacek wrote: > >Yes, but as said above, VRP is only run with >-O2 and -Os. > You meant >= -O2? Yes. Marek
Re: ICE in 4.8.2 with compound literal
On Tue, Nov 25, 2014 at 09:30:05AM +0100, Mason wrote:
> Hello,
>
> This ICE may have gotten lost in the noise of my own message.
> https://gcc.gnu.org/ml/gcc-help/2014-11/msg00094.html
>
> (The code snippet might be invalid C)
>
> $ gcc -std=gnu99 -O3 -S test.c
> test.c: In function 'main':
> test.c:3:5: internal compiler error: in expand_expr_real_1, at expr.c:10540
> int main() { return *(adds[0]); }
> ^
I can reproduce the error. Please do...
> Please submit a full bug report,
this, and don't forget about:
> with preprocessed source if appropriate.
> See for instructions.
> Preprocessed source stored into /tmp/cc2RJY0y.out file, please attach this to
> your bugreport.
(If you need to create a BZ account, please mail overseers and I'll
take care of that.)
Thanks,
Marek
Re: ICE in 4.8.2 with compound literal
On Tue, Nov 25, 2014 at 10:19:21AM +0100, Mason wrote: > Aaah, you want me to post the bug report to BZ, not here... Yep - the snippet + command-line options you posted was enough to reproduce the bug. The GCC mailing list is not for reporting bugs. > When you have a minute, can you take a look at my other message? > "Using Compound Literal + type-punning to initialize static const array" > > You committed a patch that seems relevant just a few days ago. But the > documentation lead me to believe that the feature I was looking for had > been supported for a very long time (gcc 3.x at least) I haven't read that in detail yet, but my patch just allowed the initializing even for gnu99/gnu11 (formerly, it was only allowed in the gnu89 mode). Marek
Re: GCC 4.9.2 -O3 gives a seg fault / GCC 4.8.2 -O3 works
On Tue, Jan 06, 2015 at 11:28:52AM -0500, Paul Smith wrote: > On Tue, 2015-01-06 at 09:43 +0100, Jakub Jelinek wrote: > > GCC trunk -fsanitize=undefined (in particular > > -fsanitize=nonnull-attribute) > > diagnoses it: > > /tmp/mystring.cpp:103:26: runtime error: null pointer passed as > > argument 2, which is declared to never be null > > Unfortunately adding -fsanitize=undefined in GCC 4.9.2 doesn't notice > this (in fact it actually causes the segfault to go away). > > I can try to build a trunk version for this test, I suppose. Right: -fsanitize=nonnull-attribute is a GCC 5 only thing. Marek
Re: Announcing Marek Polacek as C front-end reviewer
On Mon, Jan 12, 2015 at 10:23:16PM -0700, Jeff Law wrote: > I'm pleased to announce that Marek Polacek has been appointed as a reviewer > for the C front-end. Thanks! > Marek, please add yourself as a reviewer for the C front end in the > MAINTAINERS file. 2015-01-13 Marek Polacek * MAINTAINERS (Reviewers): Add self as C front end reviewer. diff --git gcc/MAINTAINERS gcc/MAINTAINERS index e4696a1..52fcf5f 100644 --- gcc/MAINTAINERS +++ gcc/MAINTAINERS @@ -270,6 +270,7 @@ check in changes outside of the parts of the compiler they maintain. Reviewers +C front endMarek Polacek dataflow Paolo Bonzini dataflow Seongbae Park dataflow Kenneth Zadeck Marek
Re: Serious Regressions tables on https://gcc.gnu.org
On Fri, Feb 13, 2015 at 03:12:22PM -0500, Jack Howarth wrote: > Is there a reason why the Serious Regressions tables, displayed by > the links in the 'Release Series and Status' section at > https://gcc.gnu.org, no longer have a column for the priority > (importance) of each bug? We used to have that and it was quite nice > to be able to click on the priority column header to regenerate the > table sorted by bug priority (to quickly see how many P1s are open). > Any chance of getting that functionality back? You probably need to enable the Priority column in Change Columns at the bottom of the page. Marek
Re: array bounds, sanitizer, safe programming, and cilk array notation
Sorry for late reply - I've found this in my inbox only today.
On Mon, Jan 26, 2015 at 11:53:59AM -0800, Martin Uecker wrote:
>
> Hi all,
>
> I am writing numerical code, so I am trying to make the use
> of arrays in C (with gcc) suck a bit less. In general, the long term
> goal would be to have either a compile-time warning or the possibility
> to get a run-time error if one writes beyond the end of an array as
> specified by its type.
>
> So one example (see below) I looked at is where I pass an array of
> too small size to a function, to see how see can be diagnosed. In some
> cases, we can get a runtime error with the address sanitizer, but this
> is fairly limited (e.g. it does not work when the array is embedded
> in a struct) and I also got mixed results when the function
> is inlined.
>
> For pointers to arrays with static size one can get an "incompatible
> pointer" warning - which is nice. With clang, I also get warning for
> pointers which are declared as array parameters and use the 'static'
> keyword to specify a minimum size. This a diagnostic we are currently
> missing.
>
> The next step would be to have diagnostics also for the VLA
> case if the size is known at compilation time (as in the
> example below) and a run-time error when it is not (maybe
> with the undefined behaviour sanitizer?).
>
> If we have the later, I think this might also help with safer
> programming in C, because one would get either a compile time or
> runtime error when I passing a buffer which is too small to
> a function. For example, snprintf could have a prototype like
> this:
>
> int snprintf(size_t size; char str[static size], size_t size,
> const char *format, ...);
>
> That VLAs essentially provide the bounded pointer type C is
> missing has been pointed out before, e.g. there was a proposal
> by John Nagle, although he proposed rather intrusive language
> changes (e.g. adding references to C) which are not necessary
> in my opinion:
>
> https://gcc.gnu.org/ml/gcc/2012-08/msg00360.html
>
>
> Finally, what is missing is a way to diagnose problems inside
> the called functions. -Warray-bounds=2 (with my recently
> accepted patch) helps with this, but - so far - only for static
> arrays:
>
> void foo(int (*x)[4])
> {
> (*x)[4] = 5;// warning
> }
This is detected by -fsanitize=object-size, turned on by default in
-fsanitize=undefined. Since it makes use of __builtin_object_size,
it is necessary to compile with optimizations turned on.
> It would be nice to also have these warning and runtime errors
> (with the undefined behaviour sanitizer) for VLAs.
>
> Finally, I think we should have corresponding warning also
> for pointers which are declared as array parameters:
>
> void foo2(int x[4])
> {
> x[4] = 5;
> }
Ditto.
> The later does not currently produce a warning, because x
> is converted to a pointer and the length is ignored.
>
> If it is not possible to have warning here for compatibility
> reasons, one possibility is to have an extension similar to
> 'static' which makes 'x' a proper array in the callee, e.g.
I think even the 'static in parameter array declarators' (ugly) C99 extension
isn't properly implemented yet (I don't think that the compiler makes
any optimization based on it).
So - if I understood this correctly - I think it's better to enhance
ubsan than to add any kind of language extensions.
Marek
Re: array bounds, sanitizer, safe programming, and cilk array notation
Sorry for late reply. On Tue, Jan 27, 2015 at 12:07:58AM +, Joseph Myers wrote: > On Mon, 26 Jan 2015, Martin Uecker wrote: > > > extern void bar2(int (*x)[5]); > > > int c = 4; > > int y[c]; > > > bar2(&y); // not diagnosed (found by asan) > > This is the undefined behavior "If the two array types are used in a > context which requires them to be compatible, it is undefined behavior if > the two size specifiers evaluate to unequal values." (C11 6.7.6.2#6). > Yes, it would make sense for ubsan to detect this. Generally, most forms > of runtime undefined behavior listed in J.2 should have ubsan detection > unless hard to detect / detected by some other sanitizer such as asan. I have created a table to that effect some time ago: http://people.redhat.com/mpolacek/www/analyzability.html Obviously the question marks should be replaced by a -fsanitize= option that detects a particular UB. Or say that a particular UB is a compile-time error (e.g. "declaring a function at block scope with an explicit storage-class specifier other than extern"). I don't know what to do with the UBs on the library side - those 7.* ones. > Does adding new forms of sanitization require upstream libsanitizer > changes as well or can arbitrary ubsan checks be added without needing > libsanitizer changes? I think we also need libubsan changes. But it is usually just about printing an error message along with some values - nothing terribly complex. Marek
Re: A bug (?) with inline functions at O0: undefined reference
On Fri, Mar 06, 2015 at 07:12:48PM +0300, Ilya Verbin wrote:
> Hi All,
>
> I've discovered a strange behaviour on trunk gcc, here is the reproducer:
>
> inline int foo ()
> {
> return 0;
> }
>
> int main ()
> {
> return foo ();
> }
>
> $ gcc main.c
> /tmp/ccD1LeXo.o: In function `main':
> main.c:(.text+0xa): undefined reference to `foo'
> collect2: error: ld returned 1 exit status
>
> Is this a bug? If yes, is it known?
> GCC 4.8.3 works fine though.
Not a bug, just different inline semantics now that the default is
gnu11. See https://gcc.gnu.org/gcc-5/porting_to.html for more info.
Marek
Re: Unnamed Struct / Union
On Mon, Mar 23, 2015 at 02:07:28PM +0530, Umesh Kalappa wrote:
> Hi All ,
>
> GCC 4.8.3 ,pop up with below error
>
> /home/i16382/an.c:13:18: error: duplicate member 'bOriginator'
> unsigned bOriginator;
> ^
>
> for the case
>
> union
> {
> struct
> {
> unsigned bStatusType;
> unsigned bOriginator;
> };
> struct
> {
> unsigned originator;
> unsigned memoryContentsChanged;
> unsigned interruptPending;
> unsigned bOriginator;
> };
> } USB_WORD;
>
> is that expected behaviour ?
Yes.
Marek
Re: Change to C++11 by default?
On Thu, May 07, 2015 at 01:46:32PM -0500, Jason Merrill wrote: > I think it's time to switch to C++11 as the default C++ dialect for GCC 6. > Any thoughts? Couldn't we switch directly to C++14 now that the support is complete? Regardless, I support changing the default (obviously... ;)). Marek
Re: Identifying Pure and Const Functions
On Fri, May 29, 2015 at 01:16:32PM +0530, Pritam Gharat wrote: > How do we identify whether a function is a pure or a const function? > Is there any flag associated with its cgraph_node or the tree node > (decl of cgraph_node)? You'll want to look into ipa-pure-const.c. Marek
Re: Implementing p0515 - spaceship operator
On Thu, Aug 30, 2018 at 08:07:05PM +0200, Jakub Jelinek wrote: > On Thu, Jan 11, 2018 at 02:06:06PM +, Joseph Myers wrote: > > On Thu, 11 Jan 2018, David Brown wrote: > > > > > Maybe it is easier to say "gcc supports <=> in C++2a, and as an > > > extension also supports it in C and C++ of any standard" ? I don't > > > believe there is any way for it to conflict with existing valid code, so > > > it would do no harm as a gcc extension like that - and C users can then > > > use it too. > > > > As per previous IRC discussion, changing the lexing to support this > > pp-token can break valid code in previous standards, e.g. code > > concatenating <=> and >, then stringizing the result (the C++ proposal for > > adding this feature also notes some obscure cases where the character > > sequence <=> can actually occur as tokens, not just pp-tokens - > > "X<&Y::operator<=>" and "x+&operator<=>y" - so of course patches adding > > this feature should add testcases using such cases with older -std= > > options). > > > > Changes to cpp_avoid_paste (so that preprocessed output does not put a > > pp-token starting with > immediately after <=) do not need to be > > conditional on the standard version, however. > > Here is a patch that attempts to implement this (in libcpp + gcc/testsuite > only so far). > It needs to be parsed and handled in the C++ FE obviously, which is missing. Thanks. Tim, have you had any success with this, or should I (or somebody else) feel free to take it over? Marek
Re: Delayed warning
On Mon, Apr 29, 2019 at 08:39:57AM -0600, Jeff Law wrote: > On 4/29/19 8:24 AM, Thomas Koenig wrote: > > Hi! > > > > Is there a way to mark a TREE statement (or a variable) so that > > a warning is issued at a later stage if the statement has not been > > removed in the meantime? > > > > I am thinking, for example, of Fortran's -Warray-temporaries, which > > issues a warning in the front end even though the whole temporary > > array may be optimized away later. We could, for example, mark > > a call to malloc in such a way. > I'm not aware of one, but I recently suggested the concept of > __builtin_warning which would allow us to effectively delay a warning. > > The goal was to have the warning explicitly in the IL so that if the > path to the warning was later determined infeasible the warning would > just get removed by the standard unreachable code elimination optimization. > > This would allow us to avoid false positives due to the IL not being > well enough optimized at the point where we discover something is > potentially amiss. FYI, I also raised the idea of delayed warnings in the C FE some time ago: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193#c3 Marek
Re: [PATCH] Deprecate -frepo option.
On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote: > Ok, hopefully nobody is strongly against. I've just retested the > patch and installed it as r275450. --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes) Used in Fix-and-Continue mode to indicate that object files may be swapped in at runtime. frepo -C++ ObjC++ -Enable automatic template instantiation. +C++ ObjC++ Deprecated +Deprecated in GCC 10. This switch has no effect. But it's not just deprecated, it's removed now, so shouldn't this be Ignored? Also, https://gcc.gnu.org/gcc-10/changes.html should be updated, both in Caveats and the C++ section. But I can do that. Marek
Re: Boost build broken due to recent C++ change?
On Tue, Sep 24, 2019 at 10:16:27PM +, Steve Ellcey wrote: > A recent g++ change (I haven't tracked down exactly which one, but in > the last day or two) seems to have broken my boost build. It is dying > with lots of errors like: > > ./boost/intrusive/list.hpp:1448:7: required from here > ./boost/intrusive/detail/list_iterator.hpp:93:41: error: call of > overloaded 'get > _next(boost::intrusive::list_node*&)' is ambiguous >93 | node_ptr p = node_traits::get_next(members_.nodeptr_); > |~^~~ > In file included from ./boost/intrusive/list_hook.hpp:20, > from ./boost/intrusive/list.hpp:20, > from ./boost/fiber/context.hpp:29, > from libs/fiber/src/algo/algorithm.cpp:9: > > Has anyone else run into this? I will try to create a cutdown test > case. I'm afraid this will be my commit 5ac76b02008255b7f427e6309c2dc3e42bd64561 Author: mpolacek Date: Mon Sep 23 17:37:54 2019 + PR c++/91844 - Implement CWG 2352, Similar types and reference binding. * call.c (reference_related_p): Use similar_type_p instead of same_type_p. (reference_compatible_p): Update implementation to match CWG 2352. * cp-tree.h (similar_type_p): Declare. * typeck.c (similar_type_p): New. * g++.dg/cpp0x/pr33930.C: Add dg-error. * g++.dg/cpp0x/ref-bind1.C: New test. * g++.dg/cpp0x/ref-bind2.C: New test. * g++.dg/cpp0x/ref-bind3.C: New test. * g++.old-deja/g++.pt/spec35.C: Remove dg-error. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@276058 138bc75d-0d04-0410-961f-82ee72b054a4 Please open a bug. Marek
Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th
On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote: > Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit : > > > > Please make sure to get features intended for GCC 10 finished > > and reviewed before the end of stage 1. > > > > Hi, > > I understand my question comes very (most likely too) late, but are > there any plans to switch the default C++ dialect to -std=gnu++17 when > invoking g++ ? C++17 support in gcc is now quite complete, has been > out tested by some users since gcc 8, so shall it be switched on by > default in gcc 10 ? Or gcc 11 ? However I fear doing that may break > some tests in the testsuite, I hope not too many. I plan to propose a switch to -std=gnu++17 in GCC 11. I think it's way too late for GCC 10. Dealing with the testsuite fallout, and rebuilding Fedora packages is of course part of that switch. -- Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th
On Fri, Nov 01, 2019 at 09:31:07AM -0600, Jeff Law wrote: > On 11/1/19 9:08 AM, Marek Polacek wrote: > > On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote: > >> Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit : > >>> > >>> Please make sure to get features intended for GCC 10 finished > >>> and reviewed before the end of stage 1. > >>> > >> > >> Hi, > >> > >> I understand my question comes very (most likely too) late, but are > >> there any plans to switch the default C++ dialect to -std=gnu++17 when > >> invoking g++ ? C++17 support in gcc is now quite complete, has been > >> out tested by some users since gcc 8, so shall it be switched on by > >> default in gcc 10 ? Or gcc 11 ? However I fear doing that may break > >> some tests in the testsuite, I hope not too many. > > > > I plan to propose a switch to -std=gnu++17 in GCC 11. I think it's way > > too late for GCC 10. > > > > Dealing with the testsuite fallout, and rebuilding Fedora packages is > > of course part of that switch. > FWIW, we *could* do the rebuild test, we've got time for that. What's > far more interesting would be dealing with the fallout ;-) I most definitely had your tester in mind ;). > I'd tend to agree though, flip the default as soon as gcc-11 stage1 > opens. That gives us plenty of time to deal with any fallout. Sounds like we have a plan. -- Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Re: Commit messages and the move to git
On Tue, Nov 05, 2019 at 11:27:50AM +, Jason Merrill wrote: > On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely wrote: > > On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote: > > > On Mon, 4 Nov 2019, Segher Boessenkool wrote: > > > > > > > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote: > > > > > I've already proposed a more specific format for libstdc++: > > > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html > > > > > > > > PR libstdc++/12345 takes up the first 19 chars of the short subject, > > > > adding no useful information (unless the reader knows all PRs by heart, > > > > you need to look it up to know what it is). > > > > > > > > I usually put (PR12345) at the end of the subject. The area is clear > > > > from the rest of the subject already. > > > > > > Agreed. (Hint to patch submitters: if the subject line of your patch > > > submission is just "Fix PR12345" or similar, people are less likely to > > > review your patch because nothing about the subject tells anyone that the > > > patch is in their area and so something they should pay attention to. > > > Patch submissions need to have subjects that make clear very quickly what > > > the patch is about. This is also why I don't care for [PATCH] tags at the > > > start of subject lines - they take away space for saying what the patch is > > > about, and on gcc-patches we can expect things are patches, [PATCH] > > > doesn't add useful information.) > > > > I don't mind [PATCH] in the subject of patch emails (maybe because > > nearly all my patches go to libstdc++@ as well, and not all mails on > > that list are patches), but it has negative value in the commit log. > > I actively like [PATCH] in the subject line because I see patch mail > interleaved with other mail in my inbox. > > > My mail to the libstdc++ list should have noted that [PATCH] tags in > > the email subject should be omitted from the summary in the first line > > of the commit log. > > And git format-patch/git am automatically add and remove [PATCH] > appropriately. Wrt [PATCH]: if we keep it, do we want to have a system to distinguish C/C++/... patches? Do we want [C++ PATCH] or [PATCH][C++] or [C++][PATCH], something else? (I find the latter two a bit ugly.) Marek
Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)
On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote: > On Thu, 5 Dec 2019 at 16:44, Michael Matz wrote: > > > > Hello, > > > > (oh a flame bait :) ) > > > > On Thu, 5 Dec 2019, Thomas Schwinge wrote: > > > > > So, I formally propose that we lift this characters per line restriction > > > from IBM punch card (80) to mainframe line printer (132). > > > > > > Tasks: > > > > > > - Discussion. > > > > I object to cluttering code in excuse for using sensible function names or > > temporaries that otherwise can help clearing up code. Using 132-char > > lines is cluttering code: > > - long lines are harder to read/grasp: vertical eye movement is easier > > than horizontal, and source code should be optimized for > > reading, not writing > > - long lines make it impossible to have two files next to each other at a > > comfortable font size > > - long lines are incompatible with existing netiquette re emails, for > > instance > > > > So, at least for me, that my terminals are 80 wide (but not x24) has > > multiple reasons, and the _least_ of it is because that's what punch cards > > had. > > C++17 introduces a nice feature, with rationale similar to declaring > variables in a for-loop init-statement: > > if (auto var = foo(); bar(var)) > > The variable is only in scope for the block where you need it, just > like a for-loop. > > Unfortunately nearly every time I've tried to use this recently, I've > found it's impossible in 80 columns, e.g. this from yesterday: > > if (auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=> > 0; __c != 0) > return __c; > > When you're forced to uglify every variable with a leading __ you run > out of characters pretty damn quickly. > > I can either not use the feature (and have the variable defined in a > larger scope than it needs to be) or add fairly arbitrary line breaks: > > if (auto __c > = __builtin_memcmp(&*__first1, &*__first2, __len) > <=> 0; __c != 0) > return __c; > > or try to give the variables shorter (and less meaningful) names. > Adding line breaks or picking shorter names doesn't help readability. > So I end up not using the feature. > > I'm loosely in favour of relaxing the rule for libstdc++ code. I don't > really care what the rest of GCC looks like ;-) Not using such a nice feature just because of formatting sounds really shameful. Would the compromise of 100 chars make things any better here? Marek
Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)
On Thu, Dec 05, 2019 at 02:06:50PM -0600, Segher Boessenkool wrote: > Hi! > > On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote: > > C++17 introduces a nice feature, with rationale similar to declaring > > variables in a for-loop init-statement: > > > > if (auto var = foo(); bar(var)) > > Similar to GNU C statement expressions, which are *also* only a good > idea to use in limited cases. > > > The variable is only in scope for the block where you need it, just > > like a for-loop. > > > > Unfortunately nearly every time I've tried to use this recently, I've > > found it's impossible in 80 columns, e.g. this from yesterday: > > > > if (auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=> > > 0; __c != 0) > > return __c; > > > > When you're forced to uglify every variable with a leading __ you run > > out of characters pretty damn quickly. > > If using this "nice feature" forces you to uglify your code, then maybe > it is not such a nice feature, and you should not use it. I disagree, it is a nice feature, without quotes. It's Good Style not to leak variables into enclosing scopes. > If you have issues with scoping your functions are WAY too long already. I don't think that's the case here. -- Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Re: GCC static analysis branch now available on Compiler Explorer
On Tue, Dec 10, 2019 at 10:46:59AM -0500, David Malcolm wrote: > For the adventurous/curious, my static analyzer branch of GCC [1] is > now available on Compiler Explorer (aka godbolt.org) so you can try it > out without building it yourself. [Thanks to Matt Godbolt, Patrick > Quist and others at the Compiler Explorer project] Congrats! > On https://godbolt.org/ within the C and C++ languages, select > "x86-64 gcc (static analysis)" > as the compiler (though strictly speaking only C is in-scope right > now). It's configured to automatically inject -fanalyzer (just on this > site; it isn't the default in the branch). > > Some precanned examples: > * various malloc issues: https://godbolt.org/z/tnx65n > * stdio issues: https://godbolt.org/z/4BP-Tj > * fprintf in signal handler: https://godbolt.org/z/ew7mW6 > * tainted data affecting control flow: https://godbolt.org/z/3v8vSj > * password-leakage: https://godbolt.org/z/pRPYiv > (the non-malloc examples are much more in "proof-of-concept" territory) > > Would it make sense to add an "analyzer" component to our bugzilla, > even though this is still on a branch? (with me as default assignee) I think so, we have it for e.g. JIT already, and it's probably just a matter of time before the analyzer is merged. -- Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
Re: Warning annoyances in list_read.c
On Mon, Mar 27, 2017 at 12:18:17PM +0200, Dominique d'Humières wrote: > > > If he added a new option affecting libgfortran, then he should > > > fix up libgfortran. > > > > He didn't add the warning to specifically annoy fortran developers. > > It is trivial to add seven gcc_fallthrough() or breaks for someone who > > knows the code and the person who added the warning obviously doesn't. > The following patch fixes the warnings > > --- ../_clean/libgfortran/io/list_read.c 2017-03-25 20:42:40.0 > +0100 > +++ libgfortran/io/list_read.c2017-03-27 12:06:10.0 +0200 > @@ -51,7 +51,8 @@ typedef unsigned char uchar; > #define CASE_DIGITS case '0': case '1': case '2': case '3': case '4': \ >case '5': case '6': case '7': case '8': case '9' > > -#define CASE_SEPARATORS case ' ': case ',': case '/': case '\n': \ > +#define CASE_SEPARATORS /* Fall through. */ \ > + case ' ': case ',': case '/': case '\n': \ > case '\t': case '\r': case ';' > > /* This macro assumes that we're operating on a variable. */ > > Indeed before applying this patch, someone will have to check that the > warnings do not occur because of missing breaks. > > Note that putting /* Fall through. */ before the use of the macro > CASE_SEPARATORS does not work. Is it a (known) bug? Yes, it's known that the "falls through" comments don't work if they're preceding a macro. Marek
Re: Warning annoyances in list_read.c
On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote: > On Mon, Mar 27, 2017 at 05:22:12PM +0200, Markus Trippelsdorf wrote: > > On 2017.03.27 at 06:49 -0700, Steve Kargl wrote: > > > > > > Go scan the gcc-patches mailing list for "fallthrough". I'll > > > note other have concerns. Here's one example: > > > > > > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00300.html > > > > > >Without Bernd's patch to set the default to 1 you will drown > > >in false positives once you start using gcc-7 to build a whole > > >distro. On my Gentoo test box anything but level 1 is simply > > >unacceptable, because you will miss important other warnings > > >in the -Wimplicit-fallthrough noise otherwise. > > > > The quotation doesn't have anything to do with the current discussion, > > which is the general usefulness of the warning. > > It only talks about one of the (admittedly over-engineered) six > > different levels of the warning. > > > > Yes, it does. See the part about "... drown in false positives ..." > Whoever turned this option on should have been prepared to deal > with the fallout by investigating each and every warning (i.e., > either fix a real bug or (un)fix valid code to prevent the false > positive). Having spent hours on fixing various fallthrough cases throughout the codebase, deciding whether or not a particular case is an intentional fallthru, and pursuing various maintainers if I couldn't make a call, I find your statement, erm, incorrect . I'm sorry that apparently something has slipped through. I would've fixed it if I'd hit it. The warning had been discussed extensively on the ML, and you had the chance to chime in, too. There's a reason why the warning is only enabled by -Wextra and not by -Wall. > But that's okay. I now understand that it is acceptable for > a developer to commit a change that causes issues for other > developers, and said developer can turn a blind eye. Nonsense. Marek
Re: Warning annoyances in list_read.c
On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote: > On 03/27/2017 06:45 PM, Marek Polacek wrote: > > > On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote: > > > > But that's okay. I now understand that it is acceptable for > > > a developer to commit a change that causes issues for other > > > developers, and said developer can turn a blind eye. > > > > Nonsense. > > The person developing the warning could *at least* have bootstrapped all > languages and detected, warned and helped the Fortran/Ada/whatever side to > cope with it. Of course "the person" had bootstrapped and tested all the languages before adding the warning. If only any of you bothered to check the fortran/ ChangeLogs: 2016-08-12 Marek Polacek PR c/7652 * decl.c (match_attr_spec): Add FALLTHRU. * primary.c (match_arg_list_function): Likewise. * resolve.c (resolve_operator): Adjust fall through comment. (fixup_charlen): Add FALLTHRU. (resolve_allocate_expr): Adjust fall through comment. * trans-array.c (gfc_conv_ss_startstride): Add FALLTHRU. * trans-intrinsic.c (gfc_conv_intrinsic_len): Adjust fall through comment. 2016-09-26 Marek Polacek PR c/7652 * arith.c (eval_intrinsic): Add gcc_fallthrough. * frontend-passes.c (optimize_op): Likewise. (gfc_expr_walker): Likewise. * parse.c (next_fixed): Likewise. * primary.c (match_variable): Likewise. * trans-array.c: Likewise. * trans-expr.c (flatten_array_ctors_without_strlen): Likewise. * trans-io.c (transfer_expr): Likewise. 2016-09-20 Marek Polacek * trans-intrinsic.c (conv_expr_ref_to_caf_ref): Adjust fall through comment. Marek
Re: Warning annoyances in list_read.c
On Mon, Mar 27, 2017 at 07:59:01PM +0200, Thomas Koenig wrote: > Am 27.03.2017 um 19:41 schrieb Marek Polacek: > > > Of course "the person" had bootstrapped and tested all the languages before > > adding the warning. If only any of you bothered to check the fortran/ > > ChangeLogs: > > The problem is with libfortran, which apparently was not tested > (or the problem would have been found and, presumably, dealt with). I always build libgfortran when testing. The warning was committed months ago, so it's weird that I'm only hearing about this now. I would've been happy to fix the warnings if anyone pointed out them to me. I hadn't know of them until very recently. > So, due to incomplete testing, a regression was caused. This has > probably happened a few thousand times before, so it is not an > exceptionally big deal. > > We should deal with this the same way we deal with other regressions - > fix it or, if anything else fails, roll back the offending patch. > The person who is responsible for the regression should usually take the > lead in fixing it. > > Since the fix appears to be rather trivial, I promise to review > any patch that falls into my area of review (fortran, libfortran) > within 48 hours. https://gcc.gnu.org/ml/gcc/2017-03/msg00145.html Marek
Re: Warning annoyances in list_read.c
On Mon, Mar 27, 2017 at 11:16:32AM -0700, Steve Kargl wrote: > On Mon, Mar 27, 2017 at 07:41:12PM +0200, Marek Polacek wrote: > > On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote: > > > On 03/27/2017 06:45 PM, Marek Polacek wrote: > > > > > > > On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote: > > > > > > > > But that's okay. I now understand that it is acceptable for > > > > > a developer to commit a change that causes issues for other > > > > > developers, and said developer can turn a blind eye. > > > > > > > > Nonsense. > > > > > > The person developing the warning could *at least* have bootstrapped all > > > languages and detected, warned and helped the Fortran/Ada/whatever side to > > > cope with it. > > > > Of course "the person" had bootstrapped and tested all the languages before > > adding the warning. If only any of you bothered to check the fortran/ > > ChangeLogs: > > > > fortran/ != libgfortran/ I'm aware. But it's unfair to say that I hadn't tested Fortran when I, actually, had. > "The person" also failed to post his changes to fortran/ > on the fortran@ mailing list. So, the fortran changes were > likely not reviewed. It's entirely possible that I may have forgotten to CC fortran@, mea culpa; although I see that this went to @fortran, but was committed as obvious anyway: https://gcc.gnu.org/ml/fortran/2016-09/msg00113.html Marek
Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates
On Thu, May 11, 2017 at 11:12:24AM +0100, Jonathan Wakely wrote: > On 10 May 2017 at 23:14, Daniel Santos wrote: > > Well my primary goal is programming with values that are constant in the > > compiler. There is no language in any C specification (that I'm aware of) > > for a "compile-time constant", but the concept is very important. So just > > because some expression is a compile-time constant doesn't mean we morph > > into a "constant expression" (as per the spec), even with > > __attribute__((const)). > > The C standard says "An implementation may accept other forms of > constant expressions." That means rather than inventing some > "constprop" you could just extend GCC to treat more expressions > involving constants as constant-expressions. > > There are enhancement requests for this in Bugzilla, because some > compilers are already more catholic in what they accept in constant > expressions (notably, Clang). Right, at least: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618 Marek
Re: 'make check' questions
On Thu, May 11, 2017 at 11:50:21AM +0100, Kyrill Tkachov wrote: > > On 11/05/17 11:43, Simon Wright wrote: > > I see from https://gcc.gnu.org/install/test.html that it's possible to run > > tests in parallel. I get the impression from gcc/Makefile that the check > > concerned has to be set up in the Makefile (in my build tree, configured > > with --target=x86_64-apple-darwin16 > > --enable-languages=c,c++,ada,fortran,objc,obj-c++ , I see both lang_checks > > and lang_checks_parallelized set empty). So, is it necessary for check-ada > > or check-acats to cope with being run in parallel (i.e., will they ever see > > GCC_RUNTEST_PARALLELIZE_DIR set?) > > I don't usually build Ada, but testing with "make -j check" works for me > where is the parallelism I want I have export MAKEFLAGS='-j4' in my environment. Marek
Re: comparing parallel test runs
On Wed, May 17, 2017 at 09:13:40AM -0600, Jeff Law wrote: > On 05/17/2017 04:23 AM, Aldy Hernandez wrote: > > Hi folks. > > > > I've been having troubles comparing the results of different test runs > > for quite some time, and have finally decided to whine about it. Perhaps > > someone can point out to whatever I may be doing wrong. > > > > I generally do "make check -k -j60" on two different trees and compare > Make sure you've got Andi's patch installed and report back. It's > supposed to help with smaller -j loads, but it's unclear if it's enough > to address the problems with higher loads like you're using. I'm still seeing spurious tree-prof failures there (with -j48). Marek
Re: comparing parallel test runs
On Thu, May 18, 2017 at 05:22:50PM -0600, Martin Sebor wrote: > On 05/17/2017 11:19 PM, Andi Kleen wrote: > > Marek Polacek writes: > > > > > On Wed, May 17, 2017 at 09:13:40AM -0600, Jeff Law wrote: > > > > On 05/17/2017 04:23 AM, Aldy Hernandez wrote: > > > > > Hi folks. > > > > > > > > > > I've been having troubles comparing the results of different test runs > > > > > for quite some time, and have finally decided to whine about it. > > > > > Perhaps > > > > > someone can point out to whatever I may be doing wrong. > > > > > > > > > > I generally do "make check -k -j60" on two different trees and compare > > > > Make sure you've got Andi's patch installed and report back. It's > > > > supposed to help with smaller -j loads, but it's unclear if it's enough > > > > to address the problems with higher loads like you're using. > > > > > > I'm still seeing spurious tree-prof failures there (with -j48). > > > > Do they go away if you run first (as root) > > > > echo 5000 > /proc/sys/kernel/perf_event_mlock_kb > > > > first? > > I tried three runs of the profiling tests and the failures did > clear up with the increased setting. I tried setting that but I still saw a very small number of tree-prof failures, at least in one of the runs. But it did help - thanks. Marek
Re: Help with rich_location and GIMPLE stmts
n ret; }
> >>
> >>
> >> ^
> >> ret_6 = 999;
> >> m2.c:3:215: note: output_location
> >> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
> >> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
> >> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
> >> count(#) */ return ret; }
> >>
> >>
> >>
> >> ^~~
> >> _8 = ret_2;
> >> m2.c:3:215: note: output_location
> >> # VUSE <.MEM_9(D)>
> >> return _8;
> >>
> >> Which is not optimal, for some assignments I see just LHS
> >> (false_var_4 = 0),
Note that
unsigned int false_var = 0;
is not an assignment-expression, it's an initialization. Only the
'0' here is parsed as an assignment-expression, but in this case
set_c_expr_source_range isn't called.
> >
> > My first though was: are there assignments for which this isn't the
> > case? The only one I see is the:
> > ret = 999;
> > ^
> >
> > Are the locations for these assignments coming through from the
> > frontend?
>
> Hi.
>
> Actually not all, the default assignments are created in gimplifier and
> location is assigned from DECL_EXPR:
>
> (gdb) p debug_tree(*expr_p)
> type align 8 symtab 0 alias set -1 canonical type 0x76878f18
> pointer_to_this >
> side-effects
> arg 0 type size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x76878690
> precision 32 min max 0x76860f00 4294967295>
> pointer_to_this >
> used unsigned SI file /tmp/m2.c line 4 col 16 size 0x76860f18 32> unit size
> align 32 context initial
>
> chain 0x76878690 unsigned int>
> used unsigned SI file /tmp/m2.c line 4 col 43 size 0x76860f18 32> unit size
> align 32 context initial
> chain >>
> /tmp/m2.c:4:16 start: /tmp/m2.c:4:16 finish: /tmp/m2.c:4:23>
>
> That explains why only LHS of these assignments is selected.
>
> >
> > I believe that in the C frontend these are assignment-expression, and
> > hence handled by c_parser_expr_no_commas; in particular the use of
> > op_location and the call:
> >
> > set_c_expr_source_range (&ret, lhs.get_start (), rhs.get_finish ());
> >
> > ought to be setting up the caret of the assignment to be on the
> > operator token, and for the start/finish to range from the start of the
> > lhs to the end of the rhs i.e. what we see for:
> >
> > ret = 999;
> > ^
>
> Yep, MODIFY_EXPRs created in FE go this way and it's fine.
>
> >
> >
> >> for return statements only a returned value is displayed.
> >
> > Is this running on SSA form? If so, I wonder if you're running into
> > something like this:
> >
> > retval_N = PHI ;
> > return retval_N;
> >
> > where it's using the location of that "return retval_N;" for all of the
> > return statements in the function, rather than the individual source
> > locations.
>
> Yep, but we properly assign each assignment to a SSA name that's going to
> be merged in exit BB by PHI node:
>
> _8 = ret_2;
> /tmp/m2.c:7:8: note: output_location
> return ret; }
> ^~~
>
> Here the location comes from c_finish_return function where location
> comes from a value that's returned.
>
> >
> >> For conditions, only condition beginning is showed.
> >> Is this known behavior or do I miss
> >> something?
> >
> > c_parser_if_statement has:
> >
> > loc = c_parser_peek_token (parser)->location;
> >
> > which is that of the open-paren. Maybe we should build a location
> > covering the range of the "if ( expression )" part of the if-statement?
>
> Adding Marek as C FE maintainer to reply the question.
I suppose we could do better and I'd probably highlight just the expression
part of "if ( expression )". But not sure how many use cases this range
location would have.
Marek
Re: Getting spurious FAILS in testsuite?
On Thu, Jun 01, 2017 at 02:59:37PM +0200, Georg-Johann Lay wrote:
> Hi, when I am running the gcc testsuite in $builddir/gcc then
>
> $ make check-gcc RUNTESTFLAGS='ubsan.exp'
>
> comes up with spurious fails.
>
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
> target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for
> target.
> Using /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/config/default.exp as
> tool-and-target-specific interface file.
> Running
> /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.dg/ubsan/ubsan.exp ...
> FAIL: c-c++-common/ubsan/float-cast-overflow-8.c -O2 output pattern test
> FAIL: c-c++-common/ubsan/overflow-mul-4.c -O0 output pattern test
>
> ...
>
> when I am running the 1st test alone, then it works:
>
> $ make check-gcc RUNTESTFLAGS='ubsan.exp=float-cast-overflow-8.c'
>
> In an older log file I found for a different test from the same folder:
>
> /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.h:149:1:
> runtime error: value is outside the range of representable values
> of type 'unsigned int'
> /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.h:149:1:
> runtime error: value is outside the range of representable values
> of type 'long int'
> /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.h:149:1:
> runtime error: PASS: c-c++-common/ubsan
>
> BANG: "PASS" output from previous test run shreds this one?
>
> /float-cast-overflow-10.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects execution test
> FAIL: c-c++-common/ubsan/float-cast-overflow-10.c -O2 -flto
> -fuse-linker-plugin -fno-fat-lto-objects output pattern test
> Output was:
> c-c++-common/ubsan/float-cast-overflow-7.h:147:1: runtime error: value
> is outside the range of representable values of type 'signed char'
> ...
> c-c++-common/ubsan/float-cast-overflow-7.h:149:1: runtime error:
> Should match:
>
> The last output line stops after "runtime error: ", i.e. at the place
> where the "PASS" appears.
>
> Any ideas?
Does this help?
diff --git gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c
gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c
index 4adb22a..746fe20 100644
--- gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c
+++ gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c
@@ -140,4 +140,4 @@ main ()
/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of
representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "\[^\n\r]*value -1 is outside the range of representable values
of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of
representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target { int128
} } } */
-/* { dg-output "\[^\n\r]*value -1 is outside the range of representable values
of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
+/* { dg-output "\[^\n\r]*value -1 is outside the range of representable values
of type '__int128 unsigned'" { target { int128 } } } */
Marek
Re: https://gcc.gnu.org/gcc-7/changes.html
On Tue, Jul 11, 2017 at 09:51:19AM -0700, Jonny Grant wrote: > Hello > https://gcc.gnu.org/gcc-7/changes.html > > snprintf (d, sizeof d, "%#02x", x & 0xff); > >^^ > Should be: sizeof(d) ? Why? Both are correct. Marek
Re: tests for GCC internal functions
On Wed, Aug 16, 2017 at 08:46:20AM -0600, Martin Sebor wrote: > Is there a setup for writing and running as part of the test > suite unit tests that exercise internal GCC functions like > error and warning? I ask because of a couple of bugs that > were recently reported for the %s directive in GCC's > diagnostics (81859 and 81586) that were only caught by running > valgrind on GCC, but that could have been caught by GCC's own > tests for these APIs if they existed. > > I can't find any except some in the gcc.dg/plugin directory > (though they weren't written to exercise the functions but > rather the plugin interface). Would adding a plugin for > this sort of thing be the right way to do it? Isn't -fself-test the thing you're looking for? Marek
Re: Segfault generated by gcc-7
On Tue, Aug 29, 2017 at 12:31:39PM +0200, Marco Varlese wrote: > Hi, > > I got a SEGFAULT in my program when compiling it with gcc-7 but it > is/was all good when using gcc-6. > > The SEGFAULT happens due to the line below: > d_point = *p; > > And a fix for it (with gcc-7) has been: > memcpy(&d_point, > p, > sizeof(d_point)); > > Does this make any sense to anybody? Not without a stand-alone testcase. See <https://gcc.gnu.org/bugs/> for more info. Marek
Re: FYI: Latest gcc-8 snapshot gives ICE with later isl's
On Mon, Mar 05, 2018 at 12:58:23PM -0500, Donald Parsons wrote: > > I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using either > isl-0.18 or isl-0.19. I had never had a problem using latest isl over > the past couple of years, so a change in gcc last week introduced the > problem. > > Normally I disable-bootstrap and use last weeks gcc-8 to build this > weeks gcc-8 and avoid the extra long bootstrap time. This actually > worked, at least with isl-0.18 but the resulting gcc-8 gave ICE errors > building latest "pari-gp" and the latest-rc4 Linux kernel. So went > back to bootstrapping with (Redhat gcc-7.3.1-2) and discovered the > above. > > Here is failure (using isl-0.18; 0.19 looks same): > ... > libtool: compile: /home/don/src/gcc-8-20180304-obj/./prev-gcc/xgcc > -B/home/don/src/gcc-8-20180304-obj/./prev-gcc/ -B/opt/gcc/gcc-8- > 0304/x86_64-redhat-linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat- > linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat-linux/lib/ -isystem > /opt/gcc/gcc-8-0304/x86_64-redhat-linux/include -isystem /opt/gcc/gcc- > 8-0304/x86_64-redhat-linux/sys-include -DHAVE_CONFIG_H -I. -I../../gcc- > 8-20180304/isl -I../../gcc-8-20180304/isl/include -Iinclude/ -g -O2 > -gtoggle -MT isl_factorization.lo -MD -MP -MF > .deps/isl_factorization.Tpo -c ../../gcc-8- > 20180304/isl/isl_factorization.c -o isl_factorization.o > during GIMPLE pass: pre > ../../gcc-8-20180304/isl/isl_factorization.c: In function > 'isl_basic_set_factorizer': > ../../gcc-8-20180304/isl/isl_factorization.c:256:28: internal compiler > error: in compute_antic_aux, at tree-ssa-pre.c:2148 > __isl_give isl_factorizer *isl_basic_set_factorizer( > ^~~~ > 0x11e6790 compute_antic_aux > ../../gcc-8-20180304/gcc/tree-ssa-pre.c:2148 > 0x11e713b compute_antic > ../../gcc-8-20180304/gcc/tree-ssa-pre.c:2364 > 0x11ec1b1 execute > ../../gcc-8-20180304/gcc/tree-ssa-pre.c:4131 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. > See <https://gcc.gnu.org/bugs/> for instructions. > make[5]: *** [Makefile:1463: isl_factorization.lo] Error 1 > make[5]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl' > make[4]: *** [Makefile:1571: all-recursive] Error 1 > make[4]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl' > make[3]: *** [Makefile:1167: all] Error 2 > make[3]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl' > make[2]: *** [Makefile:6155: all-stage2-isl] Error 2 > make[2]: Leaving directory '/home/don/src/gcc-8-20180304-obj' > make[1]: *** [Makefile:25157: stage2-bubble] Error 2 > make[1]: Leaving directory '/home/don/src/gcc-8-20180304-obj' > make: *** [Makefile:947: all] Error 2 I bet this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670 which is already fixed. Marek
Re: Next question: sizeof(char buf[2042])
On Wed, Jun 20, 2018 at 11:47:45AM -0700, Bruce Korb wrote: > Yeah, I guess this is Clang, but is it a legal interpretation for Clang? > > In file included from gnu-pw-mgr.c:24: > > In file included from ./fwd.h:288: > > *./seed.c:178:43: **warning: **sizeof on pointer operation will return size > of 'const char *' instead of 'const char [2042]'* > > * [-Wsizeof-array-decay]* > > char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG))); > > * ^~~* > > > *It seems like a pretty brain damaged interpretation.* We'd need to see the code but the warning seems legit. What's the problem? Marek
Re: Wabi warnings during GCC build
On Wed, Jun 27, 2018 at 08:53:48AM -0700, Steve Ellcey wrote: > Are other people building GCC seeing these messages during the build: > > cc1plus: warning: -Wabi won't warn about anything [-Wabi] > cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, > which is also used by default > cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7 > > It doesn't seem to be causing any problems in the build (even bootstrap) > but I am wondering why it is there. It seems to be happening when > using the latest (just built) g++ to build libstdc++ so it shouldn't > be related to the system GCC that I am using to build with. > > I didn't find any mention of it in the gcc or libstdc++ mailing lists > when I looked or find any bugzilla report. I see it too, started with r261571. libstdc++/acinclude.m4 needs to be adjusted: WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi' I guess to -Wabi=11? Marek
Re: RFC: Idea for code size reduction
Hello everybody, On Friday 07 March 2008 Philipp Marek wrote: > Here you are. > > > code_overlap.pl - disassembles a binary, and outputs a list > (address, name, instruction, bytes) to STDOUT. > > bytes_saved.pl - takes such a list, and tries to estimate > the amount of bytes that could be saved. > > > I normally use them this way: > #!/bin/sh > perl code_overlap.pl "$@" > overlap.txt > perl bytes_saved.pl has anyone acted on that already? I've got some more ideas, which I'd like to test (and implement) here. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
[ANN]: Redundancy remover
Hello everybody, the idea I presented last year [1], and which I said in January that I thought how to realize [2], has come true. I'd like to show you a tool that removes a bit of redundancy off your binaries, without needing to change the sources, by identifying repeated code blocks, and substituting them in the assembler listing by jumps to a common block. This is certainly not finished; depending on the AI that's put in here it could even write completely new functions, that combine small differences in the callers by using parameters. I have a prototype, which can prove the principle. I'm just inserting the README here; before more people join in hacking that, I'd like to ask whether I should open a new project for this at some OSS portal, or whether that should live in the GCC tree. Depending on that answer I'd put the code somewhere, and post the link here; I'd like to avoid having people sending me patches, because they're certain to conflict sooner or later, and I'm already a bit short on time anyway. Regards, Phil 1: http://gcc.gnu.org/ml/gcc/2008-03/msg00410.html 2: http://marc.info/?l=gcc&m=123272618027709&w=2 -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!Redundancy Remover == (C)opyright 2009 by Ph. Marek, philipp <%40> marek.priv.at Released under the GPLv3. What is this? = RR is a set of scripts to find duplicated code in binary files (like executables and shared objects), and to eliminate them by translating the assembler output of gcc before it's being converted to object code. And this works? === Yes, it does. See test results below. I chose to test FSVS because - it's my pet project, and so I know exactly how to compile it; - it has extensive tests, which I can use to verify the translation; - it's of a representative size. A bigger (partly done) test is with libgcj9; see below, too. How does this work? === Please see the POD documentation in the rr-translate perl script. Note about the savings == The values given by the script are just predictions for perfect translations, which won't be really seen. FSVS results The compilation took a bit more than twice as long; without translation 14.8 sec to 35.2 sec. The prediction was 2424 bytes, the real size difference 2128 bytes (0.8%): size: textdata bss dec hex filename 2598247960 11136 278920 44188 fsvs 2576967960 11136 276792 43938 fsvs.translated Linux kernel results I ran this on my custom linux kernel: text data bss dec hex filename 4651138 2149868 6551208 13352214 cbbd16 /usr/src/linux/vmlinux and got a prediction of about 37kB: max savings: 159513 real savings approximate 37917 bytes. Writing files to /tmp. 645 files written. In real life a bit less is to be expected; but 32kB should be possible. libgcj9 results === As I didn't have the sources available (at this moment), I only looked at the analyse results. I took /usr/lib/libgcj.so.90 from debian: libgcj9-0 4.3.3-3 Java runtime library for use with gcj -rw-r--r-- 1 root root 46903400 31. Jän 05:23 /usr/lib/libgcj.so.90 which, I believe, is one of the best cases, because it includes a high number of functions, where tail packing (;-) can be done. Analysing takes about 500MB RAM, and runs on a 800MHz machine for real 1m36.873s user 1m36.426s sys 0m3.636s The (unbelieveable) output is (surely wrong; but a straight compile of this library would give real hard numbers, so I stopped my bug hunting) max savings: 736313 real savings approximate 1561073 bytes. As an example of an output dump: # Redundancy Remover generated file. # This code part was originally seen at 0x016a9750 # got 129 hits in /usr/lib/libgcj.so.90, and was 158 bytes long. .globl RRGh7K3nv6Ocjw48SB5SACg .type RRGh7K3nv6Ocjw48SB5SACg, @function mov $0x4,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x5,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x6,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x7,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x8,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x9,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0xa,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0xb,%edi callq _Jv_ThrowBadArrayIndex mov $0xc,%edi callq _Jv_ThrowBadArrayIndex mov $0xd,%edi callq _Jv_ThrowBadArrayIndex xchg %ax,%ax sub $0x8,%rsp callq _ZN4java4util18ListResourceBundleC1Ev add $0x8,%rsp retq
Preprocessor for assembler macros?
Hello everybody, I already asked that on gcc-help@ but got no answer, so I'm trying again here. I'm looking for a way to get inbetween the assembler macro processor and the assembler. I'd like to get the assembler sources mostly as-is, but with the macros used therein already expanded. I've already taken a look at the "-a" command line option, but this does assembling as well - so I'd have to filter the real assembler from there, and try this way. Is there something easier? Thank you for all answers. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Re: Preprocessor for assembler macros?
> gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S > tmp.s > is what you need Thank you very much, I'll take a look. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Re: Preprocessor for assembler macros?
Philipp Marek marek.priv.at> writes: > > gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S > tmp.s > > is what you need > Thank you very much, I'll take a look. I tried very hard to achieve that; and one time it seemed to work, but I cannot make it work again. As an example I'm trying to expand the macros in the linux kernel source file arch/x86/kernel/entry_64.S I tried to call "gcc -S", to put the various "-I.." paths as needed, and I even renamed my "as" to "as.bin" and tried to get the assembler source directly (by using "gcc -S $COLLECT_GCC_OPTIONS sourcefile") ... I cannot make it work again ... Do you have some other hint for me? Thank you very much. Regards, Phil
use changes in STL library
We are students of Warsaw University of Technology and we are in our final year. We've just started working on our final project at our university. We'd like to develop the STL library and enhance it with some features. We checked out the GNU source using the svn command: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc Now, we'd like to modify the gnu sources that we downloaded and test the changes in our programm. In other words, we don't want to recompile the standard library that is installed on our computer, but we'd like to make some changes in the downloaded repository and check if our programms if the changes work. Could you write us what command we should use? We'd like to emphasize that we don't want to recompile whole gcc on our computer, we just want to make use of changes we did in the repository. Thank you very much for any help, Marek Zuk Maciej Lozinski Piotr Borkowski Warsaw University of Technology, Faculty of Mathematics & Computer Science
use of changes in STL library
We are students of Warsaw University of Technology and we are in our final year. We've just started working on our final project at our university. We'd like to develop the STL library and enhance it with some features. We checked out the GNU source using the svn command: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc Now, we'd like to modify the gnu sources that we downloaded and test the changes in our programm. In other words, we don't want to recompile the standard library that is installed on our computer, but we'd like to make some changes in the downloaded repository and check if our programms if the changes work. Could you write us what command we should use? We'd like to emphasize that we don't want to recompile whole gcc on our computer, we just want to make use of changes we did in the repository. Thank you very much for any help, Marek Zuk Maciej Lozinski Piotr Borkowski Warsaw University of Technology, Faculty of Mathematics & Computer Science
Re: use of changes in STL library
Hi thanks a lot for your reply. I'm not sure if you understood what I meant... I'm a student of the Faculty of Mathematics & Computer Science at the Warsaw University of Technology. I'm in my final year of my studies (MSc) and I'm working on my final project. The the subject of my project is: "Enhancing associative containers (map, multimap, set and multiset) in STL with the possibility of choosing the way of their implmentation". So I'm going to develop libstdc++. Now associative containers in STL are implemented by use of red-black trees. What I want to do, is to enable the choice of implementation of these containers by adding one parameter to the templates, so that the containers could by be built by use of b-trees, just vectors or others structures. So my question is: How to make changes in libstdc++ and how to test these changes in the easiest way? Thank you very much for your help. Marek Zuk Paolo Bonzini wrote: Could you write us what command we should use? We'd like to emphasize that we don't want to recompile whole gcc on our computer, we just want to make use of changes we did in the repository. Short answer is you can't. The gcc build system doesn't support building just the target libraries. You're going to have to build the whole thing. You can build GCC only once, and then modify libstdc++. If you don't want to install GCC, you can install libstdc++ with make install-libstdc++-v3 Paolo
Re: GCC build error
On Thu, May 09, 2013 at 08:19:45PM +, Iyer, Balaji V wrote: > Hello Everyone, > I am currently trying to build the GCC trunk (revision 198747) and it > is giving me the following error in make install for the java compiler. It > looks like it is not able to find a function. > > Thanks, > > Balaji V. Iyer. > > > libtool: link: /export/users/gcc-svn/b-trunk-gcc/./gcc/gcj > -B/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava/ > -B/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava/ > -B/export/users/gcc-svn/b-trunk-gcc/./gcc/ > -B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/bin/ > > -B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/lib/ > -isystem > /export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/include > -isystem > /export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/sys-include > -m32 -ffloat-store -fomit-frame-pointer -Usun -g -O2 -m32 -m32 -o > .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc > -L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava/.libs > -L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava > ./.libs/libgcj.so -lpthread -ldl -lrt -Wl,-rpath > -Wl,/export/users/gcc-svn/install_dir/trunk-install/lib/../lib > ./.libs/libgcj.so: undefined reference to `__cxa_throw_bad_array_length' > collect2: error: ld returned 1 exit status > make[5]: *** [jv-convert] Error 1 Should be already fixed by Jason. Marek
Re: Documentation for loop header copying
On Fri, Jul 19, 2013 at 04:42:56PM +0200, Abdul Wahid Memon wrote:
> I am searching for some documentation (books, research papers, etc) on
> loop header copying compiler optimization.
>
> Any hints on this please?
You may want to look at the comments in tree-ssa-loop-ch.c in the GCC
source tree.
Marek
Re: New file extension
On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: > Hi, > > I would like to suggest that new implementation files have > the '.cc' extension, unless they are meant to be processed > with a C compiler. (I am not proposing wholesale renaming.) Oh, I suppose this applies to ubsan, e.g. (Haven't commited it to trunk yet, but so far the files still have the '.c' extension.) Will rename it then, though I like '.c' more ;). Marek
Re: New file extension
On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > I do not care very much but I disagree. Having some files with .c > suffix and some with .cc suffix would imply some sort of difference > where there is going to be none. Yeah -- this sort of discrepancy I don't like either. In gcc/, we have 362 .c files and 0 .cc files, so every new .cc file will step out of line... That might be pain for people who are used to do 'grep foo gcc/*.c' and suchlike. Marek
Re: New file extension
On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: > On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > >> I do not care very much but I disagree. Having some files with .c > >> suffix and some with .cc suffix would imply some sort of difference > >> where there is going to be none. > > > > Yeah -- this sort of discrepancy I don't like either. In gcc/, we > > have 362 .c files and 0 .cc files, so every new .cc file will step out > > of line... That might be pain for people who are used to do > > 'grep foo gcc/*.c' and suchlike. > > Any issues with doing a mass rename then? If various svn/git blame/log's would work, then I'm fine with it. It's been discussed on gcc@ at some point; I don't remember any major (dis)advantages. Ok, I'll rename my new .c files to .cc. Marek
Re: New file extension
On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote: > On 07/30/2013 08:27 AM, Marek Polacek wrote: > >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: > >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > >>>On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > >>>>I do not care very much but I disagree. Having some files with .c > >>>>suffix and some with .cc suffix would imply some sort of difference > >>>>where there is going to be none. > >>>Yeah -- this sort of discrepancy I don't like either. In gcc/, we > >>>have 362 .c files and 0 .cc files, so every new .cc file will step out > >>>of line... That might be pain for people who are used to do > >>>'grep foo gcc/*.c' and suchlike. > >>Any issues with doing a mass rename then? > I'd suggest waiting for a mass rename until the next stage 1... (or > stage 0.9 :-) I will want to mass rename a lot of the files (ie, a > lot of tree-* will lose the tree- prefix), and I think we'll be > moving directory structures around as well... and some include files > will be split up... etc. etc.Seems like a logical time to change > extensions too. > > My point is, why go through the pain of changing a bunch of files > now when we are probably going to do it again within a year. On second thought, yes, waiting for mass rename sounds better than to add one .cc file... Marek
Re: [RFC] gcc feature request: Moving blocks into sections
On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote: > On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds > wrote: > > > > Ugh. I can see the attraction of your section thing for that case, I > > just get the feeling that we should be able to do better somehow. > > Hmm.. Quite frankly, Steven, for your use case I think you actually > want the C goto *labels* associated with a section. Which sounds like > it might be a cleaner syntax than making it about the basic block > anyway. FWIW, we also support hot/cold attributes for labels, thus e.g. if (bar ()) goto A; /* ... */ A: __attribute__((cold)) /* ... */ I don't know whether that might be useful for what you want or not though... Marek
Re: c++/linker problems maybe?
On Mon, Aug 05, 2013 at 10:05:22PM -0700, George R Goffe wrote: > Hi, > > I'm having trouble building or linking C++ code. Could one of you brains take > a peek at the enclosed and let me know where I'm goofing please? This question is not appropriate for the mailing list gcc@gcc.gnu.org, which is for the development of GCC. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. > [ 88%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bthemedlabel.cpp.o > > > [ 88%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3blsofwrapper.cpp.o > > > [ 89%] Building CXX object > src/CMakeFiles/k3b_bin.dir/k3blsofwrapperdialog.cpp.o > > [ 89%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3baction.cpp.o > > > [ 89%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bdevicemenu.cpp.o > > > [ 89%] Building CXX object > src/CMakeFiles/k3b_bin.dir/k3bviewcolumnadjuster.cpp.o > > [ 90%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bmodelutils.cpp.o > > > Linking CXX executable k3b > CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function > `K3b::MainWindow::~MainWindow()': > /tools/k3b/k3b/src/k3b.cpp:272: undefined reference to > `KXmlGuiWindow::~KXmlGuiWindow(void const**)' > CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function `K3b::MainWindow::MainWindow()': > /tools/k3b/k3b/src/k3b.cpp:227: undefined reference to > `KXmlGuiWindow::KXmlGuiWindow(void const**, QWidget*, QFlags)' > CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function `K3b::MainWindow::MainWindow()': > /tools/k3b/k3b/src/k3b.cpp:227: undefined reference to > `KXmlGuiWindow::KXmlGuiWindow(void const**, QWidget*, QFlags)' > CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function > `K3b::MainWindow::~MainWindow()': > /tools/k3b/k3b/src/k3b.cpp:272: undefined reference to > `KXmlGuiWindow::~KXmlGuiWindow(void const**)' > collect2: error: ld returned 1 exit status > make[2]: *** [src/k3b] Error 1 > make[1]: *** [src/CMakeFiles/k3b_bin.dir/all] Error 2 > make: *** [all] Error 2 It just seems the library containing the definition of KXmlGuiWindow::KXmlGuiWindow isn't properly linked in. Marek
