[Bug tree-optimization/86034] [9 regression] wrong code for bit-field manipulation at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86034 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-03 CC||ebotcazou at gcc dot gnu.org Version|unknown |9.0 Target Milestone|--- |9.0 Summary|wrong code at -Os on|[9 regression] wrong code |x86-64-linux-gnu in 64-bit |for bit-field manipulation |mode|at -Os Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed.
[Bug tree-optimization/86034] [9 regression] wrong code for bit-field manipulation at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86034 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Investigating.
[Bug tree-optimization/86035] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86035 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Eric Botcazou --- . *** This bug has been marked as a duplicate of bug 86034 ***
[Bug tree-optimization/86034] [9 regression] wrong code for bit-field manipulation at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86034 --- Comment #3 from Eric Botcazou --- *** Bug 86035 has been marked as a duplicate of this bug. ***
[Bug fortran/85996] [8/9 Regression] ICE: gfc_trans_select(): Bad type for case expr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85996 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 Status|WAITING |NEW Known to work||6.4.0, 7.3.0 Target Milestone|--- |6.5 Summary|f951: internal compiler |[8/9 Regression] ICE: |error: gfc_trans_select(): |gfc_trans_select(): Bad |Bad type for case expr. |type for case expr. Known to fail||6.4.1, 7.3.1, 8.1.0, 9.0 --- Comment #3 from Dominique d'Humieres --- Nice reduction!-) The ICE appeared between revisions r258235 (2018-03-04, OK) and r258362 (2018-03-08, ICE) and the commit has been back ported to the GCC6 and GCC7 branches. (lldb) p code->expr1->ts.type (bt) $0 = BT_UNKNOWN (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0001001707f0 f951`gfc_trans_select(code=0x000143006230) at trans-stmt.c:3310 frame #1: 0x0001000e9748 f951`::trans_code(code=0x000143006230, cond=0x) at trans.c:1940 frame #2: 0x000100119683 f951`gfc_generate_function_code(ns=) at trans-decl.c:6514 frame #3: 0x0001000ee1d2 f951`gfc_generate_module_code(ns=0x000145003000) at trans.c: frame #4: 0x00010009ad2c f951`gfc_parse_file() at parse.c:6108 frame #5: 0x00010009acc3 f951`gfc_parse_file() frame #6: 0x0001000e648c f951`::gfc_be_parse_file() at f95-lang.c:204 frame #7: 0x000100c4667a f951`::compile_file() at toplev.c:455 frame #8: 0x0001012a6c7b f951`toplev::main(int, char**) at toplev.c:2133 frame #9: 0x0001012a87be f951`main(argc=2, argv=0x7ffeefbff250) at main.c:39
[Bug fortran/36497] USE association, cray pointers and error checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36497 --- Comment #4 from Paul Thomas --- Author: pault Date: Sun Jun 3 11:14:51 2018 New Revision: 261127 URL: https://gcc.gnu.org/viewcvs?rev=261127&root=gcc&view=rev Log: 2018-06-03 Paul Thomas PR fortran/36497 * decl.c (variable_decl): Use gfc_add_type for cray pointees. 2018-06-03 Paul Thomas PR fortran/36497 * gfortran.dg/cray_pointer_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/cray_pointers_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/36497] USE association, cray pointers and error checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36497 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- I thought that 8 days short of ten years after it was reported, this bug should be fixed :-) Thanks for the report, Tobias! Paul
[Bug tree-optimization/86034] [9 regression] wrong code for bit-field manipulation at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86034 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Sun Jun 3 11:51:10 2018 New Revision: 261128 URL: https://gcc.gnu.org/viewcvs?rev=261128&root=gcc&view=rev Log: PR tree-optimization/86034 * gimple-ssa-store-merging.c (output_merged_store): Convert the RHS to the unsigned bitfield type in a bit insertion sequence if it does not have a larger precision than the bitfield size. (process_store): Also bypass widening conversions for BIT_INSERT_EXPR. Added: trunk/gcc/testsuite/gcc.dg/torture/pr86034.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-store-merging.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/86034] [9 regression] wrong code for bit-field manipulation at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86034 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- Thanks for reporting the problem.
[Bug fortran/86033] Automated reallocation of empty string array fails with -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86033 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.8 up to trunk (9.0).
[Bug c++/85739] [8/9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739 --- Comment #5 from Jason Merrill --- Author: jason Date: Sun Jun 3 12:37:03 2018 New Revision: 261129 URL: https://gcc.gnu.org/viewcvs?rev=261129&root=gcc&view=rev Log: PR c++/85739 - ICE with pointer to member template parm. * cvt.c (perform_qualification_conversions): Use cp_fold_convert. Added: trunk/gcc/testsuite/g++.dg/template/ptrmem32.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c
[Bug other/12411] Missed -Wsequence-point on functions (example reduced from historical GCC source)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12411
Eric Gallager changed:
What|Removed |Added
Summary|GCC depends on undefined|Missed -Wsequence-point on
|ISO C behavior (order of|functions (example reduced
|execution) |from historical GCC source)
--- Comment #6 from Eric Gallager ---
(In reply to Eric Gallager from comment #5)
> (In reply to Dara Hazeghi from comment #1)
> > Confirmed. One example (cited in the thread) is:
> > gcc/bb-reorder.c:1056:
> > label = emit_label_before (gen_label_rtx (), get_insns ());
>
> (In reply to Manuel López-Ibáñez from comment #3)
> > This should be warned by -Wsequence-points.
>
> A reduced testcase based on that line still doesn't warn:
>
> $ cat 12411.c && /usr/local/bin/gcc -c -Wall -Wextra -pedantic
> -Wsequence-point 12411.c
>
> int gen_label_rtx(void);
> int get_insns(void);
> int emit_label_before(int, int);
>
> int foo(void)
> {
> int label;
> label = emit_label_before(gen_label_rtx(), get_insns());
> return label;
> }
> $
>
> bb-reorder.c no longer contains the code in question though, so at least
> this doesn't affect building gcc itself any longer (hopefully)
...thus, I should have retitled this... (doing so now)
[Bug fortran/85983] ICE in check_dtio_interface1, at fortran/interface.c:4748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85983 --- Comment #2 from Jerry DeLisle --- Removing the assert at interface.c:4748 seems to fix this, giving the following error: z2.f03:14:16: subroutine s2 (dtv, unit) 1 Error: Too few dummy arguments in DTIO procedure ‘s2’ at (1)
[Bug fortran/85983] ICE in check_dtio_interface1, at fortran/interface.c:4748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85983 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org
[Bug fortran/85996] [8/9 Regression] ICE: gfc_trans_select(): Bad type for case expr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85996 --- Comment #4 from Steve Kargl --- On Sun, Jun 03, 2018 at 10:02:35AM +, dominiq at lps dot ens.fr wrote: > > Nice reduction!-) > > The ICE appeared between revisions r258235 (2018-03-04, OK) and r258362 > (2018-03-08, ICE) and the commit has been back ported to the GCC6 and GCC7 > branches. > There are 3 commits to gcc/fortran in that range. I reverted what would be the obvious one that might cause a problem and the ICE still occurs. The ICE disappears if uppercase_c and uppercase_s are moved up in the source code to a location that comes before any reference to the generic uppercase.
[Bug target/82092] [8/9 regression] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 Claus-Justus Heine changed: What|Removed |Added CC||himself@claus-justus-heine. ||de --- Comment #12 from Claus-Justus Heine --- Still no go, even with that patch: ./auto-host.h:2396:16: error: declaration does not declare anything [-fpermissive] #define rlim_t long And: In file included from /Users/heinecj/Software/src/gcc-8.1.0/build/prev-x86_64-apple-darwin16.7.0/libstdc++-v3/include/cstring:42, from ../../gcc/system.h:235, from ../../gcc/genmodes.c:21: /usr/include/string.h:134:7: note: previous declaration 'char* strsignal(int)' char *strsignal(int __sig); This is OSX Yosemite with that patch mentioned above applied, enable-languages=c,c++,fortran and latest mpc, gmp, mpfr, isl. Cheers
[Bug fortran/85996] [8/9 Regression] ICE: gfc_trans_select(): Bad type for case expr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85996 --- Comment #5 from Dominique d'Humieres --- > There are 3 commits to gcc/fortran in that range. I > reverted what would be the obvious one that might > cause a problem and the ICE still occurs. Was it r258347? > The ICE disappears if uppercase_c and uppercase_s are > moved up in the source code to a location that comes > before any reference to the generic uppercase. This rings some bells, but I am unable to remember for which PR this happened.
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING CC||pault at gcc dot gnu.org --- Comment #8 from Dominique d'Humieres --- AFAICT this PR is now fixed, likely r251949 (pr34640 and friends).
[Bug fortran/85996] [8/9 Regression] ICE: gfc_trans_select(): Bad type for case expr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85996 --- Comment #6 from Steve Kargl --- On Sun, Jun 03, 2018 at 05:05:42PM +, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85996 > > --- Comment #5 from Dominique d'Humieres --- > > There are 3 commits to gcc/fortran in that range. I > > reverted what would be the obvious one that might > > cause a problem and the ICE still occurs. > > Was it r258347? > Whoops. Reverted in the wrong tree. Appears to be related to 258347.
[Bug fortran/85996] [8/9 Regression] ICE: gfc_trans_select(): Bad type for case expr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85996 --- Comment #7 from Dominique d'Humieres --- Could be related to pr85138.
[Bug target/86036] New: [9 Regression] wrong code with -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86036 Bug ID: 86036 Summary: [9 Regression] wrong code with -mavx512bw Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 44226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44226&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O -mavx512bw testcase.c $ sde64 -- ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-261129-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-261129-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix gcc version 9.0.0 20180603 (experimental) (GCC)
[Bug target/82092] [8/9 regression] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 --- Comment #13 from Eric Gallager --- (In reply to Claus-Justus Heine from comment #12) > Still no go, even with that patch: > > ./auto-host.h:2396:16: error: declaration does not declare anything > [-fpermissive] > #define rlim_t long > > And: > > In file included from > /Users/heinecj/Software/src/gcc-8.1.0/build/prev-x86_64-apple-darwin16.7.0/ > libstdc++-v3/include/cstring:42, > from ../../gcc/system.h:235, > from ../../gcc/genmodes.c:21: > /usr/include/string.h:134:7: note: previous declaration 'char* > strsignal(int)' > char *strsignal(int __sig); > > This is OSX Yosemite with that patch mentioned above applied, > enable-languages=c,c++,fortran and latest mpc, gmp, mpfr, isl. > > Cheers That might be a different issue...
[Bug target/86027] string literals get corrupted with -O3 and gas on solaris i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86027 --- Comment #1 from Michael Teske --- Interestingly it works fine with gcc 8.1.0 and ../configure --prefix=/opt/gcc-8.1.0-gas --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-gmp=/opt/csw --with-mpfr=/opt/csw --with-mpc=/opt/csw I retried with the same configure options and 7.3.0 just to be sure, and the problem still happens. So, it must have been fixed inbetween. Unfortunately, 8.1. is not yet an option for me.
[Bug c++/85958] Make const qualifier error clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85958 --- Comment #7 from Jonathan Wakely --- (In reply to Jonny Grant from comment #5) > I personally feel "bind" is not a word any programming course teaches, we > say "passing parameters" or "passing arguments". You pass arguments, which initialize parameters. Initialization of references is called binding. > > In addition, I feel we don't think we really need the word "reference" If the parameter type wasn't a reference there would be no problem. Omitting the reason it fails seems unhelpful. > Therefore, I suggest the following: > > $ g++ -o main main.cpp -Wall -Werror -Wconversion > main.cpp: In function ‘int main()’: > main.cpp:11:25: error: cannot pass ‘const int’ to non-const ‘int&’ No this is nonsense. You are not passing something to a reference, you are passing it to the function. The object cannot be bound to the reference because of the cv-qualifiers. I'm keen to make the language clearer, but not by making it simply wrong about what's happening!
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #5 from Jonathan Wakely --- Every version of the standard says the same thing under iterator requirements: "For every iterator type X for which equality is defined, there is a corresponding signed integer type called the difference type of the iterator." Your distance objects are class types, which are not signed integer types.
[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013 --- Comment #7 from Jonathan Wakely --- The standard specifically says that if reallocation occurs then iterators and points are invalidated, which is how it talks about copying to new storage. You are making up an interpretation for shrink_to_fit which is novel, not supported by the standard, and not intended by the designers of the feature.
[Bug c++/85739] [8/9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739 --- Comment #6 from Jason Merrill --- Author: jason Date: Sun Jun 3 20:01:37 2018 New Revision: 261132 URL: https://gcc.gnu.org/viewcvs?rev=261132&root=gcc&view=rev Log: PR c++/85739 - ICE with pointer to member template parm. * cvt.c (perform_qualification_conversions): Use cp_fold_convert. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/template/ptrmem32.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cvt.c
[Bug c++/85761] [8/9 Regression] ICE on invalid in rtl with uncaptured constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85761 --- Comment #3 from Jason Merrill --- Author: jason Date: Sun Jun 3 20:01:28 2018 New Revision: 261131 URL: https://gcc.gnu.org/viewcvs?rev=261131&root=gcc&view=rev Log: PR c++/85761 - ICE with ill-formed use of const outer variable. * expr.c (mark_use): Handle location wrappers. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const8.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/expr.c
[Bug target/85969] avr/gen-avr-mmcu-specs.c:56: unused function ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85969 Georg-Johann Lay changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |WAITING Last reconfirmed||2018-06-03 Ever confirmed|0 |1 Severity|normal |minor --- Comment #1 from Georg-Johann Lay --- Sorry, I cannot find str_prefix_p in, e.g. http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/gen-avr-mmcu-texi.c?revision=256169&view=markup Are you sure this isn't a problem which has been fixed long ago? Moreover you should show how you configured the compilerr, e.g. as proposed in the bug reporting hints at http://gcc.gnu.org/bugs/#howto and in particular o the options given when GCC was configured/built
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #6 from Josh Marshall --- There is a kind of legacy manual specification, and a reason for that was for tracking usage. What I'm working on is adapted from David Musser's 1997 code which was using proposed and developmental stdlib code. So this functionality was intended at one point, and there is some limited use in the greater functionality.
[Bug c++/85739] [8/9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed.
[Bug c++/85761] [8/9 Regression] ICE on invalid in rtl with uncaptured constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85761 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed. And yes, this was accepts-invalid in GCC 7.
[Bug c++/85873] [8/9 regression] GCC omits array constant in .rodata causing a segmentation fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85873 --- Comment #7 from Jason Merrill --- (In reply to Kimon.Hoffmann from comment #6) > The situation as it stands is unfortunate though, since the standard does > not allow "static constexpr" variables in constexpr functions. Therefor I > don't see a standards compliant way to: return a constant array from a > function (the choice of which array to return possibly depending on a > function argument) that: > * Provides type erasure on the length of the returned array. > * Works in constexpr contexts. > * Does not copy values during runtime. It does seem wrong that a constexpr function can't define a constexpr static local variable.
[Bug target/85969] avr/gen-avr-mmcu-specs.c:56: unused function ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85969 --- Comment #2 from David Binderman --- $ cd ~/gcc/trunk/gcc/config/avr/ $ ls avr-arch.h avr.h avr.opt driver-avr.c specs.h avr.c avrlibc.h avr-passes.def elf.h stdfix.h avr-c.cavr-log.c avr-protos.hgen-avr-mmcu-specs.c t-avr avr-devices.c avr-mcus.def avr-stdint.hgen-avr-mmcu-texi.c t-multilib avr-dimode.md avr.md builtins.defgenmultilib.awk avr-fixed.md avr-modes.def constraints.md predicates.md $ svn update Updating '.': At revision 261132. [dcb@dhcppc0 avr]$ fgrep str_prefix_p gen-avr-mmcu-specs.c str_prefix_p (const char *str, const char *prefix) $ I show the version from today's trunk revision 261132. Your version seems to be revision 256169, some 4,963 revisions ago. I suggest you update to trunk and check again. Perhaps you are using a non-trunk branch ?
[Bug c++/86037] New: __PRETTY_FUNCTION__ for constexpr lambda's is missing [with = type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86037
Bug ID: 86037
Summary: __PRETTY_FUNCTION__ for constexpr lambda's is missing
[with = type]
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hello gcc-team,
this code changed output between gcc-7 and gcc-8
```
// pretty_function.cpp
#include
#include
template
struct pretty_lambda
{
static constexpr auto as_string = [] ()
{
return std::string{__PRETTY_FUNCTION__};
};
};
int main()
{
std::string lambda_int = pretty_lambda::as_string();
std::cout << lambda_int << "\n";
return 0;
}
```
compiling with `g++-7 -std=c++17 pretty_function.cpp` outputs:
pretty_lambda:: [with type = int]
compiling with `g++-8 -std=c++17 pretty_function.cpp` outputs:
pretty_lambda::
Is there a reason for this change? The same class, but with `as_string` as a
static function delivers an output with the `[with type = int]` part
(i.e., `static auto seqan3::detail::pretty_function::as_string() [with
type = int]`).
So it seems to me that the general format was not changed. I know that this is
in no way a standard function or something, but I would prefer a consistent
output.
> g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc7/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,lto
--enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib
--with-isl --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-werror --enable-checking=release
--enable-default-pie --enable-default-ssp --program-suffix=-7
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 7.3.1 20180406 (GCC)
> g++-8 -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.1.0 (GCC)
Thank you for your awesome work!
Marcel
[Bug c++/85958] Make const qualifier error clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85958 --- Comment #8 from W E Brown --- C++ seems very clear that the semantics of parameter passage are those of initialization. For example, according to [expr.call]/7 in N4741: "When a function is called, each parameter shall be initialized with its corresponding argument" [cross-references omitted]. (1) We might therefore consider to rephrase the diagnostic so as to be consistent with the Standard's nomenclature. For example: "can't initialize parameter of type 'int&' with argument of type 'const int'" Or, flipping the phrasing: "argument of type 'const int' can't initialize parameter of type 'int&'" (I prefer the latter, actually, because the caret indicates the argument. YMMV.) (2) For the same reason, the note accompanying the diagnostic might at the same time be more accurately rephrased as "initializing parameter 1 of ..." instead of the current "initializing argument 1 of ...". (3) Finally, there seems to be a fair amount of redundancy in the note, mentioning the called function both with and without its parameter's name. Perhaps just one of these might suffice? Just some thoughts for your consideration.
[Bug fortran/85996] [8/9 Regression] ICE: gfc_trans_select(): Bad type for case expr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85996 kargl at gcc dot gnu.org changed: What|Removed |Added Blocks||85138 --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #7) > Could be related to pr85138. Yes, it is related if not the same. I have a patch that fixes both PRs and passes regression testing. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138 [Bug 85138] [8/9 regression] ICE with generic function
[Bug tree-optimization/86038] New: [9 Regression] ICE in to_reg_br_prob_base, at profile-count.h:242
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86038
Bug ID: 86038
Summary: [9 Regression] ICE in to_reg_br_prob_base, at
profile-count.h:242
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20180603 snapshot (r261132) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -ftracer -ftree-parallelize-loops=2
-fno-tree-scev-cprop --param parloops-schedule=dynamic (=guided, =runtime):
int
sd (int lw)
{
while (lw < 1)
++lw;
return lw;
}
gcc-9.0.0-alpha20180603 -O2 -ftracer -ftree-parallelize-loops=2
-fno-tree-scev-cprop --param parloops-schedule=dynamic -c tmzmdwfg.c
during GIMPLE pass: tracer
tmzmdwfg.c: In function 'sd._loopfn.0':
tmzmdwfg.c:4:9: internal compiler error: in to_reg_br_prob_base, at
profile-count.h:242
while (lw < 1)
^
0x6579a3 profile_probability::to_reg_br_prob_base() const
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180603/work/gcc-9-20180603/gcc/profile-count.h:242
0x6579a3 find_best_successor
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180603/work/gcc-9-20180603/gcc/tracer.c:162
0xc9f64d find_trace
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180603/work/gcc-9-20180603/gcc/tracer.c:208
0xc9f64d tail_duplicate
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180603/work/gcc-9-20180603/gcc/tracer.c:319
0xc9f64d execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180603/work/gcc-9-20180603/gcc/tracer.c:429
This is apparently a regression since r260954.
[Bug c/85997] Bogus -Wvla warning from function array argument with size expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85997 --- Comment #4 from Kari Nurmela --- Yeah, well, I'm not claiming that there is anything wrong with the code generation (especially argument passing) here, this is just a really minor issue about the conformance of -Wvla with its documentation, and about its general usefulness with C99. * gcc info says about -Wvla: "Warn if variable length array is used in the code." This seems to indicate that the -Wvla alone should mean the "other uses of -Wvla" mentioned in Comment #1. * the example program doesn't use any variable length arrays (how can you use one without it existing somewhere?), so triggering the warning "if variable length array is used in the code" doesn't seem right. (The actual warning message is of course patently true :) With -std=c90 shouldn't this ideally give a separate error/warning about the violation of the constraint on the content of []? Like the one triggered by the "static" with -pedantic -std=c90: "ISO C90 does not support "static" or type qualifiers in parameter array declarators [-Wpedantic])".
