[Bug c++/90736] [9 Regression] Bogus error with alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736 Jonathan Wakely changed: What|Removed |Added CC||soap at gentoo dot org --- Comment #9 from Jonathan Wakely --- *** Bug 94929 has been marked as a duplicate of this bug. ***
[Bug c++/94929] [8 Regression] GCC 8 chokes on std::max in alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- . *** This bug has been marked as a duplicate of bug 90736 ***
[Bug c++/94929] [8 Regression] GCC 8 chokes on std::max in alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929
Jonathan Wakely changed:
What|Removed |Added
Known to fail||6.4.0, 7.5.0, 8.4.0
CC||polacek at redhat dot com
Ever confirmed|0 |1
Keywords||rejects-valid
Status|RESOLVED|NEW
Known to work||10.0, 11.0, 5.5.0, 9.2.0
Last reconfirmed||2020-05-03
Resolution|DUPLICATE |---
--- Comment #2 from Jonathan Wakely ---
Hmm, although this was fixed for gcc 9.2 by the patch for PR 90736 it seems to
be a different root cause. This compiled with GCC 5 but not 6, 7 or 8:
template
constexpr const T& max(const T& a, const T& b) { return a < b ? b : a; }
struct One {};
struct Two {};
struct Foo { alignas(max(alignof(One), alignof(Two))) char value; };
This regressed with r230365, "Merge C++ delayed folding branch."
Marek, looks like backporting r272219 would fix this.
[Bug libstdc++/94933] New: std::fill_n delegates to __builtin_memset which is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94933
Bug ID: 94933
Summary: std::fill_n delegates to __builtin_memset which is not
constexpr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rhalbersma at gmail dot com
Target Milestone: ---
std::fill_n is constexpr in C++20 but when writing unsigned chars it delegates
to __builtin_memset which is not constexpr:
#include
template
struct S {
T data[N]{};
constexpr auto& clear() {
std::fill_n(std::begin(data), N, T{0});
return *this;
}
};
int main()
{
using T = S<1, unsigned char>;
constexpr auto b = T{}.clear();
static_assert(b.data[0] == 0);
}
Tested on Wandbox:
https://wandbox.org/permlink/xRU9JUQopzEzVuUg
Works correctly for Clang + libc++ >= 9.
I haven't checked whether similar bugs appear for other algorithms which can be
optimized for chars (std::equal -> memcmp etc.).
A possible fix is to use std::is_constand_evaluated() to make a
constexpr-friendly implementation at compile-time and __builtin_memset at
run-time.
[Bug tree-optimization/94934] New: Failure to inline addv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94934
Bug ID: 94934
Summary: Failure to inline addv
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x, int y)
{
return x + y;
}
With -O3 -ftrapv, LLVM outputs this :
f(int, int): # @f(int, int)
mov eax, edi
add eax, esi
jo .LBB0_1
ret
.LBB0_1:
ud2
GCC outputs this :
f(int, int):
sub rsp, 8
call __addvsi3
add rsp, 8
ret
`-ftrapv` may not be specifically intended for speed, but it seems to make
sense to inline it on targets that have direct support for the instructions it
uses.
[Bug libstdc++/94933] std::fill_n delegates to __builtin_memset which is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94933 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-03 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- (In reply to rhalbersma from comment #0) > std::fill_n is constexpr in C++20 but when writing unsigned chars it > delegates to __builtin_memset which is not constexpr: No, it fails before reaching the call to __builtin_memset, when calling this function which isn't constexpr: template inline typename __gnu_cxx::__enable_if<__is_byte<_Tp>::__value, void>::__type __fill_a1(_Tp* __first, _Tp* __last, const _Tp& __c)
[Bug middle-end/94935] New: Failure to emit call to absvsi2 for __builtin_abs with -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94935
Bug ID: 94935
Summary: Failure to emit call to absvsi2 for __builtin_abs with
-ftrapv
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
unsigned f(int x)
{
return __builtin_abs(x);
}
This should emit a call to __absvsi2, not get "inlined" into a call to
__subvsi3
[Bug libstdc++/94933] std::fill_n delegates to __builtin_memset which is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94933 --- Comment #2 from rhalbersma --- Sorry, my bad, but that particular overload of __fill_a1 calls __builtin_memset. I was under the impression that this was the reason for the missing constexpr. It would be great if simply adding _GLIBCXX20_CONSTEXPR would fix it.
[Bug libstdc++/94936] New: pmr::synchronized_pool_resource crashes without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94936
Bug ID: 94936
Summary: pmr::synchronized_pool_resource crashes without
-pthread
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
// g++ -std=c++17 segfault.cc -o segfault
int main()
{
std::pmr::synchronized_pool_resource pool;
}
This dies in the constructor:
synchronized_pool_resource::
synchronized_pool_resource(const pool_options& opts,
memory_resource* upstream)
: _M_impl(opts, upstream)
{
if (int err = __gthread_key_create(&_M_key, destroy_TPools))
__throw_system_error(err);
exclusive_lock l(_M_mx);
_M_tpools = _M_alloc_shared_tpools(l);
}
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) up
#1 0x77f5aeca in __gthread_key_create (__dtor=0x77f5aa90
, __key=0x7fffd7c0) at
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:708
#2 std::pmr::synchronized_pool_resource::synchronized_pool_resource
(this=0x7fffd780, opts=..., upstream=) at
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/memory_resource.cc:1136
__gthread_key_create doesn't check __ghtread_active_p before calling
pthread_key_create, so calls an undefined weak symbol if not linked to
libpthread.
[Bug libstdc++/94936] pmr::synchronized_pool_resource crashes without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94936 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-05-03
[Bug c++/94896] [10/11 regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896 Andreas Schwab changed: What|Removed |Added Target|sparc-*-* |sparc-*-* riscv64-*-* --- Comment #3 from Andreas Schwab --- Same on riscv64.
[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.4 |---
[Bug libstdc++/94933] std::fill_n delegates to __builtin_memset which is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94933 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:22b6b5d6cfb76deb68ca5bc0bcae8b4245df946d commit r11-30-g22b6b5d6cfb76deb68ca5bc0bcae8b4245df946d Author: Jonathan Wakely Date: Sun May 3 12:46:15 2020 +0100 libstdc++: Make byte-sized std::fill_n a constant expression (PR 94933) The overload for byte types uses memset and isn't constexpr. This adds the specifier and uses std::is_constant_evaluated() to provide a compile-time alternative. PR libstdc++/94933 * include/bits/stl_algobase.h (__fill_a1): Make overload for byte types usable in constant expressions. * testsuite/25_algorithms/fill_n/constexpr.cc: Test with bytes and non-scalars.
[Bug libstdc++/94933] std::fill_n delegates to __builtin_memset which is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94933 --- Comment #4 from Jonathan Wakely --- Fixed on master, backport for gcc-10 will have to wait until after the 10.1 release.
[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905
--- Comment #2 from Dr. Jürgen Sauermann ---
I checked different g++ versions; the problem occurs in versions 9, 10, and 11
of g++ but not in version 8.
I tried to shrink the code to the bare minimum but if I do so then the warning
is no longer emitted.
I noticed that the warning has become more verbose in g++ version 11.
Before version 11 the warning said (one example of many):
Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
if (rho[r]) { volume /= rho[r]; rho[r] = sh; volume
*= rho[r]; }
~^
In version g++ 11 it now says:
Shape.hh: In member function ‘virtual Token Bif_F12_FORMAT::eval_B(Value_P)’:
Shape.hh:133:18: error: ‘shape_Z.Shape::rho[]’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
133 | if (rho[r]) { volume /= rho[r]; rho[r] = sh; volume *=
rho[r]; }
| ~^
The in shape_Z.Shape::rho[] above is the function argument
'axis' of the function set_shape_item(axis, length) inside which the warning is
being issued.
This suggests that the warning is issued whenever the compiler is unable to
statically determine if some function argument (the vector index 'axiss' in
this case) is inside or outside the initialized region of a vector.
This seems to be overly picky; I would normally assume that the data members of
a class are always initialized. If not then the constructor and not any member
function should emit a warning.
Thanks for your attention and for gcc/g++
Jürgen Sauermann
[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93993 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- (In reply to CVS Commits from comment #4) > The master branch has been updated by David Malcolm : > > https://gcc.gnu.org/g:4ac3eb5c5f157bea22b5ae34b0df254d729dac25 > > commit r10-7028-g4ac3eb5c5f157bea22b5ae34b0df254d729dac25 > Author: David Malcolm > Date: Wed Mar 4 12:10:34 2020 -0500 > > analyzer: add regression test for fixed ICE [PR94028] > > The C++ reproducer for PR analyzer/94028 generates a similar ICE > to that of the Fortran reproducer for PR analyzer/93993 and, like > it, was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa. > > This patch adds the C++ reproducer as a regression test. > > gcc/testsuite/ChangeLog: > PR analyzer/94028 > * g++.dg/analyzer/pr94028.C: New test. FAIL: gfortran.dg/analyzer/pr93993.f90 -O (test for excess errors) Excess errors: /home/pault/gitsources/gcc/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:21:0: Warning: leak of 'tm' [CWE-401] [-Wanalyzer-malloc-leak] On current 10-branch. FC31/x86_64 Paul
[Bug tree-optimization/94930] Failure to optimize out subvsi in expansion of __builtin_memcmp with 1 as the operand with -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94930 --- Comment #1 from Marc Glisse --- AFAIK -ftrapv doesn't work very well and is kind of abandoned, in favor of -fsanitize=signed-integer-overflow (possibly with -fsanitize-undefined-trap-on-error), which does generate the code you expect.
[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #3 from Arseny Solokha ---
The best I've been able to come up with is the following, reduced from APL 1.8:
enum { MAX_RANK = 8 };
struct Shape {
Shape(int len) { rho[0] = len; }
Shape(Shape &other) {
for (int r = 0; r < MAX_RANK; ++r)
rho[r] = other.rho[r];
}
Shape insert_axis() const;
int rho[MAX_RANK];
};
int insert_axis_len;
Shape Shape::insert_axis() const {
{
Shape ret(insert_axis_len);
return ret;
}
}
% g++-10.1.0 -O2 -Wall -Werror -c fojcdnsn.cc
fojcdnsn.cc: In member function 'Shape Shape::insert_axis() const':
fojcdnsn.cc:8:27: error: ''target_mem_ref' not supported by
dump_expr' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
8 | rho[r] = other.rho[r];
|~~~^
That's with gcc-10.1.0-RC-20200430; I failed to reproduce it at all with gcc 9.
However, without preprocessed source provided by the reporter it's impossible
to tell whether that's the issue in question.
So please, provide a self-contained testcase! It's not even necessary to
minimize it, as in many cases it's easy to do with tools like C-Reduce or newly
emerged C-Vise and can later be done by developers themselves. But without the
testcase developers cannot and likely won't do anything about the issue you
have in the first place.
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Ryo Furue from comment #0) > I'm not familiar with this bug tracker. I mean to submit a request, not a > bug report. > > Sorry if I missed anything, but it seems to me that there is no (official) > way to print the list of paths which gfortran searches for include files. If > that is correct, my request would be to provide a means to print the paths. > > The `--print-search-dirs` option indicates paths only for the installation, > executables, and libraries (It seems to me). > > This discussion applies to the INCLUDE statement of the Fortran language, > not the `#include` directive of the preprocessor. > > Off-topic: I wonder if there is a discussion available online about why > /usr/include or something like that is not searched by default? Is there a > common (more or less standard) place for gfortran to search? There isn't a list of paths. With the Fortran INCLUDE statement, by default gfortran looks in the current working directory. That is it. If you have files, which are INCLUDEd, into your program is different directories, you can create a list of paths with the -I option. gfortran also searches for its own INCLUDE files and intrinsic modules in a directory created during installation of the compiler. You can find the name of that directory by using the -v option during compilation. For example, on my OS, this command % gfcx -v -o z a.f90 | & grep -- -fin yields -fintrinsic-modules-path /usr/home/kargl/work/lib/gcc/i586-unknown-freebsd13.0/10.0.0/finclude It seems to me that an option to print the INCLUDE search path is not needed. The PR can probably be closed as RESOLVED WONTFIX, but I'll someone else make that decision.
[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905 --- Comment #4 from Dr. Jürgen Sauermann --- Created attachment 48431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48431&action=edit preprocessed apl-Bif_F12_FORMAT.cc, gzip'ed preprocessed source file apl-Bif_F12_FORMAT.cc
[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905 --- Comment #5 from Dr. Jürgen Sauermann --- Hi, above is one preprocessed source file for which the warning has occurred. g++ version was 11.0.0 (latest from github). Compiled with: g++ -E -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Werror -I/usr/include -I/usr/include/postgresql -rdynamic -g -O2 -MT apl-Bif_F12_FORMAT.o -MD -MP -MF .deps/apl-Bif_F12_FORMAT.Tpo -c -o apl-Bif_F12_FORMAT.cxx Interestingly, if I compile the file apl-Bif_F12_FORMAT.cxx separately (with -Wall) then the warning does not show up. Not sure how I can create a testcase file other than preprocessing or minimizing it.
[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905 --- Comment #6 from Arseny Solokha --- Thank you. (In reply to Dr. Jürgen Sauermann from comment #5) > Not sure how I can create a testcase file other than preprocessing or > minimizing it. Of course preprocessing is what you've been asked to do. It is stressed in the bug filing instructions[1]. [1] https://gcc.gnu.org/bugs
[Bug target/94780] [8/9 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780 --- Comment #7 from Andreas Schwab --- This also crashes on riscv64: /daten/riscv64/gcc/gcc-20200502/gcc/testsuite/gcc.dg/pr94780.c: In function 'foo': /daten/riscv64/gcc/gcc-20200502/gcc/testsuite/gcc.dg/pr94780.c:8:1: internal compiler error: Segmentation fault 0x74a3af crash_signal ../../gcc/toplev.c:328 0x7ea370 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3293 0x7ea370 convert_nonlocal_reference_op ../../gcc/tree-nested.c:1064 0x9e3abb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.c:12003 0x4be799 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:268 0x4be9e3 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:596 0x4beb93 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:51 0x4beadb walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:605 0x4beb93 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:51 0x7e4801 walk_body ../../gcc/tree-nested.c:713 0x7e4801 walk_function ../../gcc/tree-nested.c:724 0x7e4801 walk_all_functions ../../gcc/tree-nested.c:789 0x7ecb2f lower_nested_functions(tree_node*) ../../gcc/tree-nested.c:3551 0x363201 cgraph_node::analyze() ../../gcc/cgraphunit.c:676 0x365df7 analyze_functions ../../gcc/cgraphunit.c:1227 0x366c45 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2974
[Bug c++/94937] New: ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 Bug ID: 94937 Summary: ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: foss at grueninger dot de Target Milestone: --- When compiling a mid-sized numerical code, one of the test cases failed to compile as I get an ICE. /home/kiko/dune/complete/dumux/dumux/flux/cctpfa/fickslaw.hh:188:13: internal compiler error: in cp_get_fndecl_from_callee, at cp/cvt.c:1000 188 | if constexpr (FluidSystem::isTracerFluidSystem()) | ^~ Please submit a full bug report, with preprocessed source if appropriate. > gcc-10 --version gcc-10 (SUSE Linux) 10.0.1 20200424 (experimental) [revision 3685c5adf5c0b30268cb8f95c89e4c4a3240ae6f] Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/94937] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 --- Comment #1 from Christoph --- Created attachment 48433 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48433&action=edit S file
[Bug c++/94937] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 --- Comment #2 from Christoph --- Created attachment 48434 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48434&action=edit Pre-processed source code
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 --- Comment #2 from Ryo Furue --- Thanks for the detailed description. > % gfcx -v -o z a.f90 | & grep -- -fin > > yields > > -fintrinsic-modules-path > /usr/home/kargl/work/lib/gcc/i586-unknown-freebsd13.0/10.0.0/finclude So, I wonder if it is possible and would make sense to include that information in the output of `--print-search-dirs` ?
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 --- Comment #3 from Steve Kargl --- On Mon, May 04, 2020 at 01:13:22AM +, ryofurue at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 > > --- Comment #2 from Ryo Furue --- > Thanks for the detailed description. > > > > % gfcx -v -o z a.f90 | & grep -- -fin > > > > yields > > > > -fintrinsic-modules-path > > /usr/home/kargl/work/lib/gcc/i586-unknown-freebsd13.0/10.0.0/finclude > > So, I wonder if it is possible and would make sense to include > that information in the output of `--print-search-dirs` ? > Why? --print-search-dirs does not include information about C/C++ include paths. The documentation states '-print-search-dirs' Print the name of the configured installation directory and a list of program and library directories 'gcc' searches--and don't do anything else. There is only place gfortran will search for files that it installs for intrinsic modules, openmp files, and openacc files. There are no user files here.
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 --- Comment #4 from Ryo Furue --- > There is only place gfortran will search for files that > it installs for intrinsic modules, openmp files, and > openacc files. There are no user files here. I see your point! So, should a library developer install the include files there (the directory where the intrinsic modules go)? I suppose that is the design? Thanks for your patience!
[Bug c++/94938] New: internal compiler error: in value_dependent_expression_p, at cp/pt.c:26522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
Bug ID: 94938
Summary: internal compiler error: in
value_dependent_expression_p, at cp/pt.c:26522
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
template struct S { S(); S(bool); };
struct C {
bool operator()(S);
};
S fn (bool);
template void
foo (T)
{
S s;
S x = fn(false || C()(s));
}
int main ()
{
foo(int());
}
$ ./cc1plus -quiet bz.C -std=c++98
bz.C: In instantiation of ‘void foo(T) [with T = int]’:
bz.C:18:12: required from here
bz.C:13:25: internal compiler error: in value_dependent_expression_p, at
cp/pt.c:26522
13 | S x = fn(false || C()(s));
| ~~^
0xc0d67f value_dependent_expression_p(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:26522
0xc0dcea value_dependent_expression_p(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:26627
0xc0e0be value_dependent_expression_p(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:26691
0xbbf63c uses_template_parms(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:10622
0xbeddd8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:19421
0xbef8f8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:19741
0xbeb350 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:18748
0xbdb8ea tsubst_init
/home/mpolacek/src/gcc/gcc/cp/pt.c:16255
0xbe5278 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17982
0xbe3b50 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17830
0xbe6785 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:18149
0xc0a5dc instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:25709
0xc0af95 instantiate_pending_templates(int)
/home/mpolacek/src/gcc/gcc/cp/pt.c:25825
0xa6d8e2 c_parse_final_cleanups()
/home/mpolacek/src/gcc/gcc/cp/decl2.c:4889
0xd4e6e2 c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.c:1212
[Bug c++/94938] [10/11 Regression] internal compiler error: in value_dependent_expression_p, at cp/pt.c:26522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938 Marek Polacek changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|internal compiler error: in |[10/11 Regression] internal |value_dependent_expression_ |compiler error: in |p, at cp/pt.c:26522 |value_dependent_expression_ ||p, at cp/pt.c:26522 Keywords||ice-on-valid-code Target Milestone|--- |10.0 --- Comment #1 from Marek Polacek --- Started with r10-6357-g4dd468a042e19ef0fdbb1c53ca4060d4cb4972c5
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
--- Comment #5 from Steve Kargl ---
On Mon, May 04, 2020 at 01:33:43AM +, ryofurue at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
>
> --- Comment #4 from Ryo Furue ---
> > There is only place gfortran will search for files that
> > it installs for intrinsic modules, openmp files, and
> > openacc files. There are no user files here.
>
> I see your point!
>
> So, should a library developer install the include files there (the directory
> where the intrinsic modules go)? I suppose that is the design?
>
> Thanks for your patience!
>
For my personal, projects I put libraries in ${HOME}/lib
and modules in ${HOME}/modules. I don't use include files
above the library levels. For a software developer, I
would put the libraries in ${INSTALLDIR}/lib and modules
in ${INSTALLDIR?/modules. INSTALLDIR could be /usr/local,
and, of course, you would describe this in the user and
installation manuals.
[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-05-04 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Thanks for the report, I'll take a look.
[Bug c++/94938] [10/11 Regression] internal compiler error: in value_dependent_expression_p, at cp/pt.c:26522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Last reconfirmed||2020-05-04
[Bug c++/94937] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-05-04 Status|UNCONFIRMED |WAITING --- Comment #3 from Martin Liška --- Can't reproduce, you may hit of out memory. Can you please provide full command line used?
[Bug c++/94932] [10/11 Regression] ICE in ovl_skip_hidden, at cp/tree.c:2292 since r10-8016-gbce54ed494fd0e61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94932 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-05-04 Status|UNCONFIRMED |NEW Summary|ICE in ovl_skip_hidden, at |[10/11 Regression] ICE in |cp/tree.c:2292 |ovl_skip_hidden, at ||cp/tree.c:2292 since ||r10-8016-gbce54ed494fd0e61 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to fail||10.0, 11.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r10-8016-gbce54ed494fd0e61, before that it was rejected: pr94932.cc:15:24: error: declaration of ‘std::strong_ordering Synth::operator<=>(Synth::B, Synth::B) noexcept’ has a different exception specifier 15 | std::strong_ordering operator<=>(B, B) noexcept; |^~~~ pr94932.cc:13:33: note: from previous declaration ‘std::strong_ordering Synth::operator<=>(Synth::B, Synth::B)’ 13 | friend std::strong_ordering operator<=>(B, B) = default; | ^~~~
[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-05-04
[Bug c++/94926] [9/10/11 regression] invalid use of incomplete type not recogniced for static self reference of templated struct since r9-297-g683be2f77b3ce4db
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94926 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to fail||10.0, 11.0, 9.3.0 Summary|[9 regression] invalid use |[9/10/11 regression] |of incomplete type not |invalid use of incomplete |recogniced for static self |type not recogniced for |reference of templated |static self reference of |struct |templated struct since ||r9-297-g683be2f77b3ce4db Keywords||rejects-valid Last reconfirmed||2020-05-04 Known to work||8.4.0
[Bug fortran/94909] Rejects valid code for recursion where there is none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94909 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Last reconfirmed||2020-05-04 --- Comment #1 from Martin Liška --- All releases I have tend to have the problem (4.8.0).
[Bug c++/94907] ICE: Segmentation fault (in check_return_expr) since r10-8016-gbce54ed494fd0e61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94907 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|ICE: Segmentation fault (in |ICE: Segmentation fault (in |check_return_expr) |check_return_expr) since ||r10-8016-gbce54ed494fd0e61 --- Comment #2 from Martin Liška --- Started with r10-8016-gbce54ed494fd0e61.
[Bug middle-end/94895] ICE in expand_block_tm, at trans-mem.c:2643
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94895 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-05-04 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org
[Bug c++/94896] [10/11 regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #4 from Richard Biener --- Marek, can you revert that change then?
[Bug c/94902] internal compiler error: output_operand: invalid use of register 'frame'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94902 Richard Biener changed: What|Removed |Added Summary|[10 Regression] internal|internal compiler error: |compiler error: |output_operand: invalid use |output_operand: invalid use |of register 'frame' |of register 'frame' | Keywords||error-recovery, ||ice-on-invalid-code --- Comment #1 from Richard Biener --- Please fill in the target architecture (powerpc?)
[Bug c/94903] [8/9 Regression] internal compiler error: in assign_temp, at function.c:982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94903 Richard Biener changed: What|Removed |Added Known to work||10.0, 4.8.1 Last reconfirmed||2020-05-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |8.5 Keywords||accepts-invalid, ||ice-on-invalid-code --- Comment #1 from Richard Biener --- Trunk was fixed: t.c: In function ‘foo’: t.c:5:4: error: impossible constraint in ‘asm’ 5 |asm volatile ( "" : "=r" ( var ) ) ; |^~~ t.c:5:4: error: non-memory output 0 must stay in memory
[Bug c++/94907] [10/11 Regression] ICE: Segmentation fault (in check_return_expr) since r10-8016-gbce54ed494fd0e61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94907 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0 Summary|ICE: Segmentation fault (in |[10/11 Regression] ICE: |check_return_expr) since|Segmentation fault (in |r10-8016-gbce54ed494fd0e61 |check_return_expr) since ||r10-8016-gbce54ed494fd0e61
[Bug tree-optimization/94908] Failure to optimally optimize certain shuffle patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-04 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Hmm, ideally it would be extract g()[1], insert at a[0]. But yes, we're not trying to split an not handled suffle into two but leave that for targets to sort out ... (x86 has code for many 3-insn shuffles for example).
[Bug fortran/94909] Rejects valid code for recursion where there is none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94909 --- Comment #2 from Richard Biener --- how's a%dot_(b) not a recursion? (not exactly understanding what that deferred thing is ...)
[Bug c/94902] internal compiler error: output_operand: invalid use of register 'frame'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94902 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #2 from Arseny Solokha --- I can reproduce it on x86_64, and it seems to be a [9/10/11 Regression].
[Bug target/94915] MAX_EXPR weirdly optimized on x86 with -mtune=core2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94915 Richard Biener changed: What|Removed |Added Target||x86_64-*-* --- Comment #1 from Richard Biener --- We now can move integer operations over to SSE which in some cases (max/min vs. cmov can be quite a bit faster). This isolated case is probably not of such kind (but how can you know w/o benchmarking ...). On AMD archs the GPR <-> xmm moves make this unprofitable but those are "free" on intel which makes costing prefer the pmaxsd variant.
[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94920 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Keywords||missed-optimization Last reconfirmed||2020-05-04 Status|UNCONFIRMED |NEW
[Bug fortran/94925] Undesired runtime warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94925
--- Comment #1 from Richard Biener ---
The code printing this diagnostic is guarded with
if (gfc_option.rtcheck & GFC_RTCHECK_ARRAY_TEMPS)
{
char * msg;
if (fsym && proc_name)
msg = xasprintf ("An array temporary was created for argument "
"'%s' of procedure '%s'", fsym->name, proc_name);
and thus
-fcheck-array-temporaries
[Bug c++/94926] [9/10/11 regression] invalid use of incomplete type not recogniced for static self reference of templated struct since r9-297-g683be2f77b3ce4db
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94926 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug tree-optimization/93674] [8/9 Regression] GCC eliminates conditions it should not, when strict-enums is on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674 --- Comment #19 from CVS Commits --- The releases/gcc-9 branch has been updated by Bin Cheng : https://gcc.gnu.org/g:28d68fde77363520d64b2a7ea480040cf7cb004d commit r9-8561-g28d68fde77363520d64b2a7ea480040cf7cb004d Author: Bin Cheng Date: Mon May 4 14:28:54 2020 +0800 Add unsigned type iv_cand for iv_use with non mode-precision type Precisely, for iv_use if it's not integer/pointer type, or non-mode precision type, add candidate for the corresponding scev in unsigned type with the same precision, rather than its original type. Backport from master. 2020-04-09 Bin Cheng PR tree-optimization/93674 gcc/ * tree-ssa-loop-ivopts.c (langhooks.h): New include. (add_iv_candidate_for_use): For iv_use of non integer or pointer type, or non-mode precision type, add candidate in unsigned type with the same precision. gcc/testsuite/ * g++.dg/pr93674.C: New test.
[Bug c++/94929] [8 Regression] GCC 8 chokes on std::max in alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.5
[Bug c++/94932] [10/11 Regression] ICE in ovl_skip_hidden, at cp/tree.c:2292 since r10-8016-gbce54ed494fd0e61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94932 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug target/94934] Failure to inline addv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94934 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Component|tree-optimization |target --- Comment #1 from Richard Biener --- It's up to targets to decide but as was said in another bug -ftrapv hasn't seen much love (and wants re-implementation).
[Bug c++/94939] New: [9.2.1] invalid code generation in ternary op with static class member (undefined behaviour nearby?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94939
Bug ID: 94939
Summary: [9.2.1] invalid code generation in ternary op with
static class member (undefined behaviour nearby?)
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobias.pankr...@ssw-trading.com
Target Milestone: ---
I've got the following classes, which are using the type_safe library
(https://github.com/foonathan/type_safe).
struct Old
{
inline constexpr Old();
constexpr Old(std::int64_t v)
: storage(v)
{}
std::int64_t storage = -1;
static const Old magic;
};
constexpr Old::Old() { storage = 0; }
constexpr Old Old::magic = Old(12);
struct OldDerived : Old
{
constexpr OldDerived(Old old)
: Old(old)
{}
constexpr OldDerived(std::int64_t v)
: Old(v)
{}
auto get() { return storage; }
static const OldDerived magic;
};
constexpr OldDerived OldDerived::magic = OldDerived(Old::magic);
struct New : public Old
{
New() = default;
};
template
struct conversions
{
using OldType = OldType_;
const OldType& toOld() const
{
return static_cast(
static_cast(type_safe::get(static_cast(*this;
}
};
template
struct one_more_type : conversions
{};
struct NewDerived
: type_safe::strong_typedef
, one_more_type
{
NewDerived() = default;
NewDerived(std::int64_t value)
: strong_typedef(New{{value}})
{}
};
As a colleague already pointed out, conversions::toOld() might have
an illegal cast in it and maybe that is all to this. What I observe is the
following code prints 'VALUE IS 0' (in production: VALUE IS ).
OldDerived
callee(bool b)
{
NewDerived a = NewDerived{11};
return b ? a.toOld() : OldDerived::magic;
}
__attribute_noinline__ void
caller_magic(bool b)
{
OldDerived value = callee(b);
std::cerr << "VALUE IS " << value.storage << std::endl;
}
void main()
{
caller_magic(true);
}
And if I do not use OldDerived::magic, the following code prints correctly
'VALUE IS 11'.
OldDerived
callee_lit(bool b)
{
NewDerived a = NewDerived{11};
return b ? a.toOld() : OldDerived(12);
}
__attribute_noinline__ void
caller_lit(bool b)
{
OldDerived value = callee_lit(b);
std::cerr << "VALUE IS " << value.storage << std::endl;
}
void main()
{
caller_lit(true);
}
Here is the code, including the parts from type_safe) inside the compiler
explorer: https://godbolt.org/z/TGB8Jg
Is it enough to fix the cast to make sure the code does what one expects?
[Bug c++/94939] [9.2.1] invalid code generation in ternary op with static class member (undefined behaviour nearby?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94939 Tobias Pankrath changed: What|Removed |Added Target||x86_64 Host||Ubuntu 19.10 URL||https://godbolt.org/z/TGB8J ||g --- Comment #1 from Tobias Pankrath --- Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --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 --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=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,hsa --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 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
[Bug middle-end/94935] Failure to emit call to absvsi2 for __builtin_abs with -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94935
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Last reconfirmed||2020-05-04
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||wrong-code
--- Comment #1 from Richard Biener ---
Confirmed. We're expanding via
rtx
expand_abs_nojump (machine_mode mode, rtx op0, rtx target,
int result_unsignedp)
{
...
/* If this machine has expensive jumps, we can do integer absolute
value of X as (((signed) x >> (W-1)) ^ x) - ((signed) x >> (W-1)),
where W is the width of MODE. */
since the machine has no absvsi2 pattern. It smells like a correctness
issue (though you don't explicitely say so?)
[Bug c++/94939] [9.2.1] invalid code generation in ternary op with static class member (undefined behaviour nearby?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94939 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-05-04 --- Comment #2 from Richard Biener --- I would guess the type_safe libraries doing for type_safe::get(static_cast(*this)) is "wrong" (whatever type_safe is guaranteeing). Please provide a complete preprocessed testcase that can be compiled.
