https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #8 from Pedro Alves ---
- There's exactly the same number of ifs and elses in the macro.
- The indentation of the else matches that of the if.
- There's actually no "else" at all at the macro call site, making the warning
look odd.
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #9 from Jakub Jelinek ---
If you want your macro to be immune from this, can't you do something like:
static inline struct obj_section *
whatever (struct obj_section *osect, struct obj_section *sections_end)
{
while (osect < sectio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #10 from Pedro Alves ---
Sure can. But the point is discussing what makes sense for the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
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=70922
--- Comment #12 from Jakub Jelinek ---
The warning is about dangling else, which you have in the source.
if (cond)
for (...)
if (cond2)
...
else
and while the C/C++ grammar say they bind to the inner-most if, many people
actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #13 from Pedro Alves ---
Should have been:
if (condition)
ALL_OBJFILE_OSECTIONS (o, osect)
{
/* do something with each o / osect */
}
else
return 0;
So if the ALL_OBJFILE_OSECTIONS macro conta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #25 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #23)
> We need to move those special SSE SF->DF splitters before
No, this splitter will fail if the transformation doesn't result in a constant.
So, we actually want this sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #14 from Pedro Alves ---
(In reply to Jakub Jelinek from comment #12)
> The warning is about dangling else, which you have in the source.
> if (cond)
> for (...)
> if (cond2)
> ...
> else
> and while the C/C++ grammar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #15 from Manuel López-Ibáñez ---
Indeed, we also warn for
void bar(int x)
{
if (x)
for (int i = x; i < 5; i++)
if (i != 0)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #16 from Pedro Alves ---
(In reply to Manuel López-Ibáñez from comment #15)
> But I can see that one may wrongly write:
>
> void bar(int x)
> {
> if (x)
> MACRO_WITH_ELSE(x)
> if(!x)
>return;
> }
>
> and no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70956
Bug ID: 70956
Summary: ICE in build_cross_bb_scalars_def, at
graphite-scop-detection.c:1725
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
Bug ID: 70957
Summary: testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on
power7
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
--- Comment #8 from rguenther at suse dot de ---
On May 4, 2016 6:20:14 PM GMT+02:00, "dominiq at lps dot ens.fr"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
>
>--- Comment #7 from Dominique d'Humieres
>---
>The ICEs are gone wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #17 from Manuel López-Ibáñez ---
(In reply to Pedro Alves from comment #16)
>
> This could also be sorted out with indentation level tracking -- the if
> binds to the else in the macro, but it is not indented as one would expect
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #26 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #25)
> (In reply to H.J. Lu from comment #23)
>
> > We need to move those special SSE SF->DF splitters before
>
> No, this splitter will fail if the transformation doesn't r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #27 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #26)
> But when this splitter fails, no other splitters will be tried.
Bah. This is clearly an implementation bug in the split pass. I don't think we
have to work around it,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70906
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Wed May 4 20:44:40 2016
New Revision: 235902
URL: https://gcc.gnu.org/viewcvs?rev=235902&root=gcc&view=rev
Log:
PR c++/70906
PR c++/70933
* tree-core.h (enum oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70933
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Wed May 4 20:44:40 2016
New Revision: 235902
URL: https://gcc.gnu.org/viewcvs?rev=235902&root=gcc&view=rev
Log:
PR c++/70906
PR c++/70933
* tree-core.h (enum oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70933
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70906
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
from Jan van Dijk ---
It appears this has been fixed long time ago already: both
g++ (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
g++ (GCC) 7.0.0 20160504 (experimental)
print the desired error message:
16106.cpp: In constructor ‘A::A(T&) [with T = int]’:
16106.cpp:8:12: e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #16 from Manuel López-Ibáñez ---
(In reply to Eric Gallager from comment #15)
> That has since been closed as fixed. So are the chances of this one being
> fixed next somewhat better now?
Not really. PR23608 fixes the case where the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #28 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 4 21:13:13 2016
New Revision: 235906
URL: https://gcc.gnu.org/viewcvs?rev=235906&root=gcc&view=rev
Log:
PR target/70873
* config/i386/i386.md
(TA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
Bug ID: 70958
Summary: Flag -Wreturn-type does not warn about lacking return
statement in main
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68722
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
--- Comment #2 from Carlos Maziero ---
I understand you explanation and agree with it, but I still have some concerns.
For instance, when using the -std=c89 flag, GCC 5.3.1 complains about the '//'
comments, which are not allowed in C89 standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
--- Comment #3 from Andrew Pinski ---
-std=gnu90 or -std=gnu89 (depending on the naming you like :) ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70951
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 4 May 2016, msebor at gcc dot gnu.org wrote:
> First, as the C example program shows, a type qualifier on a function return
> type does have an effect even in C. The description sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
Carlos Maziero changed:
What|Removed |Added
Severity|minor |trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662
--- Comment #15 from Alan Modra ---
Author: amodra
Date: Thu May 5 00:07:27 2016
New Revision: 235914
URL: https://gcc.gnu.org/viewcvs?rev=235914&root=gcc&view=rev
Log:
[RS6000] TARGET_RELOCATABLE
For ABI_V4, -mrelocatable and -fPIC both gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942
--- Comment #2 from TC ---
This only appears to affect captureless generic lambdas with a deduced return
type.
It might have something to do with the conversion function template to function
pointer - I'm guessing that it was somehow instantiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959
Bug ID: 70959
Summary: Invalid change of value conversion warning message
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959
William Clodius changed:
What|Removed |Added
Version|unknown |6.1.0
Summary|Invalid chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70810
sd.foolegg at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70890
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
101 - 140 of 140 matches
Mail list logo
