https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64703
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #14 from Jeffrey A. Law ---
So, forgive me, but is -DOPT supposed to be the good or the bad code?
>From looking at the results I get, -DOPT is supposed to be the good code, but
that seems to conflict with c#6.
For -DOPT I get this P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
Bug ID: 65456
Summary: powerpc64le autovectorized copy loop missed
optimization
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #10 from Jan Hubicka ---
Actually perhaps we manage to produce external alias of non-external symbol
that also should not happen.
Index: ipa-icf.c
===
--- ipa-icf.c (re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439
--- Comment #5 from Jan Hubicka ---
I see, the difference is _ZN12_GLOBAL__N_11AC1Ev that is same body alias on
targets supporting it, but not on Darwin where C++ FE produces a duplicate.
I suppose we want just relax the testcase template to acce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #9 from Jan Hubicka ---
please also attachg WPA dump of -fdump-ipa-cgraph. I would be interested what
visibility _ZTCN7Utility2IO12GUnzipStreamE0_So/7 has.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #8 from Jan Hubicka ---
I am with terrible internet connection and it still does not reproduce for me
(I suppose difference between GNU LD and gold).
It is however clear what happens, we try to add symbol's alias that is external
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
--- Comment #8 from Jonathan Wakely ---
(In reply to Xiao Jia from comment #7)
> Adding "const" makes it compile. Is this the intended behavior or not?
Yes, of course. A const-reference causes a temporary to be created, you didn't
bind to the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #38 from Jerry DeLisle ---
Author: jvdelisle
Date: Wed Mar 18 01:47:12 2015
New Revision: 221482
URL: https://gcc.gnu.org/viewcvs?rev=221482&root=gcc&view=rev
Log:
2015-03-17 Jerry DeLisle
PR fortran/64432
* gfortran.dg/sy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436
--- Comment #6 from Adam Warner ---
Sorry, I did not mean to send my previous comment. I updated the title and a
hasty comment I was about to edit got added.
It is unfair to dismiss my enhancement request as invalid. I correctly
explained the cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
Xiao Jia changed:
What|Removed |Added
CC||xiaoj at google dot com
--- Comment #7 from X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #13 from Alexandre Oliva ---
I looked further into why changing gimple_can_coalesce_p didn't work:
build_ssa_conflict_graph only marks conflicts between SSA names if they share
the same base variable. This explains why we have a conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010
Aldy Hernandez changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64626
emsr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010
mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #6 from David ---
Actually, the code already uses InterlockedCompareExchange. UNLESS users
explicitly tell it not to:
#ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES
static inline long
__gthr_i486_lock_cmp_xchg(long *__dest, long __xch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #12 from Alexandre Oliva ---
I just noticed that I reversed with and without -DOPT in my analysis in comment
6. Apologies for any confusion this may have caused.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010
--- Comment #8 from Aldy Hernandez ---
PING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
--- Comment #5 from Zoltan Hidvegi ---
Btw. the original testcase was really failing because of Bug 33704, and it
seems that is already fixed, however it's still open, or is it not fully fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436
--- Comment #5 from Andrew Pinski ---
(In reply to Adam Warner from comment #4)
> Yes I've hit the limit. A limit that your competition clang does not have.
>
> This is not a theoretical discussion.
What kind of inline-asm are you using this fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #37 from Jerry DeLisle ---
(In reply to Harald Anlauf from comment #36)
--snip--->
> are you sure that .and.ing the conditions in the testcase is correct,
> or shouldn't they rather be .or.ed?
Oh of course. Thanks Harald. I will se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436
Adam Warner changed:
What|Removed |Added
Summary|Max number of extended asm |Max number of extended asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
Alexandre Oliva changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #9 from Alexandre Oliva ---
(In reply to Jeffrey A. Law from comment #7)
> OK, but why does this make such a difference in the final result. Ie, what
> happens as we get into RTL.
Err, I covered that bit in my description: we emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64802
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 17 Mar 2015, jens.gustedt at inria dot fr wrote:
> Eliminating qualifiers in expressions is easy for arithmetic types at least,
> something like
>
> __typeof__((a)+0) b;
No, that w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #2 from Jens Gustedt ---
Since typeof is a gcc extension, there is not much arguing about it, but this
sounds wrong to me. Use cases I have, and that I seen used by others are for
example something like
_Atomic int a;
__typeof__(a) b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #1 from joseph at codesourcery dot com ---
By design, typeof removes qualifiers in certain cases. Currently it only
removes them from atomic types (as needed for use in ), but
arguably it should do so more generally - this would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #13 from Jakub Jelinek ---
Created attachment 35047
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35047&action=edit
gcc5-pr65450.patch
Fix that passed bootstrap/regtest on x86_64-linux and i686-linux. It is I
think conservati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
Bug ID: 65455
Summary: typeof _Atomic fails
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #36 from Harald Anlauf ---
(In reply to Jerry DeLisle from comment #35)
> Author: jvdelisle
> Date: Tue Mar 17 01:22:12 2015
> New Revision: 221473
>
> URL: https://gcc.gnu.org/viewcvs?rev=221473&root=gcc&view=rev
> Log:
> 2015-03-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
--- Comment #7 from Marek Polacek ---
Patch queued for next stage1:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00698.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #20 from Sebastian Pop ---
Created attachment 35046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35046&action=edit
fix
The attached patch fixes the problem by not creating diamonds in the copied
jump-thread.
I'm bootstrappin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
Zoltan Hidvegi changed:
What|Removed |Added
CC||zoltan at hidvegi dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443
--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to vries from comment #3)
> (In reply to vries from comment #2)
> > The problem with this transformation is that '_20 + 1' might overflow,
> > that's what the comment 'This may need some a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65072
--- Comment #6 from Marek Polacek ---
And clang accepts it.
It looks like we don't need the C<> around decltype:
template class C
{
struct
{
int i;
};
auto operator*(const C m) -> decltype (m.i);
};
void fn1 (const C);
C a;
This o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #19 from Jeffrey A. Law ---
I'm still getting up to speed here, but this sounds vaguely familiar to
something we've run into before.
https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01073.html
Is when the code moved to a later point, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65072
--- Comment #5 from Markus Trippelsdorf ---
EDG rejects it:
tes2.ii(7): error: incomplete type is not allowed
auto operator*(const C m) -> C ;
^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65072
--- Comment #4 from Marek Polacek ---
I couldn't bisect this, but started before r193621.
A bit more reduced:
template class C
{
struct
{
int i;
};
auto operator*(const C m) -> C ;
};
void fn1 (const C);
C a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #7 from Jeffrey A. Law ---
OK, but why does this make such a difference in the final result. Ie, what
happens as we get into RTL.
It would also be helpful to see the current & desired output for the case where
we've regressed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #12 from Jakub Jelinek ---
So, I believe it is incorrect ALIGN info as can be seen in the
-fdump-tree-all-alias dumps.
Seems with current trunk on x86_64-linux and
-g -quiet -mtune=amdfam10 -O3 pr65450.f90
the problematic memory load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65061
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Tue Mar 17 17:38:25 2015
New Revision: 221478
URL: https://gcc.gnu.org/viewcvs?rev=221478&root=gcc&view=rev
Log:
PR c++/65061
* parser.c (cp_parser_template_name): Call strip_usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439
--- Comment #4 from Dominique d'Humieres ---
Created attachment 35045
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35045&action=edit
dump-ipa-icf of ipa-icf-4.C
> Can you attach the dump file? It is probalby due to lack of aliases,
> but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439
--- Comment #3 from Jan Hubicka ---
Can you attach the dump file? It is probalby due to lack of aliases, but I am
bit surprises the number of equal symbols grows up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65445
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51550
vehre at gcc dot gnu.org changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65340
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65454
Bug ID: 65454
Summary: Extending both forms of relational operators
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64208
--- Comment #3 from Yvan Roux ---
Notice that this bug is latent on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65072
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64208
Yvan Roux changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452
--- Comment #2 from Ray Strode ---
probably should catch
if (foo == foo) {
}
type situations too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078
--- Comment #11 from Jakub Jelinek ---
Created attachment 35044
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35044&action=edit
gcc5-pr65078.patch
Untested fix using a pre-reload splitter of mov[sd]i if the source is SI/DImode
lowpart sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65453
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143
--- Comment #4 from Balakrishnan B ---
Thanks for confirming!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65453
Bug ID: 65453
Summary: ICE in build_function_decl, at
fortran/trans-decl.c:2001
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic, error-recove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452
David Malcolm changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |4.9.3
Summary|[5.0 Regression]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452
Bug ID: 65452
Summary: strcmp (foo, foo) could give a warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451
--- Comment #2 from John Marino ---
right url for freshports: http://www.freshports.org/devel/matreshka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451
--- Comment #1 from John Marino ---
Note that I saw this on 20150308 snapshot with Matreshka too in a different
file. That snapshot also failed on building OpenToken with a GNAT BUG, but
OpenToken builds fine with 20150315 snapshot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451
Bug ID: 65451
Summary: gnat bug: Storage_Error stack overflow or erroneous
memory access
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #10 from Jakub Jelinek ---
(In reply to Dominique d'Humieres from comment #9)
> > Also crashes with -mtune=amdfam10. But in this case it even
> > crashes when compiled with 4.9.2.
>
> Revision r204000 (2013-10-24) is OK, r204945 (201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #9 from Dominique d'Humieres ---
> Also crashes with -mtune=amdfam10. But in this case it even
> crashes when compiled with 4.9.2.
Revision r204000 (2013-10-24) is OK, r204945 (2013-11-18) is not.
> Works fine with -fwrapv...
Confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #8 from Markus Trippelsdorf ---
Works fine with -fwrapv...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078
--- Comment #10 from Jakub Jelinek ---
During the expansion, we don't try vec_extract because we are trying to extract
low DImode (64bits) out of a V16QImode pseudo, which is not really vector
element extraction, and the middle end doesn't know t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #9 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
--- Comment #15 from ktkachov at gcc dot gnu.org ---
Hmmm, actually it's not that simple, as testing showed.
The comment at the final load-to-regs code says:
/* If part should go in registers, copy that part
into the appropriate registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296
--- Comment #6 from Georg-Johann Lay ---
Author: gjl
Date: Tue Mar 17 10:34:11 2015
New Revision: 221475
URL: https://gcc.gnu.org/viewcvs?rev=221475&root=gcc&view=rev
Log:
PR target/65296
* config/avr/avr.opt (-nodevicelib): New option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078
Jakub Jelinek changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439
Dominique d'Humieres changed:
What|Removed |Added
Target|hppa2.0w-hp-hpux11.11, |hppa2.0w-hp-hpux11.11,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #0)
> The compiler generates unaligned access for Polyhedron channel.f90 test when
> compiled with -O2 -mtune=k8:
Whoops, this should read "-O3 -mtune=k8".
>
> /home/uros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #3 from Dominique d'Humieres ---
Confirmed between r220156 (2015-01-27, OK) and r220302 (2015-01-31, segfault).
I am not sure this is a fortran problem (no segfault if the code is compiled
with '-O3 -fno-tree-vectorize -mtune=k8').
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
--- Comment #14 from ktkachov at gcc dot gnu.org ---
Right, I think the root cause is the emit_push_insn in expr.c.
It's supposed to push what needs to be pushed from a partial argument onto the
stack and do the moves into the registers.
Currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #2 from Uroš Bizjak ---
The problematic instruction (insn 1717) is generated from:
;; vect__1095.501_3524 = MEM[base: vectp.499_3571, offset: 0B];
(insn 1717 1716 0 (set (reg:V2DF 1511 [ vect__1095.501 ])
(mem:V2DF (reg/f:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65312
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65312
--- Comment #5 from radventure at yandex dot ru ---
(In reply to Marek Polacek from comment #4)
> Looks like this PR could be resolved as a NOTABUG?
Agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #1 from Uroš Bizjak ---
Created attachment 35042
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35042&action=edit
Testcase from Polyhedron testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
Bug ID: 65450
Summary: [5.0 Regression]: Unaligned access with -O3 -mtune=k8
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449
Bug ID: 65449
Summary: -fstrict-volatile-bitfields affects volatile pointer
dereference and produce wrong codes
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448
Bug ID: 65448
Summary: Allow for cascade includes in error messages
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65447
Bug ID: 65447
Summary: AArch64: iv-opt causes bad addressing
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #15 from fiesh at zefix dot tv ---
Boost 1.58.0 has a workaround by making one function "explicit".
(https://github.com/boostorg/polygon/commit/634aa3de29d63dcf02a478ca2b5045c5e9ccb7e0)
Since this means the bug becomes irrelevant for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446
--- Comment #1 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #0)
> It doesn't warn but should warn for
>printf("%u\n", _short);
Actually, it (correctly) does warn in this case (as short it promoted to int,
which is also unsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446
Bug ID: 65446
Summary: Improve -Wformat-signedness
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634
--- Comment #6 from Jörg Richter ---
Is this stable enough to be considered for 4.9.3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65445
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 101 matches
Mail list logo
