On 12/02/2016 09:07 AM, Bernd Schmidt wrote:
Arguments should be documented.
I really must get into the habit of adding FIXME when writing dev comments.
+ if (count >= (int) context->max_errors)
Looks like there are some unnecessary type mismatches leading to this
cast. Maybe declare max
On 12/02/2016 02:25 PM, Nathan Sidwell wrote:
+/* Check if we've met the maximum error limit. */
Arguments should be documented.
+void
+diagnostic_check_max_errors (diagnostic_context *context, bool flush)
+{
+ if (!context->max_errors)
+return;
I prefer to spell that as != 0 since i
Hi,
this respin of my notes patch from October
(https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00706.html) addresses the
fortran problems encountered.
I introduced a new function and call it from the fortran error machinery
at an appropriate point.
ok?
nathan
--
Nathan Sidwell
2016-12-02 N
On 10/14/16 12:17, David Malcolm wrote:
How about splitting out the bail-out code into a separate function:
diagnostic_handle_max_errors
Having discovered how fortran buffers errors, I think this approach is
necessary. I think I'm going to be in assignment-limbo for a little while though
On 10/15/16 05:31, Andreas Schwab wrote:
On Okt 13 2016, Nathan Sidwell wrote:
2016-10-13 Nathan Sidwell
* diagnostic.c (diagnostic_action_after_output): Remove max error
handling here
(diagnostic_report_diagnostic): ... do it here instead.
All tests that use
On Okt 13 2016, Nathan Sidwell wrote:
> 2016-10-13 Nathan Sidwell
>
> * diagnostic.c (diagnostic_action_after_output): Remove max error
> handling here
> (diagnostic_report_diagnostic): ... do it here instead.
All tests that use -fmax-errors now cause the compiler to cr
On Fri, 2016-10-14 at 15:50 -0400, Nathan Sidwell wrote:
> On 10/14/16 15:17, David Malcolm wrote:
>
> > "Limits the maximum number of error messages to @var{n}, at which
> > point
> > GCC bails out rather than attempting to continue processing the
> > source
> > code. If @var{n} is 0 (the defaul
On 10/14/16 15:17, David Malcolm wrote:
"Limits the maximum number of error messages to @var{n}, at which point
GCC bails out rather than attempting to continue processing the source
code. If @var{n} is 0 (the default), there is no limit on the number
of error messages produced. If @option{-Wf
On Thu, 2016-10-13 at 06:48 -0400, Nathan Sidwell wrote:
> On 10/11/16 16:07, David Malcolm wrote:
>
> > This logic is running when the next diagnostic is about to be
> > emitted.
> > But what if the user has selected -Wfatal-errors and there's a
> > single
> > error and no further diagnostics? C
On 10/11/16 16:07, David Malcolm wrote:
This logic is running when the next diagnostic is about to be emitted.
But what if the user has selected -Wfatal-errors and there's a single
error and no further diagnostics? Could this change the observable
behavior? (I'm trying to think of a case here,
On 10/11/16 16:07, David Malcolm wrote:
This logic is running when the next diagnostic is about to be emitted.
But what if the user has selected -Wfatal-errors and there's a single
error and no further diagnostics? Could this change the observable
behavior? (I'm trying to think of a case here,
On Tue, 2016-10-11 at 06:34 -0400, Nathan Sidwell wrote:
> Hi,
> Jonathan & I were chatting at the cauldron about how -fmax-errors
> kills any
> notes about the final error. That's because we bail out just after
> emitting the
> final error. This patch fixes the problem by bailing out just befo
Hi,
Jonathan & I were chatting at the cauldron about how -fmax-errors kills any
notes about the final error. That's because we bail out just after emitting the
final error. This patch fixes the problem by bailing out just before emitting
the error or warning after that.
Sure, we'll do sligh
13 matches
Mail list logo
