[Bug target/82927] [8 Regression] ICE in verify_flow_info building SH glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82927 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug target/82927] [8 Regression] ICE in verify_flow_info building SH glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82927 --- Comment #2 from Martin Liška --- Author: marxin Date: Wed Nov 15 07:11:59 2017 New Revision: 254755 URL: https://gcc.gnu.org/viewcvs?rev=254755&root=gcc&view=rev Log: Use proper probability (PR target/82927) 2017-11-15 Martin Liska PR target/82927 * config/sh/sh-mem.cc: Use proper probability for REG_BR_PROB_NOTE. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-mem.cc
[Bug debug/82155] [7 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:21655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82155 Martin Liška changed: What|Removed |Added CC||plinich at cse dot unsw.edu.au --- Comment #7 from Martin Liška --- *** Bug 82998 has been marked as a duplicate of this bug. ***
[Bug debug/82998] Internal compiler error in force_type_die in dwarf2out.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82998 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 82155 ***
[Bug fortran/82969] ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82969 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-15 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with GCC 4.7.0.
[Bug target/82961] ICE in dwarf2out.c: deferred_asm_name != NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82961 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-11-15 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Can you please provide pre-processed source file?
[Bug fortran/82996] ICE and segfault with derived type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-15 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Confirmed.
[Bug ipa/83001] [8 Regression] ICE in edge_badness, at ipa-inline.c:1025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83001 Martin Liška changed: What|Removed |Added Target Milestone|--- |8.0
[Bug ipa/83001] New: [8 Regression] ICE in edge_badness, at ipa-inline.c:1025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83001 Bug ID: 83001 Summary: [8 Regression] ICE in edge_badness, at ipa-inline.c:1025 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at ucw dot cz, marxin at gcc dot gnu.org Target Milestone: --- Starting from r254696 we ICE on: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-2.C -c -Og -fno-guess-branch-probability during IPA pass: inline /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-2.C:49:1: internal compiler error: in edge_badness, at ipa-inline.c:1025 } ^ 0x1d4355a edge_badness ../../gcc/ipa-inline.c:1024 0x1d4459f update_edge_key ../../gcc/ipa-inline.c:1224 0x1d44a66 update_caller_keys ../../gcc/ipa-inline.c:1346 0x1d449cb update_caller_keys ../../gcc/ipa-inline.c:1335 0x1d46adc inline_small_functions ../../gcc/ipa-inline.c:2051 0x1d480fa ipa_inline ../../gcc/ipa-inline.c:2442 0x1d48dfc execute ../../gcc/ipa-inline.c:2849
[Bug c++/83000] New: Constraints for union-templates do not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83000
Bug ID: 83000
Summary: Constraints for union-templates do not work
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wilhelm.me...@hs-kl.de
Target Milestone: ---
In the following example, the requirement is not met. But the template-union
Test is instantiated:
template
requires (sizeof(T) > 1)
union Test {
};
int main(){
Test x;
}
If one changes the union into a struct, the requirement is correctly checked
and the struct-template not instantiated.
[Bug target/82990] Update the default -mzeroupper setting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82990 H.J. Lu changed: What|Removed |Added CC||ubizjak at gmail dot com Target Milestone|--- |8.0 Summary|Add -mprefer-vzeroupper |Update the default ||-mzeroupper setting --- Comment #4 from H.J. Lu --- -mzeroupper is specified to generate vzeroupper instruction. If it isn't used, the default should depend on !TARGET_AVX512ER. Users can always use -mzeroupper or -mno-zeroupper to override it.
[Bug target/82990] Add -mprefer-vzeroupper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82990 H.J. Lu changed: What|Removed |Added Attachment #42608|0 |1 is obsolete|| --- Comment #3 from H.J. Lu --- Created attachment 42611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42611&action=edit A better patch Sebastian, please take a look.
[Bug target/82990] Add -mprefer-vzeroupper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82990 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-15 Ever confirmed|0 |1
[Bug target/82990] Add -mprefer-vzeroupper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82990 --- Comment #2 from H.J. Lu --- Created attachment 42608 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42608&action=edit A patch Sebastian, please take a look.
[Bug c/82999] New: a func has two entrys: one inlined, another is normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82999 Bug ID: 82999 Summary: a func has two entrys: one inlined, another is normal Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zuogang at huawei dot com Target Milestone: --- centos 7 kernel: 3.10.0-693.2.2.el7.x86_64 global func tcp_v4_mtu_reduced has two entrys , one is inlined when called in the same file (such as func tcp_v4_err call tcp_v4_mtu_reduced), aother is a normal entry call the .part. stub. the inlined entry of tcp_v4_mtu_reduced (part of code of func tcp_v4_err): /usr/src/debug/kernel-4.9.el7.centos/linux-4.9.54-203.el7.centos.x86_64/net/ipv4/tcp_ipv4.c:445 817663ab: 89 83 30 07 00 00 mov%eax,0x730(%rbx) /usr/src/debug/kernel-4.9.el7.centos/linux-4.9.54-203.el7.centos.x86_64/net/ipv4/tcp_ipv4.c:446 817663b1: 75 26 jne817663d9 tcp_v4_mtu_reduced(): /usr/src/debug/kernel-4.9.el7.centos/linux-4.9.54-203.el7.centos.x86_64/net/ipv4/tcp_ipv4.c:276 817663b3: 0f b6 43 12 movzbl 0x12(%rbx),%eax 817663b7: ba 80 04 00 00 mov$0x480,%edx 817663bc: 0f a3 c2bt %eax,%edx 817663bf: 0f 82 b7 fd ff ff jb 8176617c 817663c5: 48 89 dfmov%rbx,%rdi 817663c8: e8 43 e2 ff ff callq 81764610 817663cd: 48 8d 83 80 00 00 00lea0x80(%rbx),%rax 817663d4: e9 aa fd ff ff jmpq 81766183 test_and_set_bit(): /usr/src/debug/kernel-4.9.el7.centos/linux-4.9.54-203.el7.centos.x86_64/arch/x86/include/asm/bitops.h:206 817663d9: f0 0f ba ab 30 05 00lock btsl $0x5,0x530(%rbx) 817663e0: 00 05 817663e2: 0f 82 94 fd ff ff jb 8176617c the normal entry of tcp_v4_mtu_reduced: 817646c0 : tcp_v4_mtu_reduced(): /usr/src/debug/kernel-4.9.el7.centos/linux-4.9.54-203.el7.centos.x86_64/net/ipv4/tcp_ipv4.c:271 817646c0: e8 3b f6 0b 00 callq 81823d00 <__fentry__> 817646c1: R_X86_64_PC32 __fentry__-0x4 /usr/src/debug/kernel-4.9.el7.centos/linux-4.9.54-203.el7.centos.x86_64/net/ipv4/tcp_ipv4.c:276 817646c5: 0f b6 47 12 movzbl 0x12(%rdi),%eax 817646c9: ba 80 04 00 00 mov$0x480,%edx 817646ce: 0f a3 c2bt %eax,%edx 817646d1: 73 01 jae817646d4 /usr/src/debug/kernel-4.9.el7.centos/linux-4.9.54-203.el7.centos.x86_64/net/ipv4/tcp_ipv4.c:303 817646d3: c3 retq /usr/src/debug/kernel-4.9.el7.centos/linux-4.9.54-203.el7.centos.x86_64/net/ipv4/tcp_ipv4.c:271 817646d4: 55 push %rbp 817646d5: 48 89 e5mov%rsp,%rbp 817646d8: e8 33 ff ff ff callq 81764610 /usr/src/debug/kernel-4.9.el7.centos/linux-4.9.54-203.el7.centos.x86_64/net/ipv4/tcp_ipv4.c:303 817646dd: 5d pop%rbp 817646de: 66 90 xchg %ax,%ax 817646e0: c3 retq gcc generated code like this make ftrace and other kernel tools functions abnormal, when a func is called, ftrace cannot knew it, so I think when gcc want to do some works about generate stub func .part., should know the target func is global or not, if it is global, don't do like that, it will make a func has two entrys and confuse the kernel and peoples.
[Bug c/81156] GCC fails to compile a formula with tgmath.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81156 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #7 from Joseph S. Myers --- Fixed for GCC 8 (given appropriate change to the tgmath.h being used to use __builtin_tgmath).
[Bug c/81156] GCC fails to compile a formula with tgmath.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81156
--- Comment #6 from Joseph S. Myers ---
Author: jsm28
Date: Wed Nov 15 01:53:45 2017
New Revision: 254749
URL: https://gcc.gnu.org/viewcvs?rev=254749&root=gcc&view=rev
Log:
Add __builtin_tgmath for better tgmath.h implementation (bug 81156).
Various implementations of C99/C11 have the property that
their macro expansions contain many copies of the macro arguments, so
resulting in exponential blowup of the size of macro expansions where
a call to such a macro contains other such calls in the macro
arguments.
This patch adds a (C-only) language feature __builtin_tgmath designed
to avoid this problem by implementing the function
selection rules directly in the compiler. The effect is that
type-generic macros can be defined simply as
#define pow(a, b) __builtin_tgmath (powf, pow, powl, \
cpowf, cpow, cpowl, a, b)
as in the example added to the manual, with each macro argument
expanded exactly once. The details of __builtin_tgmath are as
described in the manual. This is C-only since C++ uses function
overloading and just defines to include and
.
__builtin_tgmath handles C99/C11 type-generic macros, and _FloatN,
_FloatNx and decimal floating-point types (following the proposed
resolution to the floating-point TS DR#9 that makes the rules for
finding a common type from arguments to a type-generic macro follow
the usual arithmetic conversions after adjustment of integer arguments
to _Decimal64 or double - or to _Complex double in the case of GNU
complex integer arguments).
Type-generic macros for functions from TS 18661 that round their
results to a narrower type are handled, but there are still some
unresolved questions regarding such macros so further changes in that
regard may be needed in future. The current implementation follows an
older version of the DR#13 resolution (allowing a function for a
wide-enough argument type to be selected if no exactly-matching
function is available), but with appropriate calls to __builtin_tgmath
is still fully compatible with the latest version of the resolution
(not yet in the DR log), and allowing such not-exactly-matching
argument types to be chosen in that case avoids needing another
special case to treat integers as _Float64 instead of double in
certain cases.
Regarding other possible language/library features, not currently
implemented in GCC:
* Imaginary types could be naturally supported by allowing cases where
the type-generic type is an imaginary type T and arguments or return
types may be T (as at present), or the corresponding real type to T
(as at present), or (new) the corresponding real type if T is real
or imaginary but T if T is complex. (tgmath.h would need a series
of functions such as
static inline _Imaginary double
__sin_imag (_Imaginary double __x)
{
return _Imaginary_I * sinh (__imag__ __x);
}
to be used in __builtin_tgmath calls.)
* __builtin_tgmath would use the constant rounding direction in the
presence of support for the FENV_ROUND / FENV_DEC_ROUND pragmas.
Support for those would also require a new __builtin_ to
cause a non-type-generic call to use the constant rounding
direction (it seems cleaner to add a new __builtin_ when
required than to make __builtin_tgmath handle a non-type-generic
case with only one function argument).
* TS 18661-5 __STDC_TGMATH_OPERATOR_EVALUATION__ would require new
__builtin_ that evaluates with excess range and precision
like arithmetic operators do.
* The proposed C bindings for IEEE 754-2018 augmented arithmetic
operations involve struct return types. As currently implemented
__builtin_tgmath does not handle those, but support could be added.
There are many error cases that the implementation diagnoses. I've
tried to ensure reasonable error messages for erroneous uses of
__builtin_tgmath, but the errors for erroneous uses of the resulting
type-generic macros (that is, when the non-function arguments have
inappropriate types) are more important as they are more likely to be
seen by users.
GCC's own tgmath.h, as used for some targets, is updated in this
patch. I've tested those changes minimally, via adjusting
gcc.dg/c99-tgmath-* locally to use that tgmath.h version. I've also
run the glibc testsuite (which has much more thorough tests of
correctness of tgmath.h function selection) with a glibc patch to use
__builtin_tgmath in glibc's tgmath.h.
Bootstrapped with no regressions on x86_64-pc-linux-gnu.
PR c/81156
gcc:
* doc/extend.texi (Other Builtins): Document __builtin_tgmath.
* ginclude/tgmath.h (__tg_cplx, __tg_ldbl, __tg_dbl, __tg_choose)
(__tg_choose_2, __tg_choose_3, __TGMATH_REAL_1_2)
(__TGMATH_REAL_2_3): Remove macros.
(__TGMATH_CPLX, __TGMATH_CPLX_2, __TGMATH_REAL, __TGMATH_REAL_2)
(__TGMATH_REAL_3, __TGMATH_CPLX_ONLY): Define using
__builtin_tgmath.
(frexp, ldexp, nexttoward,
[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82995 --- Comment #3 from Dominique d'Humieres --- OK! I have overlooked the line logical, intent(in), optional :: mask(:) in my_sum and it rung some bell. This PR is related to/duplicate of pr67277.
[Bug libgomp/60670] omp.h may differ between multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60670 Radford Neal changed: What|Removed |Added CC||radfordneal at gmail dot com --- Comment #17 from Radford Neal --- I'd like to add some urgency to getting this fixed. The problem with omp.h defining an incorrect omp_lock_t type shows up when gcc is installed with Homebrew (https://brew.sh) on macOS, for any modern 64-bit system, since the omp_lock_t type is set up for 32-bit builds. It also shows up with the Rtools package for installing R on Windows. It probably shows up in various other contexts too. The consequence is that OpenMP doesn't work correctly, in ways that may well be non-obvious, and very hard to diagnose for anyone who doesn't realize what is going on. One could say that these package providers ought to provide separate 32-bit and 64-bit versions of omp.h, but the fact is that they don't. And it's not really unreasonable for them to think that omp.h will correctly define the types for both 32-bit and 64-bit builds - that's the way just about every other package works. What you're doing with keeping omg_log_t "private" by defining it as a byte array with length filled in during the build is decidedly not a standard approach, and it's unsurprising that it ends up causing problems. You ought to change to a different approach. If that's not possible immediately, however, you should implement a kludge - just set @OMP_LOCK_SIZE@ to the maximum that it might be for any platform.
[Bug debug/82998] New: Internal compiler error in force_type_die in dwarf2out.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82998
Bug ID: 82998
Summary: Internal compiler error in force_type_die in
dwarf2out.c
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: plinich at cse dot unsw.edu.au
Target Milestone: ---
Created attachment 42607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42607&action=edit
Preprocessed source code (from ceph-10.2.9 source) which triggers the internal
compiler error
[root@alarm src]# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-7.2.0/libexec/gcc/armv7l-unknown-linux-gnueabihf/7.2.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-7.2.0/configure --prefix=/usr/local/gcc-7.2.0
--with-float=hard --enable-languages=c,c++
Thread model: posix
gcc version 7.2.0 (GCC)
[root@alarm src]#
g++ -DHAVE_CONFIG_H -I. -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE
-D__STDC_FORMAT_MACROS -D_GNU_SOURCE -DCEPH_LIBDIR="/usr/local/ceph-10.2.9/lib"
-DCEPH_PKGLIBDIR="/usr/local/ceph-10.2.9/lib/ceph" -DGTEST_USE_OWN_TR1_TUPLE=0
-D_REENTRANT -Wall -Wtype-limits -Wignored-qualifiers -Winit-self
-Wpointer-arith -fno-strict-aliasing -fsigned-char -rdynamic
-ftemplate-depth-1024 -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe
-Wall -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
--param=ssp-buffer-size=4 -fPIE -fstack-protector-strong -fno-builtin-malloc
-fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free
-Wstrict-null-sentinel -g -O2 -MT osd/libosd_a-ECBackend.o -MD -MP -MF
osd/.deps/libosd_a-ECBackend.Tpo -c -o osd/libosd_a-ECBackend.o
osd/ECBackend.cc -save-temps
g++: warning: -pipe ignored because -save-temps specified
osd/ECBackend.cc: In member function 'int ECBackend::get_remaining_shards(const
hobject_t&, const std::set&, std::set*)':
osd/ECBackend.cc:1532:52: warning: variable 'miter' set but not used
[-Wunused-but-set-variable]
map >::const_iterator miter =
^
In file included from osd/ECBackend.cc:24:0:
osd/ReplicatedPG.h: In destructor 'virtual
ReplicatedPG::WaitTrimTimer::WaitTrimTimer(boost::statechart::state::my_context)::OnTimer::~OnTimer()':
osd/ReplicatedPG.h:1667:14: internal compiler error: in force_type_die, at
dwarf2out.c:25099
struct OnTimer : Context {
^~~
0x3dac23 force_type_die
../../gcc-7.2.0/gcc/dwarf2out.c:25099
0x3d8627 get_context_die
../../gcc-7.2.0/gcc/dwarf2out.c:25013
0x3d8627 force_decl_die
../../gcc-7.2.0/gcc/dwarf2out.c:25032
0x3d5dcf gen_subprogram_die
../../gcc-7.2.0/gcc/dwarf2out.c:21895
0x3d6dc3 gen_decl_die
../../gcc-7.2.0/gcc/dwarf2out.c:25335
0x3d7ae3 dwarf2out_decl
../../gcc-7.2.0/gcc/dwarf2out.c:25844
0x3d635b dwarf2out_abstract_function
../../gcc-7.2.0/gcc/dwarf2out.c:21671
0x708aef expand_call_inline
../../gcc-7.2.0/gcc/tree-inline.c:4887
0x7099cf gimple_expand_calls_inline
../../gcc-7.2.0/gcc/tree-inline.c:4917
0x7099cf optimize_inline_calls(tree_node*)
../../gcc-7.2.0/gcc/tree-inline.c:5057
0xc4c01f early_inliner(function*)
../../gcc-7.2.0/gcc/ipa-inline.c:2721
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug other/82997] New: [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82997 Bug ID: 82997 Summary: [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- These test cases are looking for the message /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/cpp/macsyntx.c:54:6: warning: ISO C99 requires at least one argument for the "..." in a variadic macro and after this revision that message is no longer produced (at least for these tests).
[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82995 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|WAITING |NEW CC||kargl at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > IMO the code is invalid: you cannot call my_sum with only one argument. I > get a segfault for all the revision I have tested from 4.8 up to trunk > (8.0), except with my instrumented trunk for which I get 0. > > I am a little bit surprised that the mismatch between caller and callee is > not detected, but I think a compiler does have to (I did not look at the > standard legalese). The code is valid. From 2008, page 299 An optional dummy argument that is not present is subject to the following restrictions. (1) If it is a data object, it shall not be referenced or be defined. ... ... Except as noted in the list above, it may be supplied as an actual argument corresponding to an optional dummy argument, which is then also considered not to be present. By (1), one would think that the absent optional argument cannot be referenced within my_sum(). However, the exception explicitly allows this case as the MASK argument of SUM is optional.
[Bug fortran/82996] ICE and segfault with derived type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 --- Comment #2 from neil.n.carlson at gmail dot com --- In the final example I drop the elemental attribute from the FOO final procedure and modify the BAR final procedure to loop over the elements of its B array component. This too yields an ICE: f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:1975 module mod type foo integer, pointer :: f(:) => null() contains final :: foo_destroy end type type bar type(foo) :: b(2) contains final :: bar_destroy end type contains subroutine foo_destroy(this) type(foo), intent(inout) :: this if (associated(this%f)) deallocate(this%f) end subroutine subroutine bar_destroy(this) type(bar), intent(inout) :: this integer :: j do j = 1, size(this%b) call foo_destroy(this%b(j)) end do end subroutine end module program main use mod type(bar) :: x call sub(x) contains subroutine sub(x) type(bar), intent(out) :: x end subroutine end program
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985
--- Comment #16 from Markus Trippelsdorf ---
Created attachment 42606
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42606&action=edit
somewhat reduced testcase
(Creduce struggles with 7.6MB boost testcases...)
% g++ -mavx2 -c -O2 FullSystemOptimize.ii -w
FullSystemOptimize.ii: In member function ‘bool
std::FullSystem::doStepFromBackup()’:
FullSystemOptimize.ii:446:6: internal compiler error: in
vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1722
bool FullSystem::doStepFromBackup() {
^~
0xc52643 vn_nary_build_or_lookup_1
../../gcc/gcc/tree-ssa-sccvn.c:1722
0xc546a9 vn_nary_build_or_lookup
../../gcc/gcc/tree-ssa-sccvn.c:1758
0xc546a9 vn_reference_lookup_3
../../gcc/gcc/tree-ssa-sccvn.c:2037
0xbbe6fe walk_non_aliased_vuses(ao_ref*, tree_node*, void* (*)(ao_ref*,
tree_node*, unsigned int, void*), void* (*)(ao_ref*, tree_node*, void*, bool*),
tree_node* (*)(tree_node*), void*)
../../gcc/gcc/tree-ssa-alias.c:2872
0xc53179 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
../../gcc/gcc/tree-ssa-sccvn.c:2450
0xc558e0 visit_reference_op_load
../../gcc/gcc/tree-ssa-sccvn.c:3691
0xc558e0 visit_use
../../gcc/gcc/tree-ssa-sccvn.c:4031
0xc57050 process_scc
../../gcc/gcc/tree-ssa-sccvn.c:4293
0xc57050 extract_and_process_scc_for_name
../../gcc/gcc/tree-ssa-sccvn.c:4349
0xc57050 DFS
../../gcc/gcc/tree-ssa-sccvn.c:4401
0xc58496 sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-sccvn.c:4854
0x10ea63a dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:265
0xc5905a run_scc_vn(vn_lookup_kind)
../../gcc/gcc/tree-ssa-sccvn.c:4978
0xc356df execute
../../gcc/gcc/tree-ssa-pre.c:5093
[Bug fortran/82996] ICE and segfault with derived type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 --- Comment #1 from neil.n.carlson at gmail dot com --- In the second example, I add a final procedure for BAR (not necessary) and explicitly call the FOO final procedure on its B component. This gives an ICE f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:1975 module mod type foo integer, pointer :: f(:) => null() contains final :: foo_destroy end type type bar type(foo) :: b(2) contains final :: bar_destroy end type contains elemental subroutine foo_destroy(this) type(foo), intent(inout) :: this if (associated(this%f)) deallocate(this%f) end subroutine subroutine bar_destroy(this) type(bar), intent(inout) :: this call foo_destroy(this%b) end subroutine end module program main use mod type(bar) :: x call sub(x) contains subroutine sub(x) type(bar), intent(out) :: x end subroutine end program
[Bug fortran/82996] New: ICE and segfault with derived type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 Bug ID: 82996 Summary: ICE and segfault with derived type finalization Product: gcc Version: 6.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- I'm going to give 3 examples. The first gives a spurious run time segfault. The others are attempts to work around the problem, but give an internal compiler error. These all work fine with the Intel and NAG compilers. The first example: module mod type foo integer, pointer :: f(:) => null() contains final :: foo_destroy end type type bar type(foo) :: b(2) end type contains elemental subroutine foo_destroy(this) type(foo), intent(inout) :: this if (associated(this%f)) deallocate(this%f) end subroutine end module program main use mod type(bar) :: x call sub(x) contains subroutine sub(x) type(bar), intent(out) :: x end subroutine end program And the output from running the executable: $ gfortran -g gfortran-bug-20171114a.f90 $ ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f1188b42df7 in ??? #1 0x7f1188b4202d in ??? #2 0x7f118803694f in ??? #3 0x400fa7 in __mod_MOD_foo_destroy at /home/nnc/Fortran/Bugs/gfortran/tmp/gfortran-bug-20171114a.f90:46 #4 0x400f0f in __mod_MOD___final_mod_Foo at /home/nnc/Fortran/Bugs/gfortran/tmp/gfortran-bug-20171114a.f90:49 #5 0x400b29 in __mod_MOD___final_mod_Bar at /home/nnc/Fortran/Bugs/gfortran/tmp/gfortran-bug-20171114a.f90:49 #6 0x401026 in sub at /home/nnc/Fortran/Bugs/gfortran/tmp/gfortran-bug-20171114a.f90:59 #7 0x40104a in MAIN__ at /home/nnc/Fortran/Bugs/gfortran/tmp/gfortran-bug-20171114a.f90:55 #8 0x401080 in main at /home/nnc/Fortran/Bugs/gfortran/tmp/gfortran-bug-20171114a.f90:53 Segmentation fault (core dumped)
[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976 --- Comment #4 from Martin Liška --- So for following GIMPLE stmt: $ (gdb) p debug_gimple_stmt(stmt) _54 = 0; RHS (kind == 1) is created here: (gdb) bt #0 make_int_cst (len=1, ext_len=1) at ../../gcc/tree.c:2286 #1 0x0139516a in build_new_int_cst (type=0x76827b28, cst=...) at ../../gcc/tree.c:1280 #2 0x01395ef3 in wide_int_to_tree (type=0x76827b28, pcst=...) at ../../gcc/tree.c:1529 #3 0x01010b84 in set_min_and_max_values_for_integral_type (type=0x76827b28, precision=8, sgn=UNSIGNED) at ../../gcc/stor-layout.c:2680 #4 0x01010cfa in fixup_unsigned_type (type=0x76827b28) at ../../gcc/stor-layout.c:2711 #5 0x01010016 in make_unsigned_type (precision=8) at ../../gcc/stor-layout.c:2538 #6 0x013b4983 in build_common_tree_nodes (signed_char=false) at ../../gcc/tree.c:9562 #7 0x0091167e in gfc_init_decl_processing () at ../../gcc/fortran/f95-lang.c:506 #8 0x00910f2a in gfc_init () at ../../gcc/fortran/f95-lang.c:242 #9 0x01020600 in lang_dependent_init (name=0x7fffe202 "/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/realloc_on_assign_16.f90") at ../../gcc/toplev.c:1819 #10 0x01020b37 in do_compile () at ../../gcc/toplev.c:2045 #11 0x01020e84 in toplev::main (this=0x7fffdc6e, argc=16, argv=0x7fffdd68) at ../../gcc/toplev.c:2194 #12 0x01c3e1d2 in main (argc=16, argv=0x7fffdd68) at ../../gcc/main.c:39 LHS here: (gdb) bt #0 make_ssa_name_fn (fn=0x769c10b0, var=0x76833348, stmt=0x7662aa00, version=0) at ../../gcc/tree-ssanames.c:313 #1 0x012ee868 in copy_ssa_name_fn (fn=0x769c10b0, name=0x7661a750, stmt=0x7662aa00) at ../../gcc/tree-ssanames.c:691 #2 0x012eeccf in duplicate_ssa_name_fn (fn=0x769c10b0, name=0x7661a750, stmt=0x7662aa00) at ../../gcc/tree-ssanames.c:752 #3 0x010dc1a0 in duplicate_ssa_name (var=0x7661a750, stmt=0x7662aa00) at ../../gcc/tree-ssanames.h:134 #4 0x010e3605 in create_new_def_for (old_name=0x7661a750, stmt=0x7662aa00, def=0x7662aa40) at ../../gcc/tree-into-ssa.c:2949 #5 0x01079665 in gimple_duplicate_bb (bb=0x7661bea0) at ../../gcc/tree-cfg.c:6186 #6 0x00a76d6c in duplicate_block (bb=0x7661bea0, e=0x0, after=0x0) at ../../gcc/cfghooks.c:1077 #7 0x012cc659 in create_block_for_threading (bb=0x7661bea0, rd=0x2a8c950, count=0, duplicate_blocks=0x7fffd6e0) at ../../gcc/tree-ssa-threadupdate.c:336 #8 0x012cde44 in ssa_create_duplicates (slot=0x2c3be30, local_info=0x7fffd6d0) at ../../gcc/tree-ssa-threadupdate.c:1124 #9 0x012d182d in hash_table::traverse_noresize (this=0x2c3bdf0, argument=0x7fffd6d0) at ../../gcc/hash-table.h:969 #10 0x012d0d0f in hash_table::traverse (this=0x2c3bdf0, argument=0x7fffd6d0) at ../../gcc/hash-table.h:990 #11 0x012ce4e0 in thread_block_1 (bb=0x7661bea0, noloop_only=true, joiners=false) at ../../gcc/tree-ssa-threadupdate.c:1387 #12 0x012ce5b6 in thread_block (bb=0x7661bea0, noloop_only=true) at ../../gcc/tree-ssa-threadupdate.c:1431 #13 0x012d03a4 in thread_through_all_blocks (may_peel_loop_headers=false) at ../../gcc/tree-ssa-threadupdate.c:2298 #14 0x011afcb9 in (anonymous namespace)::pass_dominator::execute (this=0x2aa0470, fun=0x769c10b0) at ../../gcc/tree-ssa-dom.c:749 #15 0x00ef7b1f in execute_one_pass (pass=0x2aa0470) at ../../gcc/passes.c:2497 #16 0x00ef7e70 in execute_pass_list_1 (pass=0x2aa0470) at ../../gcc/passes.c:2586 #17 0x00ef7ea1 in execute_pass_list_1 (pass=0x2a9e270) at ../../gcc/passes.c:2587 #18 0x00ef7ef9 in execute_pass_list (fn=0x769c10b0, pass=0x2a9e090) at ../../gcc/passes.c:2597 #19 0x00ab8076 in cgraph_node::expand (this=0x769d3170) at ../../gcc/cgraphunit.c:2139 #20 0x00ab86b2 in expand_all_functions () at ../../gcc/cgraphunit.c:2275 #21 0x00ab9206 in symbol_table::compile (this=0x76817100) at ../../gcc/cgraphunit.c:2623 #22 0x00ab947b in symbol_table::finalize_compilation_unit (this=0x76817100) at ../../gcc/cgraphunit.c:2716 #23 0x0101e4c8 in compile_file () at ../../gcc/toplev.c:480 #24 0x01020b97 in do_compile () at ../../gcc/toplev.c:2059 #25 0x01020e84 in toplev::main (this=0x7fffdc6e, argc=16, argv=0x7fffdd68) at ../../gcc/toplev.c:2194 #26 0x01c3e1d2 in main (argc=16, argv=0x7fffdd68) at ../../gcc/main.c:39 Is it helpful information, or should I investigate more? Which is the problematic type?
[Bug c++/82836] [8 Regression] ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82836 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-11-14 Ever confirmed|0 |1
[Bug c++/82959] g++ doesn't appreciate C++17 evaluation order rules for overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82959
Mukesh Kapoor changed:
What|Removed |Added
CC||mukesh.kapoor at oracle dot com
--- Comment #2 from Mukesh Kapoor ---
Here is a reduced test case that shows the same problem:
extern "C" int printf(const char*, ...);
class Int {
public:
bool operator&&(const Int& rhs) const { return val && rhs.val; }
private:
int val = 0;
};
int main()
{
Int xx;
(printf("first\n"), xx) && (printf("second\n"), xx);
};
[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82995 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-11-14 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- IMO the code is invalid: you cannot call my_sum with only one argument. I get a segfault for all the revision I have tested from 4.8 up to trunk (8.0), except with my instrumented trunk for which I get 0. I am a little bit surprised that the mismatch between caller and callee is not detected, but I think a compiler does have to (I did not look at the standard legalese).
[Bug fortran/82995] New: Segmentation fault passing optional argument to intrinsic sum function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82995 Bug ID: 82995 Summary: Segmentation fault passing optional argument to intrinsic sum function Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: werner.blokbuster at gmail dot com Target Milestone: --- With gfortran 7.2 on linux the following code gives a segmentation fault on the output line starting "C2". Some earlier versions (before 4.9) give the answer '0' instead. module y implicit none contains function test_sum(input,mask) integer, intent(in) :: input(:) logical, intent(in), optional :: mask(:) integer :: test_sum if(present(mask)) then test_sum = sum(input,mask) else test_sum = sum(input) endif end function test_sum function my_sum(input,mask) integer, intent(in) :: input(:) logical, intent(in), optional :: mask(:) integer :: my_sum my_sum = sum(input,mask) end function my_sum end module y program test_my_sum use y, only: my_sum, test_sum implicit none integer :: input(3) = [1,2,3] logical :: mask(3) = [.true.,.false.,.true.] ! This works: write(*,*) 'A1: ', sum(input) write(*,*) 'A2: ', sum(input,mask) ! This works: write(*,*) 'B1: ', test_sum(input) write(*,*) 'B2: ', test_sum(input,mask) ! This works: write(*,*) 'C1: ', my_sum(input,[.true.,.true.,.true.]) ! Segmentation fault, or answer '0': write(*,*) 'C2: ', my_sum(input) end program test_my_sum
[Bug fortran/82993] ICE in free_expr0, at fortran/expr.c:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With a wrong parameter definition :
>
> $ cat z1.f90
> program p
>type t
> real :: a(3)
>end type
>type(t), parameter :: z = 1
>print *, z%a(1)
>print *, z%a
> end
>
>
> $ gfortran-8-20171112 -c z1.f90
> f951: internal compiler error: Segmentation fault
> 0xb61c7f crash_signal
> ../../gcc/toplev.c:325
> 0x69268b free_expr0
> ../../gcc/fortran/expr.c:445
> 0x6926ad gfc_free_expr(gfc_expr*)
> ../../gcc/fortran/expr.c:518
> 0x6efd59 gfc_match_rvalue(gfc_expr**)
> ../../gcc/fortran/primary.c:3250
> 0x6c655e match_primary
> ../../gcc/fortran/matchexp.c:157
> 0x6c655e match_level_1
> ../../gcc/fortran/matchexp.c:211
> 0x6c655e match_mult_operand
> ../../gcc/fortran/matchexp.c:267
> 0x6c67a8 match_add_operand
> ../../gcc/fortran/matchexp.c:356
> 0x6c6a3c match_level_2
> ../../gcc/fortran/matchexp.c:480
> 0x6c6b92 match_level_3
> ../../gcc/fortran/matchexp.c:551
> 0x6c6ca4 match_level_4
> ../../gcc/fortran/matchexp.c:599
> 0x6c6ca4 match_and_operand
> ../../gcc/fortran/matchexp.c:693
> 0x6c6e62 match_or_operand
> ../../gcc/fortran/matchexp.c:722
> 0x6c6f52 match_equiv_operand
> ../../gcc/fortran/matchexp.c:765
> 0x6c7042 match_level_5
> ../../gcc/fortran/matchexp.c:811
> 0x6c63b1 gfc_match_expr(gfc_expr**)
> ../../gcc/fortran/matchexp.c:870
> 0x6af7a9 match_io_element
> ../../gcc/fortran/io.c:3542
> 0x6af9f3 match_io_list
> ../../gcc/fortran/io.c:3581
> 0x6b4214 match_io
> ../../gcc/fortran/io.c:4242
> 0x6b592a gfc_match_print()
> ../../gcc/fortran/io.c:4298
Ugh. This one is real ugly. :(
If both print statement are commented out, one gets
% gfcx -c a.f90
a.f90:5:28:
type(t), parameter :: z = 1
1
Error: Incompatible derived type in PARAMETER at (1)
a.f90:5:28:
type(t), parameter :: z = 1
1
Error: Can't convert INTEGER(4) to TYPE(t) at (1)
This is the good news!
If the first print statement is uncomment, we get Gerhard's
trace above. If the first print is again commented out and
the second statement is uncommented, we get
% gfcx -c a.f90
a.f90:5:28:
type(t), parameter :: z = 1
1
Error: Incompatible derived type in PARAMETER at (1)
a.f90:5:28:
type(t), parameter :: z = 1
1
Error: Can't convert INTEGER(4) to TYPE(t) at (1)
(null):0: confused by earlier errors, bailing out
AFAICT, when the statement "type(t), parameter :: z = 1"
is rejected, the gfc_expr for z = 1 is not properly freed.
I see
(gdb) p *p
$8 = {op = EXEC_ASSIGN, block = 0x0, next = 0x0, loc = {nextc = 0x0,
lb = 0x0}, here = 0x0, label1 = 0x0, label2 = 0x0, label3 = 0x0,
symtree = 0x0, expr1 = 0x201d837e0, expr2 = 0x0, expr3 = 0x0, expr4 = 0x0,
resolved_sym = 0x0, resolved_isym = 0x0, ext = {actual = 0x0,
iterator = 0x0, alloc = {ts = {type = BT_UNKNOWN, kind = 0, u = {
derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0,
is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN,
deferred = false, interop_kind = 0x0}, list = 0x0,
arr_spec_from_expr3 = 0}, block = {ns = 0x0, assoc = 0x0,
case_list = 0x0}, open = 0x0, close = 0x0, filepos = 0x0, inquire = 0x0,
wait = 0x0, dt = 0x0, forall_iterator = 0x0, which_construct = 0x0,
stop_code = 0, entry = 0x0, oacc_declare = 0x0, omp_clauses = 0x0,
omp_name = 0x0, omp_namelist = 0x0, omp_bool = false,
omp_atomic = GFC_OMP_ATOMIC_UPDATE}, cycle_label = 0x0, exit_label = 0x0}
(gdb) p *p->expr1
$3 = {expr_type = EXPR_FUNCTION, ts = {type = BT_UNKNOWN, kind = 0, u = {
derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0,
is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false,
interop_kind = 0x0}, rank = 0, shape = 0x0, symtree = 0x201d805d0,
ref = 0x0, where = {nextc = 0x201dc50cc, lb = 0x201dc50a0}, base_expr = 0x0,
is_boz = 0, is_snan = 0, error = 0, user_operator = 0, mold = 0,
must_finalize = 0, representation = {length = 0, string = 0x0}, value = {
logical = 30934528, iokind = 30934528, integer = {{_mp_alloc = 30934528,
_mp_size = 2, _mp_d = 0x0}}, real = {{_mpfr_prec = 8620869120,
_mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}, complex = {{re = {{
_mpfr_prec = 8620869120, _mpfr_sign = 0, _mpfr_exp = 0,
_mpfr_d = 0x0}}, im = {{_mpfr_prec = 0, _mpfr_sign = 0,
_mpfr_exp = 0, _mpfr_d = 0x0, op = {op = 30934528, uop = 0x0,
op1 =
[Bug c++/77369] incorrect noexcept specification deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77369 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #15 from BlenderEi at LwTV dot de --- I admire your positivity, Markus ;) Good luck!
[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981 --- Comment #7 from Jim Wilson --- if (GET_MODE_2XWIDER_MODE (mode).exists (&wmode) && targetm.scalar_mode_supported_p (wmode)) This test succeeds, and then in expand_expr WIDEN_MULT_EXPR the checks for a mult widen optab entry fails, so it gnerates a TImode multiply, which is a libcall.
[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82934 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- This is now fixed on all three branches. Thanks to self for reporting it :-) Paul
[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82994 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-14 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (8.0). My instrumented compiler gives ../../work/gcc/fortran/match.c:4473:7: runtime error: member access within null pointer of type 'struct gfc_component'
[Bug fortran/82896] probably pointer assignement bug in gfortran compiler version 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82896 Paul Thomas changed: What|Removed |Added Status|WAITING |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Paul Thomas --- I cannot reproduce the bug on any of the current 6-, 7- or 8-branches. I assume that "friendly fire" in fixing another bug has killed this one. I have been doing a fair amount of general work in this area, so I assume that it was me but, I am sorry, I don't have time to retrace my steps and find which fix did the job. If it is a specific Mingw problem, please reopen the Bug report. Thanks for reporting this and sorry if it is causing you some difficulty. Best regards Paul
[Bug fortran/82993] ICE in free_expr0, at fortran/expr.c:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-14 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (8.0).
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #14 from Markus Trippelsdorf --- Thank you. I can reproduce the issue now. Reducing...
[Bug fortran/82992] ICE in create_int_parameter_array, at fortran/module.c:6586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82992 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-14 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (8.0). My instrumented compiler gives ../../work/gcc/fortran/module.c:6586:18: runtime error: null pointer passed as argument 2, which is declared to never be null
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #13 from BlenderEi at LwTV dot de --- Created attachment 42605 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42605&action=edit FullSystemOptimize.ii and FullSystemOptimize.s files - those are the only ones I got from the last command Oh yeah, of course. I only have the two generated files .ii and .s of one .cpp file. Nothing else is there in the build directory (as opposed to last time, when the compilation was successful). I have attached them.
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #12 from Markus Trippelsdorf --- (In reply to BlenderEi from comment #9) > Created attachment 42604 [details] > Output of command "make VERBOSE=1" with altered makefile with additional > flags which invokes the compiler to crash > > Oh ok. Sorry for this taking so long. If I didnt misunderstand you, I got it > now. > > I have now executed: > > make VERBOSE=1 > after I changed the Makefile (generated by CMake) by adding the flags (-v > --save-temps) inbetween "/usr/bin/c++ $(CXX_DEFINES) $(CXX_INCLUDES) > $(CXX_FLAGS)" and "-o > CMakeFiles/dso.dir/src/FullSystem/FullSystemOptimize.cpp.o -c > /home/akp/dso/src/FullSystem/FullSystemOptimize.cpp" (because building the > "FullSystemOptimize" object seems to be the reason for the crash). > > What do you say, is this useful? Yes, thank you. Can you please attach the FullSystemOptimize.ii file (again)?
[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82994 --- Comment #1 from G. Steinmetz --- Now allocated, but still not declared allocatable : (here gcc-chk was configured with --enable-checking=yes) $ cat z2.f90 program p type t end type class(t) :: x allocate (x) deallocate (x) end $ gfortran-8-20171112-chk -c z2.f90 z2.f90:5:13: allocate (x) 1 Error: Allocate-object at (1) is neither a data pointer nor an allocatable variable f951: internal compiler error: Segmentation fault 0xcaca2f crash_signal ../../gcc/toplev.c:325 0x6ee643 gfc_match_deallocate() ../../gcc/fortran/match.c:4478 0x70b309 match_word_omp_simd ../../gcc/fortran/parse.c:93 0x70fd4f match_word ../../gcc/fortran/parse.c:466 0x70fd4f decode_statement ../../gcc/fortran/parse.c:466 0x7107f4 next_free ../../gcc/fortran/parse.c:1225 0x7107f4 next_statement ../../gcc/fortran/parse.c:1457 0x7120dc parse_spec ../../gcc/fortran/parse.c:3834 0x7145d3 parse_progunit ../../gcc/fortran/parse.c:5637 0x715b94 gfc_parse_file() ../../gcc/fortran/parse.c:6177 0x75b20f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82934 --- Comment #5 from Paul Thomas --- Author: pault Date: Tue Nov 14 17:38:38 2017 New Revision: 254733 URL: https://gcc.gnu.org/viewcvs?rev=254733&root=gcc&view=rev Log: 2017-11-13 Paul Thomas Backport from trunk PR fortran/82934 * trans-stmt.c (gfc_trans_allocate): Remove the gcc_assert on null string length for assumed length typespec and set expr3_esize to NULL_TREE; 2017-11-13 Paul Thomas Backport from trunk PR fortran/82934 * gfortran.dg/allocate_assumed_charlen_1.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/allocate_assumed_charlen_1.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/trans-stmt.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/82994] New: ICE in gfc_match_deallocate, at fortran/match.c:4478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82994 Bug ID: 82994 Summary: ICE in gfc_match_deallocate, at fortran/match.c:4478 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With invalid code (no pointer/allocatable attribute, nor allocated) : $ cat z1.f90 program p type t end type class(t) :: x deallocate (x) end $ gfortran-8-20171112 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb61c7f crash_signal ../../gcc/toplev.c:325 0x6c33e3 gfc_match_deallocate() ../../gcc/fortran/match.c:4478 0x6dfe69 match_word_omp_simd ../../gcc/fortran/parse.c:93 0x6e48af match_word ../../gcc/fortran/parse.c:466 0x6e48af decode_statement ../../gcc/fortran/parse.c:466 0x6e5354 next_free ../../gcc/fortran/parse.c:1225 0x6e5354 next_statement ../../gcc/fortran/parse.c:1457 0x6e6c3c parse_spec ../../gcc/fortran/parse.c:3834 0x6e9133 parse_progunit ../../gcc/fortran/parse.c:5637 0x6ea6f4 gfc_parse_file() ../../gcc/fortran/parse.c:6177 0x72f13f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/78619] [6/7/8 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78619 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed on 6-, 7- and 8-branches. Thanks for the report. Paul
[Bug fortran/82993] ICE in free_expr0, at fortran/expr.c:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993 G. Steinmetz changed: What|Removed |Added Summary|ICE free_expr0, at |ICE in free_expr0, at |fortran/expr.c:445 |fortran/expr.c:445 --- Comment #1 from G. Steinmetz --- Similar tests : $ cat z3.f90 program p type t integer :: a(3) end type type(t), parameter :: z = 1.0 print *, z%a(1) print *, z%a end $ cat z5.f90 program p type t real :: a(3) end type type(t), parameter :: z = '1' print *, z%a(1) print *, z%a end $ cat z6.f90 program p type t real :: a(3) end type type(t), parameter :: z = .true. print *, z%a(1) print *, z%a end
[Bug fortran/82993] New: ICE free_expr0, at fortran/expr.c:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82993 Bug ID: 82993 Summary: ICE free_expr0, at fortran/expr.c:445 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With a wrong parameter definition : $ cat z1.f90 program p type t real :: a(3) end type type(t), parameter :: z = 1 print *, z%a(1) print *, z%a end $ gfortran-8-20171112 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb61c7f crash_signal ../../gcc/toplev.c:325 0x69268b free_expr0 ../../gcc/fortran/expr.c:445 0x6926ad gfc_free_expr(gfc_expr*) ../../gcc/fortran/expr.c:518 0x6efd59 gfc_match_rvalue(gfc_expr**) ../../gcc/fortran/primary.c:3250 0x6c655e match_primary ../../gcc/fortran/matchexp.c:157 0x6c655e match_level_1 ../../gcc/fortran/matchexp.c:211 0x6c655e match_mult_operand ../../gcc/fortran/matchexp.c:267 0x6c67a8 match_add_operand ../../gcc/fortran/matchexp.c:356 0x6c6a3c match_level_2 ../../gcc/fortran/matchexp.c:480 0x6c6b92 match_level_3 ../../gcc/fortran/matchexp.c:551 0x6c6ca4 match_level_4 ../../gcc/fortran/matchexp.c:599 0x6c6ca4 match_and_operand ../../gcc/fortran/matchexp.c:693 0x6c6e62 match_or_operand ../../gcc/fortran/matchexp.c:722 0x6c6f52 match_equiv_operand ../../gcc/fortran/matchexp.c:765 0x6c7042 match_level_5 ../../gcc/fortran/matchexp.c:811 0x6c63b1 gfc_match_expr(gfc_expr**) ../../gcc/fortran/matchexp.c:870 0x6af7a9 match_io_element ../../gcc/fortran/io.c:3542 0x6af9f3 match_io_list ../../gcc/fortran/io.c:3581 0x6b4214 match_io ../../gcc/fortran/io.c:4242 0x6b592a gfc_match_print() ../../gcc/fortran/io.c:4298
[Bug fortran/82992] New: ICE in create_int_parameter_array, at fortran/module.c:6586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82992 Bug ID: 82992 Summary: ICE in create_int_parameter_array, at fortran/module.c:6586 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With invalid code : $ cat z1.f90 subroutine sub (x) use iso_fortran_env, only: x => character_kinds end $ gfortran-8-20171112 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb61c7f crash_signal ../../gcc/toplev.c:325 0x6ca002 create_int_parameter_array ../../gcc/fortran/module.c:6586 0x6caaf3 use_iso_fortran_env_module ../../gcc/fortran/iso-fortran-env.def:100 0x6cffb7 gfc_use_module ../../gcc/fortran/module.c:6938 0x6d1636 gfc_use_modules() ../../gcc/fortran/module.c:7178 0x6df7dc use_modules ../../gcc/fortran/parse.c:114 0x6e3494 decode_statement ../../gcc/fortran/parse.c:332 0x6e5354 next_free ../../gcc/fortran/parse.c:1225 0x6e5354 next_statement ../../gcc/fortran/parse.c:1457 0x6e6c3c parse_spec ../../gcc/fortran/parse.c:3834 0x6e9133 parse_progunit ../../gcc/fortran/parse.c:5637 0x6eaa04 gfc_parse_file() ../../gcc/fortran/parse.c:6184 0x72f13f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #11 from Ahmad Fatoum --- (In reply to Ahmad Fatoum from comment #10) > (In reply to BlenderEi from comment #9) > > What do you say, is this useful? > > Hi Adam, > > --save-temps saves some temporary files ( *.i, *.s, *.o) which might be useful as well.
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 Ahmad Fatoum changed: What|Removed |Added CC||ahmad at a3f dot at --- Comment #10 from Ahmad Fatoum --- (In reply to BlenderEi from comment #9) > What do you say, is this useful? Hi Adam, --save-temps saves some temporary files (
[Bug target/82990] Add -mprefer-vzeroupper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82990 --- Comment #1 from H.J. Lu --- We would like -mprefer-vzeroupper default to on and -mtune=knl should override it.
[Bug tree-optimization/82991] memcpy and strcpy return value can be assumed to be equal to first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82991 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- GCC tracks that fact, see gimple_call_return_flags ERF_RETURNS_ARG and ERF_RETURN_ARG_MASK to say which argument it is. >From what I can see, it is used during aliasing and vrp (in the latter case only whether it is non-NULL or not). So it is just a matter of using it in further optimizations. But it needs to be used with care. Trying to optimize: return strcpy (x, y); as strcpy (x, y); return x; is not a good idea, it would make it not tail-call optimizable, and in many cases even for RA purposes it is cheaper to read the value from the return register rather than saving it in call saved register and restoring from there, etc. Which is why it is not that strightforward to say do it in SCCVN.
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #9 from BlenderEi at LwTV dot de --- Created attachment 42604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42604&action=edit Output of command "make VERBOSE=1" with altered makefile with additional flags which invokes the compiler to crash Oh ok. Sorry for this taking so long. If I didnt misunderstand you, I got it now. I have now executed: > make VERBOSE=1 after I changed the Makefile (generated by CMake) by adding the flags (-v --save-temps) inbetween "/usr/bin/c++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)" and "-o CMakeFiles/dso.dir/src/FullSystem/FullSystemOptimize.cpp.o -c /home/akp/dso/src/FullSystem/FullSystemOptimize.cpp" (because building the "FullSystemOptimize" object seems to be the reason for the crash). What do you say, is this useful?
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #8 from Markus Trippelsdorf --- OK. I need: > git clone https://github.com/JakobEngel/dso.git > sudo apt-get install libsuitesparse-dev libeigen3-dev libboost-all-dev > cd dso > mkdir build > cd build > cmake .. > make VERBOSE=1 Then add -v --save-temps to the gcc invocation that hits the internal compiler error. And then please paste the full output of that invocation here.
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #7 from BlenderEi at LwTV dot de --- Created attachment 42603 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42603&action=edit This is the verbose output with the CMAKE flag 'set (CMAKE_CXX_FLAGS "-v --save-temps")' Ok, in that case I hope I understood what you need. See the attached archive. Typing "make -VERBOSE=1" didn't achieve anything but displaying the help text. Therefore, again I tried the CMAKE variant. Note: My gcc version is a little different I noticed, but I was confirmed that 7.2.1 is affected by this bug too. Please tell me if you need something else.
[Bug tree-optimization/82991] New: memcpy and strcpy return value can be assumed to be equal to first argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82991
Bug ID: 82991
Summary: memcpy and strcpy return value can be assumed to be
equal to first argument
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I noticed another even more straightforward optimization opportunity that the
one pointed out in pr82665. The test case below shows that GCC knows that
stpcpy(p, s) returns p + strlen(s) but it doesn't "know" that strcpy(p, s)
returns p, or that memcmpy(p, s, n) also returns p.
$ cat c.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout c.c
void f1 (char *p)
{
char *q = __builtin_stpcpy (p, "123");
unsigned n = q - p;
if (n != 3) // eliminated
__builtin_abort ();
}
void f2 (char *p)
{
char *q = __builtin_strcpy (p, "123");
unsigned n = q - p;
if (n) // not eliminated
__builtin_abort ();
}
void f3 (char *p, const char *s)
{
char *q = __builtin_memcpy (p, s, 3);
unsigned n = q - p;
if (n) // not eliminated
__builtin_abort ();
}
;; Function f1 (f1, funcdef_no=0, decl_uid=1891, cgraph_uid=0, symbol_order=0)
f1 (char * p)
{
[local count: 1]:
__builtin_memcpy (p_2(D), "123", 4); [tail call]
return;
}
;; Function f2 (f2, funcdef_no=1, decl_uid=1896, cgraph_uid=1, symbol_order=1)
f2 (char * p)
{
unsigned int n;
char * q;
long int q.2_1;
long int p.3_2;
long int _3;
[local count: 1]:
q_7 = __builtin_memcpy (p_5(D), "123", 4);
q.2_1 = (long int) q_7;
p.3_2 = (long int) p_5(D);
_3 = q.2_1 - p.3_2;
n_8 = (unsigned int) _3;
if (n_8 != 0)
goto ; [0.04%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 9996]:
return;
}
;; Function f3 (f3, funcdef_no=2, decl_uid=1902, cgraph_uid=2, symbol_order=2)
f3 (char * p, const char * s)
{
unsigned int n;
char * q;
long int q.4_1;
long int p.5_2;
long int _3;
[local count: 1]:
q_8 = __builtin_memcpy (p_5(D), s_6(D), 3);
q.4_1 = (long int) q_8;
p.5_2 = (long int) p_5(D);
_3 = q.4_1 - p.5_2;
n_9 = (unsigned int) _3;
if (n_9 != 0)
goto ; [0.04%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 9996]:
return;
}
[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981 Jakub Jelinek changed: What|Removed |Added Attachment #42600|0 |1 is obsolete|| Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-11-14 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jakub Jelinek --- Created attachment 42602 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42602&action=edit gcc8-pr82981.patch Updated untested patch.
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #6 from Markus Trippelsdorf --- (In reply to BlenderEi from comment #5) > Wow, ok nice. So my issue is solved? > > This would be amazing. Thank you for your help in that case. > > I will leave the status as is, because I am not the one that should decide > about the status with my little experience. > > Have a great week, in case we are finished here. Kind regards! No, sorry for the misunderstanding. The issue that I was seeing was a gcc-8 only regression. It has nothing to do with your issue. So we are back to square one. Please post the full gcc invocation and output with -v --save-temps.
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #5 from BlenderEi at LwTV dot de --- Wow, ok nice. So my issue is solved? This would be amazing. Thank you for your help in that case. I will leave the status as is, because I am not the one that should decide about the status with my little experience. Have a great week, in case we are finished here. Kind regards!
[Bug tree-optimization/82187] missed PRE at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82187 --- Comment #2 from Richard Biener --- PRE thinks we are creating a loop-carried dependence that might prevent vectorization (which is enabled at -O3) thus it doesn't perform the transform. So it's a feature ...
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0 --- Comment #4 from Markus Trippelsdorf --- (In reply to Markus Trippelsdorf from comment #3) > Normally, you could enable verbose output with something like "make > VERBOSE=1". > And then add --save-temps to the failing gcc invocation by hand > (and also post the full invocation here). > > Thanks. I can reproduce the issue with trunk: Nope, that issue was already fixed yesterday: PR82360.
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Markus Trippelsdorf --- Normally, you could enable verbose output with something like "make VERBOSE=1". And then add --save-temps to the failing gcc invocation by hand (and also post the full invocation here). Thanks. I can reproduce the issue with trunk: % g++ -O3 -c FullSystemOptimize.ii In file included from /usr/include/boost/smart_ptr/enable_shared_from_this.hpp:16:0, from /usr/include/boost/enable_shared_from_this.hpp:16, from /usr/include/boost/thread/pthread/thread_data.hpp:17, from /usr/include/boost/thread/thread_only.hpp:17, from /usr/include/boost/thread/thread.hpp:12, from /usr/include/boost/thread.hpp:13, from /home/akp/dso/src/util/IndexThreadReduce.h:28, from /home/akp/dso/src/FullSystem/FullSystem.h:39, from /home/akp/dso/src/FullSystem/FullSystemOptimize.cpp:26: /usr/include/boost/smart_ptr/weak_ptr.hpp: In constructor ‘boost::weak_ptr::weak_ptr(boost::weak_ptr&&)’: /usr/include/boost/smart_ptr/weak_ptr.hpp:109:82: internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘identifier_node’ in get_inner_reference, at expr.c:7003 weak_ptr( weak_ptr && r ) ^ 0x6adc65 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) /home/markus/gcc/gcc/tree.c:9268 0xb67738 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /home/markus/gcc/gcc/tree.h:3202 0xb67738 get_inner_reference(tree_node*, long*, long*, tree_node**, machine_mode*, int*, int*, int*) /home/markus/gcc/gcc/expr.c:7003 0xbaed4b fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*) /home/markus/gcc/gcc/fold-const.c:7695 0xbb0189 fold_build1_loc(unsigned int, tree_code, tree_node*, tree_node*) /home/markus/gcc/gcc/fold-const.c:12068 0x788a6c cp_fold_convert(tree_node*, tree_node*) /home/markus/gcc/gcc/cp/cvt.c:607 0x966275 build_static_cast_1 /home/markus/gcc/gcc/cp/typeck.c:6856 0x9669b4 build_static_cast(tree_node*, tree_node*, int) /home/markus/gcc/gcc/cp/typeck.c:7078 0x87a55e cp_parser_postfix_expression /home/markus/gcc/gcc/cp/parser.c:6696 0x87d08a cp_parser_unary_expression /home/markus/gcc/gcc/cp/parser.c:8363 0x85a186 cp_parser_cast_expression /home/markus/gcc/gcc/cp/parser.c:9131 0x85a9f7 cp_parser_binary_expression /home/markus/gcc/gcc/cp/parser.c:9232 0x85c3d4 cp_parser_assignment_expression /home/markus/gcc/gcc/cp/parser.c:9519 0x85e7f6 cp_parser_parenthesized_expression_list /home/markus/gcc/gcc/cp/parser.c:7822 0x880e90 cp_parser_mem_initializer /home/markus/gcc/gcc/cp/parser.c:14548 0x880e90 cp_parser_mem_initializer_list /home/markus/gcc/gcc/cp/parser.c:14434 0x880e90 cp_parser_ctor_initializer_opt /home/markus/gcc/gcc/cp/parser.c:14405 0x880e90 cp_parser_ctor_initializer_opt_and_function_body /home/markus/gcc/gcc/cp/parser.c:21859 0x883866 cp_parser_function_definition_after_declarator /home/markus/gcc/gcc/cp/parser.c:26765 0x884abc cp_parser_late_parsing_for_member /home/markus/gcc/gcc/cp/parser.c:27645 I will try to reduced it.
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 --- Comment #2 from BlenderEi at LwTV dot de --- Created attachment 42601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42601&action=edit This is an archive containing the preprocessed File that triggered the Bug (FullSystemOptimize.ii) as well as my console history, because after I added CMAKE_CXX_FLAGS "-save-temps" it compiles?!?! Thank you for your fast reply. Ok, I have no experience if this is correct, but what I did was: Added this line to the CMakeLists.txt in the main directory "/dso": set (CMAKE_CXX_FLAGS "-save-temps") And with this, it actually compiled the code!!! o.O But it definitely didnt work before. To prove that, I attached my console history as well. You can see, that in the beginning the make-command failed. After I changed the file, the compilation succeeded! Naturally, now I am even more confused. Could you tell me if I missed a step? I checked the instruction website you referred me to, but it didnt tell me how to do this with cmake. So I googled and did my best. Maybe I did a mistake (although, I don't think so). If you need anything, please just let me know. Thanks a lot for your help!
[Bug c++/82988] [8 regression] g++.dg/cpp0x/lambda/lambda-switch.C fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82988 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug target/82990] New: Add -mprefer-vzeroupper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82990
Bug ID: 82990
Summary: Add -mprefer-vzeroupper
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: pavel.v.chupin at gmail dot com
Target Milestone: ---
Target: x86
Should we have a separate patch to add -mprefer-vzeroupper to cover all bases
in the future, like
/* opt_pass methods: */
virtual bool gate (function *)
{
return TARGET_AVX && (!TARGET_AVX512ER || TARGET_PREFER_VZEROUPPER)
&& TARGET_VZEROUPPER && flag_expensive_optimizations
&& !optimize_size;
}
Should explicit -mprefer-vzeroupper or -mno-prefer-vzeroupper override
whatever other optimization conditions there are (i.e. everything other than
TARGET_AVX and TARGET_VZEROUPPER)? I.e. use !TARGET_AVX512ER &&
flag_expensive_optimizations && !optimize_size only when the explicit bit is
not set for it?
[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976 --- Comment #3 from Janne Blomqvist --- Yes, the logical(kind=4) definitely comes from the frontend. If you compile with -fdefault-integer-8 it changes to a logical(kind=8).
[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976 --- Comment #2 from Janne Blomqvist --- Hmm. I do think r254526 does the right thing (TM). Looking at -ftree-dump-original the frontend doesn't generaty any logical(kind=1) temporary variables. So presumably some optimization pass creates such a thing and then it fails to make sure that type matches some logical(kind=4) variable defines elsewhere (by the frontend, maybe). I also checked with -fdump-tree-all, none of gfortran -O3 realloc_on_assign_16.f90 -fdump-tree-all gfortran -O3 -fno-tree-forwprop realloc_on_assign_16.f90 -fdump-tree-all gfortran -O2 -fno-tree-forwprop realloc_on_assign_16.f90 -fdump-tree-all had any logical(kind=1) variables in any of the tree dumps. It might be that due to the ICE with "-O3 -fno-tree-forwprop" the culprit tree dump is never generated.
[Bug c++/82988] [8 regression] g++.dg/cpp0x/lambda/lambda-switch.C fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82988 Jonathan Wakely changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #1 from Jonathan Wakely --- Nothing to do with libstdc++ though.
[Bug target/82989] New: Inexplicable use of NEON for 64-bit math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
Bug ID: 82989
Summary: Inexplicable use of NEON for 64-bit math
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matthijsvanduin at gmail dot com
Target Milestone: ---
The following function:
void foo( uint64_t *a ) {
*a += *a >> 32;
}
compiled with arm-linux-gnueabihf-gcc -mcpu=cortex-a8 -mfpu=neon -O2
produces the following code:
push {r4, r5}
ldrd r4, [r0]
vmov d16, r4, r5
vshr.u64 d16, d16, #32
vmov r2, r3, d16
adds r2, r2, r4
adcs r3, r3, r5
strd r2, [r0]
pop {r4, r5}
bxlr
Since -mneon-for-64bits is not enabled (I double-checked using -Q just to be
sure), the use of neon instructions here is highly unexpected.
(Moreover, shifting right by 32 bits should of course not involve any actual
arithmetic whatsoever. Ideally this function would compile to
ldrd r2, [r0]
adds r2, r2, r3
adcs r3, r3, #0
strd r2, [r0]
bxlr
)
[Bug other/31400] enable static linking of support libraries through -static-libXY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400 --- Comment #21 from janus at gcc dot gnu.org --- (In reply to Matt Arsenault from comment #20) > I would find the -static-libgomp option useful +1
[Bug libstdc++/82988] New: [8 regression] g++.dg/cpp0x/lambda/lambda-switch.C fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82988 Bug ID: 82988 Summary: [8 regression] g++.dg/cpp0x/lambda/lambda-switch.C fail Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r254630 triggers this: --- spawn -ignore SIGHUP /work/gcc/testsuite/g++5/../../xg++ -B/work/gcc/testsuite/g++5/../../ /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/work/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/work/x86_64-pc-linux-gnu/libstdc++-v3/include -I/source/libstdc++-v3/libsupc++ -I/source/libstdc++-v3/include/backward -I/source/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++11 -pedantic-errors -Wno-long-long -S -o lambda-switch.s /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C: In member function 'void main()::A::f()': /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:15:6: error: case label '4' not within a switch statement /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:16:8: error: break statement not within loop or switch /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C: In lambda function: /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:21:6: error: case label '3' not within a switch statement /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:22:8: error: break statement not within loop or switch /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C: In function 'int main()': /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:23:6: warning: statement will never be executed [-Wswitch-unreachable] compiler exited with status 1 PASS: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++11 (test for errors, line 15) PASS: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++11 (test for errors, line 16) FAIL: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++11 (test for warnings, line 19) PASS: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++11 (test for errors, line 21) PASS: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++11 (test for errors, line 22) FAIL: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++11 (test for excess errors) --- spawn -ignore SIGHUP /work/gcc/testsuite/g++5/../../xg++ -B/work/gcc/testsuite/g++5/../../ /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/work/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/work/x86_64-pc-linux-gnu/libstdc++-v3/include -I/source/libstdc++-v3/libsupc++ -I/source/libstdc++-v3/include/backward -I/source/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++14 -pedantic-errors -Wno-long-long -S -o lambda-switch.s /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C: In member function 'void main()::A::f()': /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:15:6: error: case label '4' not within a switch statement /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:16:8: error: break statement not within loop or switch /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C: In lambda function: /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:21:6: error: case label '3' not within a switch statement /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:22:8: error: break statement not within loop or switch /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C: In function 'int main()': /source/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C:23:6: warning: statement will never be executed [-Wswitch-unreachable] compiler exited with status 1 PASS: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++14 (test for errors, line 15) PASS: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++14 (test for errors, line 16) FAIL: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++14 (test for warnings, line 19) PASS: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++14 (test for errors, line 21) PASS: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++14 (test for errors, line 22) FAIL: g++.dg/cpp0x/lambda/lambda-switch.C -std=c++14 (test for excess errors) Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm
[Bug middle-end/82987] [8 regression] gcc.dg/vect/slp-perm-9.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82987 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug middle-end/82987] New: [8 regression] gcc.dg/vect/slp-perm-9.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82987 Bug ID: 82987 Summary: [8 regression] gcc.dg/vect/slp-perm-9.c fail Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r254592 triggers this: --- spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.dg/vect/slp-perm-9.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -msse2 -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./slp-perm-9.exe PASS: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects (test for excess errors) PASS: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 0 loops" 2 (found 1 times) FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 0 (found 1 times) --- spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.dg/vect/slp-perm-9.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -msse2 -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./slp-perm-9.exe PASS: gcc.dg/vect/slp-perm-9.c (test for excess errors) PASS: gcc.dg/vect/slp-perm-9.c execution test FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "vectorized 0 loops" 2 (found 1 times) FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "vectorizing stmts using SLP" 0 (found 1 times) Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=haswell --with-cpu=haswell
[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981 --- Comment #5 from Jakub Jelinek --- Actually, it might be better to verify if the can_widen_mult_without_libcall fails that hmode exists and is exactly half the size of prec, otherwise we could end up with the worst case fallback that can't do overflow. And/or, the PR71289 change could be guarded by precision equal to TYPE_MODE precision and umulv4_optab present for that mode, otherwise MUL_OVERFLOW might be more expensive than the division.
[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981 --- Comment #4 from Jakub Jelinek --- Created attachment 42600 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42600&action=edit gcc8-pr82981.patch Possible untested fix.
[Bug target/82941] Missing vzeroupper with -march=skylake-avx512 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82941 Sebastian Peryt changed: What|Removed |Added CC||sebastian.peryt at intel dot com --- Comment #1 from Sebastian Peryt --- Patch has been sent: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01052.html
[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82942 Sebastian Peryt changed: What|Removed |Added CC||sebastian.peryt at intel dot com --- Comment #6 from Sebastian Peryt --- Patch has been sent: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01052.html
[Bug tree-optimization/82986] [8 regression] gcc.dg/store_merging_13.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82986 Andrey Guskov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrey Guskov --- True. Closing as fixed.
[Bug tree-optimization/82986] [8 regression] gcc.dg/store_merging_13.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82986 --- Comment #1 from Jakub Jelinek --- This should have been fixed in r254606 already.
[Bug preprocessor/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #7 from Eric Gallager --- (In reply to Richard Biener from comment #6) > Hmm, somehow I remember reports similar to this on Darwin. Can you try > using clang for bootstrap? > > What X-Code version are you using on which OS version? > > The crash reporter suggests sth goes wrong with linking as it seems to crash > during init already. I'm using Xcode 3.2.6 on Snow Leopard. Using the system clang fails earlier in configure but I think that's because I screwed up my system headers on this system: configure: error: uint64_t or int64_t not found make[2]: *** [configure-stage1-gcc] Error 1 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 clang 5.0 from MacPorts fails in libbacktrace with: libtool: link: rm -fr .libs/libbacktrace.a .libs/libbacktrace.la libtool: link: ar rc .libs/libbacktrace.a .libs/atomic.o .libs/dwarf.o .libs/fileline.o .libs/posix.o .libs/print.o .libs/sort.o .libs/state.o .libs/backtrace.o .libs/simple.o .libs/unknown.o .libs/mmapio.o .libs/mmap.o ranlib: object: .libs/libbacktrace.a(dwarf.o) malformed object (unknown load command 1) ar: internal ranlib command failed make[4]: *** [libbacktrace.la] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-libbacktrace] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 ...which is probably an issue I should raise with MacPorts instead. It works when I use a previous version of gcc I built myself though. (8.0 from 20170525)
[Bug tree-optimization/82986] New: [8 regression] gcc.dg/store_merging_13.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82986 Bug ID: 82986 Summary: [8 regression] gcc.dg/store_merging_13.c fail Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r254536 triggers this: spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.dg/store_merging_13.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-store-merging -S -o store_merging_13.s PASS: gcc.dg/store_merging_13.c (test for excess errors) FAIL: gcc.dg/store_merging_13.c scan-tree-dump-times store-merging "Merging successful" 13 (found 12 times)
[Bug c++/82985] GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-11-14 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Please attach the (compressed) preprocessed file. See https://gcc.gnu.org/bugs/ for instructions.
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2017-11/msg01061.ht ||ml --- Comment #9 from Rainer Orth --- Patch posted.
[Bug fortran/82978] [PDT] [F2003] Paramaterized Derived Type LEN parameters take the latest value per-kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82978 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-14 Blocks||82173 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The test shows two problems with PDT: (1) The kind of the character is not taken into account: Adding the line print *, kind(w1%chr), kind(x1%chr), kind(y1%chr), kind(z1%chr) gives 1 1 1 1 As a consequence the KINDs 2 and 8 are not properly rejected. (2) The length is not properly set if there is more than one character PDT with the same kind: implicit none type :: pdt_t(k, l) integer, kind :: k integer, len :: l character(kind=k,len=l) :: chr end type type(pdt_t(1, 4)) :: x1 type(pdt_t(1, 5)) :: x2 type(pdt_t(1, 6)) :: x3 print *, 'exp. len act. len' print *, x1%l, len(x1%chr) print *, x2%l, len(x2%chr) print *, x3%l, len(x3%chr) end gives exp. len act. len 4 6 5 6 6 6 but I fail to see the logic: type(pdt_t(1, 4)) :: x1 type(pdt_t(1, 6)) :: x3 type(pdt_t(1, 50)) :: x2 ... print *, x3%l, len(x3%chr) print *, x1%l, len(x1%chr) print *, x2%l, len(x2%chr) gives 6 6 4 6 50 6 ?-( Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 [Bug 82173] [meta-bug] Parameterized derived type errors
[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981
--- Comment #3 from Jakub Jelinek ---
That might not be that easy without repeating there big chunks of internal-fn.c
stuff.
In any case, what is mips64r6 using?
From the above it seems it doesn't have a corresponding optab, so
if (icode == CODE_FOR_nothing)
is true. Thus, is it:
if (GET_MODE_2XWIDER_MODE (mode).exists (&wmode)
&& targetm.scalar_mode_supported_p (wmode))
or
else if (int_mode_for_size (prec / 2, 1).exists (&hmode)
&& 2 * GET_MODE_PRECISION (hmode) == prec)
or the fallback case that doesn't report overflow:
else
{
gcc_assert (!is_ubsan);
ops.code = MULT_EXPR;
ops.type = type;
res = expand_expr_real_2 (&ops, NULL_RTX, mode, EXPAND_NORMAL);
emit_jump (done_label);
}
? If it is the first one from these, perhaps we should have some extra checks
there whether WIDEN_MULT_EXPR will be emitted as a library call or not.
Though, if mips64r6 has hipart multiplication, I don't see why it couldn't
handle the widening multiplication by performing normal DImode multiplication
plus highpart DImode multiplication or something similar.
[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-14 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. The test compiles with '-O2 -fno-tree-forwprop' but not with'-O3 -fno-tree-forwprop'.
[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||jakub at gcc dot gnu.org Target Milestone|--- |7.3 Summary|unnecessary __multi3 call |[7/8 Regression] |for mips64r6 linux kernel |unnecessary __multi3 call ||for mips64r6 linux kernel --- Comment #2 from Richard Biener --- We could also restrict MUL_OVERFLOW pattern matching to archs that can expand it?
[Bug tree-optimization/82977] [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82977 Richard Biener changed: What|Removed |Added Version|7.0 |8.0 Target Milestone|--- |8.0
[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976 Richard Biener changed: What|Removed |Added Version|7.0 |8.0 Target Milestone|--- |8.0
[Bug fortran/82972] [8 Regression] ICE with -finit-derived in gfc_conv_structure, at fortran/trans-expr.c:7733 (and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug other/82965] [8 regression][armeb] gcc.dg/vect/pr79347.c starts failing after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965 Richard Biener changed: What|Removed |Added Target||armeb Target Milestone|--- |8.0
[Bug tree-optimization/82977] [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82977 --- Comment #4 from Jakub Jelinek --- Also, because strlen_to_stridx is only useful if warn_stringop_truncation, I think if it is turned into a pointer to hash_map, then it could be left NULL if !warn_stringop_truncation, and all the strlen_to_stridx related stuff only performed if strlen_to_stridx != NULL.
[Bug tree-optimization/82977] [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82977
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Created attachment 42599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42599&action=edit
gcc8-pr82977.patch
Untested fix. The bug is obvious, hash_map::put does:
bool put (const Key &k, const Value &v)
{
hash_entry *e = m_table.find_slot_with_hash (k, Traits::hash (k),
INSERT);
bool existed = !hash_entry::is_empty (*e);
if (!existed)
e->m_key = k;
e->m_value = v;
return existed;
}
so passing it a reference to a value inside of the hash map is wrong, because
if the hash map needs to be reallocated, it will make the reference refer to
freed memory.
I'll bootstrap/regtest this.
In any case,
static hash_map strlen_to_stridx;
is also wrong because it uselessly requires static initialization. See e.g.
decl_to_stridxlist_htab next to it, that is a pointer to hash_map instead.
[Bug sanitizer/82984] Execuable compiled with ASAN crashes with very limited information on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82984 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-11-14 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please provide steps to reproduce that?
[Bug c++/82985] New: GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82985 Bug ID: 82985 Summary: GCC 7.2.1 crashes when compiling DSO (Direct Sparse Odometry) on Linux Ubuntu 17.10 Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: BlenderEi at LwTV dot de Target Milestone: --- Created attachment 42598 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42598&action=edit Screenshot of the compilation process and the crash of GCC Hello, this is my first time reporting a bug, so please be patient ;) I came across this bug when trying to compile the Direct Sparse Odometry project for my master thesis (see screenshot). You can find it here: https://github.com/JakobEngel/dso The steps to reproduce the bug are (on Linux, type in console [why am I even telling you that... ;) ]): > git clone https://github.com/JakobEngel/dso.git > sudo apt-get install libsuitesparse-dev libeigen3-dev libboost-all-dev > cd dso > mkdir build > cd build > cmake .. > make -j I was advised to isolate the problem using "C-reduce". I try to do that, but you are probably faster given your experience. Hopefully I can add it to this report, after submitting it. Thank you for your help and great work!
[Bug sanitizer/82984] New: Execuable compiled with ASAN crashes with very limited information on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82984 Bug ID: 82984 Summary: Execuable compiled with ASAN crashes with very limited information on Linux Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: michael_22 at hotmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- I have run into an issue on Linux (RedHat): I have some C++ project compiled with ASAN, the executable crashes with almost nothing useful. The followings are the only stuff collected in ASAN logs: ==33856==ERROR: AddressSanitizer: SEGV on unknown address 0x7ffacd125490 (pc 0x7ffad5d9fa50 bp 0x7ffacd1254d8 sp 0x7ffacb49f228 T7) I also have other cases that only "=" printed in the ASAN log. It is appreciated if someone could suggest me on how to proceed with the debugging. Best regards, Ralph
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #23 from Martin Liška --- (In reply to Markus Trippelsdorf from comment #22) > (In reply to Martin Liška from comment #21) > > (In reply to Markus Trippelsdorf from comment #20) > > > Also happens on X86_64. I can reproduce the issue on gcc67 (Rzyen). > > > > Can you please provide revision and configure flags? Does it happen for the > > same source file? > > Current trunk and yes, it happens for the same source file. > > % ../gcc/configure --disable-libstdcxx-pch --disable-libvtv > --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp > --disable-werror --disable-multilib --enable-languages=c,c++,fortran > --enable-checking=release > > % make -j8 BOOT_CFLAGS="-march=native -O3 -pipe" > STAGE1_CFLAGS="-march=native -O3 -pipe" CFLAGS_FOR_TARGET="-march=native -O3 > -pipe" CXXFLAGS_FOR_TARGET="-march=native -O3 -pipe" profiledbootstrap Thanks. I can confirm it works for me!
