[Bug target/57636] cr16: ICE while building libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636 --- Comment #1 from Stefan Sørensen --- Created attachment 30318 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30318&action=edit Simple testcase that triggers the ICE when built with -Os -g
[Bug lto/57613] [LTO] error "multiple definition symbol" for local symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613 --- Comment #2 from Dmitry G. Dyachenko --- (In reply to Richard Biener from comment #1) > I don't think it works that way, hidden visibility makes it non-exported from > the dynamic object but it's still visible inside the object. You probably > want to mark it local instead? You are right. Thanks for clarifcation
[Bug lto/57613] [LTO] error "multiple definition symbol" for local symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613 Dmitry G. Dyachenko changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug c/57630] Error should include -std=c11 and friends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Tue Jun 18 07:41:19 2013 New Revision: 200163 URL: http://gcc.gnu.org/viewcvs?rev=200163&root=gcc&view=rev Log: PR c/57630 * c-decl.c (check_for_loop_decls): Improve diagnostics messages. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c
[Bug c/57630] Error should include -std=c11 and friends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637 --- Comment #1 from zhenqiang.chen at linaro dot org --- I had reproduced it on chrome book. It failed due to "alignment exception" for O3. I will do more investigation. If this bug blocks your work, please try "-fno-shrink-wrap" to disable the optimization.
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #10 from Richard Biener ---
(In reply to Jan Hubicka from comment #6)
> I am testing
> Index: lto-symtab.c
> ===
> --- lto-symtab.c(revision 200151)
> +++ lto-symtab.c(working copy)
> @@ -523,7 +523,8 @@ lto_symtab_merge_decls (void)
>
>FOR_EACH_SYMBOL (node)
> if (lto_symtab_symbol_p (node)
> - && node->symbol.next_sharing_asm_name)
> + && (node->symbol.next_sharing_asm_name
> + || node->symbol.previous_sharing_asm_name))
>{
> symtab_node n;
>
> @@ -639,6 +640,7 @@ lto_symtab_prevailing_decl (tree decl)
>ret = symtab_node_for_asm (DECL_ASSEMBLER_NAME (decl));
>if (!ret)
> return decl;
> + gcc_checking_assert (TREE_PUBLIC (ret->symbol.decl) && !DECL_EXTERNAL
> (ret->symbol.decl));
>
>return ret->symbol.decl;
> }
The loop looks weird. It probably should be re-structured to a simple
FOR_EACH_SYMBOL (node)
if (!node->symbol.prev_sharing_asm_name
&& node->symbol.next_sharing_asm_name)
lto_symtab_merge_decls_1 (node);
and not put too much magic into it.
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #11 from Richard Biener --- Which fixes the testcase, too. Giving it testing.
[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637 --- Comment #2 from ktkachov at gcc dot gnu.org --- Thanks, Zhenqiang. For me, it's a segfault in function DGETF2. gdb backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0001d964 in dgetf2_ () (gdb) bt #0 0x0001d964 in dgetf2_ () #1 0x000255a4 in dgetrf_ () #2 0x00015856 in sysnsl_ () #3 0x0001194e in MAIN__ () at galgel.f90:9 Looking further into it, the segfault seems to be from the function idamax that is inlined in dgetf2. Hope this helps, Kyrill
[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 --- Comment #6 from Mikael Pettersson --- Created attachment 30319 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30319&action=edit reduced test case Still ICEs 4.9-20130616, 4.8-20130613, and 4.7-20130615. Needs -O1 (or higher) -funroll-loops -m68000 (or -m68010). With -m68020 or higher it doesn't ICE. Suspect a target bug, so adding Andreas to cc: list.
[Bug lto/57334] [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Author: rguenth Date: Tue Jun 18 09:56:59 2013 New Revision: 200165 URL: http://gcc.gnu.org/viewcvs?rev=200165&root=gcc&view=rev Log: 2013-06-18 Richard Biener PR lto/57334 * lto-symtab.c (lto_symtab_merge_decls): Process nodes properly. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-symtab.c
[Bug lto/57483] Linux kernel (lto-3.9 branch) compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483 Bug 57483 depends on bug 57334, which changed state. Bug 57334 Summary: [4.9 regression] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/57617] OpenMP critical does not seem to synchronise correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57617 Nick Maclaren changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Nick Maclaren --- Brilliant. I had finger trouble with SSH. I do not know how I managed to look at the wrong version of the code for so long, but the update-in-critical failures for both compilers are my error. I shall change it to resolved but, if it resurfaces, it's my error. Sorry.
[Bug libstdc++/57403] A vector of volatile int doesn't work, but one of volatile void * does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403 --- Comment #5 from Nick Maclaren --- Because of the last comment, I am not going to close this as resolved, invalid, but please do so if appropriate.
[Bug rtl-optimization/57635] gcc hanging while compiling huge files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635 --- Comment #2 from vijay Nag --- With the compiler flag "-fno-var-tracking", it compiles in less than a minute. Although it is quite conspicuous from back-trace I thought it is worth mentioning this info.
[Bug libstdc++/57641] New: std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641 Bug ID: 57641 Summary: std::timed_mutex.try_lock_until() is broken Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mustrumr97 at gmail dot com It uses the duration since the time_point's clock's epoch. What if it's not the right clock? Different clocks may have different epochs. On my computer, the function works OK if the time_point is from high_resolution_clock but doesn't work if it's from steady_clock.
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641 --- Comment #1 from Jonathan Wakely --- I agree that code assumes the epochs are the same, but what you describe doesn't make sense since high_resolution_clock and steady_clock have the same epoch in our implementation. Are you seeing the first problem described at PR 54562? Do you have a testcase?
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #2 from Hristo Venev ---
Am I very stupid, or is
#include
#include
using Clock=std::chrono::steady_clock;
int main(){
std::timed_mutex m;
m.lock();
Clock::time_point tp=Clock::now()+std::chrono::seconds(2);
if(m.try_lock_until(tp)) return 1;
return 0;
}
supposed to run for ~2s and return 0?
With clang++ -stdlib=libc++ it works as I expect.
With clang++ -stdlib=libstdc++ and with g++ it returns 1 after 0.001s.
The result is the same for std::chrono::high_resolution_clock.
The test from cppreference.com is very similar.
http://en.cppreference.com/w/cpp/thread/timed_mutex/try_lock_until
What the hell is going on?
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641
--- Comment #3 from Jonathan Wakely ---
Testcase using clock with an earlier epoch:
#include
#include
#include
#include
namespace C = std::chrono;
struct clock
{
typedef C::system_clock::rep rep;
typedef C::system_clock::period period;
typedef C::system_clock::duration duration;
typedef std::chrono::time_point time_point;
static constexpr bool is_steady = C::system_clock::is_steady;
static time_point now() {
return time_point(C::system_clock::now().time_since_epoch() +
C::seconds(10));
}
};
std::timed_mutex mx;
void f()
{
mx.try_lock_until(clock::now() + C::milliseconds(1));
}
int main()
{
std::lock_guard l(mx);
auto start = C::system_clock::now();
std::thread t(f);
t.join();
auto stop = C::system_clock::now();
assert( (stop - start) < C::seconds(9) );
}
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641 --- Comment #4 from Jonathan Wakely --- It's undefined behaviour because you try to lock the same mutex twice in the same thread, see my testcase for a well-defined way to do it, calling try_lock_until in a new thread.
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-18 Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely --- The timed mutex requirements [thread.timedmutex.requirements] say: The expression m.try_lock_until(abs_time) shall be well-formed and have the following semantics: Requires: If m is of type std::timed_mutex, the calling thread does not own the mutex. Anyway, confirming as there's a bug here relating to clocks with different epochs, but it's easy enough to fix, I can look into it. The same problem exists with the private mutex type defined in std::shared_mutex
[Bug tree-optimization/57642] New: vectorizer not working with function templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642
Bug ID: 57642
Summary: vectorizer not working with function templates
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yzhang1985 at gmail dot com
Hi, the following simple loop doesn't vectorize in GCC 4.8.1, but does with
4.3.2. It does vectorize if I make DoIt a regular function instead of a
templated function.
#include
#include
#include
#include
#include
#include
class SqrtFunc
{
public:
float operator()(float x)
{
return (((3.02f * x) + 1.5f) * x - 2.1f) * x + 1.5f;
}
};
template
void DoIt(float *data, int size, Functor functor)
{
for (int i = 0; i < size; ++i)
{
data[i] = functor(data[i]);
}
}
int main()
{
float data[2048];
SqrtFunc functor;
DoIt(data, sizeof(data), functor);
return 0;
}
[Bug tree-optimization/57642] vectorizer not working with function templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642 --- Comment #1 from Yale Zhang --- I would like to know if there's an easy work around for this.
[Bug libitm/57643] New: libitm.c/reentrant.c hangs on POWER8 with HTM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643 Bug ID: 57643 Summary: libitm.c/reentrant.c hangs on POWER8 with HTM Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org The libitm.c/reentrant.c test case hangs on POWER8 hardware with HTM. The symptoms I'm seeing are my tbegin. instruction succeeds, but we fail the test (meaning someone has the write lock) at beginend.cc:200: if (unlikely(serial_lock.is_write_locked())) htm_abort(); ...so we abort the transaction. The failure is not persistent, so we do not break out of the loop due to: if (!htm_abort_should_retry(ret)) break; We then fall into the following code, where we hang trying to get the read lock: serial_lock.read_lock(tx); If I hack the call to htm_abort_should_retry(ret) so that we break of of the loop and fallback to SW TM, then the test case executes correctly. Andreas Krebbel said this fails on S390 as well. Andreas Kleen said this works on X86 with RTM. It's unknown whether on X86 whether its hw txn fails or succeeds or whether if it does fail over to sw txn, whether it skips the code we're hanging in.
[Bug c++/57638] warning container: 'integer_cst’ not supported by dump_type#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- Maybe this? It works for this testcase, but haven't run the testsuite. Index: pt.c === --- pt.c(revision 198545) +++ pt.c(working copy) @@ -16940,11 +16940,11 @@ unify (tree tparms, tree targs, tree par else if (uses_template_parms (tparm)) /* We haven't deduced the type of this parameter yet. Try again later. */ return unify_success (explain_p); else - return unify_type_mismatch (explain_p, tparm, arg); + return unify_type_mismatch (explain_p, tparm, TREE_TYPE (arg)); /* If ARG is a parameter pack or an expansion, we cannot unify against it unless PARM is also a parameter pack. */ if ((template_parameter_pack_p (arg) || PACK_EXPANSION_P (arg)) && !TEMPLATE_PARM_PARAMETER_PACK (parm))
[Bug bootstrap/57609] S/390 ESA mode bootstrap failure since r197266
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609 Jan-Benedict Glaw changed: What|Removed |Added CC||jbg...@lug-owl.de --- Comment #1 from Jan-Benedict Glaw --- Your recent commit breaks gcc build: commit f5cf1225bb37f43fa5bfca32cddadb9ee61aaa63 Author: krebbel Date: Tue Jun 18 08:59:46 2013 + 2013-06-18 Andreas Krebbel PR target/57609 * config/s390/s390.c (s390_chunkify_start): Replace next_real_insn with next_active_insn. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@200164 138bc75d-0d04-0410-961f-82ee72b054a4 g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../../gcc/gcc/../libbacktrace\ ../../../../gcc/gcc/config/s390/s390.c -o s390.o ../../../../gcc/gcc/config/s390/s390.c: In function ‘constant_pool* s390_chunkify_start()’: ../../../../gcc/gcc/config/s390/s390.c:7088:7: error: ‘dump_file’ was not declared in this scope ../../../../gcc/gcc/config/s390/s390.c:7099:6: error: ‘dump_file’ was not declared in this scope ../../../../gcc/gcc/config/s390/s390.c:7100:19: error: ‘print_rtx’ was not declared in this scope make[2]: *** [s390.o] Error 1 make[2]: Leaving directory `/home/vaxbuild/build/s390x-linux/gcc-stage1/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/vaxbuild/build/s390x-linux/gcc-stage1' You need to include dumpfile.h (for dump_file) and rtl.h (for print_rtx).
[Bug tree-optimization/57642] vectorizer not working with function templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57642 Yale Zhang changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Yale Zhang --- Sorry, please close this. My loop was eliminated as dead code, thus no vectorization. I saw the message not enough data-refs for auto-vectorization, which made me think it wasn't being vectorized, but that's probably from somewhere else.
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c++/53211] range-based 'for' expression of type 'const int []' has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|i.nixman at gmail dot com | Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini --- Comment #1 fixed in mainline so far.
[Bug other/53317] Conversion from __int128 to __float128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53317 Joseph S. Myers changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Joseph S. Myers --- Bug rediscovered through inspection of soft-fp code, patch posted at: http://sourceware.org/ml/libc-alpha/2013-06/msg00656.html I have a complete, tested GCC patch updating soft-fp and adding a testcase ready to commit once the soft-fp patch is approved for glibc. If someone then wishes to backport a fix for this (as a wrong-code bug) to active release branches, the soft-fp patch itself (plus GCC testcase) should be easy enough to apply to past branches without the whole soft-fp update.
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |4.8.2 --- Comment #6 from Jonathan Wakely --- Fixed on trunk, I'll fix this for 4.8.2 as well.
[Bug c++/57638] warning container: 'integer_cst’ not supported by dump_type#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-18 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini --- Patch works great for me and passes testing. Are you going to submit it? In fact, I don't think you really need an approval.
[Bug c++/57638] warning container: 'integer_cst’ not supported by dump_type#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638 --- Comment #3 from Manuel López-Ibáñez --- (In reply to Paolo Carlini from comment #2) > Patch works great for me and passes testing. Are you going to submit it? In > fact, I don't think you really need an approval. If you could do that for me, I would appreciate it. Sadly, I don't have as much free time to dedicate to GCC as I used to. If you don't have time, I will eventually do it, but it may take me some time.
[Bug c++/57638] warning container: 'integer_cst’ not supported by dump_type#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638 --- Comment #4 from Paolo Carlini --- No problem, patch sent.
[Bug lto/57483] Linux kernel (lto-3.9 branch) compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483 --- Comment #2 from Martin Liška --- Works for me, could be marker as fixed.
[Bug libstdc++/54562] mutex and condition variable timers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #4 from Jonathan Wakely ---
Created attachment 30320
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30320&action=edit
proposed patch to use clocks correctly
The change should be unnecessary, as high_resolution_clock
is a typedef for system_clock in our implementation.
The timed_mutex change is an improvement but not ideal, because the standard
says implementations "should" use a steady clock for try_lock_for() but use the
system_clock for try_lock_until(), and pthread_mutex_timedlock() uses
CLOCK_REALTIME, which corresponds to our system_clock.
I'm going to test this patch (against the current svn trunk, after
gcc.gnu.org/r200180) to fix the timed_mutex issue. The patch attempts to use
the steady clock for relative timeouts, converting to the high_resolution_clock
(aka system_clock) for the pthread call, and re-checks on timeout to handle
cases where a clock is adjusted during the wait.
N.B. your test technically has undefined behaviour because it attempts to
relock the mutex in the same thread, I'm using this to reproduce the problem
instead:
#include
#include
#include
#include
typedef std::chrono::high_resolution_clock rt_clock;
typedef std::chrono::time_point rt_time_point;
std::timed_mutex mutex;
void f()
{
mutex.try_lock_for(std::chrono::seconds(3));
}
int main()
{
mutex.lock();
std::cout << "mutex locked" << std::endl;
rt_time_point t1 = rt_clock::now();
std::thread(f).join();
rt_time_point t2 = rt_clock::now();
std::cout << "delay: "
<<
std::chrono::duration_cast(t2-t1).count()
<< std::endl;
return 0;
}
[Bug c++/57644] New: [C++1y] Cannot bind bitfield to lvalue reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57644
Bug ID: 57644
Summary: [C++1y] Cannot bind bitfield to lvalue reference
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
$ g++-snapshot --version
g++-snapshot (Debian 20130603-1) 4.9.0 20130603 (experimental) [trunk revision
199603]
$ cat main.cpp
struct foo {
unsigned i: 32;
};
int main()
{
foo f {};
return (f.i);
}
$ g++-snapshot -std=c++1y main.cpp
main.cpp: In function 'int main()':
main.cpp:8:15: error: cannot bind bitfield 'f.foo::i' to 'unsigned int&'
return (f.i);
^
---
The code is accepted if either the parens are removed (i.e. just return f.i;)
or when using -std=c++11.
[Bug c++/57645] New: Explicitly-declared destructor with no exception specification is always noexcept(true)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57645
Bug ID: 57645
Summary: Explicitly-declared destructor with no exception
specification is always noexcept(true)
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: travis at gockelhut dot com
#include
struct Thrower
{
~Thrower() noexcept(false) { throw 1; }
};
struct Explicit
{
~Explicit() {}
Thrower t;
};
static_assert(!std::is_nothrow_destructible::value, "Explicit");
This will fail on the static_assert in 4.8, in contrast to §15.4.14:
> ..If f is an...destructor...it's implicit exception-specification
> specifies...f has the exception-specification noexcept(true) if every
> function it directly invokes allows no exceptions.
And Thrower::~Thrower is directly invoked according to §12.4.8:
> After executing the body of the destructor and destroying any automatic
> objects allocated within the body, a destructor for class X calls the
> destructors for X’s direct non-variant non-static data members...
[Bug c++/57646] New: bogus warning about uninitialized ‘saved_stack.1’ with gotos and VLAs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57646 Bug ID: 57646 Summary: bogus warning about uninitialized ‘saved_stack.1’ with gotos and VLAs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: b.r.longbons at gmail dot com Created attachment 30321 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30321&action=edit minimal testcase The attached reduced testcase gives a warning that a nonexistent variable, 'saved_stack.1', may be used uninitialized. The testcase does not need any special compiler flags. There are a bunch of bugs with similar descriptions, but they either don't involve invented variables or were marked as fixed. In particular, it looks fairly similar to bug 43013, which was fixed before 4.6.0. The differences I can see are that this only seems to happen in C++ with VLAs. Bad versions, all amd64: Gentoo: 4.4.7, 4.5.4, 4.6.0, 4.6.1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2, 4.7.3 Debian: 4.6.4-2, 4.7.3-4, 4.8.1-2 4.3.6 does not exhibit this issue, but that's too old to compile the codebase this is in. Since I haven't found a workaround short of disabling the warning, I'm stuck with clang for now, which lacks support for a lot of other essential warnings (*grumbles about old bug reports that still aren't fixed*).
[Bug c/57647] New: lvalue required as increment operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647 Bug ID: 57647 Summary: lvalue required as increment operand Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vijunag at gmail dot com I recently upgraded my gcc compiler from 3.4.X to 4.7.2 for my project. Consider the following expression char *foo = &bar; ((unsigned long*)foo)++ While gcc 3.4.X was more forgiving of this issue, 4.7.2 barfs out an error "lvalue required as increment operand". I did notice in gcc documentation that "cast as l-value has been removed". C and Objective-C The -Wstrict-aliasing=2 option has been added. This warning catches all unsafe cases, but it may also give a warning for some cases that are safe. The cast-as-lvalue, conditional-expression-as-lvalue and compound-expression-as-lvalue extensions, which were deprecated in 3.3.4 and 3.4, have been removed. The -fwritable-strings option, which was deprecated in 3.4, has been removed. #pragma pack() semantics have been brought closer to those used by other compilers. This also applies to C++. Taking the address of a variable with register storage is invalid in C. GCC now issues an error instead of a warning. Arrays of incomplete element type are invalid in C. GCC now issues an error for such arrays. Declarations such as extern struct s x[]; (where struct s has not been defined) can be moved after the definition of struct s. Function parameters declared as arrays of incomplete type can instead be declared as pointers. So the natural fix and equivalent legitimate expression for the same would ((unsigned long *)foo++), however with -Wall gcc again warns about unused-value. While gcc accepts the expression ((unsigned long*)foo++), the expression has become useless when -Wall -Werror is turned on since it throws "-Werror=unused-value". Either the expression should completely be removed or GCC should stop warning about such expressions.
[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604 --- Comment #3 from Andreas Krebbel --- (In reply to Vladimir Makarov from comment #2) Thanks! Btw. the Ada and Java bootstraps started failing with enabling LRA for S/390 (also without --with-arch=...). I'll wait for a patch for this PR before having a closer look. Perhaps the fails are related?!
