https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79587
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79587
--- Comment #3 from Markus Trippelsdorf ---
Created attachment 40768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40768&action=edit
testcase for trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79587
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588
Bug ID: 79588
Summary: [7 Regression] ICE in warn_for_restrict with
-Wrestrict
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79589
Bug ID: 79589
Summary: ICE in gimplify_compound_expr (gimplify.c:5712) with
-fsanitize=undefined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503
--- Comment #6 from Samuel Thibault ---
Well, yes and no: -Wrestrict does indeed warn about this in gcc 7 now, but
-Wall -Wextra does not contain -Wrestrict, so that makes it almost useless.
Is there a reason for not including -Wrestrict in at l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Sat Feb 18 13:13:43 2017
New Revision: 245560
URL: https://gcc.gnu.org/viewcvs?rev=245560&root=gcc&view=rev
Log:
PR target/79559
* config/i386/i386.c (ix86_print_operand):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Sat Feb 18 13:14:43 2017
New Revision: 245561
URL: https://gcc.gnu.org/viewcvs?rev=245561&root=gcc&view=rev
Log:
PR target/79569
* config/i386/i386.opt (m3dnowa): Replace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739
--- Comment #2 from Jonathan Wakely ---
The standard says those types must have a constexpr constructor, but we can't
implement that on all targets:
// Common base class for std::mutex and std::timed_mutex
class __mutex_base
{
protected:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79581
--- Comment #2 from PeteVine ---
Created attachment 40769
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40769&action=edit
sphract
The other file required to run the benchmark straight from bugzilla! :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739
--- Comment #3 from John David Anglin ---
As far as I can tell, the definition for PTHREAD_MUTEX_INITIALIZE only involves
constant elements:
#define PTHREAD_MUTEX_INITIALIZER {\
__PTHREAD_MUTEX_VALID,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559
Jakub Jelinek changed:
What|Removed |Added
Summary|[5/6/7 Regression] ICE in |[5/6 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79569
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588
--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 40771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40771&action=edit
untested patch
Hi Jakub,
IIUC, the patch punts if param_pos < args->length(), ie, the defaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588
--- Comment #3 from Jakub Jelinek ---
I think the big question is if it isn't simply too early to warn at the place
you've added it, shouldn't it be done later on when the call arguments are
already complete? E.g. do you warn properly for calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739
--- Comment #4 from Jonathan Wakely ---
OK, so we get:
struct pthread_mutex {
short m_short[2];
int m_int;
int m_int1[4];
void *m_ptr;
int m_int2[2];
int m_int3[4];
short m_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739
--- Comment #5 from Jonathan Wakely ---
((void *)0 + 1) is also technically ill-formed, but G++ accepts it (Bug 60760).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739
--- Comment #6 from Jonathan Wakely ---
Oh, (void*)1 works, it's only rejected with the LL suffix. That's not
conforming either (and Clang rejects it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79591
Bug ID: 79591
Summary: [concepts] failure to distinguish overloads from
different namespaces with differing constraints
Product: gcc
Version: 7.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592
Bug ID: 79592
Summary: incomplete diagnostic "is not usable as a constexpr
function because:"
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Keywords: diagnost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68739
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> (I'll report that as a front-end bug).
Bug 79592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59284
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593
Bug ID: 79593
Summary: [Regression] Poor/Worse code generation for FPU on
versions after 6
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944
Oleg Pronin changed:
What|Removed |Added
CC||syber at crazypanda dot ru
--- Comment #4
27 matches
Mail list logo
