Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string
On Wed, Jan 25, 2023 at 4:09 PM Ben Boeckel via Gcc wrote: > > This simplifies the interface for other UTF-8 validity detections when a > simple "yes" or "no" answer is sufficient. > > libcpp/ > > * charset.cc: Add `_cpp_valid_utf8_str` which determines whether > a C string is valid UTF-8 or not. > * internal.h: Add prototype for `_cpp_valid_utf8_str`. > > Signed-off-by: Ben Boeckel [going through patches in patchwork] What's the status of this patch; did this ever get committed? I see that Jason preapproved this via his review of "[PATCH v3 2/3] libcpp: add a function to determine UTF-8 validity of a C string" Thanks Dave
Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string
On Mon, 2023-10-23 at 11:24 -0400, Jason Merrill wrote: > On 10/23/23 11:16, David Malcolm wrote: > > On Wed, Jan 25, 2023 at 4:09 PM Ben Boeckel via Gcc > > wrote: > > > > > > This simplifies the interface for other UTF-8 validity detections > > > when a > > > simple "yes" or "no" answer is sufficient. > > > > > > libcpp/ > > > > > > * charset.cc: Add `_cpp_valid_utf8_str` which determines > > > whether > > > a C string is valid UTF-8 or not. > > > * internal.h: Add prototype for `_cpp_valid_utf8_str`. > > > > > > Signed-off-by: Ben Boeckel > > > > [going through patches in patchwork] > > > > What's the status of this patch; did this ever get committed? > > It was superseded. Thanks; closed out in patchwork. Dave
Re: GCC GSoC 2024: Call for project ideas and mentors
On Mon, 2024-01-15 at 18:48 +0100, Martin Jambor wrote: > Hello, > > another year has passed, Google has announced there will be again > Google > Summer of Code (GsoC) in 2024 and the deadline for organizations to > apply is already approaching (February 6th). I'd like to volunteer > to > be the main org-admin for GCC again but let me know if you think I > shouldn't or that someone else should or if you want to do it > instead. > Otherwise I'll assume that I will and I hope that I can continue to > rely > on David Edelsohn and Thomas Schwinge to back me up and help me with > some decision making along the way as my co-org-admins. Hi Martin, thanks for stepping up, and thanks to you, David and Thomas for your work on this in past years. > > The most important bit: > > > I would like to ask all (moderately) seasoned GCC contributors to > consider mentoring a contributor this year and ideally also come up > with > a project that they would like to lead. I'm collecting proposal on > our > wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add > yours > to the top list there. Or, if you are unsure, post your offer and > project idea as a reply here to the mailing list. I hope to mentor again this year; I've refreshed the analyzer ideas on that page. [...snip...] Dave
Re: [Patch] Fortran: Dead-function removal in error.cc (shrinking by 40%)
On Fri, 2024-10-11 at 15:34 +0100, Paul Richard Thomas wrote: > Hi Tobias, > > Good catch! It looks 'obvious' to me too :-) > > Regards > > Paul > > > On Fri, 11 Oct 2024 at 14:08, Tobias Burnus > wrote: > > > I found always error.cc rather confusing but I just realized that > > we can reduce number of lines in that file by 40% - and remove a > > lot of > > (apparent) complexity. > > > > The removed code is from the old days, when gfortran handled a lot > > of > > diagnostic itself, also because it wanted to show lines with > > carets, > > while the C/C++ diagnostic did not support this. > > > > Well, that changed and gfortran mostly converted to the common > > diagnostic > > code, but somehow the old code remained - without actually being > > used. > > > > Thus, this patch simply removes it. > > > > > > I regarding the change as trivial and obvious and to intent to > > commit > > it as obvious. Nonetheless, any comments, suggestions, review > > remarks? > > > > > > Tobias > > > > > > PS: I also wanted to reduce code duplication, but an assert that > > was > > previously > > only in one code path triggered, showing at least one case where > > 'locus' is > > broken. Something to fix first before sending in that part ... > > > > There are also some other changes in the pipeline: > > * I want to move support range-based locations, which is also a > > good > > opportunity to fix some misplaced '1' (e.g. which point at white > > space > > instead of the actual declaration or ...). > > > > * David wants to improve json/sarif output, including stderr + > > sarif/json > > output at the same time, but that has issues with > > delayed/suppressed/buffered > > diagnostic in gfortran (because of the try & error parsing* in > > Fortran) > > → https://gcc.gnu.org/PR116613 for the former and > > https://gcc.gnu.org/105916 > > for the buffering issue. Thanks for the patch; I was planning to take a look at the SARIF buffering issue later today/Monday from the gcc/diagnostic.cc/h side (perhaps introducing an idea of "pending diagnostics" there), so any simplifications on the fortran side are most welcome! My knowledge of Fortran is almost zero, sorry. Dave
[PATCH] Implement Fortran diagnostic buffering for non-textual formats [PR105916]
ass diagnostic_xhtml_format_buffer.
(diagnostic_xhtml_format_buffer::dump): New.
(diagnostic_xhtml_format_buffer::empty_p): New.
(diagnostic_xhtml_format_buffer::move_to): New.
(diagnostic_xhtml_format_buffer::clear): New.
(diagnostic_xhtml_format_buffer::flush): New.
(xhtml_builder::on_report_diagnostic): Add "buffer" param, and use
it.
(xhtml_output_format::dump): Fix typo.
(xhtml_output_format::make_per_format_buffer): New.
(xhtml_output_format::set_buffer): New.
(xhtml_output_format::on_report_diagnostic): Fix whitespace. Pass
m_buffer to xhtml_builder::on_report_diagnostic.
(xhtml_output_format::xhtml_output_format): Initialize m_buffer.
(xhtml_output_format::m_buffer): New field.
* gfortran.dg/diagnostic-format-json-pr105916.F90: New test.
* gfortran.dg/diagnostic-format-sarif-1.F90: New test.
* gfortran.dg/diagnostic-format-sarif-1.py: New support script.
* gfortran.dg/diagnostic-format-sarif-pr105916.f90: New test.
Signed-off-by: David Malcolm
---
gcc/diagnostic-buffer.h | 109 +
gcc/diagnostic-format-json.cc | 123 --
gcc/diagnostic-format-sarif.cc| 225 +-
gcc/diagnostic-format-text.cc | 116 +
gcc/diagnostic-format-text.h | 7 +
gcc/diagnostic-format.h | 12 +
gcc/diagnostic.cc | 224 ++---
gcc/diagnostic.h | 66 +++--
gcc/fortran/error.cc | 149 +++-
gcc/fortran/gfortran.h| 7 +-
.../plugin/diagnostic_plugin_xhtml_format.c | 124 +-
.../diagnostic-format-json-pr105916.F90 | 14 ++
.../gfortran.dg/diagnostic-format-sarif-1.F90 | 18 ++
.../gfortran.dg/diagnostic-format-sarif-1.py | 53 +
.../diagnostic-format-sarif-pr105916.f90 | 13 +
15 files changed, 1069 insertions(+), 191 deletions(-)
create mode 100644 gcc/diagnostic-buffer.h
create mode 100644
gcc/testsuite/gfortran.dg/diagnostic-format-json-pr105916.F90
create mode 100644 gcc/testsuite/gfortran.dg/diagnostic-format-sarif-1.F90
create mode 100644 gcc/testsuite/gfortran.dg/diagnostic-format-sarif-1.py
create mode 100644
gcc/testsuite/gfortran.dg/diagnostic-format-sarif-pr105916.f90
diff --git a/gcc/diagnostic-buffer.h b/gcc/diagnostic-buffer.h
new file mode 100644
index ..07acd0449209
--- /dev/null
+++ b/gcc/diagnostic-buffer.h
@@ -0,0 +1,109 @@
+/* Support for buffering diagnostics before flushing them to output format.
+ Copyright (C) 2024 Free Software Foundation, Inc.
+ Contributed by David Malcolm .
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+<http://www.gnu.org/licenses/>. */
+
+#ifndef GCC_DIAGNOSTIC_BUFFER_H
+#define GCC_DIAGNOSTIC_BUFFER_H
+
+#include "diagnostic.h"
+
+class diagnostic_per_format_buffer;
+class diagnostic_output_format;
+ class diagnostic_text_output_format;
+
+/* Class representing a buffer of zero or more diagnostics that
+ have been reported to a diagnostic_context, but which haven't
+ yet been flushed.
+
+ A diagnostic_buffer can be:
+
+ * flushed to the diagnostic_context, which issues
+ the diagnostics within the buffer to the output format
+ and checks for limits such as -fmax-errors=, or
+
+ * moved to another diagnostic_buffer, which moves the diagnostics
+ within the first buffer to the other buffer, appending them after any
+ existing diagnostics within the destination buffer, emptying the
+ source buffer, or
+
+ * cleared, which discards any diagnostics within the buffer
+ without issuing them to the output format.
+
+ Since a buffer needs to contain output-format-specific data,
+ it's not possible to change the output format of the
+ diagnostic_context once any buffers are non-empty.
+
+ To simplify implementing output formats, it's not possible
+ to change buffering on a diagnostic_context whilst within a
+ diagnostic group. */
+
+class diagnostic_buffer
+{
+ public:
+ friend class diagnostic_context;
+
+ diagnostic_buffer (diagnostic_context &ctxt);
+ ~diagnostic_buffer ();
+
+ void dump (FILE *out, int indent) const;
+ void DEBUG_FUNCTION dump () const { dump (stderr, 0); }
+
+ int diagnostic_count (diagnost
[pushed: r15-4969] fortran: dynamically allocate error_buffer [PR117442]
PR fortran/117442 reports a crash on exit of f951 when configured
with --enable-gather-detailed-mem-stats.
The crash happens if any diagnostics were ever buffered into
error_buffer. The root cause is that error_buffer is statically
allocated and thus has a non-trivial destructor called at exit.
If error_buffer's diagnostic_buffer ever buffered anything, then
a diagnostic_per_format_buffer will have been created for the
buffer per-output-sink, and the destructors for these call
into the mem-stats subsystem, which has already beeen cleaned up.
The simplest fix is to allocate error_buffer on the heap, rather
that statically, which fixes the crash.
There's a comment about error_buffer:
/* pp_error_buffer is statically allocated. This simplifies memory
management when using gfc_push/pop_error. */
added by Manu in r6-1748-g5862c189c2c3c2 while fixing PR fortran/66528.
The comment appears to be out of date. I've tested maxerrors.f90 under
valgrind, and it's clean with the patch.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-4969-g8c4184682d1cdf.
gcc/fortran/ChangeLog:
PR fortran/117442
* error.cc (error_buffer): Convert to a pointer so it can be
heap-allocated.
(gfc_error_now): Update for error_buffer being heap-allocated.
(gfc_clear_error): Likewise.
(gfc_error_flag_test): Likewise.
(gfc_error_check): Likewise.
(gfc_push_error): Likewise.
(gfc_pop_error): Likewise.
(gfc_diagnostics_init): Allocate error_buffer on the heap, rather
than statically.
(gfc_diagnostics_finish): Delete error_buffer.
Signed-off-by: David Malcolm
---
gcc/fortran/error.cc | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc
index 050a8f286efd..1445ebcbecd8 100644
--- a/gcc/fortran/error.cc
+++ b/gcc/fortran/error.cc
@@ -43,7 +43,7 @@ static bool warnings_not_errors = false;
/* True if the error/warnings should be buffered. */
static bool buffered_p;
-static gfc_error_buffer error_buffer;
+static gfc_error_buffer *error_buffer;
static diagnostic_buffer *pp_error_buffer, *pp_warning_buffer;
gfc_error_buffer::gfc_error_buffer ()
@@ -707,7 +707,7 @@ gfc_error_now (const char *gmsgid, ...)
diagnostic_info diagnostic;
rich_location rich_loc (line_table, UNKNOWN_LOCATION);
- error_buffer.flag = true;
+ error_buffer->flag = true;
va_start (argp, gmsgid);
diagnostic_set_info (&diagnostic, gmsgid, &argp, &rich_loc, DK_ERROR);
@@ -842,7 +842,7 @@ gfc_internal_error (const char *gmsgid, ...)
void
gfc_clear_error (void)
{
- error_buffer.flag = false;
+ error_buffer->flag = false;
warnings_not_errors = false;
gfc_clear_diagnostic_buffer (pp_error_buffer);
}
@@ -853,7 +853,7 @@ gfc_clear_error (void)
bool
gfc_error_flag_test (void)
{
- return (error_buffer.flag
+ return (error_buffer->flag
|| !pp_error_buffer->empty_p ());
}
@@ -864,10 +864,10 @@ gfc_error_flag_test (void)
bool
gfc_error_check (void)
{
- if (error_buffer.flag
+ if (error_buffer->flag
|| ! pp_error_buffer->empty_p ())
{
- error_buffer.flag = false;
+ error_buffer->flag = false;
global_dc->flush_diagnostic_buffer (*pp_error_buffer);
return true;
}
@@ -903,7 +903,7 @@ gfc_move_error_buffer_from_to (gfc_error_buffer *
buffer_from,
void
gfc_push_error (gfc_error_buffer *err)
{
- gfc_move_error_buffer_from_to (&error_buffer, err);
+ gfc_move_error_buffer_from_to (error_buffer, err);
}
@@ -912,7 +912,7 @@ gfc_push_error (gfc_error_buffer *err)
void
gfc_pop_error (gfc_error_buffer *err)
{
- gfc_move_error_buffer_from_to (err, &error_buffer);
+ gfc_move_error_buffer_from_to (err, error_buffer);
}
@@ -955,9 +955,8 @@ gfc_diagnostics_init (void)
global_dc->m_source_printing.caret_chars[0] = '1';
global_dc->m_source_printing.caret_chars[1] = '2';
pp_warning_buffer = new diagnostic_buffer (*global_dc);
- /* pp_error_buffer is statically allocated. This simplifies memory
- management when using gfc_push/pop_error. */
- pp_error_buffer = &(error_buffer.buffer);
+ error_buffer = new gfc_error_buffer ();
+ pp_error_buffer = &(error_buffer->buffer);
}
void
@@ -970,4 +969,7 @@ gfc_diagnostics_finish (void)
diagnostic_text_finalizer (global_dc) = gfc_diagnostic_text_finalizer;
global_dc->m_source_printing.caret_chars[0] = '^';
global_dc->m_source_printing.caret_chars[1] = '^';
+ delete error_buffer;
+ error_buffer = nullptr;
+ pp_error_buffer = nullptr;
}
--
2.26.3
Re: [PATCH] Implement Fortran diagnostic buffering for non-textual formats [PR105916]
On Wed, 2024-10-23 at 11:03 +0200, Tobias Burnus wrote: > David Malcolm wrote: > > In order to handle various awkward parsing issues, the Fortran > > frontend > > implements buffering of diagnostics, so that diagnostics reported > > to > > global_dc can be either: > > (a) immediately issued, or > > (b) speculatively reported to global_dc, and stored in a buffer, to > > either be issued later or discarded. > ... > > This patch moves responsibility for such buffering of diagnostics > > from > > fortran's error.cc to the diagnostic subsystem. > ... > > Does this look OK from the Fortran side? The Fortran changes are > > essentially all specific to error.cc, converting from manipulations > > of > > output_buffer to those of diagnostic_buffer. > > Yes, LGTM. (I only looked at the Fortran changes.) Thanks; I've gone ahead and pushed it to trunk (as r15-4575- gf565063a0602ad). > > Thanks, > > Tobias > > PS: I guess we eventually want to have in the testsuite some Fortran > SARIF tests, which for actual Fortran errors/warnings and not "just" > for > #error. The fortran testsuite currently has test coverage for the following case: * json #error and #warning (unbuffered diagnostics) * sarif #error (unbuffered diagnostic) * json and sarif coverage for PR105916 (buffered diagnostics that are discarded) but I realize we don't have coverage there for the case where buffered diagnostics are flushed/emitted. I can add this, but my Fortran skills are non-existent, so is there a trivial case that would hit this path? Ideas for test coverage would be most welcome. There is some test coverage for this case in the selftests in diagnostic.cc, but not yet a DejaGnu end-to-end test of it in terms of invoking gfortran and checking the .sarif output. Note that I've deprecated the "json" output format, so new testcases for machine-readable diagnostics should be for sarif. > > > I'm hoping to get this in as I have followup work to support having > > e.g. > > both text *and* SARIF at once (PR other/116613), and fixing this is > > a > > prerequisite for that work. Thanks again for the review; I'll get back to working on PR other/116613. I'll try to add a Fortran test case for that, e.g. for outputting both sarif 2.1 *and* sarif 2.2 from the same invocation. Dave > > > > Thanks > > Dave > > > > gcc/ChangeLog: > > PR fortran/105916 > > * diagnostic-buffer.h: New file. > ... > > gcc/fortran/ChangeLog: > > PR fortran/105916 > > * error.cc (pp_error_buffer, pp_warning_buffer): Convert > > from > > output_buffer * to diagnostic_buffer *. > > (warningcount_buffered, werrorcount_buffered): Eliminate. > > (gfc_error_buffer::gfc_error_buffer): Move constructor > > definition > > here, and initialize "buffer" using *global_dc. > > (gfc_output_buffer_empty_p): Delete in favor of > > diagnostic_buffer::empty_p. > > (gfc_clear_pp_buffer): Replace with... > > (gfc_clear_diagnostic_buffer): ...this, moving > > implementation > > details to diagnostic_context::clear_diagnostic_buffer. > > (gfc_warning): Replace buffering implementation with calls > > to global_dc->get_diagnostic_buffer and > > global_dc->set_diagnostic_buffer. > > (gfc_clear_warning): Update for renaming of > > gfc_clear_pp_buffer > > and elimination of warningcount_buffered and > > werrorcount_buffered. > > (gfc_warning_check): Replace buffering implementation with > > calls > > to pp_warning_buffer->empty_p and > > global_dc->flush_diagnostic_buffer. > > (gfc_error_opt): Replace buffering implementation with > > calls to > > global_dc->get_diagnostic_buffer and > > set_diagnostic_buffer. > > (gfc_clear_error): Update for renaming of > > gfc_clear_pp_buffer. > > (gfc_error_flag_test): Replace call to > > gfc_output_buffer_empty_p > > with call to diagnostic_buffer::empty_p. > > (gfc_error_check): Replace buffering implementation with > > calls > > to pp_error_buffer->empty_p and global_dc- > > >flush_diagnostic_buffer. > > (gfc_move_error_buffer_from_to): Replace buffering > > implementation > > with usage of diagnostic_buffer. > > (gfc_free_error): Update for renaming of > > gfc_clear_pp_buffer. > > (gfc_diagnostics_init): Use "new" directly when creating > > pp_warning_buffer. Remove setting of m_flush_p on the two > > buffers, as this is handle
Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not
On Mon, 2025-02-10 at 09:29 +, Jonathan Wakely via Gcc wrote: > On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc, > wrote: > > > Hello world, > > > > looking at a few Fortran bug reports, I found some cases where > > it was not clear if the program in question was standard-conforming > > or not. I would propose to add a keyword for that, tentatively > > called "interp". > > > > Comments? Suggestions for a different name? > > > Anything except "interp"? > > That looks like it could be something to do with interpolation rather > than > interpretation. > > There's no reason to use a cryptic abbreviation. FWIW my first thought for "interp" was that we gaining an interpreter (there are some in the libgccjit test suite). Dave
Re: GCC GSoC 2022: Call for project ideas and mentors
On Thu, 2022-01-06 at 17:20 +0100, Martin Jambor wrote: > Hello, > > another year is upon us and Google has announced there will be again > Google Summer of Code 2022 (though AFAIK there is no specific timeline > yet). I'd like to volunteer to be the main Org Admin for GCC again so > let me know if you think I shouldn't or that someone else should, but > otherwise I'll assume that I will. > > There will be a few important changes to the GSoC this year. The most > important for us is that there will be two project sizes: medium-sized > projects which are expected to take about 175 hours to complete and > large projects expected to take approximately 350 hours (the size from > 2020 and earlier). I expect that most of our projects will be large > but > I think we can offer one or two medium-sized ideas too. > > Google will also increase timing flexibility, so the projects can run > for longer (up to 22 weeks) allowing mentors to go on vacation and > students to pause and focus on exams. Talking about students, Google > is > going to open the program to all adults, so from now on, the > participants working on the projects will be called GSoC contributors. > > Slightly more information about these changes can be found at > https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html > I am sure we will learn more when the actual timeline is announced too. > > The most important bit: > > > Even before that happens, I would like to ask all (moderately) seasoned > GCC contributors to consider mentoring a student this year and ideally > also come up with a project that they would like to lead. I'm > collecting proposal on our wiki page > https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the > top list there. Or, if you are unsure, post your offer and project > idea > as a reply here to the mailing list. How did it get to be 2022 already? Thanks for organizing this. I'd like to (again) mentor a project relating to the GCC static analyzer: https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer I've updated the analyzer task ideas on: https://gcc.gnu.org/wiki/SummerOfCode but the ideas there are suggestions; if any prospective candidate has other good ideas for things worth working on within the analyzer, let me know. Alternatively, I'm also up for mentoring relating to diagnostics or libgccjit, if someone can think of an idea of suitable size and scope for a GSoC project. Dave > > === > == > > Eventually, each listed project idea should have a) a project > title/description, b) more detailed description of the project (2-5 > sentences), c) expected outcomes, d) skills required/preferred, e) > project size and difficulty and f) expected mentors. > > Project ideas that come without an offer to also mentor them are always > fun to discuss, by all means feel free to reply to this email with > yours > and I will attempt to find a mentor, but please be aware that we can > only use the suggestion it if we actually find one. > > Everybody in the GCC community is invited to go over > https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or > otherwise bad project suggestions and help improve viable ones. > > Finally, please continue helping (prospective) students figure stuff > out > about GCC like you always do. So far I think all of them enjoyed > working with us, even if many sometimes struggled with GCC's > complexity. > > I will update you as more details about GSoC 2022 become available. > > Thank you, let's hope we attract some new talent again this year. > > Martin >
Question about Fortran bounds and -Wanalyzer-use-of-uninitialized-value
Sorry in advance if this is a silly question; my knowledge of Fortran
is next to nothing, I'm afraid.
PR analyzer/107210 reports an ICE in -fanalyzer on this reproducer:
! { dg-additional-options "-O1" }
subroutine check_int (j)
INTEGER(4) :: i, ia(5), ib(5,4), ip, ipa(:)
target :: ib
POINTER :: ip, ipa
logical :: l(5)
l = (/ sizeof(i) == 4, sizeof(ia) == 20, sizeof(ib) == 80, &
sizeof(ip) == 4, sizeof(ipa) == 8 /) ! { dg-warning "use of
uninitialized value" }
if (any(.not.l)) STOP 4
end subroutine check_int
The fix for the ICE is trivial (a missing check that tree_fits_uhwi_p),
but after the fix, I see these warnings from the analyzer:
10 |sizeof(ip) == 4, sizeof(ipa) == 8 /)
| ^
Warning: use of uninitialized value ‘ipa.dim[0].ubound’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
‘check_int’: events 1-3
|
|4 | INTEGER(4) :: i, ia(5), ib(5,4), ip, ipa(:)
| | ^
| | |
| | (1) region created on
stack here
| | (2) capacity: 8 bytes
|..
| 10 |sizeof(ip) == 4, sizeof(ipa) == 8 /)
| | ~
| | |
| | (3) use of uninitialized
value ‘ipa.dim[0].ubound’ here
|
../../src/gcc/testsuite/gfortran.dg/analyzer/pr107210.f90:10:43:
10 |sizeof(ip) == 4, sizeof(ipa) == 8 /)
| ^
Warning: use of uninitialized value ‘ipa.dim[0].lbound’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
‘check_int’: events 1-3
|
|4 | INTEGER(4) :: i, ia(5), ib(5,4), ip, ipa(:)
| | ^
| | |
| | (1) region created on
stack here
| | (2) capacity: 8 bytes
|..
| 10 |sizeof(ip) == 4, sizeof(ipa) == 8 /)
| | ~
| | |
| | (3) use of uninitialized
value ‘ipa.dim[0].lbound’ here
|
The gimple in question is:
__attribute__((fn spec (". w ")))
void check_int (integer(kind=4) & restrict j)
{
integer(kind=8) ipa$dim$0$lbound;
integer(kind=8) ipa$dim$0$ubound;
logical(kind=4) A.1[5];
logical(kind=4) l[5];
integer(kind=8) _1;
logical(kind=4) _3;
logical(kind=4) _4;
integer(kind=8) _5;
logical(kind=4) _6;
integer(kind=8) S.5_7;
logical(kind=4) test.6_8;
integer(kind=8) S.7_9;
integer(kind=8) S.5_16;
integer(kind=8) S.7_18;
[local count: 178992760]:
MEM [(c_char * {ref-all})&A.1] = 0x1000100010001;
_1 = ipa$dim$0$ubound_2(D) - ipa$dim$0$lbound_12(D);
_3 = _1 == 1;
MEM[(logical(kind=4) *)&A.1 + 16B] = _3;
[...snip...]
where the analyzer is complaining about this gimple statement:
_1 = ipa$dim$0$ubound_2(D) - ipa$dim$0$lbound_12(D);
where both:
ipa$dim$0$ubound_2(D)
and:
ipa$dim$0$lbound_12(D)
are considered by it to be uninitialized.
Is the analyzer correct here, or is there an aspect of Fortan and/or
gimple that I'm missing?
Thanks
Dave
Re: [PATCH RESEND 0/1] RFC: P1689R5 support
On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote: > On 10/4/22 11:11, Ben Boeckel wrote: > > This patch adds initial support for ISO C++'s [P1689R5][], a format > > for > > describing C++ module requirements and provisions based on the > > source > > code. This is required because compiling C++ with modules is not > > embarrassingly parallel and need to be ordered to ensure that > > `import > > some_module;` can be satisfied in time by making sure that the TU > > with > > `export import some_module;` is compiled first. > > > > [P1689R5]: https://isocpp.org/files/papers/P1689R5.html > > > > I'd like feedback on the approach taken here with respect to the > > user-visible flags. I'll also note that header units are not > > supported > > at this time because the current `-E` behavior with respect to > > `import > > ;` is to search for an appropriate `.gcm` file which > > is not > > something such a "scan" can support. A new mode will likely need to > > be > > created (e.g., replacing `-E` with `-fc++-module-scanning` or > > something) > > where headers are looked up "normally" and processed only as much > > as > > scanning requires. > > > > Testing is currently happening in CMake's CI using a prior revision > > of > > this patch (the differences are basically the changelog, some > > style, and > > `trtbd` instead of `p1689r5` as the format name). > > > > For testing within GCC, I'll work on the following: > > > > - scanning non-module source > > - scanning module-importing source (`import X;`) > > - scanning module-exporting source (`export module X;`) > > - scanning module implementation unit (`module X;`) > > - flag combinations? > > > > Are there existing tools for handling JSON output for testing > > purposes? > > David Malcolm would probably know best about JSON wrangling. Unfortunately our JSON output doesn't make any guarantees about the ordering of keys within an object, so the precise textual output changes from run to run. I've coped with that in my test cases by limiting myself to simple regexes of fragments of the JSON output. Martin Liska [CCed] went much further in 4e275dccfc2467b3fe39012a3dd2a80bac257dd0 by adding a run-gcov-pytest DejaGnu directive, allowing for test cases for gcov to be written in Python, which can thus test much more interesting assertions about the generated JSON. Dave > > > Basically, something that I can add to the test suite that doesn't > > care > > about whitespace, but checks the structure (with sensible > > replacements > > for absolute paths where relevant)? > > Various tests in g++.dg/debug/dwarf2 handle that sort of thing with > regexps. > > > For the record, Clang has patches with similar flags and behavior > > by > > Chuanqi Xu here: > > > > https://reviews.llvm.org/D134269 > > > > with the same flags (though using my old `trtbd` spelling for the > > format name). > > > > Thanks, > > > > --Ben > > > > Ben Boeckel (1): > > p1689r5: initial support > > > > gcc/ChangeLog | 9 ++ > > gcc/c-family/ChangeLog | 6 + > > gcc/c-family/c-opts.cc | 40 ++- > > gcc/c-family/c.opt | 12 ++ > > gcc/cp/ChangeLog | 5 + > > gcc/cp/module.cc | 3 +- > > gcc/doc/invoke.texi | 15 +++ > > gcc/fortran/ChangeLog | 5 + > > gcc/fortran/cpp.cc | 4 +- > > gcc/genmatch.cc | 2 +- > > gcc/input.cc | 4 +- > > libcpp/ChangeLog | 11 ++ > > libcpp/include/cpplib.h | 12 +- > > libcpp/include/mkdeps.h | 17 ++- > > libcpp/init.cc | 14 ++- > > libcpp/mkdeps.cc | 235 > > ++-- > > 16 files changed, 368 insertions(+), 26 deletions(-) > > > > > > base-commit: d812e8cb2a920fd75768e16ca8ded59ad93c172f >
Re: [PATCH v2 1/3] libcpp: reject codepoints above 0x10FFFF
On Thu, 2022-10-27 at 19:16 -0400, Ben Boeckel wrote: > Unicode does not support such values because they are unrepresentable > in > UTF-16. Wikipedia pointed me to RFC 3629, which was when UTF-8 introduced this restriction, whereas libcpp was implementing the higher upper limit from the earlier, superceded RFC 2279. The patch looks good to me, assuming it bootstraps and passes usual regression testing, but... > > Signed-off-by: Ben Boeckel > --- > libcpp/ChangeLog | 6 ++ > libcpp/charset.cc | 4 ++-- > 2 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog > index 18d5bcceaf0..4d707277531 100644 > --- a/libcpp/ChangeLog > +++ b/libcpp/ChangeLog > @@ -1,3 +1,9 @@ > +2022-10-27 Ben Boeckel > + > + * include/charset.cc: Reject encodings of codepoints above > 0x10. > + UTF-16 does not support such codepoints and therefore all > Unicode > + rejects such values. > + > 2022-10-19 Lewis Hyatt ...AIUI we now put ChangeLog entries in the blurb part of the patch, so that server-side git scripts add them to the actual ChangeLog file. Does the patch pass: ./contrib/gcc-changelog/git_check_commit.py ? Thanks Dave > > * include/cpplib.h (struct cpp_string): Use new > "string_length" GTY. > diff --git a/libcpp/charset.cc b/libcpp/charset.cc > index 12a398e7527..e9da6674b5f 100644 > --- a/libcpp/charset.cc > +++ b/libcpp/charset.cc > @@ -216,7 +216,7 @@ one_utf8_to_cppchar (const uchar **inbufp, size_t > *inbytesleftp, > if (c <= 0x3FF && nbytes > 5) return EILSEQ; > > /* Make sure the character is valid. */ > - if (c > 0x7FFF || (c >= 0xD800 && c <= 0xDFFF)) return EILSEQ; > + if (c > 0x10 || (c >= 0xD800 && c <= 0xDFFF)) return EILSEQ; > > *cp = c; > *inbufp = inbuf; > @@ -320,7 +320,7 @@ one_utf32_to_utf8 (iconv_t bigend, const uchar > **inbufp, size_t *inbytesleftp, > s += inbuf[bigend ? 2 : 1] << 8; > s += inbuf[bigend ? 3 : 0]; > > - if (s >= 0x7FFF || (s >= 0xD800 && s <= 0xDFFF)) > + if (s > 0x10 || (s >= 0xD800 && s <= 0xDFFF)) > return EILSEQ; > > rval = one_cppchar_to_utf8 (s, outbufp, outbytesleftp);
Re: [PATCH v2 2/3] libcpp: add a function to determine UTF-8 validity of a C string
On Thu, 2022-10-27 at 19:16 -0400, Ben Boeckel wrote: > This simplifies the interface for other UTF-8 validity detections > when a > simple "yes" or "no" answer is sufficient. > > Signed-off-by: Ben Boeckel > --- > libcpp/ChangeLog | 6 ++ > libcpp/charset.cc | 18 ++ > libcpp/internal.h | 2 ++ > 3 files changed, 26 insertions(+) > > diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog > index 4d707277531..4e2c7900ae2 100644 > --- a/libcpp/ChangeLog > +++ b/libcpp/ChangeLog > @@ -1,3 +1,9 @@ > +2022-10-27 Ben Boeckel > + > + * include/charset.cc: Add `_cpp_valid_utf8_str` which > determines > + whether a C string is valid UTF-8 or not. > + * include/internal.h: Add prototype for > `_cpp_valid_utf8_str`. > + > 2022-10-27 Ben Boeckel > > * include/charset.cc: Reject encodings of codepoints above > 0x10. The patch looks good to me, with the same potential caveat that you might need to move the ChangeLog entry from the patch "body" to the leading blurb, to satisfy: ./contrib/gcc-changelog/git_check_commit.py Thanks Dave
Re: [pushed] wwwdocs: readings: Remove Herman D. Knoble's Fortran Resources
On Wed, 2023-02-01 at 10:56 +0100, Gerald Pfeifer wrote: > The original page is gone, and search engines did not reveal a new > location. > > If any of you has a new location, feel free to add that (or let me > know and I'll take care). FWIW the most recent version in archive.org is here: https://web.archive.org/web/20220624224837/http://www.personal.psu.edu/faculty/h/d/hdk/fortran.html Dave > > Gerald > --- > htdocs/readings.html | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/htdocs/readings.html b/htdocs/readings.html > index 0a978e8f..6e640af1 100644 > --- a/htdocs/readings.html > +++ b/htdocs/readings.html > @@ -463,11 +463,6 @@ names. > Michel Olagnon's Fortran 90 List contains a "Tests and > Benchmarks" section mentioning commercial testsuites. > > - > - href="http://www.personal.psu.edu/faculty/h/d/hdk/fortran.html";>Herma > n > - D. Knoble's Fortran Resources contain some sections on > compiler > - validation and benchmarking. > - > > Complying with Fortran 90, How does the current crop > of > Fortran 90 compilers measure up to the standard?, > Steven
