[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-06 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #21 from Eric Gallager --- (In reply to Dennis Wassel from comment #20) > Created attachment 18382 [details] > Preprocessed source (of trunk revision 150835) I can't reproduce this with gcc 7 on my machine, but then again I'm on a different target. Can you still reproduce it?
[Bug bootstrap/8477] autoconf script chooses wrong value for gcc_gxx_include_path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8477 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to julians37 from comment #10) > Configuring with --enable-version-specific-runtime-libs appears to be a > workaround, although I'm a bit unclear on what exactly this flag does. Is this still necessary these days?
[Bug bootstrap/34818] --with-gmp overrides --with-mpfr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34818 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Ben Elliston from comment #1) > I agree with your reasoning for the easy fix. I'll post a patch and we'll > see if it is accepted. Did this happen?
[Bug bootstrap/38667] gcc 4.3.2 build fails to create/link libgcc in SLES9 32-bit platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38667 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-06 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Eric Gallager --- Is this still an issue with newer GCC?
[Bug fortran/82721] [7/8/9 Regression] Error message with corrupted text, sometimes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
Severity|normal |minor
--- Comment #6 from Eric Gallager ---
(In reply to kargl from comment #5)
>
> So, I looked at this on my i586-*-freebsd system. Internal state seems
> to be corrupted. The problem can be avoided by the following patch
>
> Index: resolve.c
> ===
> --- resolve.c (revision 260808)
> +++ resolve.c (working copy)
> @@ -2937,16 +2937,23 @@ is_external_proc (gfc_symbol *sym)
> /* Figure out if a function reference is pure or not. Also set the name
> of the function for a potential error message. Return nonzero if the
> function is PURE, zero if not. */
> +
> static int
> pure_stmt_function (gfc_expr *, gfc_symbol *);
>
> static int
> pure_function (gfc_expr *e, const char **name)
> {
> - int pure;
> + int error_count, pure;
>gfc_component *comp;
>
>*name = NULL;
> +
> + /* If gfortran gets here with an issued error and a BT_UNKNOWN type,
> + something has corrupted internal state. Die instead of an ICE. */
> + gfc_get_errors (NULL, _count);
> + if (error_count > 0 && e->ts.type == BT_UNKNOWN)
> +gfc_fatal_error ("Invalid Fortran detected");
>
>if (e->symtree != NULL
> && e->symtree->n.sym != NULL
Please send the patch to gcc-patches for review
[Bug c++/84733] [8/9 Regression] internal compiler error: Segmentation fault (check_local_shadow())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Severity|normal |minor --- Comment #13 from Eric Gallager --- (In reply to Jakub Jelinek from comment #6) > After the change this is only error-recovery it seems, so P4. ...and "minor" too, according to https://gcc.gnu.org/bugs/management.html
[Bug c++/84611] [6/7 Regression] ICE in operator[], at vec.h:826 (local_class_index())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84611 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Severity|normal |minor
[Bug c++/84630] [6/7 Regression] ICE: TYPE_NAME() used on error_mark_node in tsubst_lambda_expr, at cp/pt.c:17141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84630 Eric Gallager changed: What|Removed |Added Severity|normal |minor
[Bug libgcc/62269] m32c-elf libgcc fails to configure- setjmp/longjmp exception check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62269 --- Comment #2 from DJ Delorie --- Sorry for not being as responsive as I should be, but I've tried occasionally to fix the m32c-gcc issues and they just keep getting worse. I suspect m32c should be deprecated at this point, it's not one of of the mcu's Renesas is promoting these days, and there are some unsolveable ICEs building libgcc and newlib. OTOH C++ *is* supported.
[Bug c++/85014] [6/7/8/9 Regression] internal compiler error: in lookup_base, at cp/search.c:185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85014 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Severity|normal |minor
[Bug c++/84730] internal compiler error: Segmentation fault (build_class_member_access_expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84730 Eric Gallager changed: What|Removed |Added Keywords||error-recovery CC||egallager at gcc dot gnu.org Severity|normal |minor
[Bug fortran/52622] heap-use-after-free with instrumented compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622 Eric Gallager changed: What|Removed |Added Keywords||error-recovery CC||egallager at gcc dot gnu.org Severity|normal |minor
[Bug c++/84653] internal compiler error: Segmentation fault (prep_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84653 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Severity|normal |minor
[Bug c++/84652] internal compiler error: in cp_parser_template_id, at cp/parser.c:15860
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84652 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Severity|normal |minor
[Bug c++/84633] internal compiler error: in lvalue_kind, at cp/tree.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84633 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Severity|normal |minor --- Comment #3 from Eric Gallager --- Importance -> minor per https://gcc.gnu.org/bugs/management.html
[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751 Eric Gallager changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code CC||egallager at gcc dot gnu.org, ||paolo.carlini at oracle dot com Severity|normal |minor
[Bug rtl-optimization/63156] web can't handle AUTOINC correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=32339 --- Comment #10 from Eric Gallager --- (In reply to Carrot from comment #9) > > I don't know if this has any relations to bug 32339. Worth putting under "See Also" anyways just in case
[Bug libgcc/62269] m32c-elf libgcc fails to configure- setjmp/longjmp exception check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62269 Eric Gallager changed: What|Removed |Added Keywords||build CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Should DJ Delorie still remain the assignee for this?
[Bug preprocessor/44317] ,##__VA_ARGS__ comma not eaten with -std=c++0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=61389 --- Comment #7 from Eric Gallager --- (In reply to emsr from comment #6) > Created attachment 33119 [details] > Patch to pedwarn. > > This doesn't have the right column pointed out. > Also, the message (and that given by clang) is, in my opinion, obscure. > At least this starts the ball rolling. Please submit the patch to the gcc-patches mailing list for review
[Bug tree-optimization/86010] [7/8/9 Regression] redundant memset with smaller size not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86010 --- Comment #5 from Jeffrey A. Law --- Author: law Date: Fri Jul 6 03:43:42 2018 New Revision: 262464 URL: https://gcc.gnu.org/viewcvs?rev=262464=gcc=rev Log: PR tree-optimization/86010 * tree-ssa-dse.c (compute_trims): More aggressively trim at both the head and tail of mem* and str* calls. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-dse.c
[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817 --- Comment #18 from Anton Maklakov --- Thank you for the answer! I've got. Using the hint after #endif is not pretty good, by the logic. But this is easier.
[Bug tree-optimization/86010] [7/8/9 Regression] redundant memset with smaller size not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86010 --- Comment #4 from Jeffrey A. Law --- Actually, alignment considerations are really just for head trimming. When trimming the tail we can be more aggressive as residuals are usually handled reasonably efficiently.
[Bug tree-optimization/86415] strlen() not folded for substrings within constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00278.html
[Bug middle-end/77357] strlen of constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #5 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00279.html
[Bug tree-optimization/86010] [7/8/9 Regression] redundant memset with smaller size not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86010
--- Comment #3 from Jeffrey A. Law ---
It's not an off by 1 error, but a conscious decision to not pass odd addresses
into the mem* routines, which are typically doing to emit crappy code for badly
aligned data.
We correctly see that 7 bytes of data are live and that we only need a single
byte write for the first memset. One could certainly argue that in the case
were a single byte (or even perhaps up to 3 bytes) are all that's left that we
should do a full trim because the first mem* routine should end up open-coded.
If I hack something like that together we end up with:
MEM[(void *) + 7B] = 0;
__builtin_memset (, 0, 7);
f ();
a ={v} {CLOBBER};
return;
THe fact that the two memset calls use the same value is a testsuite quirk that
would allow this to be further optimized. I'm skeptical that happens often
enough in practice to be worth optimizing. If someone were to want to
optimize that better, I'd think the strlen pass is probably the right place.
[Bug libstdc++/86409] std::stod fails for denormal numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86409 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- This is the behaviour required by the standard, because strtod sets errno to ERANGE.
[Bug libstdc++/85831] types should have move constructors and move assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85831 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #2 from Jonathan Wakely --- .
[Bug libstdc++/85831] types should have move constructors and move assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85831 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Thu Jul 5 21:29:51 2018 New Revision: 262456 URL: https://gcc.gnu.org/viewcvs?rev=262456=gcc=rev Log: PR libstdc++/85831 define move constructors and operators for exceptions PR libstdc++/85831 * config/abi/pre/gnu.ver: Export move constructors and move assignment operators for std::logic_error and std::runtime_error. * include/std/stdexcept: Use _GLIBCXX_NOTHROW instead of _GLIBCXX_USE_NOEXCEPT. (logic_error, runtime_error): Declare move constructors and move assignment operators. When not declared already, define copy constructors and copy assignment operators as explicit-defaulted. (domain_error, invalid_argument, length_error, out_of_range) (overflow_error, underflow_error): Define move constructors and move assignment operators as explicitly-defaulted. * libsupc++/exception.h (exception): Likewise. * src/c++11/cow-stdexcept.cc (logic_error, runtime_error): Define move constructors and move assignment operators as defaulted. * testsuite/19_diagnostics/stdexcept.cc: Check that constructors and assignment operators are defined. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/std/stdexcept trunk/libstdc++-v3/libsupc++/exception.h trunk/libstdc++-v3/src/c++11/cow-stdexcept.cc trunk/libstdc++-v3/testsuite/19_diagnostics/stdexcept.cc
[Bug target/86394] Broken -falign-functions=512 on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86394 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |INVALID --- Comment #1 from Jeffrey A. Law --- No, .align 128 is right AFAICT. .align on the m68k is a byte alignment and requires its argument to be a power of 2.
[Bug libstdc++/86272] [6/7/8/9 Regression] __gnu_debug::string uses undefined __glibcxx_check_insert_range2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86272 --- Comment #8 from François Dumont --- Author: fdumont Date: Thu Jul 5 20:51:27 2018 New Revision: 262455 URL: https://gcc.gnu.org/viewcvs?rev=262455=gcc=rev Log: 2018-07-05 François Dumont Backport from mainline 2018-07-04 François Dumont PR libstdc++/86272 * include/debug/string (__gnu_debug::basic_string<>::insert<_Ite>(const_iterator, _Ite, _Ite)): Use __glibcxx_check_insert_range. Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/debug/string
[Bug tree-optimization/86415] strlen() not folded for substrings within constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-05 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Testing a solution.
[Bug libstdc++/86272] [6/7/8/9 Regression] __gnu_debug::string uses undefined __glibcxx_check_insert_range2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86272 --- Comment #7 from François Dumont --- Author: fdumont Date: Thu Jul 5 20:48:02 2018 New Revision: 262454 URL: https://gcc.gnu.org/viewcvs?rev=262454=gcc=rev Log: 2018-07-05 François Dumont Backport from mainline 2018-07-04 François Dumont PR libstdc++/86272 * include/debug/string (__gnu_debug::basic_string<>::insert<_Ite>(const_iterator, _Ite, _Ite)): Use __glibcxx_check_insert_range. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/debug/string
[Bug tree-optimization/86415] strlen() not folded for substrings within constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415 Martin Sebor changed: What|Removed |Added Summary|TREE_STRING_LENGTH |strlen() not folded for |incorrect for constant |substrings within constant |arrays |arrays --- Comment #1 from Martin Sebor --- Let me change the summary to something less accusatory. I've always interpreted TREE_STRING_LENGTH according to its comment in tree.h: /* In a STRING_CST */ /* In C terms, this is sizeof, not strlen. */ #define TREE_STRING_LENGTH(NODE) (STRING_CST_CHECK (NODE)->string.length) but maybe for constant character arrays it's meant to refer to the result of sizeof(STR) where STR is string literal used to initialize the array and not necessarily to the size of the array.
[Bug fortran/86416] New: [OMPVV SOLLVE] Defaultmap issues on OpenMP 4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416 Bug ID: 86416 Summary: [OMPVV SOLLVE] Defaultmap issues on OpenMP 4.5 Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: josem at udel dot edu Target Milestone: --- Created attachment 44357 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44357=edit Reproducible code Hi everyone, I hope this is useful There are a couple of issues with the default mapping of scalar values on device offloading of OpenMP 4.5 using gfortran. Please refer to the attached reproducible in which I have added #ifdef segments to separate one issue from the other one. I tried two different systems: power8 and Intel. And two versions of GCC 7.1.1 and 8.1.0 > gcc -v #system1 GCC 8.1.0 > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=path/to/gcc/8.1/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper > OFFLOAD_TARGET_NAMES=nvptx-none > Target: x86_64-pc-linux-gnu > Configured with: ../gcc_8_1_0_release/configure > --enable-offload-targets=nvptx-none > --with-cuda-driver-include=/software/apps/cuda/9.2/include/ > --with-cuda-driver-lib=/software/apps/cuda/9.2/lib64/ --disable-bootstrap > --disable-multilib --enable-languages=c,c++,fortran,lto > --prefix=/software/apps/gcc/8.1 > Thread model: posix > gcc version 8.1.0 (GCC) > gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/path/to/gcc/7.1.1-20170802/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/7.1.1/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none Target: powerpc64le-unknown-linux-gnu Configured with: ../gcc/configure --enable-offload-targets=nvptx-none --with-cuda-driver-include=/path/to/cuda/8.0.54/include --with-cuda-driver-lib=/path/to/cuda/8.0.54/lib64 --with-cuda-driver=/path/to/cuda/8.0.54 --disable-bootstrap --disable-multilib --enable-languages=c,c++,fortran,lto --prefix=/path/to/gcc/7.1.1-svn250293-20170802/install Thread model: posix gcc version 7.1.1 20170718 (GCC) The problems: 1. DOUBLE COMPLEX values produce a compiler LTO error: Compilation command: > gfortran -DDOUBLE_COMPLEX -fopenmp -foffload="-lm" -lm > gcc_defaultmap_doublecomplex.F90 -o gcc_defaultmap_doublecomplex.o Compilation output error: > lto1: fatal error: unsupported mode TF > > compilation terminated. > mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 > exit status > compilation terminated. > lto-wrapper: fatal error: > /path/to/gcc/x86_64-pc-linux-gnu/8.1.0/accel/nvptx-none/mkoffload returned 1 > exit status > compilation terminated. > /usr/bin/ld: lto-wrapper failed > collect2: error: ld returned 1 exit status 2. CHARACTER default mapping not correct according to the specs. When mapping a CHARACTER type variable by default, it is doing tofrom, even though that it should be firstprivatized Compiling the reproducible with the following line: > gfortran -fopenmp -foffload="-lm" -lm gcc_defaultmap_doublecomplex.F90 -o > gcc_defaultmap_doublecomplex.F90.o And running it yields to: > The value of scalar_char changed and it should not have Thanks and have a good day.
[Bug tree-optimization/86415] New: TREE_STRING_LENGTH incorrect for constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415
Bug ID: 86415
Summary: TREE_STRING_LENGTH incorrect for constant arrays
Product: gcc
Version: 9.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: ---
While testing a solution to bug 77357 I noticed that GCC fails to fold strlen()
calls with constant char array arguments initialized by constant strings with
an offset that's past the terminating NUL character unless the elements past
the NUL are initialized explicitly as opposed to implicitly. I tracked it down
to the c_getstr() function which normally returns a pointer to the string at
the offset. The function uses TREE_STRING_LENGTH() to obtain the size of the
string (i.e., the result of the sizeof(str) expression, as it should) but the
macro returns the length of the string rather than its size.
$ cat d.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout d.c
const char a[7] = "123\000\000\000";
int f (void)
{
return __builtin_strlen (a + 5); // folded
}
const char b[7] = "123";
int g (void)
{
return __builtin_strlen (b + 5); // not folded
}
;; Function f (f, funcdef_no=0, decl_uid=1899, cgraph_uid=1, symbol_order=1)
f ()
{
[local count: 1073741825]:
return 0;
}
;; Function g (g, funcdef_no=1, decl_uid=1903, cgraph_uid=2, symbol_order=3)
g ()
{
long unsigned int _1;
int _3;
[local count: 1073741825]:
_1 = __builtin_strlen ([(void *) + 5B]);
_3 = (int) _1;
return _3;
}
[Bug c/86414] New: AIX generates wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414 Bug ID: 86414 Summary: AIX generates wrong Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: carll at gcc dot gnu.org Target Milestone: --- The generated code for test cases gcc/testsuite/gcc.target/powerpc/divkc3-2.c gcc/testsuite/gcc.target/powerpc/divkc3-3.c gcc/testsuite/gcc.target/powerpc/mulkc3-2.c gcc/testsuite/gcc.target/powerpc/mulkc3-3.c make a call to the DC mode routine not the expected KC mode routine when compiled on AIX. Specifically on gcc119, with GCC mainline revision 262441 gcc -S -O2 -mpower8-vector -mabi=ieeelongdouble -Wno-psabi divkc3-2.c more divkc3-2.s .file "divkc3-2.c" .toc .csect .text[PR] .align 2 .align 4 .globl divide .globl .divide .csect divide[DS] divide: .long .divide, TOC[tc0], 0 .csect .text[PR] .divide: mflr 0 stw 31,-4(1) lfd 4,8(5) stw 0,8(1) lfd 3,0(5) mr 31,3 stwu 1,-80(1) lfd 2,8(4) lfd 1,0(4) bl .__divdc3 <<< Expected to see .__difkc3 The generated code for the other test files fail similarly on AIX.
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #13 from Paul Thomas --- Created attachment 44356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44356=edit Fix for the new problem? Hi Rainer, Does the attachment fix the problem? Cheers Paul
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 --- Comment #12 from janus at gcc dot gnu.org --- (In reply to Paul Thomas from comment #11) > Thanks for the heads up Janus. Thanks for the extremely quick fix, Paul! I often wish commercial vendors would even get close to gfortran's turnaround time ...
[Bug ipa/86395] add support of -fopt-info-inline in early inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86395 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Richard Biener from comment #1) > Confirmed. It looks like the inliner _completely_ lacks opt-info reporting. > > A good starting point is to amend the places we use OPT_Winline to report > missed inlinings with MSG_MISSED_OPTIMIZATION. Amend as in replace or amend as in add in addition to?
[Bug libstdc++/58265] [lwg/2063] std::string move assignment should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265 --- Comment #14 from Jonathan Wakely --- Author: redi Date: Thu Jul 5 17:03:05 2018 New Revision: 262447 URL: https://gcc.gnu.org/viewcvs?rev=262447=gcc=rev Log: PR libstdc++/58265 add noexcept to basic_string::assign(basic_string&&) PR libstdc++/58265 * include/bits/basic_string.h [!_GLIBCXX_USE_CXX11_ABI] (basic_string::assign(basic_string&&)): Add conditional noexcept depending on the allocator's is_always_equal property (LWG 2063). * testsuite/21_strings/basic_string/modifiers/assign/char/ move_assign.cc: Check for non-throwing exception specification. * testsuite/21_strings/basic_string/modifiers/assign/wchar_t/ move_assign.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/move_assign.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/move_assign.cc
[Bug demangler/85304] Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85304 Carlo B. changed: What|Removed |Added CC||castro8583bennett at gmx dot com --- Comment #2 from Carlo B. --- Hello Michael, any update for this issue? or do we have other sources to make it fixed? Thanks Castro B. https://alternatives.co/
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 86400, which changed state. Bug 86400 Summary: set::sethttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=86400 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/86400] set::set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86400 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[8/9 regression]|set::set::set --- Fixed on trunk (9.0) and 8.2.0.
[Bug tree-optimization/86400] [8/9 regression] set::set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86400 --- Comment #11 from Martin Sebor --- Author: msebor Date: Thu Jul 5 16:42:50 2018 New Revision: 262446 URL: https://gcc.gnu.org/viewcvs?rev=262446=gcc=rev Log: Backport from trunk. PR tree-optimization/86400 - set::set
[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817
--- Comment #17 from Jakub Jelinek ---
(In reply to Anton Maklakov from comment #16)
> Hi,
>
> I have the same problem:
>
>
> int main() {
> int s = 1;
>
> switch (s) {
> case 2:
> s = 2;
> #if B
> break;
> #else
> s = 4;
> /* falls through */
> #endif
> case 3:
That works as documented:
'The comment needs to be followed after optional whitespace and other comments
by "case" or "default" keywords or by a user label that precedes some "case" or
"default" label.'
So, either do what you've mentioned, or just move the comment right before the
case, where it is recognized (and not anywhere else).
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Paul Thomas --- Thanks for the heads up Janus. Paul
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 --- Comment #10 from Paul Thomas --- Author: pault Date: Thu Jul 5 16:27:38 2018 New Revision: 262445 URL: https://gcc.gnu.org/viewcvs?rev=262445=gcc=rev Log: 2018-07-05 Paul Thomas PR fortran/86408 * resolve.c.c (resolve_contained_fntype): Reference to C418 is in F2008 and not F2003. (resolve_function): Ditto in error message. Also, exclude deferred character length results from the error. 2018-07-05 Paul Thomas PR fortran/86408 * gfortran.dg/deferred_character_20.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_20.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817
Anton Maklakov changed:
What|Removed |Added
CC||antmak.pub at gmail dot com
--- Comment #16 from Anton Maklakov ---
Hi,
I have the same problem:
int main() {
int s = 1;
switch (s) {
case 2:
s = 2;
#if B
break;
#else
s = 4;
/* falls through */
#endif
case 3:
s = 3;
}
}
It appears
prog.c: In function 'main':
prog.c:11:15: warning: this statement may fall through
[-Wimplicit-fallthrough=]
s = 4;
~~^~~
prog.c:14:9: note: here
case 3:
^~~~
At the moment I use a workaround:
#if (__GNUC__ >= 7)
#define FALLTHROUGH __attribute__ ((fallthrough));
#else
#define FALLTHROUGH
#endif
int main() {
int s = 1;
switch (s) {
case 2:
s = 2;
#if B
break;
#else
s = 4;
FALLTHROUGH
#endif
case 3:
s = 3;
}
}
This code is based on the real code from libexpat
[Bug gcov-profile/86411] Some lines are considered as uncoverable when using __gcov_flush
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86411 Marco Castelluccio changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Marco Castelluccio --- Oh, I wasn't aware of that.
[Bug gcov-profile/86411] Some lines are considered as uncoverable when using __gcov_flush
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86411 --- Comment #3 from Andrew Pinski --- (In reply to Marco Castelluccio from comment #2) > Line 14 and line 16 should be "#" (not covered), instead they are "-" > (not coverable, a line not containing any code). I don't see a problem with lines 14 and 16 as not being coverable as _exit is marked as noreturn so they can never be executed (coverable).
[Bug gcov-profile/86411] Some lines are considered as uncoverable when using __gcov_flush
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86411 --- Comment #2 from Marco Castelluccio --- Line 14 and line 16 should be "#" (not covered), instead they are "-" (not coverable, a line not containing any code).
[Bug c/86407] Ignore function attributes in function type declarations?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86407
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3 from Martin Sebor ---
The warning could be suppressed by pragma diagnostic around the typedef like
so:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wattributes"
typedef DWORD (WINAPI *APPLICATION_RECOVERY_CALLBACK)(PVOID);
#pragma GCC diagnostic pop
Unfortunately, it doesn't look like it's possible to include the pragmas (in
the form of _Pragma("GCC diagnostic pop")) as part of the typedef itself and
have them have the same effect.
[Bug gcov-profile/86411] Some lines are considered as uncoverable when using __gcov_flush
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86411 --- Comment #1 from Andrew Pinski --- I think this is working as designed. You explictly flushed the gcov buffers; therefor it is not going to be flushed again.
[Bug libstdc++/58265] [lwg/2063] std::string move assignment should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265 --- Comment #13 from Jonathan Wakely --- Now also fixed for COW strings.
[Bug libstdc++/58265] [lwg/2063] std::string move assignment should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Thu Jul 5 15:56:06 2018 New Revision: 262443 URL: https://gcc.gnu.org/viewcvs?rev=262443=gcc=rev Log: PR libstdc++/58265 implement LWG 2063 for COW strings For COW strings the default constructor does not allocate when _GLIBCXX_FULLY_DYNAMIC_STRING == 0, so can be noexcept. The move constructor and swap do not allocate when the allocators are equal, so add conditional noexcept using allocator_traits::is_always_equal. PR libstdc++/58265 * include/bits/basic_string.h [!_GLIBCXX_USE_CXX11_ABI] [_GLIBCXX_FULLY_DYNAMIC_STRING==0] (basic_string::basic_string()): Add GLIBCXX_NOEXCEPT. (basic_string::operator=(basic_string&&)): Add _GLIBCXX_NOEXCEPT_IF to depend on the allocator's is_always_equal property (LWG 2063). (basic_string::swap(basic_string&)): Likewise. * include/bits/basic_string.tcc [!_GLIBCXX_USE_CXX11_ABI] (basic_string::swap(basic_string&)): Likewise. * testsuite/21_strings/basic_string/allocator/char/move_assign.cc: Check is_nothrow_move_assignable. * testsuite/21_strings/basic_string/allocator/wchar_t/move_assign.cc: Check is_nothrow_move_assignable. * testsuite/21_strings/basic_string/cons/char/ noexcept_move_construct.cc: Likewise. * testsuite/21_strings/basic_string/cons/wchar_t/ noexcept_move_construct.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/basic_string.tcc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/move_assign.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/move_assign.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/noexcept_move_construct.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/cons/wchar_t/noexcept_move_construct.cc
[Bug fortran/83183] Out of memory with option -finit-derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83183 --- Comment #2 from Fritz Reese --- Author: foreese Date: Thu Jul 5 15:39:27 2018 New Revision: 262442 URL: https://gcc.gnu.org/viewcvs?rev=262442=gcc=rev Log: 2018-07-05 Fritz Reese gcc/fortran/ChangeLog: PR fortran/83183 PR fortran/86325 * expr.c (class_allocatable, class_pointer, comp_allocatable, comp_pointer): New helpers. (component_initializer): Generate EXPR_NULL for allocatable or pointer components. Do not generate initializers for components within BT_CLASS. Do not assign to comp->initializer. (gfc_generate_initializer): Use new helpers; move code to generate EXPR_NULL for class allocatable components into component_initializer(). gcc/testsuite/ChangeLog: PR fortran/83183 PR fortran/86325 * gfortran.dg/init_flag_18.f90: New testcase. * gfortran.dg/init_flag_19.f03: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90 trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/86325] Error on valid code with pointer class components using -finit-derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86325 --- Comment #1 from Fritz Reese --- Author: foreese Date: Thu Jul 5 15:39:27 2018 New Revision: 262442 URL: https://gcc.gnu.org/viewcvs?rev=262442=gcc=rev Log: 2018-07-05 Fritz Reese gcc/fortran/ChangeLog: PR fortran/83183 PR fortran/86325 * expr.c (class_allocatable, class_pointer, comp_allocatable, comp_pointer): New helpers. (component_initializer): Generate EXPR_NULL for allocatable or pointer components. Do not generate initializers for components within BT_CLASS. Do not assign to comp->initializer. (gfc_generate_initializer): Use new helpers; move code to generate EXPR_NULL for class allocatable components into component_initializer(). gcc/testsuite/ChangeLog: PR fortran/83183 PR fortran/86325 * gfortran.dg/init_flag_18.f90: New testcase. * gfortran.dg/init_flag_19.f03: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/init_flag_18.f90 trunk/gcc/testsuite/gfortran.dg/init_flag_19.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug debug/86413] New: [9 regression] gcc.dg/guality/pr48437.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86413 Bug ID: 86413 Summary: [9 regression] gcc.dg/guality/pr48437.c fail Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r261748 triggers this: spawn gdb -nx -nw -quiet -batch -x pr48437.gdb ./pr48437.exe FAIL: gcc.dg/guality/pr48437.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 14 i == 0 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 fortran/82009] [F08] ICE with block construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009
--- Comment #10 from Jerry DeLisle ---
In the tree dump, the declaration for idxs is missing for the first subroutine.
I have modified to the following example so one can see it is not symbol name
conflicts.
MODULE sparse_matrix_csx_benchmark_utils
IMPLICIT NONE
CONTAINS
SUBROUTINE sparse_matrix_csr_benchmark ( )
WRITE(*,*) 'At*x: t1'
block
integer, dimension(1), parameter :: idxs1=[1]
integer :: i, idx
do i = 1, size(idxs1)
idx = idxs1(i)
enddo
end block
END SUBROUTINE sparse_matrix_csr_benchmark
SUBROUTINE sparse_matrix_csc_benchmark ( )
WRITE(*,*) 'An*x: t2'
block
integer, dimension(1), parameter :: idxs2=[1]
integer :: i, idx
do i = 1, size(idxs2)
idx = idxs2(i)
enddo
end block
END SUBROUTINE sparse_matrix_csc_benchmark
END MODULE sparse_matrix_csx_benchmark_utils
program main
use sparse_matrix_csx_benchmark_utils
call sparse_matrix_csr_benchmark ()
call sparse_matrix_csc_benchmark ()
end program
and the tree dump:
sparse_matrix_csc_benchmark ()
{
{
integer(kind=4) i;
integer(kind=4) idx;
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = &"pr82009.f03"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 15;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (_parm.0);
_gfortran_transfer_character_write (_parm.0, &"An*x: t2"[1]{lb: 1 sz:
1}, 8);
_gfortran_st_write_done (_parm.0);
}
i = 1;
while (1)
{
{
logical(kind=4) D.3777;
D.3777 = i > 1;
if (D.3777) goto L.3;
idx = idxs2[(integer(kind=8)) i + -1];
L.2:;
i = i + 1;
}
}
L.3:;
L.1:;
}
}
sparse_matrix_csr_benchmark ()
{
{
static integer(kind=4) idxs2[1] = {1};
integer(kind=4) i;
integer(kind=4) idx;
{
struct __st_parameter_dt dt_parm.1;
dt_parm.1.common.filename = &"pr82009.f03"[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 5;
dt_parm.1.common.flags = 128;
dt_parm.1.common.unit = 6;
_gfortran_st_write (_parm.1);
_gfortran_transfer_character_write (_parm.1, &"At*x: t1"[1]{lb: 1 sz:
1}, 8);
_gfortran_st_write_done (_parm.1);
}
i = 1;
while (1)
{
{
logical(kind=4) D.3786;
D.3786 = i > 1;
if (D.3786) goto L.6;
idx = idxs1[(integer(kind=8)) i + -1];
L.5:;
i = i + 1;
}
}
L.6:;
L.4:;
}
}
MAIN__ ()
{
sparse_matrix_csr_benchmark ();
sparse_matrix_csc_benchmark ();
}
__attribute__((externally_visible))
main (integer(kind=4) argc, character(kind=1) * * argv)
{
static integer(kind=4) options.2[7] = {2116, 4095, 0, 1, 1, 0, 31};
_gfortran_set_args (argc, argv);
_gfortran_set_options (7, [0]);
MAIN__ ();
return 0;
}
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #9 from janus at gcc dot gnu.org --- (In reply to Paul Thomas from comment #8) > > A fix is regtesting as I write. > > ...which is pretty much that of comment #2, except that it is applied to the > result. Good point :) Thanks a bunch!
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 --- Comment #8 from Paul Thomas --- (In reply to Paul Thomas from comment #7) > A fix is regtesting as I write. > > Paul ...which is pretty much that of comment #2, except that it is applied to the result. Paul
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-05 Known to work||8.1.0 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #6 from Dominique d'Humieres --- Confirmed.
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 Paul Thomas changed: What|Removed |Added Last reconfirmed|2018-07-05 00:00:00 | Known to work|8.1.0 | Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Known to fail|9.0 | --- Comment #7 from Paul Thomas --- A fix is regtesting as I write. Paul
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 --- Comment #5 from janus at gcc dot gnu.org --- Hi Paul, thanks for your comments! (In reply to paul.richard.tho...@gmail.com from comment #4) > I see two problems with my patch for PR49630. > > (i) It was F2008, not F2003. I see :) Already suspected something like that .. > (ii) More importantly, I should have excluded deferred character > length from this treatment. Right. If you agree that my patch in comment #2 is sufficient to fix this, I'll commit this to trunk after regtesting, possibly with a modification of the error wording (F03->F08). Or do you prefer to take care of this yourself?
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 --- Comment #4 from paul.richard.thomas at gmail dot com --- Hi Janus, I see two problems with my patch for PR49630. (i) It was F2008, not F2003. Bottom of page 535: C418 (R420 R421 R422) A type-param-value of * shall be used only • to declare a dummy argument, • to declare a named constant, • in the type-spec of an ALLOCATE statement wherein each allocate-object is a dummy argument of type CHARACTER with an assumed character length, • in the type-spec or derived-type-spec of a type guard statement (8.1.9), or • in an external function, to declare the character length parameter of the function result . (ii) More importantly, I should have excluded deferred character length from this treatment. I'm onto it. Paul On Thu, 5 Jul 2018 at 08:56, janus at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 > > janus at gcc dot gnu.org changed: > >What|Removed |Added > >Keywords||rejects-valid > CC||pault at gcc dot gnu.org >See Also||https://gcc.gnu.org/bugzill >||a/show_bug.cgi?id=49630 > > --- Comment #1 from janus at gcc dot gnu.org --- > 'svn blame' tells me that the piece of code that throws the error (in > 'resolve_function') was added by Paul in r261868 for PR 49630. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #0) > Moreover the error message does not really match the quoted standard clause > F03:C418, which says: > > "A function name declared with an asterisk type-param-value shall not be an > array, a pointer, recursive, or pure." > > 1) This does not talk about abstract interfaces at all, but functions in > general. > 2) The function in the examples has no asterisk type-param-value. > 3) The function in the example is neither an array, pointer, recursive or > pure. I would say that F03:C417 is more relevant in the context of the check that is being done there: C417 A function name shall not be declared with an asterisk type-param-value unless it is of type CHARACTER and is the name of the result of an external function or the name of a dummy function.
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #0)
> This error is apparently bogus, primarily because 'str' is not
> assumed-length, but deferred-length.
The following should be enough to distinguish deferred and assumed length (and
makes the test case compile):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 262304)
+++ gcc/fortran/resolve.c (working copy)
@@ -3115,7 +3115,7 @@ resolve_function (gfc_expr *expr)
/* If this is a deferred TBP with an abstract interface, its result
cannot be an assumed length character (F2003: C418). */
- if (sym && sym->attr.abstract && sym->attr.function
+ if (sym && sym->attr.abstract && sym->attr.function && !sym->ts.deferred
&& sym->result->ts.u.cl
&& sym->result->ts.u.cl->length == NULL)
{
I am about to regtest this ...
[Bug target/85434] Address of stack protector guard spilled to stack on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434 --- Comment #17 from Thomas Preud'homme --- Patch has been posted for review: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00246.html
[Bug tree-optimization/86400] [8/9 regression] set::set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86400 --- Comment #10 from Martin Sebor --- Author: msebor Date: Thu Jul 5 14:36:09 2018 New Revision: 262438 URL: https://gcc.gnu.org/viewcvs?rev=262438=gcc=rev Log: PR tree-optimization/86400 - set::set
[Bug c/86410] Incorrect init_array ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86410 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- I think the explicit .init_array section marked decls make this undefined as you are doing this behind GCCs back. You might be able to use -fno-toplevel-reorder to save yourself here.
[Bug lto/86412] lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412
Richard Biener changed:
What|Removed |Added
Keywords||ice-checking
Target||x86_64-pc-linux-gnu
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-05
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||6.4.1, 7.3.1, 8.1.1, 9.0
--- Comment #5 from Richard Biener ---
Confirmed everywhere with the reduced testcase (the pasted one misses a line).
We run into
tree
lto_symtab_prevailing_virtual_decl (tree decl)
{
...
gcc_checking_assert (!type_in_anonymous_namespace_p (DECL_CONTEXT (decl))
&& DECL_ASSEMBLER_NAME_SET_P (decl));
where type_in_anonymous_namespace_p (DECL_CONTEXT (decl)) is true.
TYPE_STUB_DECL is
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76a84348
fields
ignored BLK t.C:6:27 size unit-size
align:64 warn_if_not_align:0 offset_align 128
offset
bit-offset context
> context
pointer_to_this chain >
BLK t.C:6:27
align:8 warn_if_not_align:0 context >
[Bug lto/86412] lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412 --- Comment #4 from Ulya --- Just in case, here is the output of the latest crashing 'g++ -v': $ g++ -v Using built-in specs. COLLECT_GCC=/home/ulya/devel/gcc-9-20180701-install/bin/g++ COLLECT_LTO_WRAPPER=/home/ulya/devel/gcc-9-20180701-install/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-9-20180701/configure --prefix=/home/ulya/Downloads/gcc-9-20180701-build/../gcc-9-20180701-install --disable-bootstrap --disable-multilib --disable-multiarch --enable-languages=c++ Thread model: posix gcc version 9.0.0 20180701 (experimental) (GCC)
[Bug lto/86412] lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412 --- Comment #3 from Ulya --- Also, please delete the original file when you download it -- my co-workers are not happy with it being pasted here. :)
[Bug lto/86412] lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412
--- Comment #2 from Ulya ---
Sorry, forgot to paste the last line in the minimal file:
template class a;
template class b;
class c {
virtual bool d();
};
template class e : c {
public:
template e(f);
};
void g() { (e>>(g)); }
[Bug lto/86412] lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412 --- Comment #1 from Ulya --- Created attachment 44355 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44355=edit original reproducer
[Bug lto/86412] New: lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412
Bug ID: 86412
Summary: lto1: internal compiler error: in
lto_symtab_prevailing_virtual_decl, at
lto/lto-symtab.c
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 44354
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44354=edit
minimal reproducer
Minimal reproducer (bug.cpp in attach):
template class a;
template class b;
class c {
virtual bool d();
};
template class e : c {
public:
template e(f);
};
Crash:
$ g++ -flto bug.cpp -O2
lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at
lto/lto-symtab.c:1085
0x741dea lto_symtab_prevailing_virtual_decl(tree_node*)
/usr/src/debug/sys-devel/gcc-8.1.0-r3/gcc-8.1.0/gcc/lto/lto-symtab.c:1084
0x734977 lto_symtab_prevailing_decl(tree_node*)
/usr/src/debug/sys-devel/gcc-8.1.0-r3/gcc-8.1.0/gcc/lto/lto-symtab.h:53
0x734977 lto_fixup_prevailing_decls
/usr/src/debug/sys-devel/gcc-8.1.0-r3/gcc-8.1.0/gcc/lto/lto.c:2678
0x734977 lto_fixup_decls
/usr/src/debug/sys-devel/gcc-8.1.0-r3/gcc-8.1.0/gcc/lto/lto.c:2744
0x734977 read_cgraph_and_symbols
/usr/src/debug/sys-devel/gcc-8.1.0-r3/gcc-8.1.0/gcc/lto/lto.c:2989
0x734977 lto_main()
/usr/src/debug/sys-devel/gcc-8.1.0-r3/gcc-8.1.0/gcc/lto/lto.c:3401
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/86410] Incorrect init_array ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86410 --- Comment #1 from Ismael Ripoll --- The issue has been tested in gcc-4 gcc-5 and gcc-7 It seems that all versions are affected.
[Bug gcov-profile/86411] New: Some lines are considered as uncoverable when using __gcov_flush
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86411
Bug ID: 86411
Summary: Some lines are considered as uncoverable when using
__gcov_flush
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: mcastelluccio at mozilla dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
-:0:Source:main.c
-:0:Graph:main.gcno
-:0:Data:main.gcda
-:0:Runs:1
-:0:Programs:1
-:1:extern void __gcov_flush(void);
-:2:
1:3:void f(int c) {}
-:4:
1:5:int main(int argc, char *argv[]) {
1:6: f(1);
-:7:
1:8: __gcov_flush();
-:9:
#: 10: f(2);
-: 11:
#: 12: _exit(0);
-: 13:
-: 14: f(3);
-: 15:
-: 16: return 0;
-: 17:}
-: 18:
[Bug c/86410] New: Incorrect init_array ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86410 Bug ID: 86410 Summary: Incorrect init_array ordering Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: iripoll at disca dot upv.es Target Milestone: --- Created attachment 44353 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44353=edit Samplig the init, fin, constructor and atexit functions. Hello, While testing the glibc patch of Florian (from Red Hat) to remove some unnecessary code from the executable image, we have found what seems to be a gcc issue. The problem is related to the way the .init_array and .fini_array sections are created. When not using any optimizations the resulting initialization sequence is different (and seems to be incorrect). When using any form of optimization (i.e. -O1 -O2 -O3 -Os) the init sequence is correct. The issue occurs to dynamic and static executables. Attached is a PoC of the problem. The same code results in a different execution when compiled with different flags: When compile with -O2 gcc testing_init_arrays.c -o testing_init_arrays-O2 ./testing_init_arrays-O2 preinit2 preinit1 constructor1 constructor2 init2 init1 Main begins my_atexit2 my_atexit fini1 fini2 destructor When compiled without optimization gcc testing_init_arrays.c -o testing_init_arrays-none ./testing_init_arrays-none preinit1 preinit2 constructor1 init1 init2 constructor2 Main begins my_atexit2 my_atexit destructor fini2 fini1 Regards, Ismael and Hector.
[Bug libstdc++/86409] std::stod fails for denormal numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86409 --- Comment #1 from Ruslan --- I was testing this on Kubuntu 14.04 x86_64 with g++ 8.1.0-5ubuntu1~14.04.
[Bug libstdc++/86409] New: std::stod fails for denormal numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86409
Bug ID: 86409
Summary: std::stod fails for denormal numbers
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: b7.10110111 at gmail dot com
Target Milestone: ---
Consider the following test program:
// BEGIN
#include
#include
int main()
{
const char str[]="3.23534634e-320";
try
{
const auto value=std::stod(str);
std::cout << "stod returned " << value << '\n';
}
catch(std::exception&)
{
std::cerr << "stod failed\n";
}
std::istringstream ss(str);
double value;
ss >> value;
if(ss) std::cout << "istringstream gave " << value << '\n';
else std::cerr << "istringstream failed\n";
}
// END
Here std::stod throws std::out_of_range exception, although the number can be
represented as a denormal in double. std::istringstream works as expected,
reading the denormal into the variable.
[Bug other/86153] [9 regression] test case g++.dg/pr83239.C fails starting with r261585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153 Andrey Guskov changed: What|Removed |Added CC||andrey.y.guskov at intel dot com --- Comment #5 from Andrey Guskov --- Confirmed on Haswell and Silvermont.
[Bug target/84711] AArch32 big-endian fails when taking subreg of a vector mode to a scalar mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84711 --- Comment #13 from Tamar Christina --- Author: tnfchris Date: Thu Jul 5 10:37:36 2018 New Revision: 262436 URL: https://gcc.gnu.org/viewcvs?rev=262436=gcc=rev Log: Fix can_change_mode_class for big-endian on Arm gcc/ PR target/84711 * config/arm/arm.c (arm_can_change_mode_class): Use GET_MODE_UNIT_SIZE instead of GET_MODE_SIZE when comparing Units. gcc/testsuite/ PR target/84711 * gcc.target/arm/big-endian-subreg.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/big-endian-subreg.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug target/84711] AArch32 big-endian fails when taking subreg of a vector mode to a scalar mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84711 --- Comment #12 from Tamar Christina --- Author: tnfchris Date: Thu Jul 5 10:35:00 2018 New Revision: 262435 URL: https://gcc.gnu.org/viewcvs?rev=262435=gcc=rev Log: Correct subreg no-op handling for big-endian vec_select. gcc/ PR target/84711 * rtlanal.c (set_noop_p): Constrain on mode change, include hard-reg-set.h gcc/testuite/ PR target/84711 * gcc.dg/vect/pr84711.c: New. Added: trunk/gcc/testsuite/gcc.dg/vect/pr84711.c Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/84250] Symbol collision when using both Address and Undefined Behavior sanitizers (-fsanitize=address,undefined)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84250 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Jul 5 09:47:05 2018 New Revision: 262433 URL: https://gcc.gnu.org/viewcvs?rev=262433=gcc=rev Log: Revert 2018-07-04 Maxim Ostapenko PR sanitizer/84250 * config/gnu-user.h (LIBASAN_EARLY_SPEC): Pass -lstdc++ for static libasan. * gcc.c: Do not pass LIBUBSAN_SPEC if ASan is enabled with UBSan. * Makefile.am: Reorder libs. * Makefile.in: Regenerate. * asan/Makefile.am: Define DCAN_SANITIZE_UB=1, add dependancy from libsanitizer_ubsan.la. * asan/Makefile.in: Regenerate. * ubsan/Makefile.am: Define new libsanitizer_ubsan.la library. * ubsan/Makefile.in: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/gnu-user.h trunk/gcc/gcc.c trunk/libsanitizer/ChangeLog trunk/libsanitizer/Makefile.am trunk/libsanitizer/Makefile.in trunk/libsanitizer/asan/Makefile.am trunk/libsanitizer/asan/Makefile.in trunk/libsanitizer/ubsan/Makefile.am trunk/libsanitizer/ubsan/Makefile.in
[Bug c/86407] Ignore function attributes in function type declarations?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86407 --- Comment #2 from Zebediah Figura --- (In reply to Richard Biener from comment #1) > Not possible without creating a sub-option for the warning I guess. But if > the attribute is a semantic one then it should be a type attribute rather > than a decl one. It doesn't affect the caller at all (although, then again, neither does __force_align_arg_pointer__).
[Bug c/86407] Ignore function attributes in function type declarations?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86407 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target||x86_64-*-*, i?86-*-* --- Comment #1 from Richard Biener --- Not possible without creating a sub-option for the warning I guess. But if the attribute is a semantic one then it should be a type attribute rather than a decl one.
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |9.0
[Bug sanitizer/86406] [8/9 Regression][UBSAN] -fcompare-debug failure with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86406 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.2
[Bug testsuite/86405] UNRESOLVED bb-slp-over-widen-1.c and -2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86405 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from Richard Biener --- (In reply to Martin Sebor from comment #0) > I see the unexpected UNRESOLVED results for the > gcc.dg/vect/bb-slp-over-widen-1.c and -2.c tests in my builds on > x86_64-linux builds running Fedora 25. The results reported on > gcc-testresults for the same target (but possibly different OS) don't show > these tests as UNRESOLVED. > > PASS: gcc.dg/vect/bb-slp-over-widen-1.c execution test > PASS: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump slp2 "demoting int to > signed short" > PASS: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump slp2 "demoting int to > unsigned short" > gcc.dg/vect/bb-slp-over-widen-1.c: dump file does not exist > UNRESOLVED: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump-times vect > "basic block vectorized" 2 the last should also scan "slp2"
[Bug gcov-profile/86404] UNRESOLVED/UNSUPPORTED gcov test results due to Permission error mapping pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86404 --- Comment #3 from Richard Biener --- I think these are known and I've seen those even with -j6 on older kernels.
[Bug fortran/86408] [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||pault at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=49630 --- Comment #1 from janus at gcc dot gnu.org --- 'svn blame' tells me that the piece of code that throws the error (in 'resolve_function') was added by Paul in r261868 for PR 49630.
[Bug fortran/86408] New: [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86408 Bug ID: 86408 Summary: [9 Regression] bogus error: ABSTRACT INTERFACE must not have an assumed character length result (F2003: C418) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Test case: module m implicit none type, abstract :: t contains procedure(ifc), deferred :: tbf procedure :: tbs end type abstract interface function ifc(x) result(str) import :: t class(t) :: x character(len=:), allocatable :: str end function end interface contains subroutine tbs(x) class(t) :: x print *, x%tbf() end subroutine end This example (which I'd say is perfectly valid code), compiles well with gfortran 8 (and ifort/pgfortran/flang), but is rejected by recent trunk builds with: function ifc(x) result(str) 1 Error: ABSTRACT INTERFACE ‘ifc’ at (1) must not have an assumed character length result (F2003: C418) This error is apparently bogus, primarily because 'str' is not assumed-length, but deferred-length. Moreover the error message does not really match the quoted standard clause F03:C418, which says: "A function name declared with an asterisk type-param-value shall not be an array, a pointer, recursive, or pure." 1) This does not talk about abstract interfaces at all, but functions in general. 2) The function in the examples has no asterisk type-param-value. 3) The function in the example is neither an array, pointer, recursive or pure.
[Bug tree-optimization/86400] [8/9 regression] set::set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86400
--- Comment #9 from rguenther at suse dot de ---
On Thu, 5 Jul 2018, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86400
>
> Martin Sebor changed:
>
>What|Removed |Added
>
>Keywords||wrong-code
> Status|NEW |ASSIGNED
> Blocks||83819
>Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
> gnu.org
>
> --- Comment #7 from Martin Sebor ---
> Confirmed. The strlen pass sees:
>
> static char root[1][2] = {"/"};
> ...
> _1 = __builtin_strlen ();
>
>
> but the code in maybe_set_strlen_range() assumes the argument has the correct
> type (i.e., char*, not char[][2])
But the address of an array type is a pointer to an array type
in GENERIC.
> and uses TYPE_DOMAIN to determine the upper
> bound of the array which returns the bound of the outer array in this case.
> Using TYPE_SIZE instead avoids the problem:
>
> Index: gcc/tree-ssa-strlen.c
> ===
> --- gcc/tree-ssa-strlen.c (revision 262418)
> +++ gcc/tree-ssa-strlen.c (working copy)
> @@ -1156,22 +1156,17 @@ maybe_set_strlen_range (tree lhs, tree src, tree b
>if (src_is_array && !array_at_struct_end_p (src))
> {
> tree type = TREE_TYPE (src);
> - if (tree dom = TYPE_DOMAIN (type))
> - {
> - tree maxval = TYPE_MAX_VALUE (dom);
> - if (maxval)
> - max = wi::to_wide (maxval);
> - else
> - max = wi::zero (min.get_precision ());
> + if (tree size = TYPE_SIZE_UNIT (type))
That should indeed include sub-dimensions. Note the above
is only correct if BITS_PER_UNIT == CHAR_TYPE_SIZE (we probably
do not have any target where that isn't true).
> + if (size && TREE_CODE (size) == INTEGER_CST)
> + max = wi::to_wide (size);
>
> - /* For strlen() the upper bound above is equal to
> -the longest string that can be stored in the array
> -(i.e., it accounts for the terminating nul. For
> -strnlen() bump up the maximum by one since the array
> -need not be nul-terminated. */
> - if (bound)
> - ++max;
> - }
> + /* For strlen() the upper bound above is equal to
> +the longest string that can be stored in the array
> +(i.e., it accounts for the terminating nul. For
> +strnlen() bump up the maximum by one since the array
> +need not be nul-terminated. */
> + if (!bound && max != 0)
> + --max;
> }
>else
> {
>
>
> Referenced Bugs:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
> [Bug 83819] [meta-bug] missing strlen optimizations
>
