[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #52 from David Malcolm --- (In reply to Manuel López-Ibáñez from comment #51) > 1. C++ does not work C++ should be fixed for gcc 9 by r264887.
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #53 from David Malcolm --- (In reply to Manuel López-Ibáñez from comment #51) > 2. Locations within strings expanded from a macro (2) should also be fixed for gcc 9 by r264887: /tmp/foo.c: In function ‘foo’: /tmp/foo.c:2:25: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘double’ [-Wformat=] 2 | #define c " %d %d " | ^ /tmp/foo.c:3:20: note: in expansion of macro ‘c’ 3 | __builtin_printf(c, 0.5, 0); |^ /tmp/foo.c:2:28: note: format string is defined here 2 | #define c " %d %d " | ~^ || |int | %f /tmp/foo.c:6:20: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘double’ [-Wformat=] 6 | __builtin_printf(a, 0.5); |^ ~~~ | | | double (same output for both C and C++) > 3. Location within strings from a const char array. (3) isn't yet fixed, as can be seen above.
[Bug fortran/84640] gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x0000090de160 overflowed to 0xffffffffc0632960
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84640 --- Comment #8 from Thomas Koenig --- Author: tkoenig Date: Sat Oct 6 11:45:05 2018 New Revision: 264898 URL: https://gcc.gnu.org/viewcvs?rev=264898=gcc=rev Log: 2018-10-06 Thomas Koenig PR fortran/84640 * simplify.c (gfc_simplify_cshift): Extend size of hs_ex and ss_ex by one. Set extents one past the array boundaries to zero to avoid warning with instrumented compiler. (gfc_simplify_eoshift): Likewise, only for ss_ex. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 65677, which changed state. Bug 65677 Summary: Incomplete assignment on deferred-length character variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/65677] Incomplete assignment on deferred-length character variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Thomas Koenig --- Also fixed. At this rate, you'll be running out of deferred character bugs to fix :-)
[Bug fortran/65677] Incomplete assignment on deferred-length character variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677 --- Comment #8 from paul.richard.thomas at gmail dot com --- I am trying to run out. I was stung by some of the comments in the standards survey about quality of implementation in all brands. This came out as one of the worst for gfortran so I decided to set about fixing it :-) This version of PR87151 is turning out to be the hardest. module bvec type, public :: bvec_t private character(:), dimension(:), allocatable :: vc contains PROCEDURE, PASS :: create PROCEDURE, PASS :: delete end type bvec_t contains subroutine create(this) class(bvec_t), intent(inout) :: this allocate(character(2)::this%vc(3)) if (len (this%vc) .ne. 2) stop 1 if (size (this%vc) .ne. 3) stop 2 end subroutine create subroutine delete(this) class(bvec_t), intent(inout) :: this if (allocated (this%vc)) then print *, "> ", this%vc(2) if (size (this%vc) .ne. 3) stop 4 deallocate (this%vc) endif end subroutine delete end module bvec program test use bvec type(bvec_t) :: a call a%create() call a%delete() end program test Paul On Sat, 6 Oct 2018 at 13:05, tkoenig at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65677 > > Thomas Koenig changed: > >What|Removed |Added > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #7 from Thomas Koenig --- > Also fixed. > > At this rate, you'll be running out of deferred character bugs > to fix :-) > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug c++/87539] internal compiler error when compiling project with Os optimization flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87539 --- Comment #1 from r4sas --- Created attachment 44798 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44798=edit compressed preprocessed file
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 84640, which changed state. Bug 84640 Summary: gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x090de160 overflowed to 0xc0632960 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84640 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/84640] gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x0000090de160 overflowed to 0xffffffffc0632960
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84640 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Thomas Koenig --- Fixed, closing.
[Bug fortran/83999] [8/9 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- Created attachment 44799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44799=edit Patch for the PR For some reason, I do not see the problem on the current 8-branch. In fact, it comes up with the correct error, even though this patch has not been applied! I will apply to both branches as a belt-and-braces fix :-) Cheers Paul
[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54429 --- Comment #10 from Oleg Endo --- (In reply to Eric Gallager from comment #9) > (In reply to Oleg Endo from comment #8) > > BTW, the problem is also there when using LRA. > > Is this still the case? Just checked it on trunk. Yes, nothing has changed.
[Bug fortran/84109] ICE in adjustl on allocatable array of strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84109 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Thomas Koenig --- I think this one is fixed now. Thanks Paul!
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 84109, which changed state. Bug 84109 Summary: ICE in adjustl on allocatable array of strings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84109 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/87239] ICE in deferred-length string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87239 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Thomas Koenig --- Also fixed. Thanks!
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 87239, which changed state. Bug 87239 Summary: ICE in deferred-length string https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87239 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/72709] Incorrect assignment of allocatable character array used as component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72709 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Thomas Koenig --- Also fixed.
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 72709, which changed state. Bug 72709 Summary: Incorrect assignment of allocatable character array used as component of derived type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72709 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/83999] [8/9 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 --- Comment #8 from Thomas Koenig --- For some reason, the array spec is not set for the symbol for z1.f90: (gdb) p sym->as $11 = (gfc_array_spec *) 0x0 (gdb) p sym->name $12 = 0x7734d0b8 "f" (with a breakpoint in resolve_fl_procedure).
[Bug fortran/84109] ICE in adjustl on allocatable array of strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84109 --- Comment #7 from paul.richard.thomas at gmail dot com --- Hi Thomas, I am going to apply a cumulative deferred character patch to 8-branch just as soon as the dust has settled on trunk. Cheers Paul On Sat, 6 Oct 2018 at 12:56, tkoenig at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84109 > > Thomas Koenig changed: > >What|Removed |Added > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #6 from Thomas Koenig --- > I think this one is fixed now. Thanks Paul! > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug c++/87539] New: internal compiler error when compiling project with Os optimization flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87539 Bug ID: 87539 Summary: internal compiler error when compiling project with Os optimization flag Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: r4sas at i2pd dot xyz Target Milestone: --- GCC info: Using built-in specs. COLLECT_GCC=C:\msys64-rack\mingw64\bin\gcc.exe COLLECT_LTO_WRAPPER=C:/msys64-rack/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-8.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev3, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 8.2.0 (Rev3, Built by MSYS2 project) Command line: g++ -Os -D_MT -DWIN32 -D_WINDOWS -DWIN32_LEAN_AND_MEAN -DWIN32_APP -Wall -Wextra -std=c++11 -Ilibi2pd -Ilibi2pd_client -Idaemon -I. -maes -mavx -c -o obj/libi2pd_client/ClientContext.o libi2pd_client/ClientContext.cpp Compiler output: In file included from C:/msys64-rack/mingw64/include/boost/property_tree/ptree.hpp:516, from libi2pd_client/ClientContext.cpp:3: C:/msys64-rack/mingw64/include/boost/property_tree/detail/ptree_implementation.hpp: In instantiation of 'boost::optional boost::property_tree::basic_ptree::get_value_optional() const [with Type = int; Key = std::__cxx11::basic_string; Data = std::__cxx11::basic_string; KeyCompare = std::less >]': C:/msys64-rack/mingw64/include/boost/property_tree/detail/ptree_implementation.hpp:814:66: required from 'boost::optional boost::property_tree::basic_ptree::get_optional(const path_type&) const [with Type = int; Key = std::__cxx11::basic_string; Data = std::__cxx11::basic_string; KeyCompare = std::less >; boost::property_tree::basic_ptree::path_type = boost::property_tree::string_path, boost::property_tree::id_translator > >]' C:/msys64-rack/mingw64/include/boost/property_tree/detail/ptree_implementation.hpp:781:34: required from 'typename boost::disable_if, Type>::type boost::property_tree::basic_ptree::get(const path_type&, const Type&) const [with Type = int; Key = std::__cxx11::basic_string; Data = std::__cxx11::basic_string; KeyCompare = std::less >; typename boost::disable_if, Type>::type = int; boost::property_tree::basic_ptree::path_type = boost::property_tree::string_path, boost::property_tree::id_translator > >]' libi2pd_client/ClientContext.cpp:457:85: required from here C:/msys64-rack/mingw64/include/boost/property_tree/detail/ptree_implementation.hpp:735:59: internal compiler error: in tsubst_default_argument, at cp/pt.c:12714 typename translator_between::type()); ^~ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. Preprocessed file in attachment. By the way, when used -O2 optimization flag, that source file compiles without problems.
[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54429 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-06 Ever confirmed|0 |1 --- Comment #11 from Eric Gallager --- (In reply to Oleg Endo from comment #10) > (In reply to Eric Gallager from comment #9) > > (In reply to Oleg Endo from comment #8) > > > BTW, the problem is also there when using LRA. > > > > Is this still the case? > > Just checked it on trunk. Yes, nothing has changed. OK, changing status to ASSIGNED then
[Bug preprocessor/44317] ,##__VA_ARGS__ comma not eaten with -std=c++0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #9 from Harald van Dijk --- The comma should not be eaten, as the invocation of FAIL() is valid in standard C++. The rules of concatenation of empty pp-token sequences are well-defined: the empty sequences are replaced by placemarker preprocessor tokens, and concatenating any non-placeholder token with a placemarker preprocessor token produces the former, see [cpp.concat]. There is no exception for commas. Because of that, in that one special case where ,##__VA_ARGS__ is valid in both standard C++ and GNU C++ with different meanings, the standard C++ meaning is used in standard C++ modes, and the GNU C++ meaning is used in GNU C++ modes. If clang provides no option to let expand to standard C++'s rather than GNU C++'s , that is a clang bug, not a GCC bug. (clang does behave correctly in C99/C11 modes.) That's different from the ASSERT( false ) invocation: since that invocation is invalid in standard C++ regardless of whether the definition uses __VA_ARGS__, the invocation is diagnosed. Once the diagnostic is emitted, if GCC continues to accept the code as an extension, the standard places no requirements on its behaviour. GCC is free to change the meaning of ,##__VA_ARGS__ in that case, and no standard requires any further diagnostics for it. Extending GCC with an additional warning for diagnosing ,##__VA_ARGS__ as a GNU extension may make sense even despite that, but please do not change what ,##__VA_ARGS__ expands to. GCC is already correct there.
[Bug c/86418] warn about mismatch in type between argument and parameter type for declaration without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86418 Eric Gallager changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > Related to bug 82922 and bug 83656 Adding Martin Sebor on cc to this one, too
[Bug target/87156] [9 Regression] ICE building libstdc++ for mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156 Iain Buclaw changed: What|Removed |Added CC||ibuclaw at gdcproject dot org --- Comment #6 from Iain Buclaw --- (In reply to Jan Hubicka from comment #3) > Does the attached patch fix the bootstrap? > Index: cgraphclones.c > === > --- cgraphclones.c (revision 264180) > +++ cgraphclones.c (working copy) > @@ -967,6 +967,8 @@ cgraph_node::create_version_clone_with_b >SET_DECL_ASSEMBLER_NAME (new_decl, DECL_NAME (new_decl)); >SET_DECL_RTL (new_decl, NULL); > > + DECL_VIRTUAL_P (new_decl) = 0; > + >/* When the old decl was a con-/destructor make sure the clone isn't. */ >DECL_STATIC_CONSTRUCTOR (new_decl) = 0; >DECL_STATIC_DESTRUCTOR (new_decl) = 0; I just got round to checking this, and reached the same conclusion without realising you already made a patch. Has this been posted yet?
[Bug c/82922] Request: add -Wstrict-prototypes to -Wextra as K style is obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922 --- Comment #6 from Eric Gallager --- (In reply to Martin Sebor from comment #3) > Incremental patch for the testsuite: > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00962.html > > Unfortunately it sounds like it might be too late to enable the option in > GCC 8. What about for GCC 9?
[Bug c/82922] Request: add -Wstrict-prototypes to -Wextra as K style is obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922 --- Comment #7 from Martin Sebor --- I posted a GCC 9 patch here: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00675.html It adds -Wstrict-prototypes to -Wall. Unfortunately, it got derailed by (IMO unsubstantiated) concerns about the impact on some poorly written configure tests. I'll see if I can find the time to adjust the patch to enable the option only with -Wextra and convince the powers that be to accept it into GCC 9.
[Bug c/86418] warn about mismatch in type between argument and parameter type for declaration without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86418 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-06 Ever confirmed|0 |1 --- Comment #4 from Martin Sebor --- Confirmed. My preference would be to resolve pr82922 and diagnose all calls to functions without a prototype. Short of that, this could be handled by saving the type of the first call to a function without a prototype in a translation unit, comparing it to the type of each subsequent call, and warning if they don't match.
[Bug fortran/86111] ICE in gfc_arith_concat, at fortran/arith.c:985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86111 --- Comment #2 from Thomas Koenig --- Author: tkoenig Date: Sat Oct 6 18:20:14 2018 New Revision: 264900 URL: https://gcc.gnu.org/viewcvs?rev=264900=gcc=rev Log: 2018-10-06 Thomas Koenig PR fortran/86111 * gfortran.h (enum arith): Add ARITH_WRONGCONCAT. * arith.h (gfc_arith_error): Issue error for ARITH_WRONGCONCAT. (gfc_arith_concat): If the types of op1 and op2 are not character of if their kinds do not match, issue ARITH_WRONGCONCAT. 2018-10-06 Thomas Koenig PR fortran/86111 * gfortran.dg/array_constructor_type_23.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_type_23.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/gfortran.h trunk/gcc/testsuite/ChangeLog
[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|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > Is this still an issue with newer GCC? No reply; closing
[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 CC||dj at redhat dot com Assignee|dj at redhat dot com |unassigned at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > Should DJ Delorie still remain the assignee for this? (In reply to DJ Delorie from comment #2) > 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. OK, so that sounds like a "no" to my question then.
[Bug c/86418] warn about mismatch in type between argument and parameter type for declaration without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86418 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82922, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83656 --- Comment #2 from Eric Gallager --- Related to bug 82922 and bug 83656
[Bug target/87510] ICE in gen_reg_rtx, at emit-rtl.c:1155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87510 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-06 Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed. define_insn_and_split "*floatuns2_internal" splits if reload_completed, so no more pseudos can be created, but it calls gen_floatdi2 (floatdisf2 here), which creates a pseudo if you use -mno-popcntd. So we have enabled power9 but disabled the power7 insns. This will not fly. (This is just one instance of a more generic problem, for which we have more PRs already).
[Bug fortran/83999] [8/9 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 --- Comment #10 from Paul Thomas --- Author: pault Date: Sat Oct 6 15:14:29 2018 New Revision: 264899 URL: https://gcc.gnu.org/viewcvs?rev=264899=gcc=rev Log: 2018-10-06 Paul Thomas PR fortran/83999 * resolve.c (resolve_fl_procedure): Include class functions in the test that elemental function results be scalar. 2018-10-06 Paul Thomas PR fortran/83999 * gfortran.dg/elemental_function_4.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_function_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[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|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #22 from Eric Gallager --- (In reply to Eric Gallager from comment #21) > (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? No reply; closing.
[Bug c++/87541] New: ICE using a constant decl as an attribute alloc_size argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87541
Bug ID: 87541
Summary: ICE using a constant decl as an attribute alloc_size
argument
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Similar to bug 79984, using a named constant in an alloc_size argument causes
an ICE in C++.
$ cat x.c && gcc -S -Wall x.c
const int r = 1;
__attribute__ ((alloc_size (r))) void* f (int);
void* g (void)
{
void *p = f (1);
__builtin___memset_chk (p, 0, 1, __builtin_object_size (p, 1));
return p;
}
during RTL pass: expand
x.c: In function ‘void* g()’:
x.c:7:15: internal compiler error: tree check: expected integer_cst, have
var_decl in initialize_argument_information, at calls.c:2059
void *p = f (1);
~~^~~
0x15f600e tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/src/gcc/8-branch/gcc/tree.c:9333
0x81ca71 tree_int_cst_elt_check(tree_node*, int, char const*, int, char const*)
/src/gcc/8-branch/gcc/tree.h:3335
0xc03e68 initialize_argument_information
/src/gcc/8-branch/gcc/calls.c:2059
0xc0a4f4 expand_call(tree_node*, rtx_def*, int)
/src/gcc/8-branch/gcc/calls.c:3723
0xdc9f69 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/8-branch/gcc/expr.c:11008
0xdbca98 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc/8-branch/gcc/expr.c:8233
0xdb1e8a store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/src/gcc/8-branch/gcc/expr.c:5635
0xdb03d4 expand_assignment(tree_node*, tree_node*, bool)
/src/gcc/8-branch/gcc/expr.c:5403
0xc274b7 expand_call_stmt
/src/gcc/8-branch/gcc/cfgexpand.c:2688
0xc2a7a8 expand_gimple_stmt_1
/src/gcc/8-branch/gcc/cfgexpand.c:3624
0xc2ae82 expand_gimple_stmt
/src/gcc/8-branch/gcc/cfgexpand.c:3790
0xc32f95 expand_gimple_basic_block
/src/gcc/8-branch/gcc/cfgexpand.c:5819
0xc348ee execute
/src/gcc/8-branch/gcc/cfgexpand.c:6425
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/87542] [7/8/9 Regression] bogus error on attribute format with a named constant argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87542 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Summary|bogus error on attribute|[7/8/9 Regression] bogus |format with a named |error on attribute format |constant argument |with a named constant ||argument --- Comment #1 from Martin Sebor --- The error first appeared with r189174 (in GCC 4.8.0): r189174 | jason | 2012-07-02 15:14:23 -0400 (Mon, 02 Jul 2012) | 20 lines PR c++/53524 gcc/cp/ * call.c (build_conditional_expr_1): Don't warn about comparison of two enumerators before their enumeration is complete. (build_new_op_1): Call decay_conversion before warn_logical_operator. * decl.c (build_enumerator): Set DECL_CONTEXT of an enumerator to its enumeration. * decl2.c (mark_used): Call used_types_insert for enums. * semantics.c (finish_id_expression): Don't decay CONST_DECL. (finish_member_declaration): Don't change DECL_CONTEXT of enumerators. * class.c (check_field_decls): Don't change DECL_CONTEXT of enums. * typeck.c (convert_for_assignment): Don't decay CONST_DECL. (build_class_member_access_expr): Look through unscoped enums. * search.c (context_for_name_lookup): Look through unscoped enums. * pt.c (tsubst_copy_and_build): Don't decay CONST_DECL. (tsubst_copy): Use DECL_CONTEXT to find the enumeration. * tree.c (decl_linkage): Likewise. * cvt.c (ocp_convert): Check decayed expr for enum range warning. gcc/c-family/ * c-common.c (get_priority): Call default_conversion.
[Bug c++/87543] New: Missed opportunity to compute constant return value at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87543
Bug ID: 87543
Summary: Missed opportunity to compute constant return value at
compile time
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Brief illustration on GodBolt: https://godbolt.org/z/sQyNGA
A related question on StackOverflow:
https://stackoverflow.com/q/52677512/1593077
Consider the following two functions:
#include
int f1()
{
int arr[] = {1, 2, 3, 4, 5};
auto n = sizeof(arr)/sizeof(arr[0]);
return std::accumulate(arr, arr + n, 0);
}
int f2()
{
int arr[] = {1, 2, 3, 4, 5};
auto n = sizeof(arr)/sizeof(arr[0]);
int sum = 0;
for(int i = 0; i < n; i++) {
sum += arr[i];
}
return sum;
}
Both functions return 15, always; and while they're not marked constexpr, this
can clearly be realized by the compiler. In fact, it is, if we compiler with
-O3 (with GCC 8.2). However, with -O2, we get the following result:
f1():
movabs rax, 8589934593
lea rdx, [rsp-40]
mov ecx, 1
mov DWORD PTR [rsp-24], 5
mov QWORD PTR [rsp-40], rax
lea rsi, [rdx+20]
movabs rax, 17179869187
mov QWORD PTR [rsp-32], rax
xor eax, eax
jmp .L3
.L5:
mov ecx, DWORD PTR [rdx]
.L3:
add rdx, 4
add eax, ecx
cmp rdx, rsi
jne .L5
ret
f2():
mov eax, 15
ret
I don't think `std::accumulate` should have any code which should make -O2 fail
to notice the optimization opportunity in `f1()`. But if that assertion might
be debatable, surely adding -march=skylake to the -O3 can only result in
stronger optimization, right? However, it results in _both_ functions, rather
than just `f1()`, failing to fully optimize.
I asked about part of this issue at StackOverflow and a reply (by Florian
Weimer) suggested this might be a regression relative to GCC 6.3 . And, indeed,
if we switch the GCC version to 6.3 - both functions are not-fully-optimized in
-O2, and fully-optimized with -O3:
https://godbolt.org/z/JOqCoC
if I try GCC 7.3, things get weird in yet a different way: -O2 optimizes both
functions fully, and -O3 optimizes just the _first_ one.
[Bug fortran/86111] ICE in gfc_arith_concat, at fortran/arith.c:985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86111 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Thomas Koenig --- Fixed.
[Bug fortran/86111] ICE in gfc_arith_concat, at fortran/arith.c:985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86111 --- Comment #3 from Thomas Koenig --- Author: tkoenig Date: Sat Oct 6 22:41:06 2018 New Revision: 264902 URL: https://gcc.gnu.org/viewcvs?rev=264902=gcc=rev Log: 2018-10-06 Thomas Koenig PR fortran/86111 Backport from trunk * gfortran.h (enum arith): Add ARITH_WRONGCONCAT. * arith.h (gfc_arith_error): Issue error for ARITH_WRONGCONCAT. (gfc_arith_concat): If the types of op1 and op2 are not character of if their kinds do not match, issue ARITH_WRONGCONCAT. 2018-10-06 Thomas Koenig PR fortran/86111 Backport from trunk * gfortran.dg/array_constructor_type_23.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/array_constructor_type_23.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/arith.c branches/gcc-8-branch/gcc/fortran/gfortran.h branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/87540] New: Missed inner loop hoist if the loop does not depend on outer loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87540
Bug ID: 87540
Summary: Missed inner loop hoist if the loop does not depend on
outer loop
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Not sure how often this happens in the real world apps but anyway idea is..
int foo(void)
{
double *array = calloc(ARRAY_SIZE, sizeof(double));
double sum = 0;
int i;
for (i = 0; i < N_TIMES; i++) {
// lot of code
// well, this loop does not even depend on "i", hoist it?
for (int j = 0; j < ARRAY_SIZE; j += 8) {
sum += array[j] + array[j+1] + array[j+2] + array[j+3] + array[j+4]
+ array[j+5] + array[j+6] + array[j+7];
}
}
return sum;
}
Let's say we have the big outer loop with many inner loops. GCC should detect
if these loops really depend on the outer loop and if not, hoist them out of
this loop.
[Bug c++/87541] ]7/8 Regression] ICE using a constant decl as an attribute alloc_size argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87541 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-06 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Summary|ICE using a constant decl |]7/8 Regression] ICE using |as an attribute alloc_size |a constant decl as an |argument|attribute alloc_size ||argument Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- The ICE first appeared with r243470 (in GCC 7.0.0), though the problem was most likely latent before then. r243470 | msebor | 2016-12-08 18:50:40 -0500 (Thu, 08 Dec 2016) | 44 lines PR c/77531 - __attribute__((alloc_size(1,2))) could also warn on multiplication overflow PR c/78284 - warn on malloc with very large arguments
[Bug c++/87542] New: bogus error on attribute format with a named constant argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87542
Bug ID: 87542
Summary: bogus error on attribute format with a named constant
argument
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following program is accepted by GCC and triggers the expected diagnostic:
$ cat x.c && gcc -O2 -S -Wall x.c
enum { n = 1 };
__attribute__ ((format (printf, n, 2))) void f (const char*, ...);
void g (void)
{
f ("%i", "");
}
x.c: In function ‘g’:
x.c:6:8: warning: format ‘%i’ expects argument of type ‘int’, but argument 2
has type ‘char *’ [-Wformat=]
f ("%i", "");
~^ ~~
%s
However, the same program in rejected in C++ with:
x.c:2:65: error: format string has invalid operand number
__attribute__ ((format (printf, n, 2))) void f (const char*, ...);
^
[Bug tree-optimization/87540] Missed inner loop hoist if the loop does not depend on outer loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87540 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-06 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- you need high level loop optimizations to do this. Something like graphite. But you need to also prove it is profitable too. This is not a simple loop optimization either.
[Bug c++/71003] __extension__ silences pedwarn for "\e" in C but not in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71003 --- Comment #2 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > Confirmed. The manual says clearly that it should work so this is a G++ bug. > > '-Wpedantic' does not cause warning messages for use of the alternate > keywords > whose names begin and end with '__'. Pedantic warnings are also disabled in > the expression that follows __extension__. Thanks for confirming.
[Bug objc/80912] enhancement: -Wundeclared-selector improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80912 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org, ||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #2 from Eric Gallager --- Could someone confirm this for me? I mean, I could technically confirm it myself, but I feel like confirming your own bugs is not exactly kosher... cc-ing objc FE and diagnostics maintainers
