[Bug c++/84075] New: Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 Bug ID: 84075 Summary: Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’ Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: matteo-ml at member dot fsf.org Target Milestone: --- Created attachment 43262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43262&action=edit Preprocessed file I encounter the following error when building a C++ source file doing some moderately deep template instantiation due to Eigen + Boost.Serialization. I cannot reproduce the same error on a minimal example, although I tried. Clang builds the same sources fine (and the resulting linked binary runs correctly). I can reproduce the same problem also with older g++ versions. // - $ g++ -v Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.3.0 (Debian 7.3.0-1) // - FAILED: CMakeFiles/gadv-backend.dir/gadv-backend/logic/petri-net.cc.o /usr/bin/g++ -Dgadv_EXPORTS -Dgadv_backend_EXPORTS -I/home/matteo/Progetti/gadv/include -Iinclude -I/home/matteo/Progetti/gadv/src/gadv-backend -isystem /usr/include/eigen3 -isystem /usr/include/pangomm-1.4 -isystem /usr/lib/x86_64-linux-gnu/pangomm-1.4/include -isystem /usr/include/glibmm-2.4 -isystem /usr/lib/x86_64-linux-gnu/glibmm-2.4/include -isystem /usr/include/cairomm-1.0 -isystem /usr/lib/x86_64-linux-gnu/cairomm-1.0/include -isystem /usr/include/sigc++-2.0 -isystem /usr/lib/x86_64-linux-gnu/sigc++-2.0/include -isystem /usr/include/pango-1.0 -isystem /usr/include/harfbuzz -isystem /usr/include/cairo -isystem /usr/include/glib-2.0 -isystem /usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem /usr/include/pixman-1 -isystem /usr/include/freetype2 -isystem /usr/include/libpng16 -ftemplate-backtrace-limit=0 -fdiagnostics-color=always -O3 -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -pedantic -fstack-protector-strong -std=gnu++1z -MD -MT CMakeFiles/gadv-backend.dir/gadv-backend/logic/petri-net.cc.o -MF CMakeFiles/gadv-backend.dir/gadv-backend/logic/petri-net.cc.o.d -o CMakeFiles/gadv-backend.dir/gadv-backend/logic/petri-net.cc.o -c /home/matteo/Progetti/gadv/gadv-backend/logic/petri-net.cc In file included from /usr/include/eigen3/Eigen/Core:351:0, from /usr/include/eigen3/Eigen/SparseCore:11, from /home/matteo/Progetti/gadv/include/gadv/logic/petri-net.hh:24, from /home/matteo/Progetti/gadv/gadv-backend/logic/petri-net.cc:18: /usr/include/eigen3/Eigen/src/Core/NumTraits.h: In instantiation of ‘struct Eigen::GenericNumTraits’: /usr/include/eigen3/Eigen/src/Core/NumTraits.h:150:29: required from ‘struct Eigen::NumTraits’ /usr/include/eigen3/Eigen/src/SparseCore/SparseMatrixBase.h:109:30: required from ‘class Eigen::SparseMatrixBase >’ /usr/include/eigen3/Eigen/src/SparseCore/SparseCompressedBase.h:36:7: required from ‘class Eigen::SparseCompressedBase >’ /usr/include/boost/serialization/split_free.hpp:58:13: recursively required by substitution of ‘template class SPT> void boost::serialization::load(Archive&, SPT&, unsigned int) [with Archive = boost::archive::xml_iarchive; SPT = ]’ /usr/include/boost/serialization/split_free.hpp:58:13: required from ‘static void boost::serialization::free_loader::invoke(Archive&, T&, unsigned int) [with Archive = boost::archive::xml_iarchive; T = Eigen::Triplet]’ /usr/include/boost/serialization/split_free.hpp:74:18: required from ‘void boost::serialization::spli
[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046
--- Comment #5 from Martin Uecker ---
(In reply to Jakub Jelinek from comment #4)
> If you want aggregate with size 1 and isn't used to store information, use
> typedef struct { char : 1; } zero;
> instead.
Yes, thank you.
But for my understanding: Is there a reason why it is important that zero-sized
objects should sometimes have the same address? I am wondering because I think
zero-sized arrays would make sense to allow in C (it sometimes makes
programming edge cases simpler in numerical code) and at the same time I think
it might be a nice principle to require that all unique objects existing at the
same time should also have a unique address.
[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046 --- Comment #6 from Jakub Jelinek --- Zero sized object occupies zero bytes, if you have an array of them, necessarily all the elements of the array need to have the same address. While individual variables could be in theory padded, it would be a waste of address space for something that doesn't need to occupy any address space. Furthermore, in your testcase the objects are common variables, so it is the linker that allocates them. If you need unique addresses, just don't use zero sized objects, if you don't mind them, forcing everyone to have unique addresses might be a misoptimization for them.
[Bug fortran/41137] inefficient zeroing of an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #20 from Dominique d'Humieres --- For the test in comment 0, I get 0.107776999 0.108125009 with gcc6, 7, and trunk (8.0) if I use -O3 or -Ofast, -O2 gives 0.107547000 0.569643974 Could this PR be considered FIXED?
[Bug fortran/84065] [8 regression] string_1.f90 fails since r256944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84065 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Jan 27 10:28:20 2018 New Revision: 257121 URL: https://gcc.gnu.org/viewcvs?rev=257121&root=gcc&view=rev Log: PR fortran/84065 * decl.c (add_init_expr_to_sym): Ignore initializers for too large lengths. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c
[Bug middle-end/67220] GCC fails to properly handle libcall symbol visibility of builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
--- Comment #5 from Bernd Edlinger ---
FYI the C++ FE behaves differently:
cat x.cc
typedef __SIZE_TYPE__ size_t;
extern "C" void *memset(void *s, int c, size_t n)
__attribute__ ((visibility ("hidden")));
void
foo1 (void *s, size_t n)
{
memset (s, '\0', n);
}
void
foo2 (void *s, int c, size_t n)
{
memset (s, c, n);
}
gcc -Wall -O2 -fPIC -S x.cc
x.cc:2:18: warning: 'void* memset(void*, int, size_t)': visibility attribute
ignored because it conflicts with previous declaration [-Wattributes]
extern "C" void *memset(void *s, int c, size_t n)
^~
: note: previous declaration of 'void* memset(void*, int, size_t)'
[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #13 from Heinz Kohl ---
O.k., but following your arguments I'd expect 0xb as result for my second
example 0xb.3590da0e2a06736p-3 (attachment 41578), but it's giving 0, also
stopping at 'x' and not at '.', just as in the first case.
It might be just another case of the same problem, but I'm not sure.
An actual test run:
./a.out
Parsing 0x1P-1022 as hex gives 0
Parsing '0xb.3590da0e2a06736p-3 xyz' as hex gives 0 xb.
(The source code for the second example is:
std::istringstream("0xb.3590da0e2a06736p-3 xyz") >> std::hexfloat >> g >> a
>> b >> c ;
std::cout << "Parsing '0xb.3590da0e2a06736p-3 xyz' as hex gives " << g << ' '
<< a << b << c << std::endl;
)
[Bug plugins/83442] FAIL: gcc.dg/plugin/expensive-selftests-1.c -- timeout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83442 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #2 from David Malcolm --- Do the other plugins in plugin.exp work, or is it just this one?
[Bug c++/84076] New: [5/6/7/8 Regression] Warning about objects through POD mistakenly claims the object is a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84076
Bug ID: 84076
Summary: [5/6/7/8 Regression] Warning about objects through POD
mistakenly claims the object is a pointer
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Test program:
#include
#include
int main(void)
{
std::string str;
printf("%s\n", str);
}
GCC 4.9 and older gives:
test.cpp: In function ‘int main()’:
test.cpp:7:20: error: cannot pass objects of non-trivially-copyable type
‘std::string {aka class std::basic_string}’ through ‘...’
printf("%s\n", str);
^
GCC 5.0 and newer (including 7.3.0) prints:
test.cpp: In function ‘int main()’:
test.cpp:7:20: warning: format ‘%s’ expects argument of type ‘char*’, but
argument 2 has type ‘std::__cxx11::string* {aka
std::__cxx11::basic_string*}’ [-Wformat=]
printf("%s\n", str);
^
This is a confusing warning, since it claims I'm sending a std::string * when
I'm sending a std::string. In particular, in the program I was trying to fix
this by adding ->c_str(), but .c_str() was the correct choice.
[Bug target/83905] ix86_expand_epilogue modifies the copy of cfun->machine->frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83905 --- Comment #3 from hjl at gcc dot gnu.org --- Author: hjl Date: Sat Jan 27 13:10:24 2018 New Revision: 257123 URL: https://gcc.gnu.org/viewcvs?rev=257123&root=gcc&view=rev Log: i386: Use const reference of struct ix86_frame to avoid copy We can use const reference of struct ix86_frame to avoid making a local copy of ix86_frame. ix86_expand_epilogue makes a local copy of struct ix86_frame and uses the reg_save_offset field as a local variable. This patch uses a separate local variable for reg_save_offset. Tested on x86-64 with ada. Backport from mainline PR target/83905 * config/i386/i386.c (ix86_expand_prologue): Use cost reference of struct ix86_frame. (ix86_expand_epilogue): Likewise. Add a local variable for the reg_save_offset field in struct ix86_frame. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.c
[Bug bootstrap/43301] top-level configure script ignores ---with-build-time-tools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301 --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > (In reply to Ryan Johnson from comment #0) > > ./configure ... --with-build-time-tools=$MY_TOOLS ignores $MY_TOOLS (though > > it correctly warns when $MY_TOOLS is not an absolute path). > > > > Let's just say this led to extremely frustrating behavior until I decided to > > start digging... > > > > Suggested patch to correct the problem: > > > > Index: /home/Ryan/apps/gcc-4.5-src/configure.ac > > === > > --- /home/Ryan/apps/gcc-4.5-src/configure.ac(revision 157227) > > +++ /home/Ryan/apps/gcc-4.5-src/configure.ac(working copy) > > @@ -3221,7 +3221,9 @@ > >[ --with-build-time-tools=PATH > >use given path to find target tools during the > > build], > >[case x"$withval" in > > - x/*) ;; > > + x/*) > > + with_build_time_tools=$withval > > + ;; > > *) > > with_build_time_tools= > > AC_MSG_WARN([argument to --with-build-time-tools must be an absolute > > path]) > > Confirming that GCC's configure.ac is still unpatched. Patches go to the gcc-patches mailing list if you still want to see this fixed
[Bug bootstrap/38743] libgcc multilib fails if not able to exec "non" native programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38743 --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > (In reply to Andrew Pinski from comment #6) > > a patch like http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00474.html is > > needed for libgcc. > > Confirming that libgcc/configure.ac is still missing something like that. (the linked patch is for libiberty, not libgcc, so I can't add the "patch" keyword yet)
[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 --- Comment #21 from Waldemar Brodkorb --- I can confirm that this fixes the problem even for gcc 7.x. Any chance to get it included into gcc 7 branch? No regression found while running the uClibc-ng testsuite inside qemu-system-m68k. Thanks a lot!
[Bug plugins/83442] FAIL: gcc.dg/plugin/expensive-selftests-1.c -- timeout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83442 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin --- Test no longer fails.
[Bug objc++/49070] [6/7/8 regression] ObjC++ compiler fails to compile ObjC method invocations without keyword arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49070 Eric Gallager changed: What|Removed |Added Keywords||needs-bisection Priority|P3 |P4 Target Milestone|--- |6.4 Summary|ObjC++ compiler fails to|[6/7/8 regression] ObjC++ |compile ObjC method |compiler fails to compile |invocations without keyword |ObjC method invocations |arguments |without keyword arguments --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > > I also checked with an older version of g++ (Apple's 4.0.1) and can confirm > that the older version compiled it successfully. ...therefore, I'm adding the regression marker
[Bug objc++/66504] ICE using C++ exceptions in Objective-C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66504 Eric Gallager changed: What|Removed |Added Known to work||4.7.4, 4.8.5, 5.5.0, 6.4.0, ||7.2.0 --- Comment #2 from Eric Gallager --- Huh, I tested this testcase with more versions of gcc, and it works with all the versions I have installed from MacPorts, but still fails with the latest version I built myself... maybe it's a difference in configure options? Although I try to keep mine pretty similar to those that MacPorts uses...
[Bug other/35511] release scripts added release note to zlib/ChangeLog, not zlib/ChangeLog.gcj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35511 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-27 Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > (In reply to Debian GCC Maintainers from comment #0) > > the release scripts added the release note for 4.3.0 to zlib/ChangeLog > > (upstream), not zlib/ChangeLog.gcj > > IMO zlib/ChangeLog.gcj should be renamed since gcj has been removed from gcc. Putting this in WAITING for someone else's opinion
[Bug c/51088] undefined label with statement expression and cond expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51088
--- Comment #6 from Eric Gallager ---
(In reply to Marek Polacek from comment #5)
> Patch to give an error if taking an address of a label defined in ({}):
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00381.html
Does this patch still apply against more recent GCC?
[Bug objc/77428] incorrect 'set but not used' warning with @throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77428 --- Comment #3 from Eric Gallager --- (In reply to Tom de Vries from comment #1) > Created attachment 39528 [details] > tentative patch Have you sent this patch to the gcc-patches mailing list yet?
[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #2 from Wilco --- (In reply to Andrew Pinski from comment #1) > I think this is related to PR 81443. Can you see if the 7.3 release has it > fixed? It's related indeed, in both cases it incorrectly uses load_extend_op on registers rather than MEM. The first primarily fails on targets that return ZERO_EXTEND, the 2nd on targets that use SIGN_EXTEND.
[Bug rtl-optimization/81443] [8 regression] build/genrecog.o: virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #21 from Wilco --- See also PR84071 which has bad codegen from r242326.
[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074 --- Comment #3 from Vladimir Fuka --- The bug has been around for so long that I already forgot I saw these problems before.
[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073 --- Comment #3 from emsr at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > Withe the following change > > --- pr84073.f90 2018-01-26 22:48:32.0 +0100 > +++ pr84073_db.f902018-01-27 00:03:06.0 +0100 > @@ -13,10 +13,10 @@ module utderror > integer(c_int):: nerrorloc > real(c_double):: errorstartloc(3) > real(c_double):: errorendloc(3) > -character(kind=c_char, len=41) :: errorsubsystem > -character(kind=c_char, len=9) :: errorseverity > +character(kind=c_char) :: errorsubsystem(41) > +character(kind=c_char) :: errorseverity(9) > integer(c_int):: errorid > -character(kind=c_char, len=1001) :: errormessage > +character(kind=c_char) :: errormessage(1001) >end type > >type(utderror_t), bind(c), save :: utderror_v > > I get > > ... > char errorsubsystem[41]; > char errorseverity[9]; > int errorid; > char errormessage[1001]; > } utderror_t; > void add_utd_error (int *ierror); > extern utderror_t utderror_v; > > Possibly related to PR38506. Yes, I tries this. On the Fortran side, the arrays of character are not recognized as strings. You can't use // and len and such. I'll just do this one by hand until the new array descriptors are in. Thanks for the feature and the look anyway. I wonder if a -ffortran-interfaces from C/C++ would be of use to anyone.
[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from H.J. Lu --- Fixed by gdb.
[Bug target/83905] ix86_expand_epilogue modifies the copy of cfun->machine->frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83905 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from H.J. Lu --- Fixed for GCC 8 and GCC 7.4.
[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83828 --- Comment #3 from H.J. Lu --- On AVX512 machine, r257121 gave: FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c (test for excess errors) FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c (test for excess errors) FAIL: gcc.target/i386/avx512bitalgvl-vpopcntw-1.c execution test FAIL: gcc.target/i386/avx512bitalgvl-vpopcntw-1.c execution test FAIL: gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c execution test FAIL: gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c execution test
[Bug c/53129] Wself-assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53129 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #0) > > An implementation was submitted to GCC but never approved here: > > http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02390.html Adding the "patch" keyword
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Severity|normal |enhancement
[Bug preprocessor/49973] Column numbers count special characters as multiple columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69664 --- Comment #12 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #11) > This should be fixed in libcpp, probably in lex.c, but maybe other places > also. A good testcase to start with would be: > > /* ñ /* */ > /* a /* */ > > cc1 -Wcomment > > prog.cc:1:7: warning: "/*" within comment [-Wcomment] > /* ñ /* */ >^ > prog.cc:2:6: warning: "/*" within comment [-Wcomment] > /* a /* */ > ^ > > Both locations should point to column 6. Look for places where column info > is converted to source_location (linemap_position_for_column or > linemap_position_for_line_and_colum). Figure out where the column info got > the wrong value. Use something like wcwidth() to measure the width of > non-ASCII characters and get the right width of 'ñ'. > > Unfortunately, GCC 6 seems to be broken for the above testcase > (https://gcc.gnu.org/PR69664). Revision 229665 seems fine. Bug 69664 is fixed now.
[Bug c/23087] Misleading warning, "... differ in signedness"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #18 from Eric Gallager --- (In reply to Bernd Schmidt from comment #15) > Joseph, based on gcc-patches discussion, should we close this as invalid, or > do you think there is a beneficial change that could be made? (In reply to Keith Thompson from comment #17) > I just took a quick look at the discussion on the gcc-patches mailing > list. > Link to the gcc-patches archives where this discussion took place?
[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073 --- Comment #4 from Thomas Koenig --- The real error is that lengths unequal to one are not C interoperable, and should be rejected. From the F2003 standard, 15.2.1: "if the type is character, inter- operability also requires that the length type parameter be omitted or be specified by an initialization expression whose value is one."
[Bug preprocessor/66505] -Wno-error=pedantic does not reverse -Werror -Wpedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66505 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53075 --- Comment #2 from Eric Gallager --- Related to bug 53075
[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073 --- Comment #5 from emsr at gcc dot gnu.org --- In a way, I *am* treating this as a char array n the C side and it would probably be most correct to have character(kind=c_char) thing(42). and get char thing[42]; honestly. Is there a way in Fortran to convert, or alias such an array to a character string? Ed This is probably WONTFIX PEBKAC.
[Bug target/84077] New: Likely wrong code with `__builtin_expect()` on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077 Bug ID: 84077 Summary: Likely wrong code with `__builtin_expect()` on i686-linux-gnu Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: floessie.mail at gmail dot com Target Milestone: --- Created attachment 43263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43263&action=edit CMake generated compile command line Hi, We're having some strange behavior with `__builtin_expect()` on i686-linux-gnu in RawTherapee, probably due to wrong code generation. The `__builtin_expect()` is used as #define LIKELY(x) __builtin_expect (!!(x), 1) in our code and employed in an `if` within an OpenMP for loop: https://github.com/Beep6581/RawTherapee/blob/f5bd232cd2a1d709a25c3b3feda88ebf86dd6092/rtengine/dcp.cc#L1077 When compiling RawTherapee on i686 with a vanilla GCC 7.3 a RAW with a supplied DCP base table will show obviously wrong colors. This is neither the case with (the Debian) GCC 6.4 on i686 nor with GCC 7.2 on x86_64, but also with GCC 7.2 on i686. We've worked around that problem by disabling the use of `__builtin_expect()` on 32 bit platforms with GCC >= 7 for now. See https://github.com/Beep6581/RawTherapee/pull/4324#issuecomment-360110007 for the original issue. Reproducing the problem requires building RawTherapee. You can find instructions for various distributions here: http://rawpedia.rawtherapee.com/Linux After cloning, please checkout the commit right before we worked around the bug: git checkout f5bd232cd2a1d709a25c3b3feda88ebf86dd6092 You can find an image to test here: http://rawtherapee.com/shared/test_images/amsterdam.pef As soon as you open it, the wrong colors will be apparent, as the DCP base table should be active, otherwise you can find it on the "Color" tab. If I forgot anything, just let me know. I can also test patches against vanilla GCC 7.3. On behalf of the RawTherapee team, Flössie
[Bug target/84077] Likely wrong code with `__builtin_expect()` on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077 --- Comment #1 from Flössie --- Created attachment 43264 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43264&action=edit Preprocessed file
[Bug middle-end/84078] New: false positive for -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
Bug ID: 84078
Summary: false positive for -Wmaybe-uninitialized
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: samuel.thiba...@ens-lyon.org
Target Milestone: ---
Created attachment 43265
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43265&action=edit
testcase
Hello,
The attached testcase compiled with -O2 -Wall produces
test.c:30:2: warning: 'c' may be used uninitialized in this function
[-Wmaybe-uninitialized]
printf("%d %d %d\n", a, b, c);
^
test.c:30:2: warning: 'b' may be used uninitialized in this function
[-Wmaybe-uninitialized]
test.c:30:2: warning: 'a' may be used uninitialized in this function
[-Wmaybe-uninitialized]
while they are only used when `err' is equal to zero, and in the only case
where that happens, they do get initialized.
This is the minimal testcase I could reduce to, it seems both the asm snippet
and testing its result does make a difference, as well as the two ifs and the
three variables.
I could verify this with gcc snapshot 20180124 (Debian buster x86_64)
Samuel
[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #15 from Jonathan Wakely --- I'd like to add a workaround so it works with older GDB versions. There's more to life than ensuring our testsuite has no FAILs :-)
[Bug fortran/83152] Possible run time error in derived type i/o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83152 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jerry DeLisle --- No further comment, not a bug as far as I can see.
[Bug c/55422] gcc does not diagnose change of linkage for a function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55422
cookevillain at yahoo dot com changed:
What|Removed |Added
Version|4.4.3 |5.4.0
--- Comment #6 from cookevillain at yahoo dot com ---
I still believe (although it has been almost six years since the original
report) that gcc's diagnostics are inconsistent in this case. Here is a
slightly different version of the input above:
static void ff(int a) {
return;
}
int f(void) {
{
int ff = 0;
{
extern void ff(int);
}
return ff;
}
ff(0);
}
gcc is silent about this file in every mode (c89, c11, etc.) although the only
difference between this code and the other example above is that ff is declared
as a function. I understand that gcc does not have to produce a diagnostic for
every undefined behavior (such as ff having both external and internal linkage
as above) but since it already diagnoses it for ordinary variables, why not
functions?
[Bug tree-optimization/84079] New: missing -Warray-bounds taking the address of a multidimensional array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84079
Bug ID: 84079
Summary: missing -Warray-bounds taking the address of a
multidimensional array element
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The -Warray-bounds checker correctly diagnoses the out-of-bounds references in
the first two functions in the test case below but misses the third, even
though the referenced (nonexistent) element is at the same offset from the end
of the array in both g() and h(). (It's valid to take address of a[2] when a
has just two elements, but it is invalid to take the address of an element of
the subarray a[2].)
$ cat t.c && gcc -O2 -S -Warray-bounds=2 t.c
int a[2][3];
int f (void)
{
return a[2][0]; // -Warray-bounds (good)
}
int* g (void)
{
return &a[3][2]; // -Warray-bounds (good)
}
int* h (void)
{
return &a[2][3]; // missing -Warray-bounds
}
t.c: In function ‘f’:
t.c:5:11: warning: array subscript 2 is above array bounds of ‘int[2][3]’
[-Warray-bounds]
return a[2][0]; // -Warray-bounds (good)
~^~~
t.c: In function ‘g’:
t.c:10:10: warning: array subscript 3 is above array bounds of ‘int[2][3]’
[-Warray-bounds]
return &a[3][2]; // -Warray-bounds (good)
^~~~
[Bug c++/83924] ICE: Error reporting routines re-entered with -Wduplicated-branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83924 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Sun Jan 28 01:28:05 2018 New Revision: 257131 URL: https://gcc.gnu.org/viewcvs?rev=257131&root=gcc&view=rev Log: 2018-01-27 Paolo Carlini PR c++/83924 * g++.dg/warn/Wduplicated-branches5.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches5.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/83924] ICE: Error reporting routines re-entered with -Wduplicated-branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83924 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #3 from Paolo Carlini --- Thanks Marek, I added the testcase.
[Bug c/55422] gcc does not diagnose change of linkage for a function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55422 --- Comment #7 from cookevillain at yahoo dot com --- (In reply to Andrew Pinski from comment #5) > The first example is invalid C90 anyways: > t4.c:10:3: error: ISO C90 forbids mixed declarations and code [-Wpedantic] I forgot to mention it in my previous comment: this remark has also been addressed byt the newer example. The only reason ff(0); was there to begin with was to avoid a warning that ff is not used (which is irrelevant to the case at hand but I wanted 'gcc is quiet' mean just that)
[Bug tree-optimization/84079] missing -Warray-bounds taking the address of a multidimensional array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84079 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Blocks||56456 Known to fail||4.1.0, 4.5.4, 4.8.3, 4.9.4, ||5.4.0, 6.3.0, 7.3.0, 8.0 --- Comment #1 from Martin Sebor --- This was never diagnosed so it's not a regression. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c++/82541] Wduplicated-branches triggers in template context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82541 Paolo Carlini changed: What|Removed |Added Target Milestone|--- |8.0
[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086 --- Comment #3 from Jerry DeLisle --- I think this bug is invalid and gfortran is correct. If you do this: &n ta(1:8)%c = 'bogus' / You get what you expect. The way you have it, you can not put 8 strings called 'bogus' into one strng element of ta. Anyine else have any thoughts on this?
[Bug c++/84080] New: the compiler crashes when compiling the following sample file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84080
Bug ID: 84080
Summary: the compiler crashes when compiling the following
sample file
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fabio at cannizzo dot net
Target Milestone: ---
The command
# g++ -c prova.cpp -o prova.o
prova.cpp:9:42: internal compiler error: Segmentation fault
template <> auto foo() { return a1; }
^
cause a g++ crash with the following input file:
// prova.cpp
enum aa {a1};
enum bb {b1};
enum cc {ca1, cb1};
template T foo();
template <> auto foo() { return a1; }
template <> auto foo() { return b1; }
Tested on Linux Arch
