[Bug c++/70769] New: function definition wrongfully allowed inside comma separated member declaration list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70769
Bug ID: 70769
Summary: function definition wrongfully allowed inside comma
separated member declaration list
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fourmisain+gcc at gmail dot com
Target Milestone: ---
This code should not compile while it does:
class C {
int n, f(int) {
return 42;
}
};
To break it down (using C++14 standard draft n4140), the only
member-declaration (§9.2) which declares multiple members at once is of the
form
attribute-specifier-seq(opt) decl-specifier-seq(opt)
member-declarator-list(opt);
Note that in the above code, the required semicolon at the end is missing, so
this is already in violation of the standard, but the code still compiles
without even a warning (using -std=c++14 -Wall -pedantic) if you add that
missing semicolon.
So continuing the argument, "int n, f(int) {return 42;}" would have to be a
member-declarator-list, so "f(int){return 42;}" would have to be a
member-declarator and since it does not contain a colon it is one of the two:
declarator virt-specifier-seq(opt) pure-specifier(opt)
declarator brace-or-equal-initializer(opt)
Since "{return 42;}" is not a valid brace-or-equal-initializer, "f(int){return
42;}" has to be a declarator.
Afaik, this is not true and it also conflicts with the following:
If it were a declarator, you would be allowed to use it inside a
init-declarator-list, therefore the following code would have to compile:
int n, f(int) {
return 42;
}
But it (rightfully) does not:
"error: a function-definition is not allowed here before '{' token"
So this error message needs to be applied to the above class case.
I was made aware that the above "hack" is often used on CodeFights to save
precious characters. They seems to wrap code into a class and compile it with
g++ 5.0.
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #39 from Jakub Jelinek --- (In reply to David Edelsohn from comment #38) > The gt* files don't differ. > > I normally use > > --disable-werror --enable-languages=c,c++,fortran,objc --with-gmp=/opt/cfarm > --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch > --with-included-gettext --enable-checking=release Used /home/jakub/gcc-6.0.1-RC-20160415/configure --disable-werror --enable-languages=c,c++,fortran,objc --with-gmp=/opt/cfarm --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch --with-included-gettext --enable-checking=release myself now (inside of /home/jakub/rc1/) and it bootstrapped just fine too.
[Bug ada/70759] Ada rts fails to build with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70759 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-23 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- internal_reference_types probably needs to go away.
[Bug target/69143] PowerPC64: aggregate results are badly handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69143 --- Comment #3 from H.J. Lu --- Similar to PR 28831, PR 23782?
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #40 from David Edelsohn --- I see that you did not have /opt/freeware/bin in your path on AIX. How did it even build without GNU Make and other build requirements?
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #41 from Jakub Jelinek --- (In reply to David Edelsohn from comment #40) > I see that you did not have /opt/freeware/bin in your path on AIX. How did > it even build without GNU Make and other build requirements? I've used gmake -j64 instead of make -j64. I can retry with PATH=/opt/freeware/bin:$PATH instead, sure. Do you use relative or absolute path from the build dir to the source dir btw? On my boxes I almost always create a subdir of the source dir and do ../configure ..., but on this box I've placed the build dir next to the source dir and used absolute pathname.
[Bug c++/66256] noexcept evaluation done before end of class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66256 Michael Mehlich changed: What|Removed |Added CC||mmehlich at semanticdesigns dot co ||m --- Comment #1 from Michael Mehlich --- I agree, name resolution should consider all declarations in the class, but apparently gcc does name resolution on the exception specification way too early. An example where this causes no error message being created for obviously wrong code is the swap function in the pair template in the header file bits/stl_pair.h (for gcc 5.3.0/cygwin), which is declared as void swap(pair& __p) noexcept(noexcept(swap(first, __p.first)) && noexcept(swap(second, __p.second))) clang 3.7.1. properly reports an error for the swap in the exception specification. BTW: The header file could be fixed easily by adding std:: in front of these swap occurrences.
[Bug c++/70770] New: constexpr expansion Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70770 Bug ID: 70770 Summary: constexpr expansion Internal compiler error Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mira.fontan at gmail dot com Target Milestone: --- Command line: /usr/bin/g++ -DDEBUG -DRUN_UNITTEST -DUNDER_LINUX -D_GLIBCXX_USE_CXX11_ABI=0 -I../. -I. -fno-common -ffunction-sections -fdata-sections -fno-rtti -pedantic -pthread -Wvariadic-macros -fsigned-char -Wabi -Wabi-tag -Wall -Warray-bounds -Wbool-compare -Wcast-align -Wcomment -Wconversion -Wdeprecated-declarations -Wdelete-incomplete -Wdisabled-optimization -Wempty-body -Wenum-compare -Wextra -Wformat -Wformat-extra-args -Wformat-security -Wformat-zero-length -Wchar-subscripts -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wlogical-not-parentheses -Wlogical-op -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wno-inline -Wno-long-long -Wunknown-pragmas -Wnonnull -Wodr -Woverflow -Wpacked -Wparentheses -Wpointer-arith -Wredundant-decls -Wreturn-type -Wsequence-point -Wshadow -Wshift-count-negative -Wshift-count-overflow -Wsign-compare -Wsign-conversion -Wsizeof-array-argument -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-overflow -Wswitch -Wswitch-bool -Wswitch-default -Wswitch-enum -Wtrigraphs -Wundef -Wuninitialized -O0 -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wunknown-pragmas -Wunreachable-code -Wwrite-strings -Wabi-tag -Wcast-qual -Wdelete-non-virtual-dtor -Wdeprecated -Wno-format-nonliteral -Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual -Wreorder -Wsign-promo -Wsuggest-final-methods -Wsuggest-final-types -Wunused-macros -ftrapv -fno-omit-frame-pointer -fstack-protector -fstack-protector-all -Wstack-protector -O0 -fsanitize=address -Wno-exit-time-destructors -Wno-global-constructors -Wno-format-nonliteral -Wno-missing-format-attribute -ansi -std=c++14 -Werror -g -MMD -MT game/CMakeFiles/game.dir/ray.cpp.o -MF game/CMakeFiles/game.dir/ray.cpp.o.d -o game/CMakeFiles/game.dir/ray.cpp.o -c ../game/ray.cpp -v -save-temps
[Bug c++/70770] constexpr expansion Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70770 --- Comment #1 from Mira Fontan --- Command line output: Using built-in specs. COLLECT_GCC=/usr/bin/g++ Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.1-14ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) COLLECT_GCC_OPTIONS='-D' 'DEBUG' '-D' 'RUN_UNITTEST' '-D' 'UNDER_LINUX' '-D' '_GLIBCXX_USE_CXX11_ABI=0' '-I' '../.' '-I' '.' '-fno-common' '-ffunction-sections' '-fdata-sections' '-fno-rtti' '-Wpedantic' '-pthread' '-Wvariadic-macros' '-fsigned-char' '-Wabi' '-Wall' '-Warray-bounds' '-Wbool-compare' '-Wcast-align' '-Wcomment' '-Wconversion' '-Wdeprecated-declarations' '-Wdelete-incomplete' '-Wdisabled-optimization' '-Wempty-body' '-Wenum-compare' '-Wextra' '-Wformat=1' '-Wformat-extra-args' '-Wformat-security' '-Wformat-zero-length' '-Wchar-subscripts' '-Winit-self' '-Wint-to-pointer-cast' '-Winvalid-pch' '-Wlogical-not-parentheses' '-Wlogical-op' '-Wmissing-braces' '-Wmissing-field-initializers' '-Wsuggest-attribute=noreturn' '-Wno-inline' '-Wno-long-long' '-Wnonnull' '-Wodr' '-Woverflow' '-Wpacked' '-Wparentheses' '-Wpointer-arith' '-Wredundant-decls' '-Wreturn-type' '-Wsequence-point' '-Wshadow' '-Wshift-count-negative' '-Wshift-count-overflow' '-Wsign-compare' '-Wsign-conversion' '-Wsizeof-array-argument' '-Wsizeof-pointer-memaccess' '-Wstrict-aliasing' '-Wstrict-overflow' '-Wswitch' '-Wswitch-bool' '-Wswitch-default' '-Wswitch-enum' '-Wtrigraphs' '-Wundef' '-Wuninitialized' '-O0' '-Wunused-but-set-parameter' '-Wunused-but-set-variable' '-Wunused-function' '-Wunused-label' '-Wunused-parameter' '-Wunused-value' '-Wunused-variable' '-Wunknown-pragmas' '-Wwrite-strings' '-Wabi-tag' '-Wcast-qual' '-Wdelete-non-virtual-dtor' '-Wdeprecated' '-Wnon-virtual-dtor' '-Wold-style-cast' '-Woverloaded-virtual' '-Wreorder' '-Wsign-promo' '-Wsuggest-final-methods' '-Wsuggest-final-types' '-Wunused-macros' '-ftrapv' '-fno-omit-frame-pointer' '-fstack-protector' '-fstack-protector-all' '-Wstack-protector' '-O0' '-fsanitize=address' '-Wno-exit-time-destructors' '-Wno-global-constructors' '-Wno-format-nonliteral' '-Wno-suggest-attribute=format' '-ansi' '-std=c++14' '-Werror' '-g' '-MMD' '-MT' 'game/CMakeFiles/game.dir/ray.cpp.o' '-MF' 'game/CMakeFiles/game.dir/ray.cpp.o.d' '-o' 'game/CMakeFiles/game.dir/ray.cpp.o' '-c' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -I ../. -I . -imultiarch x86_64-linux-gnu -MMD game/CMakeFiles/game.dir/ray.cpp.d -MF game/CMakeFiles/game.dir/ray.cpp.o.d -MT game/CMakeFiles/game.dir/ray.cpp.o -D_GNU_SOURCE -D_REENTRANT -D DEBUG -D RUN_UNITTEST -D UNDER_LINUX -D _GLIBCXX_USE_CXX11_ABI=0 ../game/ray.cpp -mtune=generic -march=x86-64 -ansi -std=c++14 -Wpedantic -Wvariadic-macros -Wabi -Wall -Warray-bounds -Wbool-compare -Wcast-align -Wcomment -Wconversion -Wdeprecated-declarations -Wdelete-incomplete -Wdisabled-optimization -Wempty-body -Wenum-compare -Wextra -Wformat=1 -Wformat-extra-args -Wformat-security -Wformat-zero-length -Wchar-subscripts -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wlogical-not-parentheses -Wlogical-op -Wmissing-braces -Wmissing-field-initializers -Wsuggest-attribute=noreturn -Wno-inline -Wno-long-long -Wnonnull -Wodr -Woverflow -Wpacked -Wparentheses -Wpointer-arith -Wredundant-decls -Wreturn-type -Wsequence-point -Wshadow -Wshift-count-negative -Wshift-count-overflow -Wsign-compare -Wsign-conversion -Wsizeof-array-argument -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-overflow -Wswitch -Wswitch-bool -Wswitch-default -Wswitch-enum -Wtrigraphs -Wundef -Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wunknown-pragmas -Wwrite-strings -Wabi-tag -Wcast-qual -Wd
[Bug c++/70770] constexpr expansion Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70770 --- Comment #2 from Mira Fontan --- Created attachment 38333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38333&action=edit preprocessed file
[Bug tree-optimization/70771] New: ICE on valid code at -O3 on x86_64-linux-gnu in operator[], at vec.h:714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70771
Bug ID: 70771
Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
operator[], at vec.h:714
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 5.3.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160423 (experimental) [trunk revision 235384] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.3 -O3 small.c; ./a.out
$
$ gcc-trunk -O3 small.c
small.c: In function ‘main’:
small.c:18:1: internal compiler error: in operator[], at vec.h:714
main ()
^~~~
0xba5e89 vec::operator[](unsigned int)
../../gcc-source-trunk/gcc/vec.h:714
0xba5e89 gimple_phi_arg_edge
../../gcc-source-trunk/gcc/gimple.h:4339
0xba5e89 replace_uses_by(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/tree-cfg.c:1818
0xba60b1 gimple_merge_blocks
../../gcc-source-trunk/gcc/tree-cfg.c:1938
0x74cf75 merge_blocks(basic_block_def*, basic_block_def*)
../../gcc-source-trunk/gcc/cfghooks.c:787
0xbaecc4 cleanup_tree_cfg_bb
../../gcc-source-trunk/gcc/tree-cfgcleanup.c:660
0xbaf598 cleanup_tree_cfg_1
../../gcc-source-trunk/gcc/tree-cfgcleanup.c:710
0xbaf598 cleanup_tree_cfg_noloop
../../gcc-source-trunk/gcc/tree-cfgcleanup.c:761
0xbaf598 cleanup_tree_cfg()
../../gcc-source-trunk/gcc/tree-cfgcleanup.c:812
0xa9ad74 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1921
0xa9b7cb execute_todo
../../gcc-source-trunk/gcc/passes.c:2020
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
int a, b, c, d;
static void
fn1 ()
{
for (b = 0; b < 1; b++)
for (c = 0; c < 1; c++)
{
if (a)
break;
b = 1;
}
for (;;)
;
}
int
main ()
{
if (d)
fn1 ();
return 0;
}
[Bug c/70772] New: Wrong warning about unspecified behavior for comparison with string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70772
Bug ID: 70772
Summary: Wrong warning about unspecified behavior for
comparison with string literal
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
While compiling such program:
int main()
{
"abc" == "def";
}
I get this warning:
$ gcc -Wall -Wno-unused-value example.c
example.c: In function ‘main’:
example.c:3:9: warning: comparison with string literal results in unspecified
behavior [-Waddress]
"abc" == "def";
^~
The warning is wrong, this equality cannot be true.
I understand that the warning is intended to catch comparisons like "abc" ==
"abc" which indeed have an unspecified result. But the current warning is too
promiscuous.
The easy fix is to reformulate closer to "comparison with string literal is
always false or has an unspecified result".
The more thorough fix is to separately catch cases that could be proved to be
false at compile time.
[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684 --- Comment #15 from Jerry DeLisle --- (In reply to Andy May from comment #14) --- snip --- > > Of course, I really appreciate the work that goes into this. I've already > made a local patch file with your fix so that the mxe.cc gcc builds with it > and now our program runs correctly. > Your testing and confirming the original issue is fixed helps greatly, thanks. > I look after a project with ~2.5 million lines of Fortran, some which were > written 40 years ago on punch cards. So many of us learned on those punch cards. (yeeehah!)
[Bug c/70772] Wrong warning about unspecified behavior for comparison with string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70772 --- Comment #1 from Alexander Cherepanov --- clang bug -- https://llvm.org/bugs/show_bug.cgi?id=27495 .
[Bug c++/70755] [ARM] excessive struct alignment for globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70755
--- Comment #2 from Michael Bruck ---
(In reply to Richard Earnshaw from comment #1)
> This is a deliberate design choice. By doing this we gain significant
> benefits from having aligned objects, which helps with data copying and
> other optimizations.
>
> Consider, for example, the object
>
> struct x
> {
> char a;
> char b;
> char c;
> char d;
> };
>
> struct x A, B;
>
> f()
> {
> B = A;
> }
>
> Since the objects are aligned then this function can be optimized to single
> 32-bit load and store operations that work very efficiently.
>
> As you've noticed, it is possible to force the alignment down to the
> architectural minimums by annotations, but for most users it makes little
> difference and the defaults are preferable.
"for most users"
Maybe I should have specified -mcortex-m0 on the command line to illustrate the
point. For most Cortex-M0 users with 16 kB this 300% memory waste is a bad
trade-off.
Can you implement a command line option to deactivate this behavior?
Your reply did not address b) and c), should I open a separate bug to discuss
these?
[Bug c++/70755] [ARM] excessive struct alignment for globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70755
--- Comment #3 from Michael Bruck ---
(In reply to Michael Bruck from comment #2)
> (In reply to Richard Earnshaw from comment #1)
> > This is a deliberate design choice. By doing this we gain significant
> > benefits from having aligned objects, which helps with data copying and
> > other optimizations.
> >
> > Consider, for example, the object
> >
> > struct x
> > {
> > char a;
> > char b;
> > char c;
> > char d;
> > };
> >
> > struct x A, B;
> >
> > f()
> > {
> > B = A;
> > }
> >
> > Since the objects are aligned then this function can be optimized to single
> > 32-bit load and store operations that work very efficiently.
> >
> > As you've noticed, it is possible to force the alignment down to the
> > architectural minimums by annotations, but for most users it makes little
> > difference and the defaults are preferable.
>
> "for most users"
>
> Maybe I should have specified -mcortex-m0 on the command line to illustrate
> the point. For most Cortex-M0 users with 16 kB this 300% memory waste is a
> bad trade-off.
>
> Can you implement a command line option to deactivate this behavior?
>
> Your reply did not address b) and c), should I open a separate bug to
> discuss these?
A struct with only one bool does not derive the benefits described in your
example and should be exempted from this modified alignment for this reason
alone.(In reply to Richard Earnshaw from comment #1)
> This is a deliberate design choice. By doing this we gain significant
> benefits from having aligned objects, which helps with data copying and
> other optimizations.
>
> Consider, for example, the object
>
> struct x
> {
> char a;
> char b;
> char c;
> char d;
> };
>
> struct x A, B;
>
> f()
> {
> B = A;
> }
>
> Since the objects are aligned then this function can be optimized to single
> 32-bit load and store operations that work very efficiently.
>
> As you've noticed, it is possible to force the alignment down to the
> architectural minimums by annotations, but for most users it makes little
> difference and the defaults are preferable.
A struct with only one bool does not derive the benefits described in your
example and should be exempted from this modified alignment for this reason
alone.
[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704 --- Comment #42 from Jakub Jelinek --- Even PATH=/opt/freeware/bin/:$PATH /home/jakub/gcc-6.0.1-RC-20160415/configure --disable-werror --enable-languages=c,c++,fortran,objc --with-gmp=/opt/cfarm --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch --with-included-gettext --enable-checking=release PATH=/opt/freeware/bin/:$PATH make -j48 > LOG 2>&1 & got through comparison without failure (still finishing bootstrap, but compare file already exists).
[Bug target/69143] PowerPC64: aggregate results are badly handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69143 --- Comment #4 from Ramana Radhakrishnan --- (In reply to H.J. Lu from comment #3) > Similar to PR 28831, PR 23782? Indeed, though looks more like a base case for PR28831 than PR23782 at first glance. Ramana
[Bug rtl-optimization/70751] [7 Regression] FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3 since r235184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-23 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan --- Confirmed.
[Bug c++/70768] Increased compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70768 --- Comment #2 from James Almer --- (In reply to Markus Trippelsdorf from comment #1) > Well, you simply need more RAM to compile this testcase, because gcc-6 uses > slightly over 2GB peak, so your machine starts swapping. > On my machine (with 8GB RAM) gcc-6 is actually slightly faster. > > (For gcc-7 you need to configure it with --enable-checking=release to > compare timings.) Tried to assign more RAM to the vm and it indeed fixed the trashing and slowness with gcc-6 and newer. gcc-6/7 uses like 2.1GB of RAM to compile this file whereas gcc-5 uses only 1.6GB. Is this intended/expected, or can it be considered a memory hog?
[Bug c++/70768] Increased compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70768 --- Comment #3 from Markus Trippelsdorf --- (In reply to James Almer from comment #2) > (In reply to Markus Trippelsdorf from comment #1) > > Well, you simply need more RAM to compile this testcase, because gcc-6 uses > > slightly over 2GB peak, so your machine starts swapping. > > On my machine (with 8GB RAM) gcc-6 is actually slightly faster. > > > > (For gcc-7 you need to configure it with --enable-checking=release to > > compare timings.) > > Tried to assign more RAM to the vm and it indeed fixed the trashing and > slowness with gcc-6 and newer. > > gcc-6/7 uses like 2.1GB of RAM to compile this file whereas gcc-5 uses only > 1.6GB. Is this intended/expected, or can it be considered a memory hog? Maybe. gcc-5: phase lang. deferred: 66.28 (84%) usr 2.57 (69%) sys 68.88 (83%) wall 2722388 kB (82%) ggc phase opt and generate : 12.25 (15%) usr 0.92 (25%) sys 13.19 (16%) wall 469818 kB (14%) ggc phase finalize : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc |name lookup: 1.80 ( 2%) usr 0.12 ( 3%) sys 1.99 ( 2%) wall 279075 kB ( 8%) ggc |overload resolution: 58.89 (74%) usr 2.53 (68%) sys 61.26 (74%) wall 2619094 kB (79%) ggc template instantiation : 60.34 (76%) usr 2.66 (72%) sys 62.90 (76%) wall 2791073 kB (84%) ggc TOTAL : 79.35 3.7283.14 3325932 kB gcc-6: phase lang. deferred: 74.36 (87%) usr 3.38 (72%) sys 77.73 (86%) wall 3725459 kB (84%) ggc phase opt and generate : 10.30 (12%) usr 1.17 (25%) sys 11.46 (13%) wall 572078 kB (13%) ggc |name lookup: 2.18 ( 3%) usr 0.27 ( 6%) sys 2.19 ( 2%) wall 134001 kB ( 3%) ggc |overload resolution: 62.60 (73%) usr 3.25 (69%) sys 66.14 (73%) wall 3543436 kB (80%) ggc template instantiation : 64.42 (75%) usr 3.42 (72%) sys 67.78 (75%) wall 3798026 kB (86%) ggc TOTAL : 85.52 4.7290.24 4424695 kB
[Bug gcov-profile/70773] New: Profiling makes sudoku solver slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 Bug ID: 70773 Summary: Profiling makes sudoku solver slower Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: tulipawn at gmail dot com Target Milestone: --- Created attachment 38334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38334&action=edit .c, .i and .gcda files Compiling the attached sudoku solver the usual way and running the benchmark: $ gcc -O3 -Wall sudoku.c -o sudokuC $ time ./sudokuC 1>&2 > /dev/null takes 1.25s, whereas doing a profile build: $ gcc -O3 -Wall sudoku.c -o sudokuC -fprofile-generate $ time ./sudokuC 1>&2 > /dev/null $ gcc -O3 -Wall sudoku.c -o sudokuC -fprofile-use $ time ./sudokuC 1>&2 > /dev/null takes 1.5s which means it's 20% slower. Probably shouldn't happen.
[Bug c++/70768] Increased compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70768 --- Comment #4 from Markus Trippelsdorf --- This is the file in question: https://github.com/ericniebler/range-v3/blob/master/test/algorithm/transform.cpp
[Bug c++/70353] [5 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353 Markus Trippelsdorf changed: What|Removed |Added CC||mira.fontan at gmail dot com --- Comment #21 from Markus Trippelsdorf --- *** Bug 70770 has been marked as a duplicate of this bug. ***
[Bug c++/70770] [5 Regression] constexpr expansion Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70770 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE Summary|constexpr expansion |[5 Regression] constexpr |Internal compiler error |expansion Internal compiler ||error --- Comment #3 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 70353 ***
[Bug c++/70774] New: constexpr function with reference parameter gives reinterpret_cast from integer to pointer error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70774
Bug ID: 70774
Summary: constexpr function with reference parameter gives
reinterpret_cast from integer to pointer error
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steven.spark at gmail dot com
Target Milestone: ---
Here is the simplified code:
--
#define PORTX (*(volatile unsigned char *)(0x1B))
constexpr volatile unsigned char * testRef(volatile unsigned char & x) {
return &x;
}
volatile unsigned char* addr = testRef(PORTX); /// OK
constexpr volatile unsigned char* addr2 = testRef(PORTX); /// error:
/// reinterpret_cast from integer to pointer
--
This compiled without problem with gcc 4.8.1, but fails with 4.9.2.
Using built-in specs.
COLLECT_GCC=avr-g++.exe
Target: avr
Configured with:
/home/toolsbuild/workspace/avr8-gnu-toolchain/src/gcc/configure
LDFLAGS=-L/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86-hostlibs/lib
CPPFLAGS= --target=avr --host=i686-w64-mingw32 --build=x86_64-pc-linux-gnu
--prefix=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86
--libdir=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86/lib
--enable-languages=c,c++ --with-dwarf2 --enable-doc --disable-shared
--disable-libada --disable-libssp --disable-nls --with-avrlibc=yes
--with-mpfr=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86-hostlibs
--with-gmp=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86-hostlibs
--with-mpc=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-win32_x86-hostlibs
--enable-win32-registry=avrtoolchain
--with-pkgversion=AVR_8_bit_GNU_Toolchain_3.5.0_1662
--with-bugurl=http://www.atmel.com
Thread model: single
gcc version 4.9.2 (AVR_8_bit_GNU_Toolchain_3.5.0_1662)
I'm writing code for AVR micro controller where every byte counts, so compile
time evaluation is key. I was trying out the new Atmel Studio 7 IDE which comes
with the new 4.9.2 gcc when I came across this problem. In my real world code
I'm using constexpr constructor and constexpr instances of my pin handler class
- to make life easier and encapsulate port, data direction and other registers.
Note: If I use pointer instead of reference then it compiles fine:
constexpr volatile unsigned char * testAddr(volatile unsigned char * x) {
return x;
}
constexpr volatile unsigned char* addr3 = testAddr(&PORTX); /// OK
Why is this? Am I doing something wrong? How can I use (port) references in
constexpr functions?
This also does NOT work:
constexpr volatile unsigned char& ref5 = PORTX; /// error
[Bug tree-optimization/70775] New: ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70775
Bug ID: 70775
Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
Segmentation fault
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 5.3.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160423 (experimental) [trunk revision 235384] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-5.3 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn2’:
small.c:17:1: internal compiler error: Segmentation fault
fn2 ()
^~~
0xb6718f crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0x74e89c vec_safe_length
../../gcc-source-trunk/gcc/vec.h:524
0x74e89c loop_depth
../../gcc-source-trunk/gcc/cfgloop.h:444
0x74e89c flow_loop_nested_p(loop const*, loop const*)
../../gcc-source-trunk/gcc/cfgloop.c:64
0xdb7837 vect_is_simple_reduction
../../gcc-source-trunk/gcc/tree-vect-loop.c:2627
0xdb9011 vect_force_simple_reduction
../../gcc-source-trunk/gcc/tree-vect-loop.c:3026
0xdb9011 vect_analyze_scalar_cycles_1
../../gcc-source-trunk/gcc/tree-vect-loop.c:865
0xdbc807 vect_analyze_scalar_cycles
../../gcc-source-trunk/gcc/tree-vect-loop.c:939
0xdbc807 vect_analyze_loop_2
../../gcc-source-trunk/gcc/tree-vect-loop.c:1845
0xdbc807 vect_analyze_loop(loop*)
../../gcc-source-trunk/gcc/tree-vect-loop.c:2264
0xdd7611 vectorize_loops()
../../gcc-source-trunk/gcc/tree-vectorizer.c:532
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$
--
struct S
{
int f1;
int f2;
} a;
int b, c, d, e;
short f;
int
fn1 (int p1, unsigned p2)
{
return p1 + p2;
}
void
fn2 ()
{
struct S g;
int h;
for (; c; c++)
for (f = -3; f < 3; f = fn1 (f, 8))
{
a.f1 = e;
if (b)
a = g;
else
for (; h; h++)
d = b;
}
}
[Bug c++/70776] New: ICE on invalid code on x86_64-linux-gnu: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70776
Bug ID: 70776
Summary: ICE on invalid code on x86_64-linux-gnu: Segmentation
fault (program cc1plus)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current GCC trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes.
It seems to affect at least all GCC versions 4.4.x and later.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160423 (experimental) [trunk revision 235384] (GCC)
$
$ g++-trunk small.cpp -c
g++-trunk: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
template < int > struct A;
template < typename, typename = void > struct B;
template < typename T >
struct B < T, typename A < B < T >::value >::type >
{
B < int > b; // OK: B < int > *b;
};
[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684 --- Comment #16 from Jerry DeLisle --- Author: jvdelisle Date: Sun Apr 24 05:07:21 2016 New Revision: 235391 URL: https://gcc.gnu.org/viewcvs?rev=235391&root=gcc&view=rev Log: 2016-04-23 Jerry DeLisle PR libgfortran/70684 * io/list_read (check_buffers): Add '\r' to check for end of line. factor. * gfortran.dg/list_read_14.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/list_read_14.f90 Modified: branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/libgfortran/ChangeLog branches/gcc-6-branch/libgfortran/io/list_read.c
