On Wed, Jul 13, 2016 at 03:35:10PM -0700, Bruce Korb wrote:
> Actually, it occurs to me:
>
> On Wed, Jul 13, 2016 at 11:23 AM, Marek Polacek wrote:
> > My current implementation warns here, but the warning can be suppressed
> > by adding /* FALLTHRU */ or [...]
>
> that the traditional "lint-ean
Actually, it occurs to me:
On Wed, Jul 13, 2016 at 11:23 AM, Marek Polacek wrote:
> My current implementation warns here, but the warning can be suppressed
> by adding /* FALLTHRU */ or [...]
that the traditional "lint-ean" spelling is "/* FALLTHROUGH */", so
why would the abbrev be accepted and
On Wed, Jul 13, 2016 at 11:39 AM, Marek Polacek wrote:
> Most likely what you saw was in cxx_pretty_printer::declaration_specifiers.
I only saw it once and, of course, it was once too often. ;)
If you fix it, it would sooth my sensibilities as the fixincludes maintainer,
making mine a small voice
On Wed, Jul 13, 2016 at 11:30:34AM -0700, Bruce Korb wrote:
> > On Mon, Jul 11, 2016 at 01:36:02PM -0700, Bruce Korb wrote:
> > [[putrid code deleted]]
> >> Does this patch mean that the above got fixed? I mean, if you're
> >> going to fret over linguistic tags to make falling through explicit,
>
> On Mon, Jul 11, 2016 at 01:36:02PM -0700, Bruce Korb wrote:
> [[putrid code deleted]]
>> Does this patch mean that the above got fixed? I mean, if you're
>> going to fret over linguistic tags to make falling through explicit,
>> it would seem the above code is pretty sore-thumby, yes?
>
> My cur
On Mon, Jul 11, 2016 at 01:36:02PM -0700, Bruce Korb wrote:
> I'm curious about this. In the process of developing a code analysis
> tool, I found some GCC code that was, basically:
>
> switch (v) {
> case 0:
> if (e) {
> do_something();
> } else {
> case 1:
> do_something_else();
>
On Tue, Jul 12, 2016 at 04:42:21PM +0200, Bernd Schmidt wrote:
> On 07/12/2016 04:19 PM, Marek Polacek wrote:
> >
> >>>@@ -30191,6 +30200,7 @@ rs6000_adjust_cost (rtx_insn *insn, rtx link,
> >>>rtx_insn *dep_insn, int cost)
> >>> && (INSN_CODE (dep_insn) >= 0)
> >>>
On 07/12/2016 04:19 PM, Marek Polacek wrote:
@@ -30191,6 +30200,7 @@ rs6000_adjust_cost (rtx_insn *insn, rtx link, rtx_insn
*dep_insn, int cost)
&& (INSN_CODE (dep_insn) >= 0)
&& (get_attr_type (dep_insn) == TYPE_MFFGPR))
return 2;
+ g
On Tue, Jul 12, 2016 at 09:10:54AM -0500, Segher Boessenkool wrote:
> Hi Marek,
>
> On Mon, Jul 11, 2016 at 09:59:39PM +0200, Marek Polacek wrote:
> > 2016-07-11 Marek Polacek
> >
> > PR c/7652
> > * config/rs6000/rs6000.c (rs6000_builtin_vectorized_libmass): Likewise.
>
> Likewise?
Hi Marek,
On Mon, Jul 11, 2016 at 09:59:39PM +0200, Marek Polacek wrote:
> 2016-07-11 Marek Polacek
>
> PR c/7652
> * config/rs6000/rs6000.c (rs6000_builtin_vectorized_libmass): Likewise.
Likewise? Like what? :-)
> --- gcc/gcc/config/rs6000/rs6000.c
> +++ gcc/gcc/config/rs6000/
I'm curious about this. In the process of developing a code analysis
tool, I found some GCC code that was, basically:
switch (v) {
case 0:
if (e) {
do_something();
} else {
case 1:
do_something_else();
}
}
Does this patch mean that the above got fixed? I mean, if you're
going to f
2016-07-11 Marek Polacek
PR c/7652
* config/rs6000/rs6000.c (rs6000_builtin_vectorized_libmass): Likewise.
(rs6000_legitimate_offset_address_p): Likewise.
(rs6000_emit_move): Likewise.
(altivec_expand_ld_builtin): Likewise.
(altivec_expand_st_buil
12 matches
Mail list logo
