[Bug libstdc++/86910] std::filesystem::create_directories doesn't set error code or throw while violating postcondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86910 --- Comment #3 from Steffen Schuemann --- Sorry, g++-8 -v: Using built-in specs. COLLECT_GCC=g++-8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8-20180414-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-8 --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 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu 8-20180414-1ubuntu2) I see, that LWG defect 2935 addresses this question. But first, my understanding is a defect in WP status is still not part of the standard, so it might become part of some C++20 or some TC, but it currently doesn't seem to be part of C++17 (selected by -std=c++17). I might be wrong with that. And second, I still I don't really see how this is expected to be used by the developers usinf std::fs. Without that postcondition you have to do a check for the directory before using that it, so the "spared" call was simply moved to the user code. Not testing could lead to harder to track down bugs later on in a different domain of the software. And third, as testing for existence and type can be done with one call, I don't see the issue raised in the defect about additional system calls in the implementation on Windows and POSIX. I found this issue while implementing a closely C++17 compatible filesystem for C++11/14 level compilers on Windows and POSIX and simply ran my (still growing) test suite against GCCs std::fs where that case failed, so I thought I just report it. ;-) I didn't need any extra system calls to detect that situation in my (wip) implementation. So I just looked into https://github.com/gcc-mirror/gcc/blob/a2809afdf9560accb06cdb595ce20e32f652a75c/libstdc%2B%2B-v3/src/filesystem/std-ops.cc#L652-L665 and when the fs::file_status result of the fs::status(pp, ec) call tracking the file_type::not_found elements would have been keept, the fs::is_directory(s)-call on that last file_status would have been free of any additional system calls. Well, this might not be the place to discuss the LWG decision, it just doesn't look like a helpfull one to me, and it feels like beeing taken based on a false assumtion about the implementation, so it hurts and it converts a supposed system call actually not needed to a definitive system call on the user side. I guess I stick to the current C++17 descritpion and keep the error reporting, as it seems the way to go for me, and it's still good to know I need to take care on other implementations, but as I would use the compiler given std::fs whereever I can (I just don't allways have it), I sure would prefer it to follow the original wording. Thank you for pointing me on that LWG defect!
[Bug c++/86915] New: Segmentation fault for an array of auto in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86915 Bug ID: 86915 Summary: Segmentation fault for an array of auto in template parameter Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: v.reshetnikov at gmail dot com Target Milestone: --- /** BEGIN SOURCE **/ template struct S; /*** END SOURCE ***/ ' Segmentation fault 1 | template struct S; | ^ Tested with 9.0.0 20180809 (experimental)
[Bug libstdc++/68210] nothrow operator fails to call default new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed for gcc 9.
[Bug tree-optimization/86914] New: gcc 8.1 -O2 generates wrong code with strlen() of pointers within one-element arrays of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914
Bug ID: 86914
Summary: gcc 8.1 -O2 generates wrong code with strlen() of
pointers within one-element arrays of structures
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: even.rouault at spatialys dot com
Target Milestone: ---
The following code
{{{
#include
struct s
{
int i;
char c[1];
};
size_t foo(struct s* p)
{
return strlen(p->c+1);
}
}}}
compiled with gcc 8.1 -O2 generates the following code
{{{
:
0: 31 c0 xor%eax,%eax
2: c3 retq
}}}
returning 0
Previous gcc versions generate the "correct" code
{{{
:
0: 48 83 c7 05 add$0x5,%rdi
4: e9 00 00 00 00 jmpq 9 5: R_X86_64_PC32
strlen-0x4
}}}
According to https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html , """Although
using one-element arrays this way is discouraged, GCC handles accesses to
trailing one-element array members analogously to zero-length arrays. """
If modifying c[1] to be c[0], gcc 8.1 -O2 generates the correct code. If
changing strlen(p->c+1) to strlen(p->c), the correct code is although generated
So it looks to be a too agressive optimization.
[Bug objc/86913] New: Sending a nil message using a method signature returning a struct corrupts the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86913
Bug ID: 86913
Summary: Sending a nil message using a method signature
returning a struct corrupts the stack
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: yavor at gnu dot org
Target Milestone: ---
Created attachment 44524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44524&action=edit
Preprocessed source of the test program
Josh Freeman discovered that sending a nil message using a method signature
that returns a structure results in:
1. Garbage values in the returned structure's members (affects: x86/x86_64,
with and without optimization)
2. A corrupted stack (affects: x86 with -O1 or -O2)
After some investigation, I can confirm that this bug was fixed in April 2013
(r198140, PR target/57018). But the change was reverted in November 2013 as
part of a fix for PR target/57293 (r205498). AFAICT all compiler versions are
affected, except 4.8 (the fix was backported to the gcc-4_8-branch in May
2013).
Minimized test program based on Josh's test program for GNUstep:
...
#include
#import
int printf (const char *, ...);
struct Size { float w; float h; };
static const struct Size ZeroSize = {0.0, 0.0};
@interface NilMsgCheck : Object
+ (id) new;
- (struct Size) nmcZeroSize;
- (void) nmcSendNilMsg;
@end
@implementation NilMsgCheck
+ (id) new
{
return class_createInstance (self, 0);
}
- (struct Size) nmcZeroSize
{
return ZeroSize;
}
- (void) nmcSendNilMsg
{
struct Size size = [self nmcZeroSize];
printf ("[self nmcZeroSize] returned: w = %f; h = %f\n", size.w, size.h);
size = [nil nmcZeroSize];
printf ("[nil nmcZeroSize] returned: w = %f; h = %f\n", size.w, size.h);
}
@end
int
main (void)
{
NilMsgCheck *object = [NilMsgCheck new];
[object nmcSendNilMsg];
return 0;
}
...
On x86_64-linux-gnu, it prints:
[self nmcZeroSize] returned: w = 0.00; h = 0.00
[nil nmcZeroSize] returned: w = -nan; h = 0.00
On x86-linux-gnu (with optimization) it segfaults (or, if built with
-fstack-protector-strong it aborts with "stack smashing detected").
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/yavor/libexec/gcc/i686-pc-linux-gnu/8.2.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/yavor --disable-nls
--disable-multilib --enable-languages=c,objc
Thread model: posix
gcc version 8.2.0 (GCC)
[Bug target/86197] POWERPC: float128 parameter passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Segher Boessenkool --- Fixed everywhere.
[Bug target/86197] POWERPC: float128 parameter passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197 --- Comment #7 from Segher Boessenkool --- Author: segher Date: Fri Aug 10 20:46:04 2018 New Revision: 263479 URL: https://gcc.gnu.org/viewcvs?rev=263479&root=gcc&view=rev Log: Backport from mainline 2018-06-19 Segher Boessenkool PR target/86197 * config/rs6000/rs6000.md (rs6000_discover_homogeneous_aggregate): An ieee128 argument takes up only one (vector) register, not two (floating point) registers. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
[Bug fortran/84094] several correctness issues in gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094 Bug 84094 depends on bug 57160, which changed state. Bug 57160 Summary: short-circuit IF only with -ffrontend-optimize https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/68210] nothrow operator fails to call default new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Aug 10 20:20:27 2018 New Revision: 263478 URL: https://gcc.gnu.org/viewcvs?rev=263478&root=gcc&view=rev Log: PR libstdc++/68210 adjust operator new and delete for LWG 206 Ensure that nothrow versions of new and delete call the ordinary versions of new or delete, instead of calling malloc or free directly. These files are all compiled with -std=gnu++14 so can use noexcept and nullptr to make the code more readable. PR libstdc++/68210 * doc/xml/manual/intro.xml: Document LWG 206 change. * libsupc++/del_op.cc: Replace _GLIBCXX_USE_NOEXCEPT with noexcept. * libsupc++/del_opa.cc: Likewise. * libsupc++/del_opant.cc: Likewise. * libsupc++/del_opnt.cc: Likewise. Call operator delete(ptr) instead of free(ptr). * libsupc++/del_ops.cc: Replace _GLIBCXX_USE_NOEXCEPT with noexcept. * libsupc++/del_opsa.cc: Likewise. * libsupc++/del_opva.cc: Likewise. * libsupc++/del_opvant.cc: Likewise. * libsupc++/del_opvnt.cc: Likewise. Call operator delete[](ptr) instead of operator delete(ptr). * libsupc++/del_opvs.cc: Replace _GLIBCXX_USE_NOEXCEPT with noexcept. * libsupc++/del_opvsa.cc: Likewise. * libsupc++/new_op.cc: Use __builtin_expect in check for zero size. * libsupc++/new_opa.cc: Use nullptr instead of literal 0. * libsupc++/new_opant.cc: Likewise. Replace _GLIBCXX_USE_NOEXCEPT with noexcept. * libsupc++/new_opnt.cc: Likewise. Call operator new(sz) instead of malloc(sz). * libsupc++/new_opvant.cc: Use nullptr and noexcept. * libsupc++/new_opvnt.cc: Likewise. Call operator new[](sz) instead of operator new(sz, nothrow). * testsuite/18_support/new_nothrow.cc: New test. Added: trunk/libstdc++-v3/testsuite/18_support/new_nothrow.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/libsupc++/del_op.cc trunk/libstdc++-v3/libsupc++/del_opa.cc trunk/libstdc++-v3/libsupc++/del_opant.cc trunk/libstdc++-v3/libsupc++/del_opnt.cc trunk/libstdc++-v3/libsupc++/del_ops.cc trunk/libstdc++-v3/libsupc++/del_opsa.cc trunk/libstdc++-v3/libsupc++/del_opva.cc trunk/libstdc++-v3/libsupc++/del_opvant.cc trunk/libstdc++-v3/libsupc++/del_opvnt.cc trunk/libstdc++-v3/libsupc++/del_opvs.cc trunk/libstdc++-v3/libsupc++/del_opvsa.cc trunk/libstdc++-v3/libsupc++/new_op.cc trunk/libstdc++-v3/libsupc++/new_opa.cc trunk/libstdc++-v3/libsupc++/new_opant.cc trunk/libstdc++-v3/libsupc++/new_opnt.cc trunk/libstdc++-v3/libsupc++/new_opvant.cc trunk/libstdc++-v3/libsupc++/new_opvnt.cc
[Bug fortran/57160] short-circuit IF only with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=58224 Resolution|--- |FIXED Assignee|tkoenig at gcc dot gnu.org |janus at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #15 from janus at gcc dot gnu.org --- The issue is fixed with r263471. As a follow up, the -fcheck diagnostics should be improved (see e.g. PR 58224), so that cases like the one in comment #0 give a proper runtime error instead of a segfault.
[Bug target/86197] POWERPC: float128 parameter passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197 --- Comment #6 from Segher Boessenkool --- Author: segher Date: Fri Aug 10 20:14:11 2018 New Revision: 263477 URL: https://gcc.gnu.org/viewcvs?rev=263477&root=gcc&view=rev Log: Backport from mainline 2018-06-19 Segher Boessenkool PR target/86197 * config/rs6000/rs6000.md (rs6000_discover_homogeneous_aggregate): An ieee128 argument takes up only one (vector) register, not two (floating point) registers. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
[Bug libstdc++/68210] nothrow operator fails to call default new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210
--- Comment #5 from Jonathan Wakely ---
Or maybe:
int main ()
{
void *p = operator new (1, std::nothrow);
VERIFY (p != 0);
VERIFY (1 == new_called);
VERIFY (0 == new_handler_called);
VERIFY (!bad_alloc_thrown);
operator delete(p);
new_fail = true;
p = operator new (1, std::nothrow);
VERIFY (0 == p);
VERIFY (2 == new_called);
VERIFY (0 == new_handler_called);
VERIFY (bad_alloc_thrown);
new_fail = true;
bad_alloc_thrown = false;
std::set_new_handler (new_handler);
p = operator new (1, std::nothrow);
VERIFY (0 == p);
VERIFY (3 == new_called);
VERIFY (2 == new_handler_called);
VERIFY (!bad_alloc_thrown);
}
[Bug libstdc++/68210] nothrow operator fails to call default new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #4 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #0)
> assert (0 == p);
> assert (2 == new_handler_called);
> assert (bad_alloc_thrown);
I think this test case is wrong. The new handler is set, so we never get to:
else {
bad_alloc_thrown = true;
throw MyBadAlloc ();
}
So bad_alloc_throw is never set.
I'm using this instead, which passes with my fixed libstdc++ and with libc++:
int main ()
{
new_called = 0;
void *p = operator new (1, std::nothrow);
VERIFY (p != 0);
VERIFY (1 == new_called);
std::set_new_handler (new_handler);
new_fail = true;
try {
p = operator new (1, std::nothrow);
}
catch (...) {
VERIFY (!"nothrow operator new threw");
}
VERIFY (0 == p);
VERIFY (2 == new_handler_called);
VERIFY (!bad_alloc_thrown);
std::set_new_handler (0);
new_fail = true;
new_handler_called = 0;
try {
p = operator new (1, std::nothrow);
}
catch (...) {
VERIFY (!"nothrow operator new threw");
}
VERIFY (0 == p);
VERIFY (0 == new_handler_called);
VERIFY (bad_alloc_thrown);
}
[Bug target/86131] powerpc: gcc uses costly multiply instead of shift left
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86131 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- A multiply is cost 2 for mpccore. Expand creates a single "mulli ..,-8" for this. And no other RTL pass will break this apart again.
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #6 from Segher Boessenkool --- So, what is happening at all? What is different during/after combine, etc.?
[Bug c++/86908] static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 --- Comment #5 from Kostya Frumkin --- (In reply to Jonathan Wakely from comment #4) > (In reply to Kostya Frumkin from comment #3) > > Hi, for example msvc2013 calls base class's virtual method when msvc2015 > > calls derived class's virtual method. > > It's undefined behaviour. Anything can happen. > > > This is developer's mistake which can be predicted by compiler. Few > > developers know about this behavior. > > Using placement new to replace a polymorphic type is not a common idiom, I > don't think it's worth adding a warning about it. Just don't do it. > > > It'd be awesome to see the correct behavior or at least warning that base > > method is being used after placement new. > > GCC's behaviour is already correct. It is best way to get away with heap allocation in many cases. Let's make a warning about undefined behavior.
[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86684 --- Comment #12 from Segher Boessenkool --- So, ignoring all the configury stuff: the problem is that TARGET_VSX does not imply TARGET_FPRND. It should.
[Bug c++/86908] static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 --- Comment #4 from Jonathan Wakely --- (In reply to Kostya Frumkin from comment #3) > Hi, for example msvc2013 calls base class's virtual method when msvc2015 > calls derived class's virtual method. It's undefined behaviour. Anything can happen. > This is developer's mistake which can be predicted by compiler. Few > developers know about this behavior. Using placement new to replace a polymorphic type is not a common idiom, I don't think it's worth adding a warning about it. Just don't do it. > It'd be awesome to see the correct behavior or at least warning that base > method is being used after placement new. GCC's behaviour is already correct.
[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86684 Segher Boessenkool changed: What|Removed |Added Target|ppc64le-linux-gnu |powerpc*-*-* Host|x86_64-pc-linux-gnu | --- Comment #11 from Segher Boessenkool --- So it seems ppc64le-linux is NOT equivalent to powerpc64le-linux: it fails here, without the -mno-fprnd flag.
[Bug fortran/57160] short-circuit IF only with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 --- Comment #14 from janus at gcc dot gnu.org --- Author: janus Date: Fri Aug 10 14:08:53 2018 New Revision: 263471 URL: https://gcc.gnu.org/viewcvs?rev=263471&root=gcc&view=rev Log: 2018-08-10 Janus Weil PR fortran/57160 * invoke.texi (frontend-optimize): Mention short-circuiting. * options.c (gfc_post_options): Disable -ffrontend-optimize with -Og. * resolve.c (resolve_operator): Warn about short-circuiting only with -ffrontend-optimize. * trans-expr.c (gfc_conv_expr_op): Use short-circuiting operators only with -ffrontend-optimize. Without that flag, make sure that both operands are evaluated. 2018-08-10 Janus Weil PR fortran/57160 * gfortran.dg/actual_pointer_function_1.f90: Fix invalid test case. * gfortran.dg/inline_matmul_23.f90: Add option "-ffrontend-optimize". * gfortran.dg/short_circuiting_2.f90: New test case. * gfortran.dg/short_circuiting_3.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/short_circuiting_2.f90 trunk/gcc/testsuite/gfortran.dg/short_circuiting_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/options.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90 trunk/gcc/testsuite/gfortran.dg/inline_matmul_23.f90
[Bug target/85640] [8/9 Regression] Code size regression vs 7.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85640 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-10 CC||amonakov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Alexander Monakov --- This is interesting. First scev-cprop emits computation of final value of 'buf' before the inner loop. Then ivopts emits the same, but *after* the loop. In gcc-8, ivopts uses a slightly more efficient form though, so dom3 fails to unify the two, and we end up with redundant computations. Previously two final value computations were identical and dom3 managed to clean up. Final value replacement is unnecessary in this case, 'buf' remains used in the loop and the final value is non-constant so doesn't lead to further simplification. I believe we should try to throttle down scev-cprop (especially for -Os, but likely for -O2 as well). Emitting final value in the loop preheader instead of after exit may also be useful as it may reduce the amount of variables that live across the loop. (-fno-tree-scev-cprop leads to good code on the testcase)
[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86684 --- Comment #10 from Segher Boessenkool --- Also happens on native builds: ~/build/tot/gcc/f951 -quiet -Wall -W -O2 bounds_check_19.f90 -mabi=elfv2 -mlittle -mno-fprnd Error: unrecognizable insn: (insn 79 78 80 6 (set (reg:DI 175) (unspec:DI [ (reg:SF 176) ] UNSPEC_FCTID)) "bounds_check_19.f90":22 -1 (nil)) during RTL pass: vregs
[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86684 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW --- Comment #9 from Segher Boessenkool --- I found the problem. You need -mno-fprnd to reproduce this. Somehow you get this by default. Confirmed.
[Bug c++/86911] [9 Regression] ICE in gcc/c-family/c-indentation.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86911
--- Comment #2 from Martin Liška ---
Sounds very probable, this is what I see in GDB:
$ Breakpoint 1, get_visual_column (exploc=..., loc=2147489278,
out=0x7fffca24, first_nws=0x0) at
/home/marxin/Programming/gcc2/gcc/c-family/c-indentation.c:79
79 in /home/marxin/Programming/gcc2/gcc/c-family/c-indentation.c
(gdb) p line
$3 = {m_ptr = 0x75ebde79 "{\n while (__first != __last &&
!__pred(__first))\n\t++__first;\n return __first;\n}\n\n /// This is
an overload used by find algos for the RAI case.\n template
[Bug target/86133] powerpc (-mcpu=8548) internal compiler error for double variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86133 Segher Boessenkool changed: What|Removed |Added Target|powerpc |powerpcspe-*-* CC||segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- This does not happen on trunk, for powerpc-* (-mspe does not exist). Without -mno-spe it does not ICE, either. Changing target to powerpcspe.
[Bug c++/86911] [9 Regression] ICE in gcc/c-family/c-indentation.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86911 David Malcolm changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70693 --- Comment #1 from David Malcolm --- Possibly a dup of PR 70693
[Bug c++/86908] static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 Kostya Frumkin changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Version|unknown |9.0 Resolution|INVALID |--- --- Comment #3 from Kostya Frumkin --- (In reply to Jonathan Wakely from comment #1) > No, your program has undefined behaviour. To make it valid you either need > to use std::launder, or use the pointer that is returned by the placement > new. > > The compiler is allowed to assume that the dynamic type of &strategy does > not change (that's why you need to use std::launder). Hi, for example msvc2013 calls base class's virtual method when msvc2015 calls derived class's virtual method. This is developer's mistake which can be predicted by compiler. Few developers know about this behavior. It'd be awesome to see the correct behavior or at least warning that base method is being used after placement new.
[Bug middle-end/86912] New: Function pointer imposes an optimization barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86912
Bug ID: 86912
Summary: Function pointer imposes an optimization barrier
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following minimized example of std::variant visitation:
struct A {};
struct B : A {};
struct C : A {};
struct D : A {};
struct E : A {};
struct X : A {};
template
struct helper {
static A& call(void* value) {
return *static_cast(value);
}
};
A& get_base(int index, void* value) {
using f_ptr = A&(*)(void*);
constexpr f_ptr visitors[] = {
helper::call, helper::call, helper::call,
helper::call, helper::call, helper::call,
};
return visitors[index](value);
}
For the above code GCC generates very suboptimal assembly that fills an array
with pointers and does the jmp:
<...>
get_base(int, void*):
mov QWORD PTR [rsp-56], OFFSET FLAT:(anonymous
namespace)::helper::call(void*)
movsx rax, edi
mov rdi, rsi
mov QWORD PTR [rsp-48], OFFSET FLAT:(anonymous
namespace)::helper::call(void*)
mov QWORD PTR [rsp-40], OFFSET FLAT:(anonymous
namespace)::helper::call(void*)
mov QWORD PTR [rsp-32], OFFSET FLAT:(anonymous
namespace)::helper::call(void*)
mov QWORD PTR [rsp-24], OFFSET FLAT:(anonymous
namespace)::helper::call(void*)
mov QWORD PTR [rsp-16], OFFSET FLAT:(anonymous
namespace)::helper::call(void*)
mov rax, QWORD PTR [rsp-56+rax*8]
jmp rax
Optimal assembly should be the following:
get_base(int, void*):
mov rax, rsi
ret
If we rewrite `get_base` to avoid calls by function pointer, the assembly
becomes optimal:
A& get_base(int index, void* value) {
if (index == 0) return helper::call(value);
if (index == 1) return helper::call(value);
if (index == 2) return helper::call(value);
if (index == 3) return helper::call(value);
if (index == 4) return helper::call(value);
if (index == 5) return helper::call(value);
}
[Bug target/86896] invalid vmovdqa64 instruction for KNL emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86896
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC||hjl.tools at gmail dot com,
||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #3 from Martin Liška ---
So it's hard to isolate self-contained test-case, but we really generate:
vmovdqa64 %xmm16, %xmm4
I'm not i386 expert, but according to this:
https://hjlebbink.github.io/x86doc/html/MOVDQA,VMOVDQA32_64.html
+---++++-+
|Opcode/Instruction | Op/En | 64/32
bit Mode Support | CPUID Feature Flag |
Description |
+---++++-+
| EVEX.128.66.0F.W1 6F /r VMOVDQA64 xmm1 {k1}{z}, xmm2/m128 | FVM-RM | V/V
| AVX512VL AVX512F | Move aligned quadword integer values from
xmm2/m128 to xmm1 using writemask k1. |
+---++++-+
The instruction requires AVX512VL flags, but we don't require it:
953 (define_insn "mov_internal"
954[(set (match_operand:VMOVE 0 "nonimmediate_operand"
955 "=v,v ,v ,m")
956 (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"
957 " C,BC,vm,v"))]
958"TARGET_SSE
959 && (register_operand (operands[0], mode)
960 || register_operand (operands[1], mode))"
961 {
962switch (get_attr_type (insn))
963 {
964 case TYPE_SSELOG1:
965return standard_sse_constant_opcode (insn, operands);
966
967 case TYPE_SSEMOV:
968/* There is no evex-encoded vmov* for sizes smaller than 64-bytes
969 in avx512f, so we need to use workarounds, to access sse
registers
970 16-31, which are evex-only. In avx512vl we don't need
workarounds. */
971if (TARGET_AVX512F && < 64 && !TARGET_AVX512VL //
<-
972&& (EXT_REX_SSE_REG_P (operands[0])
973|| EXT_REX_SSE_REG_P (operands[1])))
974 {
975if (memory_operand (operands[0], mode))
976 {
977if ( == 32)
978 return "vextract64x4\t{$0x0, %g1, %0|%0,
%g1, 0x0}";
979else if ( == 16)
980 return "vextract32x4\t{$0x0, %g1, %0|%0,
%g1, 0x0}";
981else
982 gcc_unreachable ();
983 }
984else if (memory_operand (operands[1], mode))
985 {
986if ( == 32)
987 return "vbroadcast64x4\t{%1, %g0|%g0,
%1}";
988else if ( == 16)
989 return "vbroadcast32x4\t{%1, %g0|%g0,
%1}";
990else
991 gcc_unreachable ();
992 }
993else
994 /* Reg -> reg move is always aligned. Just use wider move.
*/
995 switch (get_attr_mode (insn))
996{
997case MODE_V8SF:
998case MODE_V4SF:
999 return "vmovaps\t{%g1, %g0|%g0, %g1}";
1000case MODE_V4DF:
1001case MODE_V2DF:
1002 return "vmovapd\t{%g1, %g0|%g0, %g1}";
1003case MODE_OI:
1004case MODE_TI:
1005 return "vmovdqa64\t{%g1, %g0|%g0, %g1}";
1006default:
1007 gcc_unreachable ();
1008}
Adding to CC port maintainers.
--- Comment #4 from Jan Hubicka ---
Yep, it seems that we are missing TARGET_AVX512VL check here. I am also not
very familiar with avx512 ISA extension. Hj, would it be possible for you to
check if we have more missing tests here?
[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86684 --- Comment #8 from Martin Liška --- (In reply to Segher Boessenkool from comment #7) > Something wrong with that tarball then, maybe? Please try trunk. I see it day by day on my periodic tester machine that pulls GCC tip.
[Bug c++/86911] New: [9 Regression] ICE in gcc/c-family/c-indentation.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86911 Bug ID: 86911 Summary: [9 Regression] ICE in gcc/c-family/c-indentation.c:403 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Target Milestone: --- It's a recent regression that I see on Inkscape: $ abuild@marxinbox:~/rpmbuild/BUILD/inkscape-0.92.3/build/src> cd /home/abuild/rpmbuild/BUILD/inkscape-0.92.3/build/src && /usr/bin/c++ -DHAVE_CAIRO_PDF=1 -DHAVE_CONFIG_H -DHAVE_POTRACE -DHAVE_TR1_UNORDERED_SET -DORBIT2=1 -DWITH_CSSBLEND -DWITH_CSSCOMPOSITE -DWITH_MESH -DWITH_SVG2 -D_FORTIFY_SOURCE=2 -Dinkscape_base_EXPORTS -I/home/abuild/rpmbuild/BUILD/inkscape-0.92.3/build/src -I/home/abuild/rpmbuild/BUILD/inkscape-0.92.3/src -I/home/abuild/rpmbuild/BUILD/inkscape-0.92.3 -I/home/abuild/rpmbuild/BUILD/inkscape-0.92.3/build/include -isystem /usr/include/pango-1.0 -isystem /usr/include/cairo -isystem /usr/include/pixman-1 -isystem /usr/include/libdrm -isystem /usr/include/libpng16 -isystem /usr/include/harfbuzz -isystem /usr/include/fribidi -isystem /usr/include/freetype2 -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/include/gc -isystem /usr/include/poppler -isystem /usr/include/libwpg-0.3 -isystem /usr/include/librevenge-0.0 -isystem /usr/include/libvisio-0.1 -isystem /usr/include/libcdr-0.1 -isystem /usr/include/gtkmm-2.4 -isystem /usr/lib64/gtkmm-2.4/include -isystem /usr/include/atkmm-1.6 -isystem /usr/include/gtk-unix-print-2.0 -isystem /usr/include/gtk-2.0 -isystem /usr/include/gdkmm-2.4 -isystem /usr/lib64/gdkmm-2.4/include -isystem /usr/include/giomm-2.4 -isystem /usr/lib64/giomm-2.4/include -isystem /usr/include/pangomm-1.4 -isystem /usr/lib64/pangomm-1.4/include -isystem /usr/include/glibmm-2.4 -isystem /usr/lib64/glibmm-2.4/include -isystem /usr/include/cairomm-1.0 -isystem /usr/lib64/cairomm-1.0/include -isystem /usr/include/sigc++-2.0 -isystem /usr/lib64/sigc++-2.0/include -isystem /usr/lib64/gtk-2.0/include -isystem /usr/include/atk-1.0 -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/gtkspell-2.0 -isystem /usr/include/libxml2 -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -Wall -fasynchronous-unwind-tables -fmessage-length=0 -fopenmp -fstack-clash-protection -fstack-protector-strong -funwind-tables -g -grecord-gcc-switches -pthread -O2 -g -DNDEBUG -fPIC -pthread -UWITH_LPETOOL -ULPE_ENABLE_TEST_EFFECTS -pthread -fPIC -o CMakeFiles/inkscape_base.dir/ui/view/view.cpp.o -c /tmp/ice.ii abuild@marxinbox:~/rpmbuild/BUILD/inkscape-0.92.3/build/src> cd /home/abuild/rpmbuild/BUILD/inkscape-0.92.3/build/src && /usr/bin/c++ -DHAVE_CAIRO_PDF=1 -DHAVE_CONFIG_H -DHAVE_POTRACE -DHAVE_TR1_UNORDERED_SET -DORBIT2=1 -DWITH_CSSBLEND -DWITH_CSSCOMPOSITE -DWITH_MESH -DWITH_SVG2 -D_FORTIFY_SOURCE=2 -Dinkscape_base_EXPORTS -I/home/abuild/rpmbuild/BUILD/inkscape-0.92.3/build/src -I/home/abuild/rpmbuild/BUILD/inkscape-0.92.3/src -I/home/abuild/rpmbuild/BUILD/inkscape-0.92.3 -I/home/abuild/rpmbuild/BUILD/inkscape-0.92.3/build/include -isystem /usr/include/pango-1.0 -isystem /usr/include/cairo -isystem /usr/include/pixman-1 -isystem /usr/include/libdrm -isystem /usr/include/libpng16 -isystem /usr/include/harfbuzz -isystem /usr/include/fribidi -isystem /usr/include/freetype2 -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/include/gc -isystem /usr/include/poppler -isystem /usr/include/libwpg-0.3 -isystem /usr/include/librevenge-0.0 -isystem /usr/include/libvisio-0.1 -isystem /usr/include/libcdr-0.1 -isystem /usr/include/gtkmm-2.4 -isystem /usr/lib64/gtkmm-2.4/include -isystem /usr/include/atkmm-1.6 -isystem /usr/include/gtk-unix-print-2.0 -isystem /usr/include/gtk-2.0 -isystem /usr/include/gdkmm-2.4 -isystem /usr/lib64/gdkmm-2.4/include -isystem /usr/include/giomm-2.4 -isystem /usr/lib64/giomm-2.4/include -isystem /usr/include/pangomm-1.4 -isystem /usr/lib64/pangomm-1.4/include -isystem /usr/include/glibmm-2.4 -isystem /usr/lib64/glibmm-2.4/include -isystem /usr/include/cairomm-1.0 -isystem /usr/lib64/cairomm-1.0/include -isystem /usr/include/sigc++-2.0 -isystem /usr/lib64/sigc++-2.0/include -isystem /usr/lib64/gtk-2.0/include -isystem /usr/include/atk-1.0 -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/gtkspell-2.0 -isystem /usr/include/libxml2 -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -Wall -fasynchronous-unwind-tables -fmessage-length=0 -fopenmp -fstack-clash-protection -fstack-protector-strong -funwind-tables -g -grecord-gcc-switches -pthread -O2 -g -DNDEBUG -fPIC -pthread -UWITH_LPETOOL -ULPE_ENABLE_TEST_EFFECTS -pthread -fPIC -o CMakeFiles/inkscape_base.dir/ui/view/view.cpp.o -c /home/abuild/rpmbuild/BUILD/inkscape-0.92.3/src/ui/view/view.cpp In file included from /usr/include/boost
[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86684 --- Comment #7 from Segher Boessenkool --- Something wrong with that tarball then, maybe? Please try trunk.
[Bug c++/86728] [7/8/9 Regression] unexpected error: conversion from ', ...)>' to non-scalar type 'std::function' requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86728 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/86910] std::filesystem::create_directories doesn't set error code or throw while violating postcondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86910 --- Comment #2 from Jonathan Wakely --- (In reply to Steffen Schuemann from comment #0) > std::filesystem::create_directories should create all directories that don't > exists in the given path. It is not an error if some of the directories > exist. But they must be directories to fulfil the postcondition. > > The current implementation doens't signal an error if it didn't create the > directory because a file existed with the same name, so the given > postcondition is_directory(p) is violated but no error occurs. That is the correct behaviour: https://cplusplus.github.io/LWG/lwg-defects.html#2935 I don't think this is a bug.
[Bug libstdc++/86910] std::filesystem::create_directories doesn't set error code or throw while violating postcondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86910 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-10 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Please provide the output of 'gcc -v' as requested by https://gcc.gnu.org/bugs/
[Bug libstdc++/86910] New: std::filesystem::create_directories doesn't set error code or throw while violating postcondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86910
Bug ID: 86910
Summary: std::filesystem::create_directories doesn't set error
code or throw while violating postcondition.
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ssh at pobox dot com
Target Milestone: ---
std::filesystem::create_directories should create all directories that don't
exists in the given path. It is not an error if some of the directories exist.
But they must be directories to fulfil the postcondition.
The current implementation doens't signal an error if it didn't create the
directory because a file existed with the same name, so the given postcondition
is_directory(p) is violated but no error occurs.
//create_directories.cpp
#include
#include
#include
#include
namespace fs = std::filesystem;
int main()
{
fs::path p("testxyz");
if(!fs::exists(p)) {
std::ofstream file(p);
file.close();
}
std::error_code ec;
if(fs::create_directories(p, ec))
std::cout << "created" << std::endl;
else
std::cout << "didn't create" << std::endl;
if(!fs::is_directory(p))
std::cerr << "postcondition failed!" << std::endl;
std::cerr << "error code " << (ec?"set":"not set") << std::endl;
fs::remove(p);
}
Compiled on Ubuntu 18.04 with
g++-8 -std=c++17 -o create_dirs create_directories.cpp -lstdc++fs
The expected output would be:
didn't create
postcondition failed!
error code set
but current code gives:
didn't create
postcondition failed!
error code not set
The interface without ec should throw, but doesn't.
[Bug middle-end/86909] Missing common subexpression elimination for types other than int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86909
--- Comment #1 from Antony Polukhin ---
Another std::variant related example where GCC fails to eliminate
subexpressions and generates 6 times bigger assembly:
using size_t = unsigned long long;
struct A {} a;
static const size_t variant_npos = -1;
struct variant {
using __index_type = unsigned char; // O_O !!
__index_type _M_index;
size_t index() const noexcept {
return (_M_index == __index_type(variant_npos) ? variant_npos :
_M_index);
}
};
template
static A* get_if(variant* __ptr) noexcept {
return (__ptr->index() == _Np ? &a : nullptr);
}
A* foo(int i, variant& in) {
if (i==0) return get_if<0>(&in);
if (i==1) return get_if<1>(&in);
if (i==2) return get_if<2>(&in);
if (i==3) return get_if<3>(&in);
if (i==4) return get_if<4>(&in);
if (i==5) return get_if<5>(&in);
if (i==6) return get_if<6>(&in);
return get_if<7>(&in);
}
[Bug middle-end/86909] New: Missing common subexpression elimination for types other than int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86909
Bug ID: 86909
Summary: Missing common subexpression elimination for types
other than int
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following minimized example of the std::variant visitation:
using size_t = unsigned long long;
struct A {};
static const size_t variant_npos = -1;
struct variant {
A a;
using __index_type = unsigned char; //
__index_type _M_index;
size_t index() const noexcept {
return (_M_index == __index_type(variant_npos) ? variant_npos :
_M_index);
}
};
template
static A* get_if(variant* __ptr) noexcept {
return (__ptr->index() == _Np ? &__ptr->a : nullptr);
}
A* foo(variant& in) {
int i = in.index();
if (i==0) return get_if<0>(&in);
if (i==1) return get_if<1>(&in);
if (i==2) return get_if<2>(&in);
if (i==3) return get_if<3>(&in);
if (i==4) return get_if<4>(&in);
if (i==5) return get_if<5>(&in);
if (i==6) return get_if<6>(&in);
return get_if<7>(&in);
}
GCC generates assembly with multiple comparisons:
foo(variant&):
<...>
cmp ecx, 1
je .L4
cmp ecx, 2
je .L4
cmp ecx, 3
je .L4
cmp ecx, 4
je .L4
cmp ecx, 5
je .L4
cmp ecx, 6
je .L4
cmp dl, 7
je .L4
Clang eliminates the subexpressions:
foo(variant&):# @foo(variant&)
movzx ecx, byte ptr [rdi + 1]
cmp cl, -1
mov edx, -1
cmovne edx, ecx
cmp edx, 7
jb .LBB0_2
mov dl, 7
.LBB0_2:
xor eax, eax
cmp cl, dl
cmove rax, rdi
ret
Note that if we change `__index_type` to `int` then GCC generates great
assembly:
foo(variant&):
mov edx, DWORD PTR [rdi+4]
xor eax, eax
cmp edx, -1
je .L1
cmp edx, 7
cmovbe rax, rdi
.L1:
ret
[Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843 --- Comment #2 from Jonathan Wakely --- Hmm, many of the checks in algorithms rely on the fact that the iterators are Debug Mode iterators (e.g. to check that the end iterator is reachable from the begin one, or that the iterators are not singular). That means the checks are not possible without using the Debug Mode containers, which means ABI changes. These don't depend on debug mode iterators: // Verify that [_First, _Last) forms a non-empty iterator range. #define __glibcxx_check_non_empty_range(_First,_Last) \ // Verify that the subscript _N is less than the container's size. #define __glibcxx_check_subscript(_N) \ // Verify that the bucket _N is less than the container's buckets count. #define __glibcxx_check_bucket_index(_N)\ _GLIBCXX_DEBUG_VERIFY(_N < this->bucket_count(),\ // Verify that the container is nonempty #define __glibcxx_check_nonempty() \ _GLIBCXX_DEBUG_VERIFY(! this->empty(), \ // Verify that load factor is positive #define __glibcxx_check_max_load_factor(_F) \ _GLIBCXX_DEBUG_VERIFY(_F > 0.0f,\ #define __glibcxx_check_equal_allocs(_This, _Other) \ _GLIBCXX_DEBUG_VERIFY(_This.get_allocator() == _Other.get_allocator(), \ // Verify that a predicate is irreflexive #define __glibcxx_check_irreflexive(_First,_Last) \ _GLIBCXX_DEBUG_VERIFY(_First == _Last || !(*_First < *_First),\ It looks like the is_sorted and is_partitioned and is_heap checks could be enabled too (and they're definitely not OK for _GLIBCXX_ASSERTIONS because they change the algorithmic complexity).
[Bug other/86904] Column numbers ignore tab characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 --- Comment #2 from David Malcolm --- (In reply to richard.earnshaw from comment #1) > On 09/08/18 21:08, dmalcolm at gcc dot gnu.org wrote: [...snip...] > > Maybe: > > -fdiagnostics-x-coord=bytes : count of bytes > > -fdiagnostics-x-coord=characters : count of characters (not special-casing > > tab) > > -fdiagnostics-x-coord=columns : count of columns: as per characters, but > > with > > tabs doing tabstops > > how about -fdiagnostics-x-coord=visual-[n] > > Where n is the size of a hard tab? Some folks change the tab stop to 4, > for example. Or maybe ...coord=tab[-n], where -n defaults to "-8". The C family of frontends already has: -ftabstop=Distance between tab stops for column reporting. which IIRC is currently only used by -Wmisleading-indentation. I guess it could be moved to common.opt.
[Bug c++/86908] static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 --- Comment #2 from Jonathan Wakely --- This makes the program correct: strategyPtr = new(&strategy) AStrategy; static_cast(std::launder(&strategy))->doIt(); strategyPtr->doIt();
[Bug c++/86908] static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- No, your program has undefined behaviour. To make it valid you either need to use std::launder, or use the pointer that is returned by the placement new. The compiler is allowed to assume that the dynamic type of &strategy does not change (that's why you need to use std::launder).
[Bug target/82418] Division on a constant is suboptimal because of not using imul instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418 Alexander Monakov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Alexander Monakov --- Fixed for gcc-9, thanks for the report.
[Bug target/82418] Division on a constant is suboptimal because of not using imul instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418 --- Comment #8 from Alexander Monakov --- Author: amonakov Date: Fri Aug 10 10:13:37 2018 New Revision: 263467 URL: https://gcc.gnu.org/viewcvs?rev=263467&root=gcc&view=rev Log: i386: do not use SImode mul-highpart on 64-bit (PR 82418) PR target/82418 * config/i386/i386.md (mul3_highpart): Use DWIH mode iterator instead of SWI48. testsuite/ * gcc.target/i386/pr82418.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr82418.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/86900] [8/9 Regression] -gdwarf-5 -O2 -ffunction-sections = assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86900
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
CC||hubicka at gcc dot gnu.org
Target Milestone|--- |8.3
Summary|-gdwarf-5 -O2 |[8/9 Regression] -gdwarf-5
|-ffunction-sections = |-O2 -ffunction-sections =
|assembler error |assembler error
--- Comment #3 from Martin Liška ---
Minimal test-case:
$ cat pr86900.cpp
class a;
class b {
public:
b(a);
};
class a {
public:
a(int);
~a();
};
void c(int f) {
a d(0);
b e(d);
}
Started with r249885.
[Bug c++/86908] New: static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908
Bug ID: 86908
Summary: static_cast(&derivedClassO
bject)->virtualMehod() calls base version of
virtualMethod()
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fro0m.spam at gmail dot com
Target Milestone: ---
#include
#include
#include
#include
class BaseStrategy{
public:
virtual void doIt() {
printf("base do it\n");
};
};
class AStrategy : public BaseStrategy
{
public:
void doIt() {
printf("A do it\n");
};
};
class BStrategy : public BaseStrategy
{
public:
void doIt() {
printf("B do it\n");
};
};
int main()
{
BaseStrategy strategy;
BaseStrategy* strategyPtr = &strategy;
strategyPtr->doIt();
new(&strategy) AStrategy;
static_cast(&strategy)->doIt();
strategyPtr->doIt();
}
Output in gcc 4.9 and gcc 9.0 is
base do it
base do it
A do it
the right output must be (according to standard and behavior of MSVC 2015 and
clang 6) is
base do it
A do it
A do it
[Bug middle-end/85559] [meta-bug] Improve conditional move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85559 Bug 85559 depends on bug 83610, which changed state. Bug 83610 Summary: Come up with __builtin_expect_with_probabilty https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83610 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/83610] Come up with __builtin_expect_with_probabilty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83610 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Implemented.
Re: [Bug other/86904] New: Column numbers ignore tab characters
On 09/08/18 21:08, dmalcolm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 > > Bug ID: 86904 >Summary: Column numbers ignore tab characters >Product: gcc >Version: unknown > Status: UNCONFIRMED > Keywords: diagnostic > Severity: normal > Priority: P3 > Component: other > Assignee: unassigned at gcc dot gnu.org > Reporter: dmalcolm at gcc dot gnu.org > Target Milestone: --- > > As noted in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c21 : > > /* Both gcc and emacs number source *lines* starting at 1, but >they have differing conventions for *columns*. > >GCC uses a 1-based convention for source columns, >whereas Emacs's M-x column-number-mode uses a 0-based convention. > >For example, an error in the initial, left-hand >column of source line 3 is reported by GCC as: > > some-file.c:3:1: error: ...etc... > >On navigating to the location of that error in Emacs >(e.g. via "next-error"), >the locus is reported in the Mode Line >(assuming M-x column-number-mode) as: > > some-file.c 10% (3, 0) > >i.e. "3:1:" in GCC corresponds to "(3, 0)" in Emacs. */ > > In terms of 0 vs 1, GCC complies with the GNU standards here: > https://www.gnu.org/prep/standards/html_node/Errors.html > > However our "column numbers" are also simply a 1-based byte-count, so a tab > character is treated by us as simply an increment of 1 right now. > > (see also PR 49973, which covers the case of multibyte characters). > > It turns out that we convert tab characters to *single* space characters when > printing source code. > > This behavior has been present since Manu first implemented > -fdiagnostics-show-caret in r186305 (aka > 5a9830842f69ebb059061e26f8b0699cbd85121e, PR 24985), where it was this logic > (there in diagnostic.c's diagnostic_show_locus): > char c = *line == '\t' ? ' ' : *line; > pp_character (context->printer, c); > > (that logic is now in diagnostic-show-locus.c in layout::print_source_line) > > This is arguably a bug, but it's intimately linked to the way in which we > track > "column numbers". > > Our "column numbers" are currently simply a 1-based byte-count, I believe, so > a > tab character is treated by us as simply an increment of 1 right now. > > There are similar issues with encodings that aren't 1 byte per character (e.g. > non-ASCII unicode characters), which are being tracked in PR 49973. > > Presumably, when we print source lines containing tab characters, we should > emit a number of spaces to reach a tab stop. > > Consider a diagnostic with a multiline range covering the > following source (and beyond): > > indent: 6 (tabs: 0, spaces: 6) >indent: 7 (tabs: 0, spaces: 7) > indent: 8 (tabs: 1, spaces: 0) > indent: 9 (tabs: 1, spaces: 1) > > i.e.: > > " indent: 6 (tabs: 0, spaces: 6)\n" > " indent: 7 (tabs: 0, spaces: 7)\n" > "\tindent: 8 (tabs: 1, spaces: 0)\n" > "\t indent: 9 (tabs: 1, spaces: 1)\n" > > Currently diagnostic_show_locus prints: > >indent: 6 (tabs: 0, spaces: 6) >~~ > indent: 7 (tabs: 0, spaces: 7) > ~~ > indent: 8 (tabs: 1, spaces: 0) > ~~ >indent: 9 (tabs: 1, spaces: 1) >~~ > > i.e: > " indent: 6 (tabs: 0, spaces: 6)\n" > " ~~\n" > "indent: 7 (tabs: 0, spaces: 7)\n" > "~~\n" > " indent: 8 (tabs: 1, spaces: 0)\n" > " ~~\n" > " indent: 9 (tabs: 1, spaces: 1)\n" > " ~~\n" > > which misrepresents the indentation of the user's code. > > It should respect tabstops, and print: > >indent: 6 (tabs: 0, spaces: 6) >~~ > indent: 7 (tabs: 0, spaces: 7) > ~~ > indent: 8 (tabs: 1, spaces: 0) > ~~ > indent: 9 (tabs: 1, spaces: 1) > ~~ > > i.e.: > > " indent: 6 (tabs: 0, spaces: 6)\n" > " ~~\n" > "indent: 7 (tabs: 0, spaces: 7)\n" > "~~\n" > " indent: 8 (tabs: 1, spaces: 0)\n" > " ~~\n" > " indent: 9 (tabs: 1, spaces: 1)\n" > " ~~\n" > > We should also handle erroneous leading spaces before a tab, so that e.g. > > " \tfoo" > > should be printed as if it were: > > "\tfoo" > > (given that that's what the user's editor is probably printing it as). > > Similarly, we should presumably print "8" for the column number for the '
[Bug other/86904] Column numbers ignore tab characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 --- Comment #1 from richard.earnshaw at arm dot com --- On 09/08/18 21:08, dmalcolm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 > > Bug ID: 86904 >Summary: Column numbers ignore tab characters >Product: gcc >Version: unknown > Status: UNCONFIRMED > Keywords: diagnostic > Severity: normal > Priority: P3 > Component: other > Assignee: unassigned at gcc dot gnu.org > Reporter: dmalcolm at gcc dot gnu.org > Target Milestone: --- > > As noted in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c21 : > > /* Both gcc and emacs number source *lines* starting at 1, but >they have differing conventions for *columns*. > >GCC uses a 1-based convention for source columns, >whereas Emacs's M-x column-number-mode uses a 0-based convention. > >For example, an error in the initial, left-hand >column of source line 3 is reported by GCC as: > > some-file.c:3:1: error: ...etc... > >On navigating to the location of that error in Emacs >(e.g. via "next-error"), >the locus is reported in the Mode Line >(assuming M-x column-number-mode) as: > > some-file.c 10% (3, 0) > >i.e. "3:1:" in GCC corresponds to "(3, 0)" in Emacs. */ > > In terms of 0 vs 1, GCC complies with the GNU standards here: > https://www.gnu.org/prep/standards/html_node/Errors.html > > However our "column numbers" are also simply a 1-based byte-count, so a tab > character is treated by us as simply an increment of 1 right now. > > (see also PR 49973, which covers the case of multibyte characters). > > It turns out that we convert tab characters to *single* space characters when > printing source code. > > This behavior has been present since Manu first implemented > -fdiagnostics-show-caret in r186305 (aka > 5a9830842f69ebb059061e26f8b0699cbd85121e, PR 24985), where it was this logic > (there in diagnostic.c's diagnostic_show_locus): > char c = *line == '\t' ? ' ' : *line; > pp_character (context->printer, c); > > (that logic is now in diagnostic-show-locus.c in layout::print_source_line) > > This is arguably a bug, but it's intimately linked to the way in which we > track > "column numbers". > > Our "column numbers" are currently simply a 1-based byte-count, I believe, so > a > tab character is treated by us as simply an increment of 1 right now. > > There are similar issues with encodings that aren't 1 byte per character (e.g. > non-ASCII unicode characters), which are being tracked in PR 49973. > > Presumably, when we print source lines containing tab characters, we should > emit a number of spaces to reach a tab stop. > > Consider a diagnostic with a multiline range covering the > following source (and beyond): > > indent: 6 (tabs: 0, spaces: 6) >indent: 7 (tabs: 0, spaces: 7) > indent: 8 (tabs: 1, spaces: 0) > indent: 9 (tabs: 1, spaces: 1) > > i.e.: > > " indent: 6 (tabs: 0, spaces: 6)\n" > " indent: 7 (tabs: 0, spaces: 7)\n" > "\tindent: 8 (tabs: 1, spaces: 0)\n" > "\t indent: 9 (tabs: 1, spaces: 1)\n" > > Currently diagnostic_show_locus prints: > >indent: 6 (tabs: 0, spaces: 6) >~~ > indent: 7 (tabs: 0, spaces: 7) > ~~ > indent: 8 (tabs: 1, spaces: 0) > ~~ >indent: 9 (tabs: 1, spaces: 1) >~~ > > i.e: > " indent: 6 (tabs: 0, spaces: 6)\n" > " ~~\n" > "indent: 7 (tabs: 0, spaces: 7)\n" > "~~\n" > " indent: 8 (tabs: 1, spaces: 0)\n" > " ~~\n" > " indent: 9 (tabs: 1, spaces: 1)\n" > " ~~\n" > > which misrepresents the indentation of the user's code. > > It should respect tabstops, and print: > >indent: 6 (tabs: 0, spaces: 6) >~~ > indent: 7 (tabs: 0, spaces: 7) > ~~ > indent: 8 (tabs: 1, spaces: 0) > ~~ > indent: 9 (tabs: 1, spaces: 1) > ~~ > > i.e.: > > " indent: 6 (tabs: 0, spaces: 6)\n" > " ~~\n" > "indent: 7 (tabs: 0, spaces: 7)\n" > "~~\n" > " indent: 8 (tabs: 1, spaces: 0)\n" > " ~~\n" > " indent: 9 (tabs: 1, spaces: 1)\n" > " ~~\n" > > We should also handle erroneous leading spaces before a tab, so that e.g. > > " \tfoo" > > should be printed as if it were: > > "\tfoo" > > (given that that's what the user's editor
[Bug target/83610] Come up with __builtin_expect_with_probabilty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83610 --- Comment #7 from Martin Liška --- Author: marxin Date: Fri Aug 10 09:43:06 2018 New Revision: 263466 URL: https://gcc.gnu.org/viewcvs?rev=263466&root=gcc&view=rev Log: Introduce __builtin_expect_with_probability (PR target/83610). 2018-08-10 Martin Liska PR target/83610 * builtin-types.def (BT_FN_LONG_LONG_LONG_DOUBLE): Add new function type. * builtins.c (expand_builtin_expect_with_probability): New function. (expand_builtin_expect_with_probability): New function. (build_builtin_expect_predicate): Add new argumnet probability for BUILT_IN_EXPECT_WITH_PROBABILITY. (fold_builtin_expect): (fold_builtin_2): (fold_builtin_3): * builtins.def (BUILT_IN_EXPECT_WITH_PROBABILITY): * builtins.h (fold_builtin_expect): Set new argument. * doc/extend.texi: Document __builtin_expect_with_probability. * doc/invoke.texi: Likewise. * gimple-fold.c (gimple_fold_call): Pass new argument. * ipa-fnsummary.c (find_foldable_builtin_expect): Handle also BUILT_IN_EXPECT_WITH_PROBABILITY. * predict.c (get_predictor_value): New function. (expr_expected_value): Add new argument probability. Assume that predictor and probability are always non-null. (expr_expected_value_1): Likewise. For __builtin_expect and __builtin_expect_with_probability set probability. Handle combination in binary expressions. (tree_predict_by_opcode): Simplify code by simply calling get_predictor_value. (pass_strip_predict_hints::execute): Add handling of BUILT_IN_EXPECT_WITH_PROBABILITY. * predict.def (PRED_BUILTIN_EXPECT_WITH_PROBABILITY): Add new predictor. * tree.h (DECL_BUILT_IN_P): New function. 2018-08-10 Martin Liska PR target/83610 * gcc.dg/predict-17.c: New test. * gcc.dg/predict-18.c: New test. * gcc.dg/predict-19.c: New test. Added: trunk/gcc/testsuite/gcc.dg/predict-17.c trunk/gcc/testsuite/gcc.dg/predict-18.c trunk/gcc/testsuite/gcc.dg/predict-19.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtin-types.def trunk/gcc/builtins.c trunk/gcc/builtins.def trunk/gcc/builtins.h trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/gimple-fold.c trunk/gcc/ipa-fnsummary.c trunk/gcc/predict.c trunk/gcc/predict.def trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h
[Bug c++/86900] -gdwarf-5 -O2 -ffunction-sections = assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86900 --- Comment #2 from Jan Kratochvil --- Created attachment 44523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44523&action=edit 1.cc.xz Sorry, the 1.cc file somehow did not get attached.
[Bug tree-optimization/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Liška --- Fixed on trunk.
[Bug tree-optimization/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799 --- Comment #9 from Martin Liška --- Author: marxin Date: Fri Aug 10 09:31:51 2018 New Revision: 263465 URL: https://gcc.gnu.org/viewcvs?rev=263465&root=gcc&view=rev Log: Strip only selected predictors after early tree passes (PR tree-optimization/85799). 2018-08-10 Martin Liska PR tree-optimization/85799 * passes.def: Add argument for pass_strip_predict_hints. * predict.c (class pass_strip_predict_hints): Add new argument early_p. (strip_predictor_early): New function. (pass_strip_predict_hints::execute): Call the function to strip predictors. (strip_predict_hints): New function. * predict.def: Fix comment. 2018-08-10 Martin Liska PR tree-optimization/85799 * gcc.dg/pr85799.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr85799.c Modified: trunk/gcc/ChangeLog trunk/gcc/passes.def trunk/gcc/predict.c trunk/gcc/predict.def trunk/gcc/testsuite/ChangeLog
[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86684 --- Comment #6 from Martin Liška --- (In reply to Segher Boessenkool from comment #5) > I cannot reproduce this, not on gcc14 either. I notice you use > ppc64le-linux, > while the canonical name is powerpc64le-linux; maybe that matters? No it does not matter.
[Bug c++/86900] -gdwarf-5 -O2 -ffunction-sections = assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86900 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-10 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please provide a test-case?
[Bug c++/86905] g++ ICE on valid code: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86905 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-10 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it's old, one needs enabled checking. Started with GCC 5.1.0.
