Re: [PATCH v5 3/5] p1689r5: initial support
On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote:
> I notice that the actual flags are all -fdep-*, though some of them are
> -fdeps-* here, and the internal variables all seem to be fdeps_*. I
> lean toward harmonizing on "deps", I think.
Done.
> I don't love the three separate options, but I suppose it's fine. I'd
> prefer "target" instead of "output".
Done.
> It should be possible to omit both -file and -target and get reasonable
> defaults, like the ones for -MD/-MQ in gcc.cc:cpp_unique_options.
`file` can be omitted (the `output_stream` will be used then). I *think*
I see that adding:
%{fdeps_file:-fdeps-file=%{!o:%b.ddi}%{o*:%.ddi%*}}
would at least do for `-fdeps-file` defaults? I don't know if there's a
reasonable default for `-fdeps-target=` though given that this command
line has no information about the object file that will be used (`-o` is
used for preprocessor output since we're leaning on `-E` here).
--Ben
Re: [PATCH v5 1/5] libcpp: reject codepoints above 0x10FFFF
On Mon, Feb 13, 2023 at 10:53:17 -0500, Jason Merrill wrote: > On 1/25/23 13:06, Ben Boeckel wrote: > > Unicode does not support such values because they are unrepresentable in > > UTF-16. > > > > libcpp/ > > > > * charset.cc: Reject encodings of codepoints above 0x10. > > UTF-16 does not support such codepoints and therefore all > > Unicode rejects such values. > > It seems that this causes a bunch of testsuite failures from tests that > expect this limit to be checked elsewhere with a different diagnostic, > so I think the easiest thing is to fold this into _cpp_valid_utf8_str > instead, i.e.: Since then, `cpp_valid_utf8_p` has appeared and takes care of the over-long encodings. The new patchset just checks for codepoints beyond 0x10 and rejects them in this function (and the test suite matches `master` results for me then). --Ben
Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies
On Mon, Feb 13, 2023 at 13:33:50 -0500, Jason Merrill wrote: > Both this and the mapper dependency patch seem to cause most of the > modules testcases to crash; please remember to run the regression tests > (https://gcc.gnu.org/contribute.html#testing) Fixed for v6. `cpp_get_deps` can return `NULL` which `deps_add_dep` assumes to not be true; fixed by checking before calling. --Ben
Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
I plan to commit the following as simple.
The issue was a value was being modified on a short namelist read. After
tthe first read gives the correct EOF, a second read would give the
error but modify the variable.
diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index 82664dc5f98..36d025949c2 100644
--- a/libgfortran/io/unit.c
+++ b/libgfortran/io/unit.c
@@ -504,6 +504,7 @@ set_internal_unit (st_parameter_dt *dtp, gfc_unit
*iunit, int kind)
iunit->current_record=0;
iunit->read_bad = 0;
iunit->endfile = NO_ENDFILE;
+ iunit->last_char = 0;
/* Set flags for the internal unit. */
The revised test case attached. It has been regression tested OK.
Regards,
Jerry! { dg-do run }
! { dg-options "-std=f2003" }
! PR109662-a semi-colon after namelist name accepted on input.
program testnmlread
implicit none
character(16) :: line = '&stuff; n = 759/'
character(100)::message
integer :: n, i, ioresult
namelist/stuff/n
message = ""
ioresult = 0
n = 99
read(line,nml=stuff,iostat=ioresult)
if (ioresult == 0) STOP 13 ! Should error with the semi-colon in there.
! Intentional short input (-> EOF)
line = "&stuff"
! Problem manifests on two bad reads on same string.
do i = 1, 6
n = -1
ioresult = 0
read (line,nml=stuff,iostat=ioresult)
if (n /= -1) STOP 24
if (ioresult == 0) STOP 25
end do
end program testnmlread
