[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek 2013-04-10 06:54:28 UTC --- Author: jakub Date: Wed Apr 10 06:33:26 2013 New Revision: 197660 URL: http://gcc.gnu.org/viewcvs?rev=197660&root=gcc&view=rev Log: PR c++/56895 * typeck.c (cp_build_binary_op): Call fold_non_dependent_expr_sfinae first before calling maybe_constant_value for warn_for_div_by_zero or invalid shift count warning purposes. * g++.dg/template/arrow3.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/arrow3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog Author: jakub Date: Wed Apr 10 06:37:07 2013 New Revision: 197662 URL: http://gcc.gnu.org/viewcvs?rev=197662&root=gcc&view=rev Log: PR c++/56895 * typeck.c (cp_build_binary_op): Call fold_non_dependent_expr_sfinae first before calling maybe_constant_value for warn_for_div_by_zero or invalid shift count warning purposes. * g++.dg/template/arrow3.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/arrow3.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/typeck.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/56883] error openmp parallel for order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56883 --- Comment #5 from Jakub Jelinek 2013-04-10 06:53:47 UTC --- Author: jakub Date: Wed Apr 10 06:35:48 2013 New Revision: 197661 URL: http://gcc.gnu.org/viewcvs?rev=197661&root=gcc&view=rev Log: Backported from mainline 2013-04-09 Jakub Jelinek PR middle-end/56883 * omp-low.c (expand_omp_for_generic, expand_omp_for_static_nochunk, expand_omp_for_static_chunk): Use simple_p = true in force_gimple_operand_gsi calls when assigning to addressable decls. * c-c++-common/gomp/pr56883.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/gomp/pr56883.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/omp-low.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/56898] stack smashing protector for alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56898 --- Comment #2 from Uros Bizjak 2013-04-10 06:43:52 UTC --- Please post patches to gcc-patches mailing list, as described in [1]. [1] http://gcc.gnu.org/contribute.html
[Bug target/56897] unaligned memory access on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56897 --- Comment #2 from Uros Bizjak 2013-04-10 06:43:14 UTC --- > Attached the diff against trunk. Please post patches to gcc-patches mailing list, as described in [1]. [1] http://gcc.gnu.org/contribute.html
[Bug target/56898] stack smashing protector for alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56898 --- Comment #1 from Martynas Venckus 2013-04-10 03:57:00 UTC --- Created attachment 29846 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29846 gcc-ssp-alpha.diff
[Bug target/56898] New: stack smashing protector for alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56898 Bug #: 56898 Summary: stack smashing protector for alpha Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: marty...@venck.us Hi, The attached diff brings stack smashing protector for alpha by reorganizing soft frame pointer so that locals are below it and grow downwards. In a similar fashion as mips. Martynas.
[Bug target/56897] unaligned memory access on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56897 --- Comment #1 from Martynas Venckus 2013-04-10 03:55:11 UTC --- Created attachment 29845 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29845 gcc-unalign-alpha.diff
[Bug target/56897] New: unaligned memory access on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56897
Bug #: 56897
Summary: unaligned memory access on alpha
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marty...@venck.us
Hi,
After looking at the RTL dumps here and there, I've noticed that
GCC generates unaligned loads in the following manner:
foo = ([reg:X & -8] << (64 - (((reg:FP+reg:Y) & 0x7) << 3))) >> 56
Obviously, we're losing every eighth byte here (consider FP-0,FP-8).
Since FP is aligned, GCC optimizes this to foo = 0. The right way
to do this is:
foo = ([reg:X & -8] << (56 - (((reg:FP+reg:Y-1) & 0x7) << 3))) >> 56
To reproduce, try this out:
unsigned long foo = 0x010203040a0b0c0d;
printf("%02x", *((char *)&foo + 7));
With -O (and onwards) it will turn out to be zero; at every &X+15,
&X+23, etc. Depending on the offset from the frame pointer.
Attached the diff against trunk.
Martynas.
[Bug target/34653] operation performed unnecessarily in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34653 --- Comment #9 from Tony Poppleton 2013-04-10 02:01:27 UTC --- GCC 4.8.0 with -O2 produces something similar to the original, so the regression noted in comment #7 and comment #8 is now resolved. movzbl (%rdi), %eax shrq$4, %rax movqtable(,%rax,8), %rax ret However the original bug from comment #1 is still present.
[Bug rtl-optimization/47521] Unnecessary usage of edx register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521 --- Comment #7 from Tony Poppleton 2013-04-10 01:51:36 UTC --- This appears to be fixed with GCC 4.8.0 and flag -O2. The asm code produced is now exactly as Jeff said in comment #3: .file "test.c" .text .p2align 4,,15 .globl foo .type foo, @function foo: .LFB0: .cfi_startproc testb $16, %dil movl$1, %eax cmovne %edi, %eax ret .cfi_endproc .LFE0: .size foo, .-foo .ident "GCC: (GNU) 4.8.0 20130316 (Red Hat 4.8.0-0.17)" .section.note.GNU-stack,"",@progbits
[Bug rtl-optimization/47477] [4.6/4.7/4.8/4.9 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 --- Comment #13 from Tony Poppleton 2013-04-10 01:44:18 UTC --- The test case appears to be fixed in GCC 4.8.0, compiling with just -S and -O3, the asm output is now a much simpler: .file "test.c" .text .p2align 4,,15 .globl add .type add, @function add: .LFB0: .cfi_startproc andq$-2, %rsi leaq(%rdi,%rsi), %rax ret .cfi_endproc .LFE0: .size add, .-add .ident "GCC: (GNU) 4.8.0 20130316 (Red Hat 4.8.0-0.17)" .section.note.GNU-stack,"",@progbits I don't know if other test cases would reproduce the original bug however.
[Bug target/35926] Pushing / Poping ebx without using it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926 --- Comment #8 from Tony Poppleton 2013-04-10 01:42:20 UTC --- This appears to be fixed in GCC 4.8.0, compiling with just -S and -O3, the asm output is now a much simpler: .file "test.c" .text .p2align 4,,15 .globl add .type add, @function add: .LFB0: .cfi_startproc andq$-2, %rsi leaq(%rdi,%rsi), %rax ret .cfi_endproc .LFE0: .size add, .-add .ident "GCC: (GNU) 4.8.0 20130316 (Red Hat 4.8.0-0.17)" .section.note.GNU-stack,"",@progbits
[Bug c++/54216] Missing diagnostic for ill-formed anonymous enum declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54216
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Paolo Carlini 2013-04-10
00:41:06 UTC ---
Hi Jason. I'm working on this and the patch is trivial but I suspect that quite
a few testcases (in the library too) need adjusting. Thus, before I start to do
that, wanted to ask: is it Ok a pedwarn for the first case:
enum {}; //-std=c++98 or -std=c++11
and an hard error for the other two:
enum class {}; //-std=c++11
enum class { x }; //-std=c++11
? Like:
54216.C:1:6: warning: anonymous enumeration may not be empty [-Wpedantic]
enum {}; //-std=c++98 or -std=c++11
^
54216.C:3:12: error: scoped enumeration without a name
enum class {}; //-std=c++11
^
54216.C:5:12: error: scoped enumeration without a name
enum class { x }; //-std=c++11
^
[Bug c++/54216] Missing diagnostic for ill-formed anonymous enum declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54216 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-10 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.9.0 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2013-04-10 00:36:11 UTC --- Mine.
[Bug c++/56388] catch(...) in lambda rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56388 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-09 Blocks||54367 Ever Confirmed|0 |1
[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791 --- Comment #1 from John David Anglin 2013-04-09 23:17:04 UTC --- Introduced in r195702. Guess I didn't do enough testing of PA 1.1. Looks like we need to ban symbolic destinations to work around this bug.
[Bug debug/37132] Debug: No DW_TAG_namelist emitted for NAMELISTS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37132 --- Comment #2 from Tobias Burnus 2013-04-09 23:08:35 UTC --- For gdb-support, see http://sourceware.org/bugzilla/show_bug.cgi?id=15353
[Bug c++/56835] std::promise seems broken on 10.8 lion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835 --- Comment #5 from Jack Howarth 2013-04-09 22:57:00 UTC --- This has been filed with MacPorts as https://trac.macports.org/ticket/38732
[Bug c++/56835] std::promise seems broken on 10.8 lion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835 --- Comment #4 from Jack Howarth 2013-04-09 22:55:27 UTC --- IMHO, this should be closed as invalid since MacPorts is applying unnecessary and invalid patches to gcc 4.8.0.
[Bug target/55487] ICE in mark_jump_label_1, at jump.c:1134 compiling gcc.c-torture/execute/pr51447.c at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55487 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from John David Anglin 2013-04-09 22:24:19 UTC --- Fixed on 4.8 and trunk.
[Bug debug/37132] Debug: No DW_TAG_namelist emitted for NAMELISTS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37132 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2013-04-09 22:18:25 UTC --- Draft patch: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00560.html
[Bug c++/23055] overload resolution does not find templated function (zero -> pointer)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23055 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/56835] std::promise seems broken on 10.8 lion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #3 from Jack Howarth 2013-04-09 20:33:39 UTC --- I can't reproduce this crash with the fink build of gcc 4.8.0 on x86_64-apple-darwin12. Notice that MacPorts is building the their gcc48 package with additional change of... https://trac.macports.org/browser/trunk/dports/lang/gcc48/files/libstdc%2B%2B-configure-timespec.patch to get the _GLIBCXX_USE_CLOCK_MONOTONIC defined in config.h. This is claimed to be in order to get libstdc++ to use nanosleep. However, a different fix was checked in... r192335 | redi | 2012-10-10 19:12:10 -0400 (Wed, 10 Oct 2012) | 6 lines 2012-10-10 Jack Howarth Jonathan Wakely * config/os/bsd/darwin/os_defines.h: Define _GLIBCXX_USE_NANOSLEEP and _GLIBCXX_USE_SCHED_YIELD. * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add comment. which results in nanosleep being used on darwin by default... % cd /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.3.0/libstdc++-v3/src/c++11 % nm thread.o | grep nanosleep U _nanosleep
[Bug c/56882] ICE: when compiling gegl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56882 --- Comment #2 from xperience at interia dot pl 2013-04-09 20:03:30 UTC --- Compiler ICE's during compile phase, without LTO. Previous versions of GCC ie. 4.7.1 or 4.6.3 doesn't ICE, and output of gcc -O3 -mtune=native -march=native -fomit-frame-pointer -pipe -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -floop-parallelize-all -E -v - &1 | grep cc1 is /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/cc1 -E -quiet -v - -march=bdver2 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mno-bmi2 -mtbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -floop-parallelize-all -O3 it seems that compiler will not ICE when i don't have -floop-parallelize-all in my CFLAGS full command from makefile: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../gegl -I../../gegl -I../../gegl/property-types -I../../gegl/property-types -I../../gegl/buffer -I../../gegl/buffer -I../../gegl/opencl -I../../gegl/opencl -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/babl-0.1 -O3 -mtune=native -march=native -fomit-frame-pointer -pipe -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -floop-parallelize-all -mmmx -msse -ftree-vectorize -ffast-math -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -DG_LOG_DOMAIN=\"GEGL-\"__FILE__ -MT gegl-processor.lo -MD -MP -MF .deps/gegl-processor.Tpo -c gegl-processor.c -fPIC -DPIC -o .libs/gegl-processor.o
[Bug c++/51424] [C++11] G++ should diagnose self-delegating constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51424 --- Comment #1 from Andrew Schepler 2013-04-09 19:38:15 UTC --- The diagnostic is easy in the direct case of delegating to the same constructor, but difficult in the indirect case of multiple delegating constructors. (The condition might still be detectable if enough constructors can be inlined.) This difficulty is presumably why the Standard specifies "no diagnostic required". But yes, it seems like a good idea to support a warning for the easy case.
[Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889
--- Comment #6 from Amali Praveena 2013-04-09
19:23:38 UTC ---
Hi Daniel,
The Stack template is an abstract type, so I don't have to add default
constructor to it, do I? Since the abstract type can't be copied/moved, i'm
explicitly specifying those functions as delete; but the derived classes
(vector_stack) are copyable through clone function(clone pattern).
I tried to do the following (adding default constructor), which still gave me
an error(both options):
template
class Stack{
public:
// pure virtual member functions
virtual Stack* clone() const=0; // polymorphic
virtual ~Stack() {} // explicitly define a destructor
// no copy operations Bug No:- 56889
Stack() // option 1
{
}
Stack()=default; // option 2
Stack(const Stack&)=delete;
Stack& operator=(const Stack&)=delete;
//no move operations
Stack(Stack&&)=delete;
Stack& operator=(Stack&&)=delete;
virtual bool empty() const=0; // const member function
virtual std::size_t size() const=0; // const member function
virtual T& top()=0;
virtual const T& top() const=0; // const member function
virtual void push(const T& x)=0;
virtual void pop()=0;
};
Here is a section from Bjarne stroustrup's PL fourth edition draft version :
Preventing Copy and Move [tour2.copy.hier]
Using the default copy or move for a class in a hierarchy is typically a
disaster: Given only
a pointer to a base, we simply don’t know what members the derived class has
(§3.3.3), so
we can’t know how to copy them. So, the best thing to do is usually to delete
the default
copy and move operations; that is, to eliminate to default definitions of those
two operations:
class Shape {
public:
Sha pe(const Sha pe&) =delete; // no copy operations
Sha pe& opera tor=(const Sha pe&) =delete;
Sha pe(Sha pe&&) =delete; // no move operations
Sha pe& opera tor=(Shape&&) =delete;
˜Sha pe();
// ...
};
Now an attempt to copy a Sha pe will be caught by the compiler. If you need to
copy an
object in a class hierarchy, write some kind of clone function (§22.2.4).
In case you forgot to delete a copy or move operation, no harm is done. A move
operation
is not implicitly generated for a class where the user has explicitly declared
a destructor.
Furthermore, the generation of copy operations are deprecated in this case
(§42.2.3). This can be a good reason to explicitly define a destructor even
where the compiler
would have implicitly provided one (§17.2.3).
A base class in a class hierarchy is just one example of an object we wouldn’t
want to
copy.
The C++ Programming Language, 4th edition ©2012 by Pearson Education, Inc.
Reproduced in draft form with the permission of the publisher. D R A F T
thanks,
Amali.
From: daniel.kruegler at googlemail dot com
To: amalispe...@yahoo.com
Sent: Tuesday, 9 April 2013 7:10 PM
Subject: [Bug c++/56889] =delete(ing) default copy and move operations for a
polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889
Daniel Krügler changed:
What |Removed |Added
CC| |daniel.kruegler at
| |googlemail dot com
--- Comment #1 from Daniel Krügler
2013-04-09 09:10:52 UTC ---
There are several problems in your example:
1) You have not declared a default constructor in template Stack, but you have
provided user-declared constructors (The deleted ones). This has the effect
that the Stack template has a no implicitly declared default constructor, which
again has the effect that the initializer-list constructor generated by the
compiler in vector_stack is deleted, because it would implicitly call the
missing default constructor of Stack. Solution: Add a (defaulted) default
constructor to the Stack template.
2) The clone function in vector_stack would call the copy constructor of that
type. But this one is deleted, because the Stack template has an explicitly
deleted copy constructor. This is a design error.
[Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889 --- Comment #5 from Daniel Krügler 2013-04-09 19:13:55 UTC --- This issue is not the right place for discussing programming idioms, but as a last comment to the code: Your reference to PL alone does not solve your programing error: You need to define a copy constructor in vector_stack, because the compiler-defined one is also deleted (because of the deleted one in the base class), or define the clone function without a copy constructor.
[Bug c++/56896] New: Missing DIR_SEPARATOR if --with-gxx-include-dir configured as subdir of sysroot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56896 Bug #: 56896 Summary: Missing DIR_SEPARATOR if --with-gxx-include-dir configured as subdir of sysroot Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com If gcc is configured with --with-sysroot= and --with-gxx-include-dir=/ then gcc_gxx_include_dir will end up as a relative path, and then incpath.c will trip the trailing sysroot DIR_SEPARATOR and construct an invalid path. e.g. ~/gnu/gcc/trunk/tmp/gcc$ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c++ --disable-bootstrap --with-gxx-include-dir=/home/ryan/foo/bar/usr/include/4.9.0 --with-sysroot=/home/ryan/foo/bar/ Thread model: posix gcc version 4.9.0 20130409 (experimental) [trunk revision 197644] (GCC) ## - ## ## Platform. ## ~/gnu/gcc/trunk/tmp$ grep -nr gcc_gxx_include_dir * gcc/Makefile:623:gcc_gxx_include_dir = usr/include/4.9.0 gcc/Makefile:624:gcc_gxx_include_dir_add_sysroot = 1 gcc/Makefile:1108:"gxx_include_dir=$(gcc_gxx_include_dir)" \ gcc/Makefile:4055: -DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \ gcc/Makefile:4056: -DGPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT=$(gcc_gxx_include_dir_add_sysroot) \ gcc/Makefile:4057: -DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/$(target_noncanonical)\" \ gcc/Makefile:4058: -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/backward\" \ gcc/config.log:6339:gcc_gxx_include_dir='usr/include/4.9.0' gcc/config.log:6340:gcc_gxx_include_dir_add_sysroot='1' gcc/config.status:682:S["gcc_gxx_include_dir_add_sysroot"]="1" gcc/config.status:683:S["gcc_gxx_include_dir"]="usr/include/4.9.0" ~/gnu/gcc/trunk/tmp/gcc$ ./xgcc -B. ~/hw.cc -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c++ --disable-bootstrap --with-gxx-include-dir=/home/ryan/foo/bar/usr/include/4.9.0 --with-sysroot=/home/ryan/foo/bar/ Thread model: posix gcc version 4.9.0 20130409 (experimental) [trunk revision 197644] (GCC) COLLECT_GCC_OPTIONS='-B' '.' '-v' '-mtune=generic' '-march=x86-64' ./cc1plus -quiet -v -iprefix /home/ryan/gnu/gcc/trunk/tmp/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/ -isystem ./include -isystem ./include-fixed -D_GNU_SOURCE /home/ryan/hw.cc -quiet -dumpbase hw.cc -mtune=generic -march=x86-64 -auxbase hw -version -o /tmp/cclOMQFL.s GNU C++ (GCC) version 4.9.0 20130409 (experimental) [trunk revision 197644] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/home/ryan/gnu/gcc/trunk/tmp/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include" ignoring nonexistent directory "/home/ryan/gnu/gcc/trunk/tmp/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include-fixed" ignoring nonexistent directory "/home/ryan/gnu/gcc/trunk/tmp/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/home/ryan/foo/barusr/include/4.9.0" ignoring nonexistent directory "/home/ryan/foo/barusr/include/4.9.0/x86_64-unknown-linux-gnu" ignoring nonexistent directory "/home/ryan/foo/barusr/include/4.9.0/backward" Or: ~/gnu/gcc/trunk/tmp/gcc$ ./xgcc -B. ~/hw.cc --sysroot=/foo/bar ignoring nonexistent directory "/foo/barusr/include/4.9.0" ignoring nonexistent directory "/foo/barusr/include/4.9.0/x86_64-unknown-linux-gnu" ignoring nonexistent directory "/foo/barusr/include/4.9.0/backward" I'm not sure if the following is sufficient, or if the gcc_gxx_include_dir should never end up without a leading DIR_SEPARATOR. Index: gcc/incpath.c === --- gcc/incpath.c(revision 197644) +++ gcc/incpath.c(working copy) @@ -179,7 +179,8 @@ char *sysroot_no_trailing_dir_separator = xstrdup (sysroot); size_t sysroot_len = strlen (sysroot); - if (sysroot_len > 0 && sysroot[sysroot_len - 1] == DIR_SEPARATOR) + if (sysroot_len > 0 && sysroot[sysroot_len - 1] == DIR_SEPARATOR + && p->fname[0] == DIR_SEPARATOR) sysroot_no_trailing_dir_separator[sysroot_len - 1] = '\0'; str = concat (sysroot_no_trailing_dir_separator, p->fname, NULL); free (sysroot_no_trailing_dir_separator);
[Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889
--- Comment #4 from Amali Praveena 2013-04-09
19:02:32 UTC ---
Hi Jonathan,
The Stack in the example is an abstract type, so I'm explicitly saying
that this abstract type cannot be copied or moved; but the derived class
vector_stack, which provides implementation for this abstract type is copyable
through clone function. Since the compiler won't know to which more derived
class the Stack points to at run time and so it cannot copy it, I've provided
the clone function (clone pattern).
This is what bjarne stroustrup says in his draft version of PL Fourth Edition,
as I quoted before.
Here is that section from the book.
3.3.4 Prev enting Copy and Move [tour2.copy.hier]
Using the default copy or move for a class in a hierarchy is typically a
disaster: Given only
a pointer to a base, we simply don’t know what members the derived class has
(§3.3.3), so
we can’t know how to copy them. So, the best thing to do is usually to delete
the default
copy and move operations; that is, to eliminate to default definitions of those
two operations:
class Shape {
public:
Sha pe(const Sha pe&) =delete; // no copy operations
Sha pe& opera tor=(const Sha pe&) =delete;
Sha pe(Sha pe&&) =delete; // no move operations
Sha pe& opera tor=(Shape&&) =delete;
˜Sha pe();
// ...
};
Now an attempt to copy a Sha pe will be caught by the compiler. If you need to
copy an
object in a class hierarchy, write some kind of clone function (§22.2.4).
In case you forgot to delete a copy or move operation, no harm is done. A move
operation
is not implicitly generated for a class where the user has explicitly declared
a destructor.
Furthermore, the generation of copy operations are deprecated in this case
(§42.2.3). This can be a good reason to explicitly define a destructor even
where the compiler
would have implicitly provided one (§17.2.3).
The C++ Programming Language, 4th edition ©2012 by Pearson Education, Inc.
Reproduced in draft form with the permission of the publisher. D R A F T
Thanks,
Amali.
From: redi at gcc dot gnu.org
To: amalispe...@yahoo.com
Sent: Tuesday, 9 April 2013 10:26 PM
Subject: [Bug c++/56889] =delete(ing) default copy and move operations for a
polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889
Jonathan Wakely changed:
What |Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--- Comment #3 from Jonathan Wakely 2013-04-09
12:26:18 UTC ---
As Daniel says, you're missing a default constructor.
And if you define the type as non-copyable then obviously you can't copy it.
This is not a GCC bug.
[Bug c++/23055] overload resolution does not find templated function (zero -> pointer)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23055 Jason Merrill changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #9 from Jason Merrill 2013-04-09 18:51:23 UTC --- *** Bug 52072 has been marked as a duplicate of this bug. ***
[Bug c++/52072] Several non-deduced contexts not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52072 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #6 from Jason Merrill 2013-04-09 18:51:23 UTC --- Yes. *** This bug has been marked as a duplicate of bug 23055 ***
[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #17 from Jason Merrill 2013-04-09 18:49:48 UTC --- Fixed for 4.9.
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 --- Comment #10 from Jason Merrill 2013-04-09 18:49:28 UTC --- OK.
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 --- Comment #9 from Jakub Jelinek 2013-04-09 18:46:16 UTC --- Created attachment 29844 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29844 gcc49-pr56895.patch Untested complete patch.
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 --- Comment #8 from Jakub Jelinek 2013-04-09 18:37:36 UTC --- Though, there are several other maybe_constant_value calls now in cp/typeck.c, and only 2 of them are guarded with !processing_template_decl. So I guess the warn_for_div_by_zero argument (twice) and RSHIFT_EXPR/LSHIFT_EXPR would need the same treatment.
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 --- Comment #7 from Jakub Jelinek 2013-04-09 18:36:41 UTC --- The reason for that is that I don't want errors being printed just when trying to optimize to see if I should warn or not.
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg00554.htm ||l CC||jb at gcc dot gnu.org --- Comment #8 from Janne Blomqvist 2013-04-09 18:35:46 UTC --- Patch for compressing module files with zlib at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00554.html .
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 --- Comment #6 from Paolo Carlini 2013-04-09 18:33:26 UTC --- It seems a bit weird not propagating complain..
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895
--- Comment #5 from Jakub Jelinek 2013-04-09
18:15:51 UTC ---
So:
@@ -4178,7 +4178,8 @@ cp_build_binary_op (location_t location,
}
else if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
{
- tree const_op1 = maybe_constant_value (op1);
+ tree const_op1 = fold_non_dependent_expr_sfinae (op1, tf_none);
+ const_op1 = maybe_constant_value (const_op1);
if (TREE_CODE (const_op1) != INTEGER_CST)
const_op1 = op1;
result_type = type0;
? Seems to work on this testcase.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #17 from Paolo Carlini 2013-04-09 18:11:12 UTC --- I'm not surprised by that, the real problem is that if you go to gcc-patches like I did some weeks ago, the correspinding discussion is even less usefull :(
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865 --- Comment #7 from Fredrick 2013-04-09 18:10:34 UTC --- HJ, Thanks for pointing the patch. The patch works. I tested it on x86-64. Could this patch be integrated into the mainline GCC? Thanks, Fredrick
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #16 from Manuel López-Ibáñez 2013-04-09 18:04:14 UTC --- (In reply to comment #15) > Manuel, compile_file changed with this commit: > > http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=118362 > > I seem to remember that another PR regressed with it. Unfortunately, Changelogs are mostly useless and don't explain the why :(
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 --- Comment #4 from Jason Merrill 2013-04-09 18:03:47 UTC --- (In reply to comment #3) > Introduced by my http://gcc.gnu.org/r195051 , potential_constant_expression > returns true about it, because fun in a call expr isn't a FUNCTION_DECL. > Jason, can you look at whether this is something that should be changed in > potential_constant_expression, or instead in cxx_eval_const* ? The problem is that we're passing an expression to maybe_constant_value that hasn't yet been through fold_non_dependent_expr. Either we need to call that first or disable this checking in templates.
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.8.1 --- Comment #3 from Jakub Jelinek 2013-04-09 17:54:16 UTC --- Introduced by my http://gcc.gnu.org/r195051 , potential_constant_expression returns true about it, because fun in a call expr isn't a FUNCTION_DECL. Jason, can you look at whether this is something that should be changed in potential_constant_expression, or instead in cxx_eval_const* ?
[Bug c++/56859] alignas() fails in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56859 Jason Merrill changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill 2013-04-09 17:39:22 UTC --- Dodji, please take a look at this one too.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #15 from Paolo Carlini 2013-04-09 17:38:06 UTC --- Manuel, compile_file changed with this commit: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=118362 I seem to remember that another PR regressed with it.
[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466 Paolo Carlini changed: What|Removed |Added CC|jason at gcc dot gnu.org| AssignedTo|paolo.carlini at oracle dot |jason at gcc dot gnu.org |com | --- Comment #16 from Paolo Carlini 2013-04-09 17:34:17 UTC --- Sure.
[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466 --- Comment #15 from Jason Merrill 2013-04-09 17:32:49 UTC --- Mind if I take this one?
[Bug c++/15485] [tree-ssa] The C++ front-end generates a lot of (void) casts for statements (NVR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15485 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #11 from Paolo Carlini 2013-04-09 17:21:58 UTC --- Is this still an issue?
[Bug c++/37885] Accepts invalid CV qualifiers on member function returning function pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37885 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||DUPLICATE Known to fail|| --- Comment #1 from Paolo Carlini 2013-04-09 17:15:57 UTC --- Dup. *** This bug has been marked as a duplicate of bug 13452 ***
[Bug c++/13452] No error on invalid (I think) C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13452 Paolo Carlini changed: What|Removed |Added CC||witmer at averagesoftware ||dot org --- Comment #5 from Paolo Carlini 2013-04-09 17:15:57 UTC --- *** Bug 37885 has been marked as a duplicate of this bug. ***
[Bug c++/33068] volatile struct bit fields not treated as volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33068 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |sch...@linux-m68k.org --- Comment #2 from Paolo Carlini 2013-04-09 17:05:55 UTC --- Maybe Andreas is willing to revisit this issue.
[Bug c++/52072] Several non-deduced contexts not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52072 --- Comment #5 from Paolo Carlini 2013-04-09 16:52:07 UTC --- I suppose PR23055 is another Dup?
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-09 Summary|ICE: unexpected expression |[4.8/4.9 Regression] ICE: |of kind arrow_expr |unexpected expression of ||kind arrow_expr Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2013-04-09 16:20:16 UTC --- Confirmed.
[Bug c++/56895] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf
2013-04-09 16:11:24 UTC ---
A bit more reduced:
% cat test.ii
struct A
{
int *foo ();
A bar ();
}
*a;
template void
fn1 ()
{
0 << (a->bar().foo() ? 1 : 0);
}
% c++ -c test.ii
test.ii: In function ‘void fn1()’:
test.ii:11:33: internal compiler error: unexpected expression ‘a->’ of kind
arrow_expr
0 << (a->bar().foo() ? 1 : 0);
[Bug target/56890] Invalid fdtox %f8, %f9 on Sparc 64 Bits with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56890 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot| |gnu.org | AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #5 from Eric Botcazou 2013-04-09 16:11:22 UTC --- Fixing.
[Bug target/56890] Invalid fdtox %f8, %f9 on Sparc 64 Bits with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56890 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-09 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #4 from Eric Botcazou 2013-04-09 16:09:06 UTC --- Confirmed, thanks for the reduced testcases.
[Bug c++/56895] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 Paolo Carlini changed: What|Removed |Added Severity|major |normal
[Bug plugins/56893] gcc-ar-4.7: Cannot find liblto_plugin.so on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56893 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2013-04-09 15:56:47 UTC --- gcc-ar is for use with newer GNU binutils only as that is the only ar which supports plugins. Apple's ar does not support plugins (though it could be made to; it will be a different plugin interface than the GNU BFD plugin interface which GCC supports right now).
[Bug c++/56895] New: ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 Bug #: 56895 Summary: ICE: unexpected expression of kind arrow_expr Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: woebbek...@web.de Created attachment 29843 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29843 reduced test case Hi, I get an ICE with the attached test case. I'm using GCC 4.8.0 from Debian experimental (x86_64). Cheers, André
[Bug c++/56894] performance regression in gcc 4.7.x due to a += operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56894 --- Comment #1 from Laurent Aflonsi 2013-04-09 15:23:16 UTC --- Created attachment 29842 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29842 testcase to reproduce
[Bug c++/56894] New: performance regression in gcc 4.7.x due to a += operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56894 Bug #: 56894 Summary: performance regression in gcc 4.7.x due to a += operation Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: laurent.alfo...@st.com Hello, I have identified a big performance regression between 4.6 and 4.7. (I have enclosed the pathological test). After investigation, it is because of the += statement applied on 2 signed chars. - It is now type-promoted to "int" when it is written "result += foo()". (since 4.7) - it is type promoted to "unsigned char" when it is written "result = result + foo()". The "char->int->char" cast is blocking the sccp constant propagation optimization. More precisely, in gcc 4.6, the "result" variable is seen as a loop_invariant (no_evolution_in_loop_p): arg 0 arg 0 arg 1 arg 2 >> In gcc 4.7, the result variable is not seen as a loop_invariant due to the cast to int: type arg 0 arg 0 arg 1 arg 2 >> I don't know how to change the chrec detection to recover the constant propagation in gcc 4.7. Thanks, Laurent
[Bug tree-optimization/48762] valgrind: Invalid read/write of size 8 in cse_main with -O --param max-cse-path-length=0 on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48762 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Marek Polacek 2013-04-09 15:02:25 UTC --- Fixed.
[Bug tree-optimization/48762] valgrind: Invalid read/write of size 8 in cse_main with -O --param max-cse-path-length=0 on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48762 --- Comment #4 from Marek Polacek 2013-04-09 15:02:01 UTC --- Author: mpolacek Date: Tue Apr 9 15:01:43 2013 New Revision: 197638 URL: http://gcc.gnu.org/viewcvs?rev=197638&root=gcc&view=rev Log: PR tree-optimization/48762 * params.def (PARAM_MAX_CSE_INSNS): Increase the minimum value to 1. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/params.def
[Bug plugins/56893] New: gcc-ar-4.7: Cannot find liblto_plugin.so on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56893 Bug #: 56893 Summary: gcc-ar-4.7: Cannot find liblto_plugin.so on Darwin Classification: Unclassified Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassig...@gcc.gnu.org ReportedBy: datas...@yahoo.com Created attachment 29841 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29841 Makefile for Mac Using gcc 4.7.2 on the Mac I appear to be running into LTO problems as well: $ /usr/gcc-4.7.2/bin/gcc-ar-4.7 /usr/gcc-4.7.2/bin/gcc-ar-4.7: Cannot find plugin /usr/gcc-4.7.2/libexec/gcc//x86_64-apple-darwin12.2.0/4.7.2/liblto_plugin.so $ /usr/gcc-4.7.2/bin/gcc-ranlib-4.7 /usr/gcc-4.7.2/bin/gcc-ranlib-4.7: Cannot find plugin /usr/gcc-4.7.2/libexec/gcc//x86_64-apple-darwin12.2.0/4.7.2/liblto_plugin.so $ /usr/gcc-4.7.2/bin/gcc-nm-4.7 /usr/gcc-4.7.2/bin/gcc-nm-4.7: Cannot find plugin /usr/gcc-4.7.2/libexec/gcc//x86_64-apple-darwin12.2.0/4.7.2/liblto_plugin.so That is a bummer, one of the charms of 4.7 is supposed to be link time optimisation. For what it is worth the patch mentioned in Bug 53126 – gcc-4.7.0 error "gcc-ar: Cannot find plugin" was already applied to the source code. But the fact that on the mac gcc-ar is looking for an '.so' instead of a '.dylib' seems odd. It would seem that /usr/gcc-4.7.2/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/lto-wrapper needs to be used because this symlink seems to fix it: sudo ln -s /usr/gcc-4.7.2/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/lto-wrapper /usr/gcc-4.7.2/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/liblto_plugin.so
[Bug tree-optimization/48762] valgrind: Invalid read/write of size 8 in cse_main with -O --param max-cse-path-length=0 on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48762 --- Comment #3 from Marek Polacek 2013-04-09 14:57:25 UTC --- Author: mpolacek Date: Tue Apr 9 14:56:59 2013 New Revision: 197637 URL: http://gcc.gnu.org/viewcvs?rev=197637&root=gcc&view=rev Log: PR tree-optimization/48762 * params.def (PARAM_MAX_CSE_INSNS): Increase the minimum value to 1. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def
[Bug c++/56698] "array subscript is above array bounds" triggered on code that doesn't have that problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56698 --- Comment #5 from Mike Hommey 2013-04-09 14:54:51 UTC --- As noted in https://bugzilla.mozilla.org/show_bug.cgi?id=854105#c4, fileIndex is uint32_t, so 0 - 1 is UINT32_MAX, which makes the error valid. Now the question is why does it only show up with PGO with gcda info?
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881 --- Comment #3 from Mikael Pettersson 2013-04-09 14:45:33 UTC --- The test case is incomplete, as it lacks both main() and domalloc(). Please add those (in a separate file if you like) so that the test case can be compiled to an executable, and the presence or absence of a runtime failure can be observed.
[Bug rtl-optimization/56885] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -O -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56885 --- Comment #6 from Yuri Rumyantsev 2013-04-09 14:22:28 UTC --- Forgot to mention that __builtin_memset and function argument are not interchangeable since both use the same register di.
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881 devspam at moreofthesa dot me.uk changed: What|Removed |Added Target||amd64 Known to work||4.7.2 Host||amd64 Version|unknown |4.8.0 Known to fail||4.8.0 --- Comment #2 from devspam at moreofthesa dot me.uk 2013-04-09 13:57:08 UTC --- (In reply to comment #1) > IMHO, if domalloc() does return NULL for some cases, > having NULL-checking statement before/inside memmove is required. It doesn't return NULL – if malloc() returns null, domalloc() will report that and exit. But even if it did, that doesn't explain the problem occurring only at some optimisation levels. Anyway. I've done some more testing. The problem is (or is related to) -fcaller-saves: -O2 and -Os both trigger the problem, but add -fno-caller-saves and all is well.
[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-09 Ever Confirmed|0 |1
[Bug target/56720] ICE when expanding vcond with floating point unordered comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56720 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from ktkachov at gcc dot gnu.org 2013-04-09 13:43:50 UTC --- Fixed on trunk and 4.8 Doesn't seem to significantly affect users of earlier release branches to justify the risk of backporting the fix.
[Bug rtl-optimization/56885] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -O -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56885
--- Comment #5 from Yuri Rumyantsev 2013-04-09
13:33:53 UTC ---
I did simple investigation and found out that
1. Test is compiled successfully without selective scheduling, i.e. with
'-fschedule-insns' only.
2. The problem is that selective scheduler moves function argument (off) uo
through bunch of instructions correspondent to __builtin_memset() ignoring
dependency creating by ix86_dependencies_evaluation_hook() ( i tried to add
output dependency instead of anti dependency between them but it also did not
help). More precisely, we have the following sequence of insns:
(insn 30 29 31 5 (parallel [
(set (reg:DI 77)
(const_int 0 [0]))
(set (reg/f:DI 75 [ D.1742 ])
(plus:DI (reg/f:DI 74 [ D.1742 ])
(reg:DI 77)))
(set (mem:BLK (reg/f:DI 74 [ D.1742 ]) [0 MEM[(void *)_17]+0 S15
A8])
(const_int 0 [0]))
(use (reg:QI 78))
(use (reg:DI 77))
]) t.c:16 909 {*rep_stosqi}
(expr_list:REG_DEAD (reg/f:DI 74 [ D.1742 ])
(expr_list:REG_UNUSED (reg:DI 77)
(expr_list:REG_UNUSED (reg/f:DI 75 [ D.1742 ])
(nil)
(insn 31 30 32 5 (set (reg:SI 5 di)
(subreg:SI (reg:DI 69 [ ivtmp.3 ]) 0)) t.c:17 85 {*movsi_internal}
(nil))
(call_insn 32 31 33 5 (call (mem:QI (symbol_ref:DI ("bar") [flags 0x41]
) [0 bar S1 A8])
(const_int 0 [0])) t.c:17 646 {*call}
(expr_list:REG_DEAD (reg:SI 5 di)
(nil))
(expr_list:REG_BR_PRED (use (reg:SI 5 di))
(nil)))
and there exist anti or output dependency between 30 and 31 insns created by
ix86-hook which is ignored by selective scheduler:
Moving [((31;di=r69#0;)type:set;count:2;)prio:3;orig_bb:5;] through 30:
unchanged (as RHS)
So I assume that selective scheduler needs to be tuned to be invoked before
Register Allocation phase on x86.
[Bug fortran/56887] Test for equality of reals now flagged with a warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56887 --- Comment #3 from fkrogh at mathalacarte dot com 2013-04-09 13:30:45 UTC --- On 04/09/2013 06:06 AM, burnus at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56887 > > Tobias Burnus changed: > > What|Removed |Added > > CC||burnus at gcc dot gnu.org > > --- Comment #2 from Tobias Burnus 2013-04-09 > 13:06:15 UTC --- > (In reply to comment #0) >> tests for equality between reals is flagged with a warning. > The support for the warning follows ISO/IEC TR 24772, which recommends users > to > "Avoid creating a logical value from a test for equality or inequality > between two floating-point expressions." - And compiler vendors to provide > such > a warning. > > The problem with many constructs is that one cannot reliably detect whether > they are okay or a bug in the code. Thus, warnings are issued for those; there > are always false positives and missed bugs with warning diagnostic. Those > checks, where the false-positive rate is low and the likelihood for bugs is > high, are enabled by default; others only with -Wall or -Wextra or only with > -W. > > In your case, using integer-valued floating-point numbers is probably fine. As > Thomas wrote, you can use -Wno-compare-reals to disable the warning. See GCC > 4.8 release notes or gfortran's man page (or user manual) under -Wextra. > Many thanks Tobias. That works fine for me and is just what I wanted. For some reason it is not in my info pages or man pages -- I really did look for anything like this. On another subject, I know that you had some contact with Dr. Richard Hanson concerning IEEE exceptions. He has completed his work on these and is free to tun them over to GNU. He is under the impression that there is no interest on your part. Thanks again, Fred
[Bug middle-end/56883] error openmp parallel for order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56883 Jakub Jelinek changed: What|Removed |Added Known to work||4.9.0 Known to fail|4.9.0 | --- Comment #4 from Jakub Jelinek 2013-04-09 13:29:54 UTC --- Author: jakub Date: Tue Apr 9 13:25:58 2013 New Revision: 197633 URL: http://gcc.gnu.org/viewcvs?rev=197633&root=gcc&view=rev Log: PR middle-end/56883 * omp-low.c (expand_omp_for_generic, expand_omp_for_static_nochunk, expand_omp_for_static_chunk): Use simple_p = true in force_gimple_operand_gsi calls when assigning to addressable decls. * c-c++-common/gomp/pr56883.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr56883.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #7 from Max Reitz 2013-04-09 13:20:06 UTC --- (In reply to comment #6) > On Tue, 9 Apr 2013, xanclic at gmail dot com wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 > > > > --- Comment #5 from Max Reitz 2013-04-09 > > 13:02:19 UTC --- > > (In reply to comment #3) > > > Just add -fno-tree-loop-distribute-patterns to the already long list of > > > options > > > you need for compilation of certain routines in your C library. > > > > This works for me, however, I don't see this parameter documented in gcc's > > manpage (which might prove helpful). > > It is documented in it's "positive" form, -ftree-loop-distribute-patterns Oh, now that's embarrassing… Sorry :-/ Well then, this seems to be exactly the thing I've been looking for. Thanks!
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #6 from rguenther at suse dot de 2013-04-09 13:17:10 UTC --- On Tue, 9 Apr 2013, xanclic at gmail dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 > > --- Comment #5 from Max Reitz 2013-04-09 13:02:19 > UTC --- > (In reply to comment #3) > > Just add -fno-tree-loop-distribute-patterns to the already long list of > > options > > you need for compilation of certain routines in your C library. > > This works for me, however, I don't see this parameter documented in gcc's > manpage (which might prove helpful). It is documented in it's "positive" form, -ftree-loop-distribute-patterns
[Bug fortran/56887] Test for equality of reals now flagged with a warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56887 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2013-04-09 13:06:15 UTC --- (In reply to comment #0) > tests for equality between reals is flagged with a warning. The support for the warning follows ISO/IEC TR 24772, which recommends users to "Avoid creating a logical value from a test for equality or inequality between two floating-point expressions." - And compiler vendors to provide such a warning. The problem with many constructs is that one cannot reliably detect whether they are okay or a bug in the code. Thus, warnings are issued for those; there are always false positives and missed bugs with warning diagnostic. Those checks, where the false-positive rate is low and the likelihood for bugs is high, are enabled by default; others only with -Wall or -Wextra or only with -W. In your case, using integer-valued floating-point numbers is probably fine. As Thomas wrote, you can use -Wno-compare-reals to disable the warning. See GCC 4.8 release notes or gfortran's man page (or user manual) under -Wextra.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #5 from Max Reitz 2013-04-09 13:02:19 UTC --- (In reply to comment #3) > Just add -fno-tree-loop-distribute-patterns to the already long list of > options > you need for compilation of certain routines in your C library. This works for me, however, I don't see this parameter documented in gcc's manpage (which might prove helpful).
[Bug c++/56892] dllexport prevents inline inside dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892 --- Comment #1 from Geoff Worboys 2013-04-09 12:35:33 UTC --- I realised I should add that I put the same code (adjusted for lack of C++11 support) through msvc v17, and can see it optimising the inline calls inside the library binary.
[Bug c++/56838] [4.9 regression] GCC svn doesn't compile libreoffice 4.0.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56838 Jason Merrill changed: What|Removed |Added CC||zeratul976 at hotmail dot ||com --- Comment #5 from Jason Merrill 2013-04-09 12:32:58 UTC --- *** Bug 56886 has been marked as a duplicate of this bug. ***
[Bug c++/56886] [4.9 regression] undesirable instantiation of class template default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56886 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Jason Merrill 2013-04-09 12:32:58 UTC --- Yes. *** This bug has been marked as a duplicate of bug 56838 ***
[Bug c++/52072] Several non-deduced contexts not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52072 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jason Merrill 2013-04-09 12:30:15 UTC --- The rule G++ is getting wrong is in 14.8.1: Implicit conversions (Clause 4) will be performed on a function argument to convert it to the type of the corresponding function parameter if the parameter type contains no template-parameters that participate in template argument deduction. And there's a FIXME to this effect in unify_one_argument: /* FIXME uses_deducible_template_parms */ if (TYPE_P (parm) && !uses_template_parms (parm)) return check_non_deducible_conversion (parm, arg, strict, flags, explain_p);
[Bug c++/56892] New: dllexport prevents inline inside dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56892
Bug #: 56892
Summary: dllexport prevents inline inside dll
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ge...@telesiscomputing.com.au
Created attachment 29840
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29840
Preprocessed result of: mingw32-g++.exe -v -save-temps -std=c++11 -O2 -Winline
testlib.cpp
When the dllexport attribute is used at the class level (which is most common),
any inline methods for that class will NOT be inlined inside the shared library
binary itself. This prevents the shared library from being fully optimised,
sometimes with significant impact on performance.
Produced on mingw / gcc v4.7.2, and on mingw64 / gcc v4.8.0.
Given these three classes (testlib.hpp):
class __declspec(dllexport) A {
public:
int fa() { return m; }
int ga();
private:
int m{0};
};
class __declspec(dllexport) B {
public:
int fb();
int gb();
private:
int m{0};
};
inline int B::fb() { return m; }
class C {
public:
int fc() { return m; }
__declspec(dllexport) int gc();
private:
int m{0};
};
Implemented as (testlib.cpp):
#include "testlib.hpp"
int A::ga() { return (fa() + 1); }
int B::gb() { return (fb() + 1); }
int C::gc() { return (fc() + 1); }
And then compiled with: -std::c++11 -O2 -Winline testlib.cpp
(The -std::c++11 is just for the in-class initializer.)
A::fa() is not inlined, and no warning is given.
B::fb() is not inlined, the compiler warns that it won't inline.
C::fc() is inlined as expected.
Almost no-one writes their classes like class C, they use class A or (less
commonly) class B. If they use class A style code they won't even know that
their inlines are being ignored when building the library itself.
I do understand the potential issues (the theory being that exported functions
are supposed to replaceable), but if __declspec(dllexport) - a synonym for
__attrribute__((dllexport)) - is supposed to emulate the behaviour seen by the
same declaration under msvc (why else create the synonym?) then it is failing
to do so. See this link for details:
http://msdn.microsoft.com/en-us/library/xa0d9ste.aspx
It is apparent that dllexport and dllimport are introducing additional
semantics above that of "export symbol" and "import symbol". So the other
work-around is to stop using dllexport and dllimport and use manual .def files,
or --export-all-symbols when calling the linker. Obviously neither options is
ideal.
It's possible that there could be overlap with this bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50779
[Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jonathan Wakely 2013-04-09 12:26:18 UTC --- As Daniel says, you're missing a default constructor. And if you define the type as non-copyable then obviously you can't copy it. This is not a GCC bug.
[Bug c++/56793] ICE with scoped enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56793 Paolo Carlini changed: What|Removed |Added CC||luto at mit dot edu --- Comment #2 from Paolo Carlini 2013-04-09 11:47:15 UTC --- *** Bug 51348 has been marked as a duplicate of this bug. ***
[Bug c++/51348] [c++0x] ICE in finish_class_member_access_expr with enum class use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51348 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini 2013-04-09 11:47:15 UTC --- Dup. *** This bug has been marked as a duplicate of bug 56793 ***
[Bug fortran/56887] Test for equality of reals now flagged with a warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56887 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Thomas Koenig 2013-04-09 11:24:07 UTC --- Please see the release notes: "The -Wcompare-reals command-line option has been added. When this is set, warnings are issued when comparing REAL or COMPLEX types for equality and inequality; consider replacing a == b by abs(a−b) < eps with a suitable eps. -Wcompare-reals is enabled by -Wextra." Following the usual gcc option conventions, you can disable the -Wcompare-reals flag by -Wno-compare-reals.
[Bug rtl-optimization/56885] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -O -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56885 Igor Zamyatin changed: What|Removed |Added CC||ysrumyan at gmail dot com --- Comment #4 from Igor Zamyatin 2013-04-09 10:53:09 UTC --- Adding the author of the changes that fix failures of pre-alloc scheduler
[Bug tree-optimization/56854] [4.9 Regression] error: non-decl/MEM_REF LHS in clobber statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56854 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2013-04-09 10:16:15 UTC --- Author: jakub Date: Tue Apr 9 10:04:24 2013 New Revision: 197625 URL: http://gcc.gnu.org/viewcvs?rev=197625&root=gcc&view=rev Log: PR tree-optimization/56854 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Don't forward into clobber stmts if it would change MEM_REF lhs into non-MEM_REF. * g++.dg/torture/pr56854.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr56854.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 --- Comment #33 from Dmitry G. Dyachenko 2013-04-09 10:07:47 UTC --- *** Bug 56830 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/56830] [4.8 regression] internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56830 Dmitry G. Dyachenko changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #9 from Dmitry G. Dyachenko 2013-04-09 10:07:47 UTC --- fixed in r197580 *** This bug has been marked as a duplicate of bug 34949 ***
[Bug tree-optimization/56878] Issue with candidate choice in vect_gen_niters_for_prolog_loop.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56878 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-09 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Biener 2013-04-09 10:05:57 UTC --- I will have a look.
[Bug c/56882] ICE: when compiling gegl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56882 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-09 Ever Confirmed|0 |1
[Bug c++/56886] [4.9 regression] undesirable instantiation of class template default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56886 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-09 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Richard Biener 2013-04-09 10:01:48 UTC --- I will have a look.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek 2013-04-09 10:01:31 UTC --- Just add -fno-tree-loop-distribute-patterns to the already long list of options you need for compilation of certain routines in your C library.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #2 from Mikael Pettersson 2013-04-09 09:59:20 UTC --- Started with Richard Biener's http://gcc.gnu.org/r188261 aka PR53081 fix, which added or improved memcpy recognition. I'm guess the new code fails to check for whatever option is supposed to disable this sort of transformation.
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881 Chung-Ju Wu changed: What|Removed |Added CC||jasonwucj at gmail dot com --- Comment #1 from Chung-Ju Wu 2013-04-09 09:52:35 UTC --- (In reply to comment #0) > > hs1 = (Hideset)domalloc(len*sizeof(Hideset)); > memmove(hs1, nhs, len*sizeof(Hideset)); > hidesets[nhidesets] = hs1; > IMHO, if domalloc() does return NULL for some cases, having NULL-checking statement before/inside memmove is required.
[Bug c++/56889] =delete(ing) default copy and move operations for a polymorphic type gives compilation error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56889 --- Comment #2 from Daniel Krügler 2013-04-09 09:36:29 UTC --- (In reply to comment #1) In addition I would like to remark that the precise declaration state of the inherited initializer-list constructor in vector_stack is unclear, because of http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1573 But the existing wording implies that any usage of this constructor would be ill-formed because of the unavailable default constructor of its base class.
