[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 --- Comment #12 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #10) Putting this inside a subroutine, one gets: class(c), pointer :: px = x 1 Error: Pointer initialization target at (1) must have the SAVE attribute That sounds like a bug: Explicit initialization of a variable that is not in a common block implies the SAVE attribute, which may be confirmed by explicit specification. (5.2.3 Initialization, F2008) And px is clearly initialized Oh, wait: The error is about the *target*, not the pointer. Therefore I think it's indeed correct and there is no bug!
[Bug c++/58054] New: 11.3 Friends, example from standard not compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58054
Bug ID: 58054
Summary: 11.3 Friends, example from standard not compiled
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dushistov at mail dot ru
Here is example from standard (page 250-251),
class A {
class B { };
friend class X;
};
struct X : A::B { // OK: A::B accessible to friend
A::B mx; // OK: A::B accessible to member of friend
class Y {
A::B my; // OK: A::B accessible to nested member of friend
};
};
$ g++ -std=c++11 -Wall -c test_friend.cc
test_friend.cc:2:9: error: 'class A::B' is private
class B { };
^
test_friend.cc:6:15: error: within this context
struct X : A::B { // OK: A::B accessible to friend
^
I suppose that lines marked as OK in C++11 standard should
not emit any errors.
[Bug c++/58054] 11.3 Friends, example from standard not compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58054 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Looks like they changed how base classes are handled in C++ for C++11. 98 says this: [class.friend]/2 Also, because the base-clause of the friend class is not part of its member declarations, the base-clause of the friend class cannot access the names of the private and protected members from the class granting friendship. Or is this just in a need for a defect report.
[Bug c++/58054] 11.3 Friends, example from standard not compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58054
--- Comment #2 from Evgeniy Dushistov dushistov at mail dot ru ---
Yes, for C++ 2003 this is invalid code(page 212):
class A {
class B { };
friend class X;
};
class X : A::B { // ill-formed: A::B cannot be accessed
// in the base-clause for X
A::B mx; // OK: A::B used to declare member of X
class Y : A::B { // OK: A::B used to declare member of X
A::B my; // ill-formed: A::B cannot be accessed
// to declare members of nested class of X
};
};
but for 2011 they looks like change behaviour.
[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 --- Comment #14 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Martin, Your patch is of course OK, but the MALLOC_ABI_ALIGNMENT is probably wrong too. At least in targets with neon processor it should be raised to 64 bits. If the malloc would really return 4 byte aligned pointers, and you pass such a pointer to an external function, that function may assume naturally 8 byte aligned pointers and fault at runtime, right? I've just re-read the relevant ARM ABI document AAPCS: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf I have not found specific alignment requirements for malloc, but they specify alignments of different basic types up to 8 byte. Therefore I assume that the default value for MALLOC_ABI_ALIGNMENT is generally too low for the ARM architecture. The usual Doug Lee Malloc implementation has by design a lowest possible alignment of 8 bytes. What I mean is, maybe the defautlt for MALOC_ABI_ALIGNMENT should changed to BIGGEST_ALIGNMENT. What do You think?
[Bug libstdc++/58049] [4.9 Regression] libstdc++ bootstrap failure for fix to PR libstdc++/57779
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58049 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com
[Bug inline-asm/58044] -mno-see2avx does not seems to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58044 --- Comment #1 from Jérôme Pouiller jerome.pouiller at gmail dot com --- AVX instructions seems to not been generated by assembler. Compiler directly generate these instructions. Since -mavx2 is specified, compiler behaviour can be considered correct. But, I don't see any case where -mno-sse2avx may change result, isn't? This option may be removed? For my specific test case, there is a workaround. I can add __attribute__((__target__(no-avx))) to memcpy_16to8_sse.
[Bug c++/58052] Copy initialization using conversion operator does not find correct candidates for initialization of final result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Not having spent a lot of time on this, I doubt it's a bug: the latest clang and icc behave exactly like gcc.
[Bug libstdc++/58049] [4.9 Regression] libstdc++ bootstrap failure for fix to PR libstdc++/57779
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58049 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/58055] New: [meta-bug] RVO / NRVO improvements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 Bug ID: 58055 Summary: [meta-bug] RVO / NRVO improvements Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: paolo.carlini at oracle dot com
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-02 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Adding Jason in CC, I seem to remember he did the ssa implementation.
[Bug c++/58050] No return value optimization when calling static function through unnamed temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58050 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug c++/58051] No named return value optimization when returned object is implicitly converted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-02 CC||mpolacek at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Known to work||4.7.3 Target Milestone|--- |4.8.2 Summary|internal compiler error:|[4.8/4.9 Regression] |Max. number of generated|internal compiler error: |reload insns per insn is|Max. number of generated |achieved (90) |reload insns per insn is ||achieved (90) Ever confirmed|0 |1 Known to fail||4.8.1, 4.9.0 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, started with http://gcc.gnu.org/r192719 I'll try to reduce this a bit.
[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Note that with -O0: d.c: In function ‘div3’: d.c:102:3: error: inconsistent operand constraints in an ‘asm’
[Bug c++/54537] undiagnosed using-declaration conflicting with used function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537 --- Comment #3 from fabien at gcc dot gnu.org --- (In reply to Peter Bergner from comment #1) Given the OK by Paolo, I retested the patch from: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01166.html It needed a small change to the expected error message from using9.C, but otherwise bootstrapped and regtested with no errors. Committed to mainline as revision 201414. Thank you very much. I have also asked about the appropriateness of backporting it to the FSF 4.8 branch. It is not a regression, so I think you would need an approval. Just ask it on gcc-patches.
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #8 from fabien at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #7) Any news on this? Sorry Paolo, no news. I will look into it after I resurrect some stage one 1 material patches on using decls (comming after c++/54537). I think this one can be tackled in stage 3.
[Bug c++/58056] New: ld segfaults when -undefined dynamic_lookup is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58056 Bug ID: 58056 Summary: ld segfaults when -undefined dynamic_lookup is set Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: freget at googlemail dot com Created attachment 30588 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30588action=edit Object file causing the error I'm using g++ 4.8.1 on OS X with the following configuration: Ziel: x86_64-apple-darwin12.4.0 Konfiguriert mit: ../configure --build=x86_64-apple-darwin12.4.0 --prefix=/usr/local/Cellar/gcc48/4.8.1/gcc --datarootdir=/usr/local/Cellar/gcc48/4.8.1/share --bindir=/usr/local/Cellar/gcc48/4.8.1/bin --enable-languages=c,c++,fortran,java,objc,obj-c++ --program-suffix=-4.8 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog --with-isl=/usr/local/opt/isl --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --enable-plugin --with-ecj-jar=/usr/local/opt/ecj/share/java/ecj.jar --disable-multilib Thread-Modell: posix gcc-Version 4.8.1 (GCC) Using the (faulty) object file attached, the following call causes a segfault: g++-4.8 -std=c++0x -g -dynamiclib -undefined dynamic_lookup -o output.dylib Notifications.cpp.o collect2: Fehler: ld mit Signal 11 [Segmentation fault: 11] beendet However, once I link without -undefined dynamic_lookup, I get a meaningful error description: g++-4.8 -std=c++0x -g -dynamiclib -o output.dylib Notifications.cpp.o Undefined symbols for architecture x86_64: libsoda::(anonymous namespace)::CustomOutputBuffer::~CustomOutputBuffer(), referenced from: libsoda::(anonymous namespace)::CustomWarnBuffer::~CustomWarnBuffer() in Notifications.cpp.o libsoda::(anonymous namespace)::CustomErrBuffer::~CustomErrBuffer() in Notifications.cpp.o libsoda::(anonymous namespace)::CustomPrintBuffer::~CustomPrintBuffer() in Notifications.cpp.o vtable for libsoda::(anonymous namespace)::CustomOutputBuffer, referenced from: libsoda::(anonymous namespace)::CustomOutputBuffer::CustomOutputBuffer(unsigned long) in Notifications.cpp.o NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. _elog_finish, referenced from: libsoda::(anonymous namespace)::CustomPrintBuffer::printToUser(char*) in Notifications.cpp.o libsoda::(anonymous namespace)::CustomErrBuffer::printToUser(char*) in Notifications.cpp.o libsoda::(anonymous namespace)::CustomWarnBuffer::printToUser(char*) in Notifications.cpp.o libsoda::(anonymous namespace)::DefaultHandler(char const*, char const*, char const*, int) in Notifications.cpp.o _elog_start, referenced from: libsoda::(anonymous namespace)::CustomPrintBuffer::printToUser(char*) in Notifications.cpp.o libsoda::(anonymous namespace)::CustomErrBuffer::printToUser(char*) in Notifications.cpp.o libsoda::(anonymous namespace)::CustomWarnBuffer::printToUser(char*) in Notifications.cpp.o libsoda::(anonymous namespace)::DefaultHandler(char const*, char const*, char const*, int) in Notifications.cpp.o ld: symbol(s) not found for architecture x86_64 collect2: Fehler: ld gab 1 als Ende-Status zurück This is something I can work with. Debugging with the only output beeing a segfault is not that easy. Not that the example above was stripped down as much as possible and will never compile successfully in this configuration.
[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Marek Polacek from comment #3) Note that with -O0: d.c: In function ‘div3’: d.c:102:3: error: inconsistent operand constraints in an ‘asm’ Just replace 32 with 32.0 as the asm operand.
[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org ---
Right, thanks, but then the ICE doesn't occur, so this makes it pretty much ICE
on invalid. Reduced nevertheless...
void
div3 (void)
{
double tmp1;
asm volatile (fscale:=t (tmp1):0 (0), u (0));
}
(with sed 's/(0/(0.0/g' the ICE's gone)
[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- ...and -O is everything that's needed to trigger that.
[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-08-02 Assignee|unassigned at gcc dot gnu.org |fabien at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from fabien at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #2) Fabien, are you interested in this? Yes, let's put it on my TODO list. Might be related to PR c++/19377.
[Bug c++/58057] New: gcc lexer cannot parse extern \x43 void blah();
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057 Bug ID: 58057 Summary: gcc lexer cannot parse extern \x43 void blah(); Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: schnoerr at mailzone dot com g++ 4.7.3 fails to compile extern \x43 void blah(); which is obfuscated and equivalent to extern C void blah(); This is no problem for the g++ 4.6.3 so it must have been newly introduced in g++.
[Bug tree-optimization/58010] [4.8/4.9 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-02 CC||mpolacek at gcc dot gnu.org Known to work||4.7.3 Target Milestone|--- |4.8.2 Summary|ICE in |[4.8/4.9 Regression] ICE in |vect_create_epilog_for_redu |vect_create_epilog_for_redu |ction, at |ction, at |tree-vect-loop.c:4378 |tree-vect-loop.c:4378 Ever confirmed|0 |1 Known to fail||4.8.1, 4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c++/58056] ld segfaults when -undefined dynamic_lookup is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58056 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Thus this is about ld *not* gcc, right?
[Bug c++/58040] Cannot take address-of public using-declaration of member from protected base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks!
[Bug c++/58057] gcc lexer cannot parse extern \x43 void blah();
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I can't seem to reproduce it with 4.7/4.8/trunk (if you really parse it using the C++ compiler).
[Bug c++/58057] gcc lexer cannot parse extern \x43 void blah();
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|--- |WORKSFORME --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Indeed.
[Bug rtl-optimization/58048] [4.8/4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #7 from Uroš Bizjak ubizjak at gmail dot com ---
Looking a bit into this problem:
A reload reg is inserted before fscale asm, but the chosen alternative can
move an immediate to memory directly.
Inserting insn reload before:
227: r184:SI=0x20
alt=0,overall=13,losers=2,rld_nregs=1
alt=1,overall=9,losers=1,rld_nregs=0
alt=4,overall=19,losers=2 -- reject
alt=10,overall=19,losers=2 -- reject
Choosing alt 1 in insn 227: (0) m (1) re {*movsi_internal}
Creating newreg=185 from oldreg=184, assigning class NO_REGS to r185
227: r185:SI=0x20
Inserting insn reload after:
The alternative does not need a register, so class NO_REGS is correct. However,
it looks that follow-up code is not prepared for this and trips into a loop,
trying to assign another reload reg.
[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341 --- Comment #4 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- I can see the same problem under Linux (gcc110.fsffrance.org). According to the C standard (C99 and C11), the *_EPSILON values are the difference between 1 and the least value greater than 1 that is representable in the given floating point type, b^(1-p). Here b = 2 and p = LDBL_MANT_DIG = 106. I think that the C standard is badly worded. It should have said the difference between 1 and the least floating-point value greater than 1 that is representable in the given type, b^(1-p). What is regarded as a floating-point value is specified by the standard: see 5.2.4.2.2p2 A floating-point number (x) is defined by the following model: [...].
[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341 --- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Vincent Lefèvre from comment #4) I can see the same problem under Linux (gcc110.fsffrance.org). In case this wasn't clear, the architecture is also a PowerPC. The double-double format comes from the PowerPC ABI, and isn't directly related to the OS itself (FYI it was also used under Mac OS X / PowerPC). Thus the summary of this bug should be changed to: LDBL_EPSILON is wrong on PowerPC
[Bug tree-optimization/58010] [4.8/4.9 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with http://gcc.gnu.org/r189527
[Bug rtl-optimization/58008] ICE: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58008 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Might be the same as PR58048...
[Bug c++/58047] parse error with typedef introduced from base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Let's have this at hand, just c++98:
template int N
struct print_arg { };
struct const_holder {
static const int CONSTANT = 42;
};
template typename T
struct identity {
typedef T type;
};
template class T
struct test_case : public identityT {
using typename identityT::type;
print_argtype::CONSTANT printer;
};
template struct test_caseconst_holder;
[Bug c++/58047] parse error with typedef introduced from base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||fabien at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- ... hard to believe we don't have a Dup.
[Bug c++/58047] parse error with typedef introduced from base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Seems closely related to PR37140.
[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Vincent Lefèvre from comment #4) I can see the same problem under Linux (gcc110.fsffrance.org). In case this wasn't clear, the architecture is also a PowerPC. The double-double format comes from the PowerPC ABI, and isn't directly related to the OS itself (FYI it was also used under Mac OS X / PowerPC). Thus the summary of this bug should be changed to: LDBL_EPSILON is wrong on PowerPC Certainly not: IRIX isn't PowerPC but MIPS! If need be, just refer to the double/double format. Rainer
[Bug c++/57408] lambda, Variable length arrays, thread, internal compiler error: in expand_expr_real_1, at expr.c:9327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57408 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|jason at gcc dot gnu.org | Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Thus fixed for 4.9.0.
[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341 --- Comment #7 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to r...@cebitec.uni-bielefeld.de from comment #6) Certainly not: IRIX isn't PowerPC but MIPS! OK, that wasn't clear because the original but report mentioned: gcc.target/powerpc/rs6000-ldouble-2.c. ^^^ If need be, just refer to the double/double format. Yes.
[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #7 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to r...@cebitec.uni-bielefeld.de from comment #6) Certainly not: IRIX isn't PowerPC but MIPS! OK, that wasn't clear because the original but report mentioned: gcc.target/powerpc/rs6000-ldouble-2.c. ^^^ Right, but that test isn't run on regular testsuite runs on IRIX, although there's nothing powerpc specific in there except for the -mlong-double-128 option which can only be used on powerpc targets. Running it manually on IRIX shows the failure. Rainer
[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 schnoerr at mailzone dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||schnoerr at mailzone dot com Resolution|WORKSFORME |--- Summary|gcc lexer cannot parse |gcc lexer cannot parse |extern \x43 void blah(); |extern \x43 void blah() ||with option -std=c++0x; --- Comment #3 from schnoerr at mailzone dot com --- sorry, I've forgotten a detail: The problem only occurs with the option '-std=c++0x'. With '-std=c++98' all works fine.
[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 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Weird, even with -std=c++0x I still see no failures at all.
[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|--- |WORKSFORME --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Yep.
[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- OK, so eventually I have posted the patch to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00074.html Thanks.
[Bug fortran/58058] New: Memory leak with transfer function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058 Bug ID: 58058 Summary: Memory leak with transfer function Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thomas.jourdan at orange dot fr Hello, Using gfortran 4.8.1, the following code runs fine but according to valgrind it produces a memory leak: program test1 implicit none integer, dimension(3) :: t1, t2 character(len=64) :: str t1 = (/1,2,3/) !str = transfer((/1,2,3/),str) ! works str = transfer(t1,str) ! memory leak t2 = transfer(str,t1) write(*,*) 't2 = ',t2 end program test1 The output is: ==7005== Memcheck, a memory error detector ==7005== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==7005== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==7005== Command: ./test1 ==7005== t2 =1 2 3 ==7005== ==7005== HEAP SUMMARY: ==7005== in use at exit: 64 bytes in 1 blocks ==7005== total heap usage: 23 allocs, 22 frees, 11,897 bytes allocated ==7005== ==7005== LEAK SUMMARY: ==7005==definitely lost: 64 bytes in 1 blocks ==7005==indirectly lost: 0 bytes in 0 blocks ==7005== possibly lost: 0 bytes in 0 blocks ==7005==still reachable: 0 bytes in 0 blocks ==7005== suppressed: 0 bytes in 0 blocks ==7005== Rerun with --leak-check=full to see details of leaked memory ==7005== ==7005== For counts of detected and suppressed errors, rerun with: -v ==7005== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) If I use directly str = transfer((/1,2,3/),str) instead, no memory problem occurs. I experienced the same problem with the following test: program test2 implicit none type tuple integer :: nn integer :: pp integer :: qq end type tuple character(len=64) :: str type(tuple) :: mt1, mt2 mt1%nn = 1 mt1%pp = 2 mt1%qq = 3 str = transfer(mt1,str) mt2 = transfer(str,mt2) end program test2 Thanks, Thomas
[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 --- Comment #15 from Martin Jambor jamborm at gcc dot gnu.org --- I have submitted the patch to the mailing list for review: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00082.html (In reply to Bernd Edlinger from comment #14) What I mean is, maybe the defautlt for MALOC_ABI_ALIGNMENT should changed to BIGGEST_ALIGNMENT. What do You think? If ARM can trap accessing an 8 byte variable of a type that can be defined without any fancy attributes, then unambiguously yes, malloc has to return memory aligned to at least 8 bytes and MALLOC_ABI_ALIGNMENT needs to be bumped to at least 64. I am not sure whether BIGGEST_ALIGNMENT is the right value, e.g. on x86_64 the value of MALLOC_ABI_ALIGNMENT is 64 whereas BIGGEST_ALIGNMENT is 128. Of course, on ARM the latter is also 64, so at the moment it would not make a real difference. Anyway, the policy of GCC seems to be that the default of MALLOC_ABI_ALIGNMENT is ultra-safe and targets should override it. So I would suggest, again :-), that you open a separate bug and CC ARM maintainers that should take care of it.
[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
schnoerr at mailzone dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WORKSFORME |---
--- Comment #6 from schnoerr at mailzone dot com ---
I'm sorry again, the cause of the error seemed to be so obvious.
The removed spaces are the reason.
Here is a small program I could isolate the problem:
--
//command: g++ -std=c++0x test.cc -o test
//version: g++ (GCC) 4.7.3
extern C void * blah_1( void * ); //ok
extern \x43 void*blah_2(void*);//ok
extern\x43void*blah_3(void*); //-- error only here with -std=c++0x and
g++4.7.3
//no error with g++4.6.3
int main() {
}
error message: test.cc:7:7: error: expected unqualified-id before
‘STRING_USERDEF’ token
[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 CC|schnoerr at mailzone dot com |3dw4rd at verizon dot net --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- The error message could be better, but I don't think this is valid.
[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 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Among the compilers I have at hand, only the latest Icc accepts this.
[Bug other/58056] ld segfaults when -undefined dynamic_lookup is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58056 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c++ |other --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #1) Thus this is about ld *not* gcc, right? Meaning you should report this to Apple about their ld crashing.
[Bug c++/58052] Copy initialization using conversion operator does not find correct candidates for initialization of final result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052
--- Comment #2 from Hubert Tong hstong at ca dot ibm.com ---
(In reply to Paolo Carlini from comment #1)
Not having spent a lot of time on this, I doubt it's a bug: the latest clang
and icc behave exactly like gcc.
I had a vague recollection why I found the code weird to begin with.
After consideration, I found that the MSVC behaviour made sense after all.
There is wording in 12.3 [class.conv]:
At most one user-defined conversion (constructor or conversion function) is
implicitly applied to a single value.
To poke some holes in the applicability of the above wording, I will modify the
test case:
@@ -3,7 +3,8 @@ struct A {
A();
A(const A , bool = 0);
A(const A , short = 0);
- A(B );
+
+ template typename T explicit A(T );
};
struct B : A { };
Note that explicit constructors are not converting constructors.
The modified version of the test case works fine with clang++ and icc, but not
GCC. MSVC chokes on the explicit.
[Bug tree-optimization/58010] [4.8/4.9 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010 --- Comment #3 from Bill Schmidt wschmidt at gcc dot gnu.org --- r189527 is probably a red herring. That just changed the cost model to be turned on by default at -O3. Somebody who's actively working on the vectorizer should probably have a look at this. If you want to narrow it down further, try turning on -fvect-cost-model and bisecting. The problem will probably show up as being introduced further back if you do this. This also suggests a workaround for the OP of using -fno-vect-cost-model, if a workaround is needed.
[Bug fortran/58058] [4.7/4.8/4.9 Regression] Memory leak with transfer function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-02 CC||janus at gcc dot gnu.org, ||pault at gcc dot gnu.org Summary|Memory leak with transfer |[4.7/4.8/4.9 Regression] |function|Memory leak with transfer ||function Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I can confirm the leak with gfortran versions 4.7, 4.8 and trunk. However, there is no leak in 4.3, so it is a regression (haven't tried other versions). Indeed the dump produced by -fdump-tree-original shows a __builtin_malloc, which is never freed. The regression seems to be due to this commit: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=143462
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #185 from Jan Hubicka hubicka at gcc dot gnu.org --- I merged in some patches intended to reduce memory of Firefox LTO and also updated firefox tree. Some more involved patches are on the way, so it is summary where we stand now. WPA usage in TOP is 10GB now. 1) After streaming in trees, the GGC usage is now 5.1GB - 2.5GB are trees, - 1GB are linemaps - 0.8GB are decl maps (decl states) tree_list12561507 integer_type 1511296 pointer_type 4610735 record_type 8139077 method_type 2401664 integer_cst 6677946 string_cst 2127890 function_decl6069299 label_decl504859 field_decl 5104957 var_decl 596020 const_decl 5401253 parm_decl9002744 type_decl10150100 result_decl 2181250 addr_expr4173661 tree_binfo 4780477 I have cache that cuts down the linemaps + patch to not stream PARM_DECLs and RETURN_DECLs. With this the usage goes bellow 3GB. 2) Cgraph streaming now becomes important factor. GGC usage goes up to 7.7GB GGC use: - cgraph nodes themselves are 1.5GB - inline summaries are 0.5GB - cgraph edges are 3.7GB - IPA references 2.3GB - IPA-prop 0.7GB Off GGC - IPA-prop 0.6GB - Inline summary 0.5GB - symtab encoder 0.17GB Here one can easily - compress the vectors recording definitions - pull off parts of cgraph nodes that are not really needed by WPA (nested info, etc.) - perhaps implement of streaming of merged cgraph. so good news is that we now have a lot of interesting low hanging fruit. Bad news is that tree streaming still feels slow. I suppose we need to dig more into what trees really need to go into WPA...
[Bug c++/58059] New: gcc-4.7.2-r1 - g++: internal compiler error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059 Bug ID: 58059 Summary: gcc-4.7.2-r1 - g++: internal compiler error: Segmentation fault (program cc1plus) Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nacitar at ubercpp dot com Created attachment 30589 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30589action=edit source file When building a c++11 program using the command line: g++ -std=c++11 gcc_crash.cc I get an internal compiler error. When trying to generate the preprocessed source, the same crash occurs. $ gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include --datadir=/usr/share/gcc-data/x86_6 4-pc-linux-gnu/4.7.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-cloog --without-ppl --disable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.2-r1 p1.6, pie-0.5.5' Thread model: posix gcc version 4.7.2 (Gentoo 4.7.2-r1 p1.6, pie-0.5.5)
[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 #1 from Jacob McIntosh nacitar at ubercpp dot com --- Created attachment 30590 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30590action=edit preprocessed output Generating this file crashed too: $ gcc -v -save-temps -std=c++11 gcc_crash.cc Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-cloog --without-ppl --disable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.2/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.2-r1 p1.6, pie-0.5.5' Thread model: posix gcc version 4.7.2 (Gentoo 4.7.2-r1 p1.6, pie-0.5.5) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/cc1plus -E -quiet -v -D_GNU_SOURCE gcc_crash.cc -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o gcc_crash.ii ignoring nonexistent directory /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4/x86_64-pc-linux-gnu /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4/backward /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/cc1plus -fpreprocessed gcc_crash.ii -quiet -dumpbase gcc_crash.cc -mtune=generic -march=x86-64 -auxbase gcc_crash -std=c++11 -version -o gcc_crash.s GNU C++ (Gentoo 4.7.2-r1 p1.6, pie-0.5.5) version 4.7.2 (x86_64-pc-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (Gentoo 4.7.2-r1 p1.6, pie-0.5.5) version 4.7.2 (x86_64-pc-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 6937aad24b81042c4f11f96fe3cea84a gcc: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions.
[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 #2 from Jacob McIntosh nacitar at ubercpp dot com --- Oh, and of course, compilation yields nothing more than this: $ g++ -std=c++11 gcc_crash.cc g++: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. I also filed a downstream bug on gentoo, https://bugs.gentoo.org/show_bug.cgi?id=479444 but the gentoo guys in the help channel advised me to file this one upstream.
[Bug c++/57546] templated gnu multiversion function pointer returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546 mib.bugzilla at gmail dot com changed: What|Removed |Added CC||mib.bugzilla at gmail dot com --- Comment #1 from mib.bugzilla at gmail dot com --- Created attachment 30591 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30591action=edit test case without template, also segfault
[Bug c++/57546] templated gnu multiversion function pointer returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546 --- Comment #2 from mib.bugzilla at gmail dot com --- I rerun this test today and the program segfaults. Also get the same behavior (segfault) if the template is removed. I'll attach the non-templated test case g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/4.8.1/rhel60/efi2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /rusers/sys_cron/grab_gcc/downloads_rel/4.8.1/gcc-4.8.1/configure --prefix=/rdrive/ref/gcc/4.8.1/rhel60/efi2 --enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap --target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float --with-gmp=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 --with-mpfr=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 --with-mpc=/rusers/sys_cron/grab_gcc/downloads_rel/lib/efi2 Thread model: posix gcc version 4.8.1 (GCC)
[Bug c++/58060] New: separate compilation of gnu multiversioning gives undefined/multiple defined symbols at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58060
Bug ID: 58060
Summary: separate compilation of gnu multiversioning gives
undefined/multiple defined symbols at link time
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mib.bugzilla at gmail dot com
Created attachment 30592
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30592action=edit
test case part 1
I tried gnu multiversioning with separate compilation but I get both these
messages at link time: multiple defined symbols and undefined symbol.
g++ -o foo.exe mv6c-1.o mv6c.o
mv6c.o: In function `foo()':
mv6c.C:(.text+0x0): multiple definition of `foo()'
mv6c-1.o:mv6c-1.C:(.text+0x0): first defined here
mv6c-1.o: In function `_Z3foov.resolver':
mv6c-1.C:(.text._Z3foov.resolver[_Z3foov.resolver]+0x1b): undefined reference
to `_Z3foov.arch_corei7'
collect2: error: ld returned 1 exit status
-bash-4.1$ cp mv6c*C ~/my_home
-bash-4.1$ cat mv6c.C
/* corei7 version of foo. */
__attribute__ ((target(arch=corei7)))
int foo () { return 7; }
// I thought this compilation unit would create a function with the name
arch_corei7, but it just creates a foo without target decoration
[Bug c++/58060] separate compilation of gnu multiversioning gives undefined/multiple defined symbols at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58060 --- Comment #1 from mib.bugzilla at gmail dot com --- Created attachment 30593 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30593action=edit test case part 2
[Bug fortran/58058] [4.7/4.8/4.9 Regression] Memory leak with transfer function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058
--- Comment #2 from janus at gcc dot gnu.org ---
I think the following should be enough to fix it:
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c(revision 201331)
+++ gcc/fortran/trans-intrinsic.c(working copy)
@@ -5652,8 +5652,7 @@ scalar_transfer:
if (expr-ts.type == BT_CHARACTER)
{
- tree direct;
- tree indirect;
+ tree direct, indirect, free;
ptr = convert (gfc_get_pchar_type (expr-ts.kind), source);
tmpdecl = gfc_create_var (gfc_get_pchar_type (expr-ts.kind),
@@ -5686,6 +5685,13 @@ scalar_transfer:
tmp = build3_v (COND_EXPR, tmp, direct, indirect);
gfc_add_expr_to_block (se-pre, tmp);
+ /* Free the temporary string, if necessary. */
+ free = gfc_call_free (tmpdecl);
+ tmp = fold_build2_loc (input_location, GT_EXPR, boolean_type_node,
+ dest_word_len, source_bytes);
+ tmp = build3_v (COND_EXPR, tmp, free, build_empty_stmt
(input_location));
+ gfc_add_expr_to_block (se-post, tmp);
+
se-expr = tmpdecl;
se-string_length = fold_convert (gfc_charlen_type_node, dest_word_len);
}
[Bug target/57431] ICE in simplify_const_unary_operation vld1_dup_s64/vst1_s64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57431 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-02 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Confirmed. vld1_dup_[su]64() are degenerate into simple load operations and shouldn't be using vec_duplicate at all.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #20 from Bill Schmidt wschmidt at gcc dot gnu.org --- After thinking it over some more, I think you are right, Martin. We should go ahead with the optimization with the corrected alignment attached to the type. Please go ahead with your patch. I will run a round of regression testing on PowerPC (an architecture for which the generic test produces misaligned but legal memory references) as well. Sorry for going back and forth on this. I try to avoid wasting compile time on useless transformations, but in this case we will still see some benefit in some cases, and the code should be no worse than before when we don't. Thanks, Bill
[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 --- Comment #9 from Ed Smith-Rowland 3dw4rd at verizon dot net --- I think I need to test for keyword in addition to testing for macro in libcpp/lex.c I'll look at this. I'll also look at getting a better error.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #22 from Eric Botcazou ebotcazou at gcc dot gnu.org --- After thinking it over some more, I think you are right, Martin. We should go ahead with the optimization with the corrected alignment attached to the type. Please go ahead with your patch. I will run a round of regression testing on PowerPC (an architecture for which the generic test produces misaligned but legal memory references) as well. Sorry for going back and forth on this. I try to avoid wasting compile time on useless transformations, but in this case we will still see some benefit in some cases, and the code should be no worse than before when we don't. We should be very wary of generating unaligned accesses during optimization for targets that define SLOW_UNALIGNED_ACCESS. And note that most architectures supported by GCC are STRICT_ALIGNMENT, not the other way around, so it's the common case.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #23 from Bill Schmidt wschmidt at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #22) We should be very wary of generating unaligned accesses during optimization for targets that define SLOW_UNALIGNED_ACCESS. And note that most architectures supported by GCC are STRICT_ALIGNMENT, not the other way around, so it's the common case. I fully agree. In this case, we aren't introducing new unaligned accesses, but simply restructuring the address that points to the same (unaligned) location. The restructuring allows us to common the base addressing for related array elements in the same misaligned structure, which will produce slightly better code with the same number of unaligned accesses. Martin's patch just makes sure the necessary alignment is recorded on the restructured memory reference, so the back ends can do their usual tricks to copy misaligned references in parts, etc.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #21 from Bill Schmidt wschmidt at gcc dot gnu.org --- My only comment on the patch would be to please add commentary indicating why the change is being made, and referencing this PR. Something along the lines of: /* Ensure the memory reference carries the minimum alignment requirement for the data type. Some targets (e.g., ARM) can't always handle an unaligned reference otherwise. See PR58041. */ ...or something like that. Thanks again! Bill
[Bug fortran/58058] [4.7/4.8/4.9 Regression] Memory leak with transfer function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) I think the following should be enough to fix it: It also regtests cleanly.
[Bug libgcc/58061] New: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061 Bug ID: 58061 Summary: internal compiler error Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: whitequill at abstractions dot me Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) AR=/tools/bin/$LFS_TGT-ar RANLIB=/tools/bin/$LFS_TGT-ranlib /mnt/Share/source/gcc/configure --build=$MACHTYPE --host=$MACHTYPE --target=$LFS_TGT --prefix=/tools --disable-nls --disable-shared --disable-multilib --disable-decimal-float --disable-threads --disable-libmudflap --disable-libssp --disable-libgomp --enable-languages=c,c++ --without-ppl --without-cloog --with-headers=/tools/$LFS_TGT/include /home/lfs/./gcc/xgcc -B/home/lfs/./gcc/ -L/tools/x86_64-w64-mingw32/lib -L/tools/mingw/lib -isystem /tools/x86_64-w64-mingw32/include -isystem /tools/mingw/include -B/tools/x86_64-w64-mingw32/bin/ -B/tools/x86_64-w64-mingw32/lib/ -isystem /tools/x86_64-w64-mingw32/include -isystem /tools/x86_64-w64-mingw32/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc -I/mnt/Share/source/gcc/libgcc -I/mnt/Share/source/gcc/libgcc/. -I/mnt/Share/source/gcc/libgcc/../gcc -I/mnt/Share/source/gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _trampoline.o -MT _trampoline.o -MD -MP -MF _trampoline.dep -DL_trampoline -c /mnt/Share/source/gcc/libgcc/libgcc2.c In file included from /home/lfs/gcc/include/x86intrin.h:27:0, from /tools/x86_64-w64-mingw32/include/intrin.h:30, from /tools/x86_64-w64-mingw32/include/winnt.h:1444, from /tools/x86_64-w64-mingw32/include/windef.h:137, from /tools/x86_64-w64-mingw32/include/windows.h:62, from /mnt/Share/source/gcc/libgcc/libgcc2.c:2082: /home/lfs/gcc/include/ia32intrin.h:54:9: internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633 #pragma GCC target(sse4.2) ^ 0x50f1a2 c_builtin_function_ext_scope(tree_node*) /mnt/Share/source/gcc/gcc/c/c-decl.c:3633 0x808f01 add_builtin_function_common /mnt/Share/source/gcc/gcc/langhooks.c:561 0x809bb3 add_builtin_function_ext_scope(char const*, tree_node*, int, built_in_class, char const*, tree_node*) /mnt/Share/source/gcc/gcc/langhooks.c:597 0xb7fdc8 ix86_add_new_builtins /mnt/Share/source/gcc/gcc/config/i386/i386.c:27184 0xb7fdc8 ix86_valid_target_attribute_tree(tree_node*) /mnt/Share/source/gcc/gcc/config/i386/i386.c:4512 0x5c99d0 ix86_pragma_target_parse /mnt/Share/source/gcc/gcc/config/i386/i386-c.c:385 0x5afb6d handle_pragma_target /mnt/Share/source/gcc/gcc/c-family/c-pragma.c:805 0x54f5be c_parser_pragma /mnt/Share/source/gcc/gcc/c/c-parser.c:8972 0x55ffeb c_parser_external_declaration /mnt/Share/source/gcc/gcc/c/c-parser.c:1345 0x560957 c_parser_translation_unit /mnt/Share/source/gcc/gcc/c/c-parser.c:1251 0x560957 c_parse_file() /mnt/Share/source/gcc/gcc/c/c-parser.c:11223 0x5ad6f4 c_common_parse_file() /mnt/Share/source/gcc/gcc/c-family/c-opts.c:1046 for proper reproduction the version of gcc build being cross-built was: revision: 201377 from svn update. the headers being included are here: http://mingw-wine.googlecode.com/files/mingw64api-mingwport-src.7z /mnt/network/source/mingw64api-mingwport-src/mingw-w64-headers/configure --build=$MACHTYPE --host=$LFS_TGT --prefix=/tools/$LFS_TGT
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #186 from Jan Hubicka hubicka at gcc dot gnu.org --- oprofile of merging 6764713.0501 lto1 inflate_fast 38682 7.4624 lto1 compare_tree_sccs_1(tree_node*, tree_node*, tree_node***) 32365 6.2437 lto1 streamer_read_uhwi(lto_input_block*) 31198 6.0186 lto1 streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*) 21155 4.0811 libc-2.11.1.so msort_with_tmp 19581 3.7775 lto1 ht_lookup_with_hash(ht*, unsigned char const*, unsigned long, unsigned int, ht_lookup_option) 16584 3.1993 lto1 lto_input_tree(lto_input_block*, data_in*) 15203 2.9329 lto1 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int) 15194 2.9312 libc-2.11.1.so memcpy 14823 2.8596 lto1 htab_find_slot_with_hash 12860 2.4809 lto1 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*) 12705 2.4510 lto1 hash_tabletree_scc_hasher, xcallocator::find_slot_with_hash(tree_scc const*, unsigned int, insert_option) 11773 2.2712 lto1 adler32 11504 2.2193 libc-2.11.1.so _IO_vfscanf 11401 2.1994 lto1 unify_scc(streamer_tree_cache_d*, unsigned int, unsigned int, unsigned int, unsigned int) 9548 1.8420 lto1 streamer_get_pickled_tree(lto_input_block*, data_in*) 9315 1.7970 lto1 inflate IPA 18799 6.2862 lto1 symtab_remove_unreachable_nodes(bool, _IO_FILE*) 11878 3.9719 lto1 cgraph_redirect_edge_callee(cgraph_edge*, cgraph_node*) 11223 3.7528 lto1 do_per_function(void (*)(void*), void*) 10813 3.6157 lto1 pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) 8415 2.8139 lto1 ipa_reverse_postorder(cgraph_node**) 7689 2.5711 lto1 htab_find_slot_with_hash 7677 2.5671 lto1 do_estimate_growth_1(cgraph_node*, void*) 7477 2.5002 libc-2.11.1.so free 7035 2.3524 libc-2.11.1.so malloc_consolidate Stream out 9440 16.1663 lto1 linemap_lookup(line_maps*, unsigned int) 7663 13.1231 lto1 DFS_write_tree(output_block*, sccs*, tree_node*, bool, bool) 6052 10.3643 lto1 streamer_write_uhwi_stream(lto_output_stream*, unsigned long) 5831 9.9858 lto1 pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) 3342 5.7233 lto1 streamer_tree_cache_lookup(streamer_tree_cache_d*, tree_node*, unsigned int*) 2229 3.8172 lto1 pointer_map_insert(pointer_map_t*, void const*) 2196 3.7607 lto1 streamer_pack_tree_bitfields(output_block*, bitpack_d*, tree_node*) 2054 3.5175 lto1 lto_output_tree(output_block*, tree_node*, bool, bool) 1656 2.8360 lto1 inflate_fast 1655 2.8342 lto1 pointer_mapunsigned int::insert(void const*, bool*)
[Bug c++/57548] calling gnu multiversioned function at file scope causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- What happened to the patch?
[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|UNCONFIRMED |NEW Last reconfirmed||2013-08-02 Component|target |rtl-optimization Summary|function clobbers callee|[4.8 regression] function |saved register on ARM |clobbers callee saved ||register on ARM Ever confirmed|0 |1 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org --- This is a bug in peep2_find_free_register() which fails to correctly validate that second and subsequent registers in a multi-register mode are available for use. Marked as a regression since this code would have worked correctly on older compilers.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Assignee|wschmidt at gcc dot gnu.org|jamborm at gcc dot gnu.org --- Comment #24 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 30594 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30594action=edit Proposed patch (In reply to Bill Schmidt from comment #20) After thinking it over some more, I think you are right, Martin. We should go ahead with the optimization with the corrected alignment attached to the type. Please go ahead with your patch. I will run a round of regression testing on PowerPC (an architecture for which the generic test produces misaligned but legal memory references) as well. Sorry for going back and forth on this. I try to avoid wasting compile time on useless transformations, but in this case we will still see some benefit in some cases, and the code should be no worse than before when we don't. No worries, I'm currently bootstrapping and testing the attached patch. I'm bootstrapping on x86_64-linux and with bugs like this one, any additional testing on other platforms is very welcome. (In reply to Bill Schmidt from comment #21) My only comment on the patch would be to please add commentary indicating why the change is being made, and referencing this PR. Something along the lines of: /* Ensure the memory reference carries the minimum alignment requirement for the data type. Some targets (e.g., ARM) can't always handle an unaligned reference otherwise. See PR58041. */ ...or something like that. The alignment information should be there regardless of the target so I just used the first sentence and the PR reference. I hope that is enough. Thanks.
[Bug c++/56014] [C++1y] ICE using return type deduction for member functions with -g enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56014 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 53756 ***
[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||jogojapan at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 56014 has been marked as a duplicate of this bug. ***
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #25 from Bill Schmidt wschmidt at gcc dot gnu.org --- Yep, that's terrific. Thanks.
[Bug c++/58062] New: [C++11] bogus __func__ lookup in lambda body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062
Bug ID: 58062
Summary: [C++11] bogus __func__ lookup in lambda body
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
In the case below, the __func__ identifier appears within a lambda body at
namespace scope.
GCC seems to find __func__ from somewhere, but the behaviour does not appear to
be supported by the Standard. MSVC gives the expected error.
When we are told by C++11 subclause 5.1.2 [expr.prim.lambda] paragraph 7 that
the compound-statement yields the function-body of the function call
operator, it can be taken that it means that a function-body is produced from
the compound-statement and that the latter is not an actual function-body. We
are also told that for the purposes of name lookup, the compound-statement is
considered in the context of the lambda-expression.
We find that, in the absence of a function-body, __func__ is not a specified to
be a predefined variable (8.4.1 [dcl.fct.def.general] paragraphs 7-8). We also
note that the form of a function definition (8.4.1 paragraph 1) is not present
in the above program and that the wording in subclauses 3.3.2
[basic.scope.pdecl] and 3.3.3 [basic.scope.block] (paragraphs 8 and 2,
respectively) covers only function-local predefined variables in function
definitions.
The conclusion is that __func__ in a lambda body is bound using the context of
the lambda-expression, and not bound later to be the function-local predefined
variable which would exist in the context of the function-call operator's
compiler-generated definition.
In the case of the code below, it means that the lookup for __func__ fails and
renders the program ill-formed.
## Small test:
namespace K {
auto ff = [] { return __func__; };
}
## Actual output:
Clean compile.
## Expected output:
main.cpp: In lambda function:
main.cpp:2:26: error: ‘__func__’ was not declared in this scope
auto ff = [] { return __func__; };
^
## g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
[Bug c++/58062] [C++11] bogus __func__ lookup in lambda body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062 --- Comment #1 from Hubert Tong hstong at ca dot ibm.com --- Compiler invocation was: g++ -std='c++11' main.cpp -Wall -Wextra -pedantic -c
[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 --- Comment #10 from Ed Smith-Rowland 3dw4rd at verizon dot net --- No, I remember now. This code *cannot* be right. With the addition of user-defined literals in C++11 and DR1473 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1473) placing keywords immediately after a string literal forms a valid user-defined string literal. As an extension we admit macros so placed with a warning. We do this not to break user code with inttypes.h and other user-created string macros. See http://gcc.gnu.org/ml/gcc/2013-06/msg00119.html and onwards - especially http://gcc.gnu.org/ml/gcc/2013-06/msg00121.html. This is not a bug. I vote close INVALID.
[Bug c++/57548] calling gnu multiversioned function at file scope causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548 --- Comment #3 from Sriraman Tallam tmsriram at google dot com --- (In reply to Paolo Carlini from comment #2) What happened to the patch? http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00426.html Patch has been submitted on Jun 7 in rev. 199842 to trunk. Sorry for not updating this bug. It can be marked fixed. Thanks Sri
[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 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com --- Ed, your analysis matches my intuition, but the error message is still very poor: to the user something like ... before STRING_USERDEF... makes no sense at all. Can we improve it?
[Bug c++/57548] calling gnu multiversioned function at file scope causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, thanks.
[Bug middle-end/58041] Unaligned access to arrays in packed structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041 --- Comment #26 from Bill Schmidt wschmidt at gcc dot gnu.org --- Martin's patch bootstrapped on powerpc64-unknown-linux-gnu with no new regressions.
[Bug c++/58054] 11.3 Friends, example from standard not compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58054 --- Comment #3 from Evgeniy Dushistov dushistov at mail dot ru --- Here history of changes of C++ standard that related to this bug: http://wg21.cmeerw.net/cwg/issue372
[Bug c++/58063] New: default arguments evaluated twice per call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
Bug ID: 58063
Summary: default arguments evaluated twice per call
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plokinom at gmail dot com
% cat try.cc
#include iostream
void f(bool x = !(std::cout hi!\n)) {
std::cout x '\n';
}
int main() {
f();
}
% g++ try.cc
% ./a.out
hi!
hi!
0
My question: Why is the default argument evaluated twice for each call to f()?
Is this allowed by the standard or a bug in g++?
% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/mauke/usr/local/libexec/gcc/i686-pc-linux-gnu/4.8.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.8.1/configure --prefix=/home/mauke/usr/local
--with-arch=native --with-tune=native --enable-__cxa_atexit
--enable-languages=c,c++,go --disable-nls
Thread model: posix
gcc version 4.8.1 (GCC)
[Bug libstdc++/57885] unordered_map find slower in 4.8.1 than 4.7.3 with integer key
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885 --- Comment #7 from François Dumont fdumont at gcc dot gnu.org --- I had a try and the result is not good. I attached the modified implementation if you want to have a try even if it is not perfect cause there are some exception safety issue. With the current implementation on my device I have the following result: Container:std::unordered_mapint,int Key:int Insertion: 23521 13329 13899 13544 13870 min=13329 max=23521 Lookup:29246 29120 32406 29524 29065 min=29065 max=32406 Container:std::tr1::unordered_mapint,int Key:int Insertion: 24410 10392 10404 10226 10180 min=10180 max=24410 Lookup:22728 19985 20314 19918 20741 min=19918 max=22728 With the modified solution using empty nodes to mark end of bucket I had: Container:std::unordered_mapint,int Key:int Insertion: 30080 19250 17861 18955 18350 min=17861 max=30080 Lookup:35884 36518 38623 35896 36661 min=35884 max=38623 Container:std::tr1::unordered_mapint,int Key:int Insertion: 28912 10112 10046 10447 13026 min=10046 max=28912 Lookup:22515 20114 19517 20400 19543 min=19517 max=22515 I fear that the memory overhead is not only impacting memory. It is surely not good for memory cache. If you want to give it a try and check generated assembly, additional testq should have vanish. François
[Bug libstdc++/57840] ::std ::result_of is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added CC||fdumont at gcc dot gnu.org --- Comment #1 from François Dumont fdumont at gcc dot gnu.org --- Created attachment 30595 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30595action=edit To replace hashtable_policy.h in include/bits folder
[Bug libstdc++/57840] ::std ::result_of is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840 --- Comment #2 from François Dumont fdumont at gcc dot gnu.org --- Created attachment 30596 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30596action=edit The modified hashtable implementation To replace hashtable.h in include/bits
[Bug libstdc++/57885] unordered_map find slower in 4.8.1 than 4.7.3 with integer key
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Francois, you attached to the wrong bug.
[Bug fortran/58064] New: Cannot compile gcc-4.8.1 by gcc-3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58064 Bug ID: 58064 Summary: Cannot compile gcc-4.8.1 by gcc-3.4.6 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: shinn.wu at gmail dot com Created attachment 30597 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30597action=edit config.log When compiling gcc-4.8.1 from SunOS xxx 5.11 11.1 i86pc i386 i86pc the error occurred after two hours.
[Bug target/58065] New: ARM MALLOC_ABI_ALIGNMENT is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065 Bug ID: 58065 Summary: ARM MALLOC_ABI_ALIGNMENT is wrong Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Target: arm*-*-* the ARM target architecture does not define the MALLOC_ABI_ALIGNMENT, therefore the default is used as BITS_PER_WORD, 32 in this case. This produces sometimes suboptimal code, because the front-end assumes that the function malloc() returns only word-aligned pointers, which is likely wrong. I have not found any specific requirements on the malloc alignment in the AAPCS document at http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf but I believe that the intention is to align everything including stack pointers to 8 bytes. Therefore I would suggest the attached patch which defines MALLOC_ABI_ALIGNMENT as BIGGEST_ALIGNMENT, which is 64 bits. As a proof that this has indeed some subtle influence on the generated code I attach a test case. The function foo is called by bar, and bar uses malloc to allocate the memory, with compiler options -O3 -g0 -mfpu=neon -mfloat-abi=softfp the function foo is inlined into bar, but the inlined version does not use vstr instructions any more, because the front-end does assume that malloc returns 4 byte aligned memory. If that was really true, foo must fail, if it is called without inlining. Therefore this code is just clumsy and less optimal than it could be.
[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30598 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30598action=edit test case
[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065 --- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30599 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30599action=edit compiler output without this patch
[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065 --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30600 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30600action=edit correct compiler output with patch
[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065 --- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30601 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30601action=edit Proposed patch
[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 --- Comment #16 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Martin Jambor from comment #15) Anyway, the policy of GCC seems to be that the default of MALLOC_ABI_ALIGNMENT is ultra-safe and targets should override it. So I would suggest, again :-), that you open a separate bug and CC ARM maintainers that should take care of it. Done. Bug#58065
[Bug c/58066] New: GCC mis-compiles access to TLS variable with -fPIC on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
Bug ID: 58066
Summary: GCC mis-compiles access to TLS variable with -fPIC on
x86_64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/10151411
Reproduced with current trunk, but is broken since at least gcc-4.3.1.
On Linux/x86_64, libstdc++.so.6 __cxa_get_globals looks like so:
Dump of assembler code for function __cxa_get_globals:
0x000cb430 +0: lea0x233131(%rip),%rdi
0x000cb437 +7: callq 0x4f570 __tls_get_addr@plt
0x000cb43c +12:add$0x0,%rax
0x000cb442 +18:retq
This calls external function __tls_get_addr with mis-aligned stack.
__tls_get_addr may itself call malloc, and malloc is user-replaceable,
and may assume that stack is properly aligned (and crash when it isn't).
Trivial test case:
static __thread char ccc;
extern C void* __cxa_get_globals() throw()
{
return ccc;
}
g++ -fPIC -S -O2 t.cc
results in:
__cxa_get_globals:
leaq_ZL3ccc@tlsld(%rip), %rdi
call__tls_get_addr@PLT
addq$_ZL3ccc@dtpoff, %rax
ret
Ian Lance Taylor says:
There is code in the i386 backend that is designed to avoid this.
However, it appears to have only been fully implemented for the GNU2 TLS
descriptor style ...
I suspect that the right fix is to add the line
ix86_tls_descriptor_calls_expanded_in_cfun = true;
to tls_global_dynamic_64_mode and tls_local_dynamic_base_64_mode
in gcc/config/i386/i386.md.
[Bug tree-optimization/57994] Constant folding of infinity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com --- Let's see.
[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- However, it appears to have only been fully implemented for the GNU2 TLS descriptor style ... Which most Linux distro default to anyways ...
