[Bug target/58067] ICE in GFortran recog.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- You can add -mtls-dialect=gnu2 to -fpic and -mcmodel=large.
[Bug c++/58047] parse error with typedef introduced from base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |fabien at gcc dot gnu.org --- Comment #4 from fabien at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #3) Seems closely related to PR37140. Can be a dup indeed, but let it open. This way, I will not forget to check this tescase when I work on PR37140 -- which I generally don't for duplicates.
[Bug testsuite/58070] New: gcc.c-torture: useless check -O3 -fomit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070 Bug ID: 58070 Summary: gcc.c-torture: useless check -O3 -fomit-frame-pointer Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de The -fomit-frame-pointer is now (since 4.6) the default at -O3. Therefore I would suggest to change that to test -O3 and -O3 -fno-omit-frame-pointer instead.
[Bug target/53976] [SH] Unnecessary clrt after bt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #2)
Interestingly, the following function shows some improved behavior (notice
the removed volatile mem store):
int test_2_1 (int* a, int b, int c)
{
a[1] = b != 0;
if (b == 0)
a[10] = c;
return b == 0;
}
-O2 -m2a:
tst r5,r5
movrt r1
mov.l r1,@(4,r4)
bf .L4
mov.l r6,@(40,r4)
.L4:
rts
movtr0
This is already minimal.
However, for non-SH2A it's still the same:
tst r5,r5
mov #-1,r1
negcr1,r1
tst r5,r5
bf/s.L4
mov.l r1,@(4,r4)
mov.l r6,@(40,r4)
tst r5,r5
.L4:
rts
movtr0
One of the problems in this case is that negc clobbers the T bit. Another
alternative
movt r0
xor#1,r0
should be selected here. This could be done by looking at the insns around the
negc-movrt and check whether some insn after negc-movrt sets the T bit in the
same way as it was set before the negc-movrt. In this case not clobbering the
T bit would eliminate the redundant test. However, if this pattern occurs in a
loop or pressure on R0 is high, using negc and the redundant test is probably
going to be better.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #27 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Martin Jambor from comment #24) Created attachment 30594 [details] Proposed patch I think it would be safe to put my initial test case under gcc/testsuite/gcc.target/arm/pr58041.c It passes with your patch at least in my environment.
[Bug testsuite/58070] gcc.c-torture: useless check -O3 -fomit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- This is target dependent.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #187 from Jan Hubicka hubicka at gcc dot gnu.org --- WPA time report Execution times (seconds) phase setup : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 1398 kB ( 0%) ggc phase opt and generate : 80.79 (13%) usr 1.01 ( 3%) sys 81.96 (12%) wall 315727 kB (25%) ggc phase stream in : 283.33 (45%) usr 7.82 (24%) sys 292.12 (44%) wall 940315 kB (74%) ggc phase stream out: 261.66 (42%) usr 23.14 (72%) sys 287.88 (43%) wall 7534 kB ( 1%) ggc garbage collection : 14.45 ( 2%) usr 0.02 ( 0%) sys 14.48 ( 2%) wall 0 kB ( 0%) ggc callgraph optimization : 2.55 ( 0%) usr 0.00 ( 0%) sys 2.55 ( 0%) wall 33 kB ( 0%) ggc ipa cp : 10.45 ( 2%) usr 0.36 ( 1%) sys 10.81 ( 2%) wall 456287 kB (36%) ggc ipa inlining heuristics : 42.12 ( 7%) usr 1.06 ( 3%) sys 43.27 ( 7%) wall 1485346 kB (117%) ggc ipa lto gimple in : 0.56 ( 0%) usr 0.25 ( 1%) sys 0.87 ( 0%) wall 0 kB ( 0%) ggc ipa lto gimple out : 21.77 ( 3%) usr 1.72 ( 5%) sys 23.53 ( 4%) wall 0 kB ( 0%) ggc ipa lto decl in : 183.90 (29%) usr 4.77 (15%) sys 189.46 (29%) wall 959299 kB (76%) ggc ipa lto decl out: 231.70 (37%) usr 10.78 (34%) sys 242.73 (37%) wall 0 kB ( 0%) ggc ipa lto cgraph I/O : 14.38 ( 2%) usr 1.57 ( 5%) sys 15.99 ( 2%) wall 2405760 kB (190%) ggc ipa lto decl merge : 32.16 ( 5%) usr 0.00 ( 0%) sys 32.24 ( 5%) wall 8268 kB ( 1%) ggc ipa lto cgraph merge: 28.72 ( 5%) usr 0.06 ( 0%) sys 28.81 ( 4%) wall 135235 kB (11%) ggc whopr wpa : 9.57 ( 2%) usr 0.05 ( 0%) sys 9.62 ( 1%) wall 7537 kB ( 1%) ggc whopr wpa I/O : 2.07 ( 0%) usr 10.62 (33%) sys 15.49 ( 2%) wall 0 kB ( 0%) ggc whopr partitioning : 3.26 ( 1%) usr 0.03 ( 0%) sys 3.29 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 5.55 ( 1%) usr 0.05 ( 0%) sys 5.62 ( 1%) wall 0 kB ( 0%) ggc ipa profile : 2.82 ( 0%) usr 0.05 ( 0%) sys 2.88 ( 0%) wall 0 kB ( 0%) ggc ipa pure const : 6.25 ( 1%) usr 0.13 ( 0%) sys 6.38 ( 1%) wall 0 kB ( 0%) ggc unaccounted todo: 13.25 ( 2%) usr 0.28 ( 1%) sys 13.58 ( 2%) wall 0 kB ( 0%) ggc TOTAL : 625.7931.97 661.97 1264976 kB
[Bug testsuite/58070] gcc.c-torture: useless check -O3 -fomit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070 --- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Andreas Schwab from comment #1) This is target dependent. OK, my target is --target=arm-eabi What exactly is target dependent?
[Bug testsuite/58070] gcc.c-torture: useless check -O3 -fomit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org --- The default state of -fomit-frame-pointer.
[Bug c++/58059] gcc-4.7.2-r1 - g++: internal compiler error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- The non-preprocessed test case crashes g++ 4.7, 4.8, and 4.9 for me on x86_64-linux.
[Bug libgcc/58061] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- This is clearly a duplicate of PR57848. Then there is PR57897 which crashes with a different error message but still on #pragma target and mingw, I believe that one is at least closely related.
[Bug fortran/58064] Cannot compile gcc-4.8.1 by gcc-3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58064 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- init2.c:37: MPFR assertion failed: (64 - 0) == ((64 - 0)/8) * 8 sizeof(mp_limb_t) == ((64 - 0)/8) seems your mpfr library is broken
[Bug c++/58071] New: Premature instantiation of default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58071
Bug ID: 58071
Summary: Premature instantiation of default argument
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
If a function is declared with a default argument of a template type the
compiler fails if the constructor cannot be instantiated at the point of
definition of the function.
As I understand it 8.3.6p5 states The names in the default argument are
bound, and the semantic constraints are checked, at the point where the default
argument appears.
So the compiler can instantiate the *class* definition but I do not believe it
should be instantiating the constructor body unless and until the default
argument is actually *used*.
The code below compiles and links with Clang and icc (and msvc)
Example:
template typename T
class generic
{
public:
generic() { T p; test(p); }
generic(T *) {}
};
class Foo {};
void f(genericFoo const = genericFoo());
int main() {}
g++ -Wall -Wextra 8.3.6p5.cpp
8.3.6p5.cpp: In instantiation of 'genericT::generic() [with T = Foo]':
8.3.6p5.cpp:11:44: required from here
8.3.6p5.cpp:5:20: error: 'test' was not declared in this scope
[Bug c++/58071] Premature instantiation of default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58071 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- We may have a Dup of this. I'll check later today if nobody beats me.
[Bug testsuite/58070] gcc.c-torture: useless check -O3 -fomit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58070 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- x86_64 is not the only target which GCC supports. Some other targets disable omit-frame-pointer.
[Bug c++/58047] parse error with typedef introduced from base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- You should ;) Seriously, when committing a patch I think that it's a good practice to double check it on the duplicates, even if everything goes well consider adding sufficiently different testcases coming from the dups. The division of labor between triaging and fixing will never be perfect! Thanks for working on this!
[Bug rtl-optimization/57708] [4.8 regression] function clobbers callee saved register on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot gnu.org
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #48 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reopened as the test gcc.c-torture/execute/pr51447.c still fails on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00136.html ). The test succeeds with the patch for pr10901 at http://gcc.gnu.org/bugzilla/attachment.cgi?id=26370 .
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #49 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #48) Reopened as the test gcc.c-torture/execute/pr51447.c still fails on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00136.html ). The test succeeds with the patch for pr10901 at http://gcc.gnu.org/bugzilla/attachment.cgi?id=26370 . As Andrew noted above, that was recorded in PR 10901 :) [I have a PPC patch-in-progress - add 10901 to your list, and I'll post to there when ready to test].
[Bug tree-optimization/57993] [4.9 Regression] ICE: verify_ssa failed (definition in block n does not dominate use in block m)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993 --- Comment #9 from Bill Schmidt wschmidt at gcc dot gnu.org --- I missed a couple of candidate replacements in the previous fix; these are fixed in r201466.
[Bug c++/58072] New: [C++11] Error messages involving user-defined literals are poor (refer to tokens)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58072
Bug ID: 58072
Summary: [C++11] Error messages involving user-defined literals
are poor (refer to tokens)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 3dw4rd at verizon dot net
Created attachment 30603
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30603action=edit
Patch triggering a range of bad errors.
This bug is branched from PR58057.
in that bug a file such as this:
---
...
externCvoid*blah_4(void*);//error: expected unqualified-id before
user-defined string literal
extern\x43void*blah_5(void*); //error: expected unqualified-id before
user-defined string literal
int main() {}
---
gives errors like this:
blah.cpp:12:7: error: expected unqualified-id before ‘STRING_USERDEF’ token
externCvoid*blah_4(void*);//error: expected unqualified-id before
user-defined string literal
^
blah.cpp:14:7: error: expected unqualified-id before ‘STRING_USERDEF’ token
extern\x43void*blah_5(void*); //error: expected unqualified-id before
user-defined string literal
Referring to internal tokens is not helpful to users.
Let's fix this.
[Bug c++/58072] [C++11] Error messages involving user-defined literals are poor (refer to tokens)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58072 --- Comment #1 from Ed Smith-Rowland 3dw4rd at verizon dot net --- Created attachment 30604 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30604action=edit Patch c_parse_error to catch and describe user-defined literal tokens explicitly. gcc/c-family: 2013-08-03 Ed Smith-Rowland 3dw...@verizon.net PR c++/58072 * c-common.c (c_parse_error): Catch user-defined literal tokens and provide useful error strings. Waiting for testing because I'm sure there will be testsuite fallout. We get this: ed@bad-horse:~$ ./bin_literal/bin/g++ -fdiagnostics-color -std=c++1y blah.cpp -o blah blah.cpp:6:8: error: expected unqualified-id before user-defined character literal extern 'c'void*blah(void*); ^ blah.cpp:7:8: error: expected unqualified-id before user-defined character literal extern L'c'void*Lblah(void*); ^ blah.cpp:8:8: error: expected unqualified-id before user-defined character literal extern u'c'void*ublah(void*); ^ blah.cpp:9:8: error: expected unqualified-id before user-defined character literal extern U'c'void*Ublah(void*); ^ blah.cpp:11:8: error: expected unqualified-id before user-defined string literal extern cvoid*strblah(void*); ^ blah.cpp:12:8: error: expected unqualified-id before user-defined string literal extern Lcvoid*Lstrblah(void*); ^ blah.cpp:13:8: error: expected unqualified-id before user-defined string literal extern ucvoid*ustrblah(void*); ^ blah.cpp:14:8: error: expected unqualified-id before user-defined string literal extern Ucvoid*Ustrblah(void*); ^ blah.cpp:15:8: error: expected unqualified-id before user-defined string literal extern u8cvoid*u8strblah(void*); ^ blah.cpp:17:8: error: expected unqualified-id before numeric constant extern 123void*ULLblah(void*); ^ blah.cpp:18:8: error: expected unqualified-id before numeric constant extern 123.456void*Ldblblah(void*); ^
[Bug fortran/56666] Suppression flag for DO loop at (1) will be executed zero times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug c/58073] New: Suboptimal optimisation of ((x 0x70) == 0x00 (x 0x70) == 0x10 (x 0x70) == 0x20) on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58073 Bug ID: 58073 Summary: Suboptimal optimisation of ((x 0x70) == 0x00 (x 0x70) == 0x10 (x 0x70) == 0x20) on x86_64 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Created attachment 30605 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30605action=edit Demonstration source code When the attached demo code is compiled with gcc-4.8.1, two of the cases optimise fine and the third case is optimised suboptimally - probably because it initially matches the optimisation for the second case. Going through the cases individually for 'shift' being 4: (1) return (mask(d) == (0x0 shift)); This is rendered as a single TEST instruction in x86_64 asm: 0: f6 07 70testb $0x70,(%rdi) 3: 0f 94 c0sete %al 6: c3 retq which is good. (2) return (mask(d) == (0x0 shift) || mask(d) == (0x1 shift)); This is also rendered as a single TEST instruction: 10: f6 07 60testb $0x60,(%rdi) 13: 0f 94 c0sete %al 16: c3 retq which is again good. The problem comes with the third case: (3) return (mask(d) == (0x0 shift) || mask(d) == (0x1 shift) || mask(d) == (0x2 shift)); This is rendered as: 20: 8b 17 mov(%rdi),%edx 22: b8 01 00 00 00 mov$0x1,%eax 27: f6 c2 60test $0x60,%dl 2a: 74 09 je 35 foo3+0x15 2c: 83 e2 70and$0x70,%edx 2f: 83 fa 20cmp$0x20,%edx 32: 0f 94 c0sete %al 35: f3 c3 repz retq which is odd. I would expect the thing to be turned into MOV, AND, CMP, SETE, RETQ since the numbers it is checking for lie adjacent to each other, starting from zero. I think what has happened is that the first two comparisons matched the optimisation for case (2) - resulting in three extra instructions. The compilation command line was: gcc -O2 -c foo.c -Wall objdump -d foo.o The compiler version: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC) as supplied by Fedora: gcc-4.8.1-1.fc19.x86_64
[Bug c/58073] Suboptimal optimisation of ((x 0x70) == 0x00 (x 0x70) == 0x10 (x 0x70) == 0x20) on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58073 --- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com --- Interestingly, the suboptimality shifts if the 'shift' value in the demo program is changed to 0: Going through the cases individually:: (1) return (mask(d) == (0x0 shift)); This is rendered as a single TEST instruction in x86_64 asm: 0: f6 07 07testb $0x7,(%rdi) 3: 0f 94 c0sete %al 6: c3 retq which is fine. (2) return (mask(d) == (0x0 shift) || mask(d) == (0x1 shift)); is rendered as: 10: 8b 07 mov(%rdi),%eax 12: 83 e0 07and$0x7,%eax 15: 83 f8 01cmp$0x1,%eax 18: 0f 96 c0setbe %al 1b: c3 retq which is not what I'd expect. What happened to the single TEST instruction that was produced for shift = 4? And then: (3) return (mask(d) == (0x0 shift) || mask(d) == (0x1 shift) || mask(d) == (0x2 shift)); which is rendered as: 20: 8b 07 mov(%rdi),%eax 22: 83 e0 07and$0x7,%eax 25: 83 f8 02cmp$0x2,%eax 28: 0f 96 c0setbe %al 2b: c3 retq which is good (and which is similar to what I'd've expected case 3 to generate when shift = 4).
[Bug c++/58057] gcc lexer cannot parse extern \x43 void blah() with option -std=c++0x;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, let's close this one. The diagnostic issue is tracked in PR58072.
[Bug c++/58072] [C++11] Error messages involving user-defined literals are poor (refer to tokens)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58072 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-08-03 Assignee|unassigned at gcc dot gnu.org |3dw4rd at verizon dot net Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks. As soon as you are ready with the testsuite tweaks, just send it to gcc-patches CC Jason.
[Bug c++/58074] New: [C++11] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074
Bug ID: 58074
Summary: [C++11] __is_trivial intrinsic fails for deleted
members and for non-trivial copy-c'tors
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
The following observations where originally found by testing the
std::is_trivial trait from type_traits, but the actual problem seems to
result from the __is_trivial intrinsic, therefore I created a non-library issue
from this.
gcc 4.9.0 20130616 (experimental) when compiled with the flags
-std=c++11 -Wall -pedantic
rejects the following code:
//-
struct Trivial
{
Trivial() = delete;
};
struct NonTrivial
{
NonTrivial() = default;
NonTrivial(NonTrivial) = default;
NonTrivial operator=(NonTrivial) = default;
};
static_assert(__is_trivial(Trivial), Ouch);
static_assert(!__is_trivial(NonTrivial), Ouch);
//-
main.cpp|13|error: static assertion failed: Ouch|
main.cpp|14|error: static assertion failed: Ouch|
The first test should be valid, because 12.1 p4 says
A default constructor is trivial if it is **not user-provided** and if [..]
and according to 8.4.2 p4
A function is user-provided if it is user-declared and **not explicitly
defaulted or deleted** on its first declaration..
The deleted default constructor should not prevent type Trivial of being
trivial (Maybe this part of the problem is related to bug 52707, but I'm not
sure).
The second test should succeed, because according to 12.8 p12:
A copy/move constructor for class X is trivial if it is not user-provided,
**its declared parameter type is the same as if it had been implicitly
declared**, and if [..]
and 12.8 p25, respectively:
A copy/move assignment operator for class X is trivial if it is not
user-provided, **its declared parameter type is the same as if it had been
implicitly declared**, and if [..]
The copy-constructor/assignment operator of NonTrivial do both not have the
parameter type (according to the definition of function parameter types as of
8.3.5) as if it had been implicitly declared.
[Bug c++/58074] [C++11] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- ... and the issue is one more level deeper, because __is_trivial just uses the internal trivial_type_p. I mean, it should be pretty easy to construct testcases not involving __is_trival at all but handled incorrectly: outside the implementation of the intrinsics, the internal pod_type_p itself is, predictably, std_layout_type_p trivial_type_p and then anything depending on POD-ness is sensitive.
[Bug c++/58046] template operator= in SFINAE class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58046
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com ---
The same problem occurs for gcc 4.9.0 20130616 (experimental) as well.
A version without any dependencies to the library headers:
//
templatebool, class T = void
struct enable_if {};
templateclass T
struct enable_iftrue, T
{
using type = T;
};
templateclass T
struct is_true
{
static constexpr bool value = true;
};
extern void* enabler;
template typename T, typename enable_ifis_trueT::value::type* = enabler
class A
{
public:
A()
{}
template typename U
A operator=( AU rhs )
{
return *this;
}
};
int main()
{
Aint a_i;
Adouble a_d;
a_i = a_d;
}
//-
Gives as well:
main.cpp|36|required from here|
main.cpp|36|internal compiler error: in unify, at cp/pt.c:17325|
It is interesting to note that a variation of this sfinae construction doesn't
produce the ICE:
template typename T, typename enable_ifis_trueT::value, bool::type =
false
class A
{
public:
A()
{}
template typename U
A operator=( AU rhs )
{
return *this;
}
};
int main()
{
Aint a_i;
Adouble a_d;
a_i = a_d;
}
[Bug c++/58062] [C++11] bogus __func__ lookup in lambda body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- The fact that MSVC is giving the expected error is a bit misleading. It rejects it, because it still is not conforming and is not aware of __func__ in any context. But I agree that correct MSVC behaviour can be deduced when __FUNCTION__ is used instead. While I agree that gcc is not conforming I would like to add that many existing compilers do not and to my knowledge there is an core language issue planned in regard to exactly this problem, so I recommend to defer working on that.
[Bug c++/58063] default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com ---
The behavior looks indeed odd to me (and I can confirm it for gcc 4.9 as well).
I suspect at the moment that it is somehow related to the very specific
definition of std::cout, because when I try to mimic the problem for a model
type like the following, I cannot produce this effect:
//-
#include iostream
struct my_ostream
{
my_ostream(){}
virtual ~my_ostream() {}
operator void*() const { return const_castmy_ostream*(this); }
bool operator!() const { return false; }
private:
my_ostream(const my_ostream);
my_ostream operator=(const my_ostream);
} my_cout;
my_ostream operator(my_ostream os, const char* s)
{
std::cout s;
return os;
}
void f(bool x = !(std::cout hi!\n)) {
std::cout x '\n';
}
void f2(bool x = !(my_cout hi!\n)) {
std::cout x '\n';
}
int main() {
f();
std::cout --\n;
f2();
}
//-
gives the output:
quote
hi!
hi!
0
--
hi!
0
/quote
Looking at the generate assembly (mingw 64 but), I see the following relevant
lines:
0x004017ADlea0x7a86d(%rip),%rdx# 0x47c021
std::piecewise_construct+1
0x004017B4mov0x7e4a5(%rip),%rcx# 0x47fc60 .refptr._ZSt4cout
0x004017BBcallq 0x4624c0 std::operator std::char_traitschar
(std::basic_ostreamchar, std::char_traitschar , char const*)
0x004017C0mov%rax,%rbx
0x004017C3lea0x7a857(%rip),%rdx# 0x47c021
std::piecewise_construct+1
0x004017CAmov0x7e48f(%rip),%rcx# 0x47fc60 .refptr._ZSt4cout
0x004017D1callq 0x4624c0 std::operator std::char_traitschar
(std::basic_ostreamchar, std::char_traitschar , char const*)
0x004017D6mov(%rax),%rax
0x004017D9sub$0x18,%rax
0x004017DDmov(%rax),%rax
0x004017E0add%rbx,%rax
0x004017E3mov%rax,%rcx
0x004017E6callq 0x433f60 std::basic_ioschar, std::char_traitschar
::operator!() const
0x004017EBmovzbl %al,%eax
0x004017EEmov%eax,%ecx
[Bug fortran/58027] Arithmetic overflow converting ... in PARAMETER triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58027 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-03 Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org --- The problem is that the error raised in arith_error does not get emitted, and the function gets passed to gfc_conv_array_initializer, where it ICEs. I played around this a little bit. The problem is that an obvious thing like issuing a gfc_error_now in arith_error leads to regressions (like unclassifiable statements) in boz_4.f90. Putting in a specific error for this case where the ICE occurs seems hackish, to put it mildly.
[Bug c++/57138] [4.8 Regression][DR 1430] ICE with pack expansion and alias template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57138 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Summary|[4.8/4.9 Regression] ICE in |[4.8 Regression][DR 1430] |cp_parser_class_specifier |ICE with pack expansion and |with variadic templates,|alias template |using declarations | --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- ICE fixed for 4.9 with r201469.
[Bug c++/51239] [DR 1430] ICE with variadic template alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51239 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Patch applied as r201469. Leaving suspended until the DR resolution is final.
[Bug c++/58063] default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- The standard streams are indeed special, being constructed once and never destroyed, see libstdc++-v3/src/c++98/ios_init.cc. I suppose a minimal reproducer could involve a file scope static of some sort...
[Bug c++/53756] [C++1y] ICE: in gen_type_die_with_usage, at dwarf2out.c:18774 with -g and operator auto ()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53756 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Jason, looks like some bits related to debugging are missing from the work on return type deduction and people cannot debug uses of the new facility. gen_type_die_with_usage gets a TEMPLATE_TYPE_PARM which doesn't know how to handle. Is it just matter of somehow having an equivalent of is_auto and using a DW_TAG_unspecified_type? Or we shouldn't have a TEMPLATE_TYPE_PARM at all at this point? (I don't see what else) ... or you prefer to look a bit into this? ;)
[Bug c++/58063] default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Paolo Carlini from comment #2) I suppose a minimal reproducer could involve a file scope static of some sort... I'm a bit confused by your reply, Paolo: Isn't my_cout also a file scope static? (Even, if I declare it to have static linkage, it still behaves differently compared to std::cout)
[Bug c++/58063] default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Sorry, I didn't study it in sufficient detail. Anyway, no mysteries, this is free software: libstdc++-v3/src/c++98/ios_init.cc etc.
[Bug c++/58063] default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Ah, in case isn't obvious already: it only happens when the I/O expression has the ! operator in front.
[Bug c++/58063] default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
--- Comment #6 from Daniel Krügler daniel.kruegler at googlemail dot com ---
(In reply to Paolo Carlini from comment #5)
Ah, in case isn't obvious already: it only happens when the I/O expression
has the ! operator in front.
I suspected that and ensured that I added a similar operator! to my ostream
model type, but this hadn't any impact on the outcome for that type. Further, I
don't understand how it is related to ostream initialization, because the issue
also occurs when we invert the order of the function calls:
int main() {
f2();
std::cout --\n;
f();
}
gives me:
quote
hi!
0
--
hi!
hi!
0
/quote
Are you sure that this is not due to improper code generation?
[Bug c++/58063] default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- I'm not at all sure! But it happens with -O0 too, right?, thus at this point the front-end seems more likely than the back-end, I would not change the Component from c++ to something else. In any case we badly need a reduced testcase ;)
[Bug c++/58063] default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 --- Comment #8 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Paolo Carlini from comment #7) But it happens with -O0 too, right? Yes. In any case we badly need a reduced testcase ;) I agree. Unfortunately I'm on vacations from tomorrow on (1 week), so I cannot look into it until next week.
[Bug c++/58063] default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- Your help is always very appreciated, Daniel. Here we have plenty of work to do anyway, if when you will back the bug will be unchanged, consider helping more.
[Bug target/56979] ICE in output_operand: invalid operand for code 'P'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org --- The problem here is that float2 has alignment 8, although this is not it's natural alignment (which would be 4). This argument is passed by value to the routine operator-(float, float2), and the compiler treats float2 as an HFA containing 2 floats; these get allocated to s1 and s2 under the AAPCS VFP rules. On entry to the function, the compiler then tries to store s1 and s2 as a pairwise (64-bit) type to the stack (since the type is 64-bit aligned) -- the latter fails because for this to work the 64-bit type must start with an even numbered register. The AAPCS does not describe what happens when arguments do not have their natural alignment -- most cases will almost certainly not work as expected, particularly if the alignment is greater than the natural stack alignment. Although the compiler shouldn't ICE, it's arguable that passing over-aligned values by value to functions is not supportable (c11, for example, does not support over-aligning function arguments even though it does permit over-aligning some other objects) and that this case is really an ICE on invalid.
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 David Abdurachmanov david.abdurachmanov at gmail dot com changed: What|Removed |Added CC||david.abdurachmanov at gmail dot c ||om --- Comment #17 from David Abdurachmanov david.abdurachmanov at gmail dot com --- Just for the record. I hit the same bug on Cortex-A9 NEON GCC 4.8.1 hard floats, while compiling scipy 0.8.0 RPM. There was not issue on 4.8.0 and pre-4.9.0 w/o NEON as FPU. scipy/spatial/ckdtree.c: In function '__pyx_f_5scipy_7spatial_7ckdtree_7cKDTree___query': scipy/spatial/ckdtree.c:4194:66: internal compiler error: in expand_assignment, at expr.c:4761 (__pyx_v_inf2-side_distances[__pyx_v_inode-split_dim]) = __pyx_f_5scipy_7spatial_7ckdtree_dabs((__pyx_v_inode-split - (__pyx_v_x[__pyx_v_inode-split_dim]))); ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. error: Command gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/build/davidlt/481-ext/a/fc18_armv7hl_gcc481/external/py2-numpy/1.6.1/lib/python2.7/site-packages/numpy/core/include -I/build/davidlt/481-ext/a/fc18_armv7hl_gcc481/external/python/2.7.3/include/python2.7 -c scipy/spatial/ckdtree.c -o build/temp.linux-armv7l-2.7/scipy/spatial/ckdtree.o failed with exit status 1 ### GCC configuration ### Target: armv7hl-redhat-linux-gnueabi Configured with: ../configure --prefix=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1 --disable-multilib --disable-nls --with-zlib=no --enable-languages=c,c++,fortran --enable-gold=yes --enable-ld=default --enable-lto --with-gmp=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1 --with-mpfr=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1 --with-mpc=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1 --with-isl=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1 --with-cloog=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1 --enable-checking=release --build=armv7hl-redhat-linux-gnueabi --host=armv7hl-redhat-linux-gnueabi --enable-libstdcxx-time=rt --enable-bootstrap --enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --enable-linker-build-id --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-cpu=cortex-a9 --with-tune=cortex-a9 --with-arch=armv7-a --with-float=hard --with-fpu=neon --with-abi=aapcs-linux --disable-sjlj-exceptions --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC' CPP=cpp CXXCPP='c++ -E' Thread model: posix
[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065 David Abdurachmanov david.abdurachmanov at gmail dot com changed: What|Removed |Added CC||david.abdurachmanov at gmail dot c ||om --- Comment #5 from David Abdurachmanov david.abdurachmanov at gmail dot com --- malloc() [glibc implementation] default alignment is sizeof(long double) or 2 * sizeof(size_t) if I remember correctly, which is 8 bytes for ARMv7. I think, based on C and C++ standard you have to make sure that alignment is good for whatever primitive type, which means alignment size being the size of the biggest primitive type (long double). Reference bug ticket(9 years old): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795 Quote from C standard (identical or similar exist in C++): The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated).
[Bug go/58075] New: Unable to build go on ia64-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58075 Bug ID: 58075 Summary: Unable to build go on ia64-hp-hpux11.31 Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: pda at freeshell dot org Excuse the lack of further detail, but the message looks pretty self-explanatory. .../gcc-4.7.3/libgo/runtime/proc.c:114:4: error: #error unknown case for SETCONTEXT_CLOBBERS_TLS Is this just a case of go not being ready for this platform yet?
[Bug libgcc/58061] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061 --- Comment #2 from Whitequill Riclo whitequill at abstractions dot me --- This is the first bug I have reported, so I didn't know where to look to see if it has been reported before. Also I can reproduce it over, and over again without fail. I was a little unnerved when I saw the text: Please submit a full bug report, with prepossessed source if appropriate. Please include complete back-trace with any bug report. Did I include enough?
