Re: Test with an lto-build of libgfortran.
On Wed, Sep 27, 2023 at 11:28 PM Richard Biener via Fortran wrote: > > On Wed, Sep 27, 2023 at 11:48 PM Jeff Law via Fortran > wrote: > > > > > > > > On 9/27/23 12:21, Toon Moene wrote: > > > > > > > > The lto-ing of libgfortran did succeed, because I did get a new warning: > > > > > > gfortran -O3 -flto -flto-partition=none -static -o xlintstrfz zchkrfp.o > > > zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o > > > zlaipd.o zlarhs.o zsbmv.o zget04.o zpot01.o zpot03.o zpot02.o chkxer.o > > > xerbla.o alaerh.o aladhd.o alahd.o alasvm.o ../../libtmglib.a > > > ../../liblapack.a ../../librefblas.a > > > In function 'xtoa_big', > > > inlined from 'write_z' at > > > /home/toon/compilers/gcc/libgfortran/io/write.c:1296:11, > > > inlined from 'formatted_transfer_scalar_write' at > > > /home/toon/compilers/gcc/libgfortran/io/transfer.c:2136:4: > > > /home/toon/compilers/gcc/libgfortran/io/write.c:1222:6: warning: writing > > > 1 byte into a region of size 0 [-Wstringop-overflow=] > > > 1222 | *q = '\0'; > > >| ^ > > > /home/toon/compilers/gcc/libgfortran/io/write.c: In function > > > 'formatted_transfer_scalar_write': > > > /home/toon/compilers/gcc/libgfortran/io/write.c:1291:8: note: at offset > > > [34, 4294967294] into destination object 'itoa_buf' of size 33 > > > 1291 | char itoa_buf[GFC_XTOA_BUF_SIZE]; > > >|^ > > > > > > which was (of course) not given with a non-lto libgfortran. > > Yea. This certainly can happen with LTO. These warnings would > > definitely be something worth investigating. > > > > Essentially the inlining enabled by LTO can expose a different set of > > diagnostics. > > This particular place in libgfortran has > > /* write_z, which calls xtoa_big, is called from transfer.c, > formatted_transfer_scalar_write. There it is passed the kind as > argument, which means a maximum of 16. The buffer is large > enough, but the compiler does not know that, so shut up the > warning here. */ > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wstringop-overflow" > *q = '\0'; > #pragma GCC diagnostic pop > > so obviously the #pragma doesn't survive through LTO. Somehow I think > this is a known bug, but maybe I misremember (I think we are not streaming > any of the ad-hoc location parts). Yes it is a known bug. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 . Thanks, Andrew > > Richard. > > > > > Jeff
Re: gfortran: error: unrecognized argument in option '-mcmodel=medium'
On Tue, Sep 26, 2023 at 11:39 PM Richard Biener via Fortran wrote: > > On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023) > wrote: > > > > Dear GCC Team, > > > > I'm running Ubuntu 22 on my Mac virtually and my gfortran version is > > 11.4.0. When I try to install a certain software package, I encounter the > > following error: > > > > gfortran: error: unrecognized argument in option '-mcmodel=medium' > > gfortran: note: valid arguments to '-mcmodel=' are: large small tiny > > > > Is this due to attempting to run gfortran on arm64 architecture? Could you > > please let me know how I could resolve the issue? > > You have to turn to Ubuntu here, -mcmodel=medium is certainly > supported in GCC 11, maybe Ubuntu patches out > the support? Well -mcmodel=medium is the x86_64 specific option while they are trying to run on aarch64 which has a different set options. > > > > > Thank you > > > > Warm regards, > > Vishakha > > > > This email, its contents and any attachments are intended solely for the > > addressee and may contain confidential information. In certain > > circumstances, it may also be subject to legal privilege. Any unauthorised > > use, disclosure, or copying is not permitted. If you have received this > > email in error, please notify us and immediately and permanently delete it. > > Any views or opinions expressed in personal emails are solely those of the > > author and do not necessarily represent those of Royal Holloway, University > > of London. It is your responsibility to ensure that this email and any > > attachments are virus free.
[PATCH] libfortran: Fix build for targets that don't have 10byte or 16 byte floating point
So the problem here is EXPAND_INTER_MACRO_16 expands to nothing if 16 byte FP does not exist but we still add a comma after it and that causes a build failure. The same is true for EXPAND_INTER_MACRO_10 too. Committed as obvious after a bootstrap and test on x86_64-linux-gnu and aarch64-linux-gnu. libgfortran/ChangeLog: PR libfortran/110759 * ieee/ieee_arithmetic.F90 (COMP_INTERFACE): Remove the comma after EXPAND_INTER_MACRO_16 and EXPAND_INTER_MACRO_10. (EXPAND_INTER_MACRO_16): Add comma here if 16 byte fp exist. (EXPAND_INTER_MACRO_10): Likewise. --- libgfortran/ieee/ieee_arithmetic.F90 | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libgfortran/ieee/ieee_arithmetic.F90 b/libgfortran/ieee/ieee_arithmetic.F90 index aa897abae39..debe40449f4 100644 --- a/libgfortran/ieee/ieee_arithmetic.F90 +++ b/libgfortran/ieee/ieee_arithmetic.F90 @@ -535,13 +535,13 @@ UNORDERED_MACRO(4,4) end interface #ifdef HAVE_GFC_REAL_16 -# define EXPAND_INTER_MACRO_16(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_16 +# define EXPAND_INTER_MACRO_16(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_16 , #else # define EXPAND_INTER_MACRO_16(TYPE,OP) #endif #ifdef HAVE_GFC_REAL_10 -# define EXPAND_INTER_MACRO_10(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_10 +# define EXPAND_INTER_MACRO_10(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_10 , #else # define EXPAND_INTER_MACRO_10(TYPE,OP) #endif @@ -549,8 +549,8 @@ UNORDERED_MACRO(4,4) #define COMP_INTERFACE(TYPE,OP) \ interface IEEE_/**/TYPE/**/_/**/OP ; \ procedure \ - EXPAND_INTER_MACRO_16(TYPE,OP) , \ - EXPAND_INTER_MACRO_10(TYPE,OP) , \ + EXPAND_INTER_MACRO_16(TYPE,OP) \ + EXPAND_INTER_MACRO_10(TYPE,OP) \ _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_8 , \ _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_4 ; \ end interface ; \ -- 2.31.1
Re: Building Legacy Code and Intel Libraries
On Wed, May 17, 2023 at 1:15 PM Larry Lemons via Fortran wrote: > > Hello, > > I inherited a project where the customer wants us to re-build this ForTran > application with a more modern compiler. I did some research and found that > the GCC compiler probably has the most up to date compiler available, so we > decided to us 13.1.0 version of GCC. It has been about 40 years since I last > used Fortran, and very little at that time, and I didn't realize that there > were different libraries available based upon which compiler that was used at > the time. Apparently, from what I can tell from the research that I've done, > is it was last built using a MicroSoft compiler because of two of the > libraries that are used. From what I've read, Compaq had the compiler for a > time and now Intel has it. > > Anyway, since I was not the person who originally worked on this code, I am > not sure what functionality from the two libraries are being used, so I would > like to find the one or more libraries that are equivalent to the libraries > that are being used from the Intel libraries. From what I understand, the > libraries have been split up into more than one library since Intel took it > over, but all that I know is that the two libraries in question are DFPORT > and DFLIB. > > Can someone help me find the equivalent libraries in GCC that replace all of > the functionality in DFPORT and DFLIB or point me in a direction where I can > find this information? I've been trying to find it for the last 3 weeks and > have found a lot of things, but nothing I can use or that works. I've tried, > unsuccessfully, to use the Intel libraries, as well as trying to rebuild > them. If there aren't any equivalent libraries then I may need to work on > getting the Intel compiler added to the software list, which will take > another month or more. Please read https://gcc.gnu.org/legacy-ml/fortran/2010-04/msg00314.html for about DFPORT and gfortran. For DFLIB, you might need to re-implement some of it. It looks like it was Windows only even. Thanks, Andrew Pinski > > So any help would be very much appreciated. > > Thank you, > > Larry M. Lemons > Sr. Software Developer
Re: libsanitizer: sync from master
On Tue, Nov 15, 2022 at 7:47 AM Martin Liška wrote: > > Hi. > > I've just pushed libsanitizer update that was tested on x86_64-linux and > ppc64le-linux systems. > Moreover, I run bootstrap on x86_64-linux and checked ABI difference with > abidiff. This broke hwasan on aarch64. See https://gcc.gnu.org/PR109674 . Thanks, Andrew > > Pushed as r13-4068-g3037f11fb86eda. > > Cheers, > Martin
Re: Hosting our gfortran MatterMost workspace
On Fri, Apr 28, 2023 at 8:32 AM Jerry D via Fortran wrote: > > Hello all and gcc overseers, > > I received a notice that the MasterMost server providers decided to drop > their free service. Unfortunate and understandable. > > I plan to contact the Open Software Lab folks at Oregon State University > to see if they can host for us. > > If anyone else has any suggestions of possible places we can host an > instance, please let me know. The software for the platform is open > source many folks self host, so we can do this. > > I am not sure where gcc.gnu.org is hosted, but that might be a logical > place. Take a look at https://sourceware.org/bugzilla/show_bug.cgi?id=29853 . gcc.gnu.org is currently hosted as part of sourceware so ... Thanks, Andrew > > Best regards, > > Jerry
[PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.
The problem here is we were outputing long_long instead of
"long long". This was just an oversight and a missing check.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (get_c_type_name): Fix "long_long"
type name to be "long long". Add a comment on why adding
2 to the name too.
---
gcc/fortran/dump-parse-tree.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 3b24bdc1a6c..f4490da6a19 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -3696,7 +3696,10 @@ get_c_type_name (gfc_typespec *ts, gfc_array_spec *as,
const char **pre,
if (c_interop_kinds_table[i].f90_type == ts->type
&& c_interop_kinds_table[i].value == ts->kind)
{
+ /* Skip over 'c_'. */
*type_name = c_interop_kinds_table[i].name + 2;
+ if (strcmp (*type_name, "long_long") == 0)
+ *type_name = "long long";
if (strcmp (*type_name, "signed_char") == 0)
*type_name = "signed char";
else if (strcmp (*type_name, "size_t") == 0)
--
2.17.1
Re: [PATCH][stage1] Remove conditionals around free()
On Wed, Mar 1, 2023 at 3:52 PM Bernhard Reutner-Fischer wrote: > > On Wed, 1 Mar 2023 14:59:44 -0800 > Andrew Pinski wrote: > > > On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran > > wrote: > > > > > > Hi! > > > > > > Mere cosmetics. > > > > > > - if (foo != NULL) > > > free (foo); > > > > > > With the caveat that coccinelle ruins replacement whitespace or i'm > > > uneducated enough to be unable to _not_ run the diff through > > > sed -e 's/^+\([[:space:]]*\)free(/+\1free (/' > > > at least. If anybody knows how to improve replacement whitespace, > > > i'd be interrested but didn't look nor ask. ISTM that leading > > > whitespace is somewhat ruined, too, so beware (8 spaces versus tab as > > > far as i have spot-checked). > > > > > > Would touch > > > gcc/ada/rtinit.c |3 +-- > > > > > > It's funny how you apparently did not comment that hunk in the end ;) No, I was just trying to make it look seperate from the intl hunk really. > > > > intl/bindtextdom.c |3 +-- > > > intl/loadmsgcat.c|6 ++ > > > intl/localcharset.c |3 +-- > > > > intl is imported from glibc, though I don't know we have updated it in > > recent years from glibc. > > i don't think we did, overdue, as we (probably) all know. > OTOH i'm thankful that we don't have submodules but a plain, manageable > repo. Of course that comes with a burden, which is nil if ignored > throughout. Doesn't always pay out too well longterm if nobody > (voluntarily) is in due charge. I looked and nobody has filed a bug report about merging from recent glibc sources for intl. Most likely because not many folks use code from intl any more as glibc is main libc that people use for development these days in GCC world. > > > > zlib/contrib/minizip/unzip.c |2 +- > > > zlib/contrib/minizip/zip.c |2 +- > > > zlib/examples/enough.c |6 ++ > > > zlib/examples/gun.c |2 +- > > > zlib/examples/gzjoin.c |3 +-- > > > zlib/examples/gzlog.c|6 ++ > > > > zlib is definitely imported from zlib upstream. > > So it might be good to check if we could import a new version and see > > if it still works instead. updating zlib is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 . Thanks, Andrew > > From a meta POV, i wonder where the trailing space in the subject comes > from, looking at e.g.: > https://gcc.gnu.org/pipermail/gcc-patches/2023-March/date.html#613110 > I think and hope that the newer(?) ones by > https://inbox.sourceware.org/gcc-patches/?t=xyz do not exhibit these > invented trailing blanks nobody ever wrote for real, does it. > > Thanks for reminding me of intl and it's outdatedness, although i > certainly don't have ambition to do anything about it for sure. > I didn't care 15 or 20 years ago and nowadays i'd call that attitude a > tradition, at least ATM ;) TBH i initially had only considered gcc/ but > somehow found that unfair. Great idea that inclusion was. > > thanks, > > > > 4) i most likely will not remember to split it apart and send proper > > >patches, tested patches, in stage 1 to maintainers proper, so if > > >anyone feels like pursuing this, be my guest. I thought i'd just > > >mention it. > > > > > > cheers, >
Re: [PATCH][stage1] Remove conditionals around free()
On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran wrote: > > Hi! > > Mere cosmetics. > > - if (foo != NULL) > free (foo); > > With the caveat that coccinelle ruins replacement whitespace or i'm > uneducated enough to be unable to _not_ run the diff through > sed -e 's/^+\([[:space:]]*\)free(/+\1free (/' > at least. If anybody knows how to improve replacement whitespace, > i'd be interrested but didn't look nor ask. ISTM that leading > whitespace is somewhat ruined, too, so beware (8 spaces versus tab as > far as i have spot-checked). > > Would touch > gcc/ada/rtinit.c |3 +-- > intl/bindtextdom.c |3 +-- > intl/loadmsgcat.c|6 ++ > intl/localcharset.c |3 +-- intl is imported from glibc, though I don't know we have updated it in recent years from glibc. > libbacktrace/xztest.c|9 +++-- > libbacktrace/zstdtest.c |9 +++-- > libbacktrace/ztest.c |9 +++-- > libgfortran/caf/single.c |6 ++ > libgfortran/io/async.c |6 ++ > libgfortran/io/format.c |3 +-- > libgfortran/io/transfer.c|6 ++ > libgfortran/io/unix.c|3 +-- > libgo/runtime/go-setenv.c|6 ++ > libgo/runtime/go-unsetenv.c |3 +-- > libgomp/target.c |3 +-- > libiberty/concat.c |3 +-- This code is really old and only has gotten some modernization in recent years (post 8 years ago). > zlib/contrib/minizip/unzip.c |2 +- > zlib/contrib/minizip/zip.c |2 +- > zlib/examples/enough.c |6 ++ > zlib/examples/gun.c |2 +- > zlib/examples/gzjoin.c |3 +-- > zlib/examples/gzlog.c|6 ++ zlib is definitely imported from zlib upstream. So it might be good to check if we could import a new version and see if it still works instead. Thanks, Andrew Pinski > > coccinelle script and invocation inline. > Would need to be split for the respective maintainers and run through > mklog with subject changelog and should of course be compiled and > tested before that. > > Remarks: > 1) We should do this in if-conversion (?) on our own. >I suppose. Independently of -fdelete-null-pointer-checks > 2) Maybe not silently, but raise language awareness nowadays. >By now it's been a long time since this was first mandated. > 3) fallout from looking at something completely different > 4) i most likely will not remember to split it apart and send proper >patches, tested patches, in stage 1 to maintainers proper, so if >anyone feels like pursuing this, be my guest. I thought i'd just >mention it. > > cheers,
Re: [PATCH v5 0/5] P1689R5 support
On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran wrote: > > Hi, > > This patch series 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 any > TU with `export import some_module;` is compiled first. I like how folks are complaining that GCC outputs POSIX makefile syntax from GCC's dependency files which are supposed to be in POSIX Makefile syntax. It seems like rather the build tools are people like to use are not understanding POSIX makefile syntax any more rather. Also I am not a fan of json, it is too verbose for no use. Maybe it is time to go back to standardizing a new POSIX makefile syntax rather than changing C++ here. Thanks, Andrew Pinski > > [P1689R5]: https://isocpp.org/files/papers/P1689R5.html > > I've also added patches to include imported module CMI files and the > module mapper file as dependencies of the compilation. I briefly looked > into adding dependencies on response files as well, but that appeared to > need some code contortions to have a `class mkdeps` available before > parsing the command line or to keep the information around until one was > made. > > 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. > > FWIW, Clang as taken an alternate approach with its `clang-scan-deps` > tool rather than using the compiler directly. > > Thanks, > > --Ben > > --- > v4 -> v5: > > - add dependency tracking for imported modules to `-MF` > - add dependency tracking for static module mapper files given to > `-fmodule-mapper=` > > v3 -> v4: > > - add missing spaces between function names and arguments > > v2 -> v3: > > - changelog entries moved to commit messages > - documentation updated/added in the UTF-8 routine editing > > v1 -> v2: > > - removal of the `deps_write(extra)` parameter to option-checking where > ndeeded > - default parameter of `cpp_finish(fdeps_stream = NULL)` > - unification of libcpp UTF-8 validity functions from v1 > - test cases for flag parsing states (depflags-*) and p1689 output > (p1689-*) > > Ben Boeckel (5): > libcpp: reject codepoints above 0x10 > libcpp: add a function to determine UTF-8 validity of a C string > p1689r5: initial support > c++modules: report imported CMI files as dependencies > c++modules: report module mapper files as a dependency > > gcc/c-family/c-opts.cc| 40 +++- > gcc/c-family/c.opt| 12 + > gcc/cp/mapper-client.cc | 4 + > gcc/cp/mapper-client.h| 1 + > gcc/cp/module.cc | 23 +- > gcc/doc/invoke.texi | 15 ++ > gcc/testsuite/g++.dg/modules/depflags-f-MD.C | 2 + > gcc/testsuite/g++.dg/modules/depflags-f.C | 1 + > gcc/testsuite/g++.dg/modules/depflags-fi.C| 3 + > gcc/testsuite/g++.dg/modules/depflags-fj-MD.C | 3 + > gcc/testsuite/g++.dg/modules/depflags-fj.C| 4 + > .../g++.dg/modules/depflags-fjo-MD.C | 4 + > gcc/testsuite/g++.dg/modules/depflags-fjo.C | 5 + > gcc/testsuite/g++.dg/modules/depflags-fo-MD.C | 3 + > gcc/testsuite/g++.dg/modules/depflags-fo.C| 4 + > gcc/testsuite/g++.dg/modules/depflags-j-MD.C | 2 + > gcc/testsuite/g++.dg/modules/depflags-j.C | 3 + > gcc/testsuite/g++.dg/modules/depflags-jo-MD.C | 3 + > gcc/testsuite/g++.dg/modules/depflags-jo.C| 4 + > gcc/testsuite/g++.dg/modules/depflags-o-MD.C | 2 + > gcc/testsuite/g++.dg/modules/depflags-o.C | 3 + > gcc/testsuite/g++.dg/modules/modules.exp | 1 + > gcc/testsuite/g++.dg/modules/p1689-1.C| 18 ++ > gcc/testsuite/g++.dg/modules/p1689-1.exp.json | 27 +++ > gcc/testsuite/g++.dg/modules/p1689-2.C| 16 ++ > gcc/testsuite/g++.dg/modules/p1689-2.exp.json | 16 ++ > gcc/testsuite/g++.dg/modules/p1689-3.C| 14 ++ > gcc/testsuite/g++.dg/modules/p1689-3.exp.json | 16 ++ > gcc/testsuite/g++.dg/modules/p1689-4.C| 14 ++ > gcc/testsuite/g++.dg/modules/p1689-4.exp.json | 14 ++ > gcc/testsuite/g++.dg/modules/p1689-5.C| 14 ++ > gcc/testsuite/g++.dg/modules/p1689-5.exp.json | 14 ++ > gcc/testsuite/g++.dg/modules/test-p1689.py| 222 ++ > gcc/testsuite/lib/modules.exp | 71 ++ >
Re: Testsuite, dejagnu
On Mon, Jan 30, 2023 at 12:27 PM Harald Anlauf via Fortran wrote: > > Dear Hackers, > > is there a way to check that a particular warning is emitted only > once for a source code line instead of multiple times? > > It appears that by default dg-warn matches one or more times. One example of how to do this is located in testsuite/g++.dg/lookup/duperr1.C . I don't know if this is the best way of doing it though. Basically it uses dg-bogus to match the multiple warnings (since it is a regex over all output lines and `.*` will even match new lines) so you get a failure if there was a duplicated one and then dg-message to match the original message just to make sure it is outputted once (dg-message was because it was originally a note: rather than a warning/error but similar thing can be done for dg-error/dg-warning). Thanks, Andrew Pinski > > Thanks, > Harald >
Re: [PATCH 4/5] value-range: Add as_string diagnostics helper
On Sat, Nov 12, 2022 at 3:47 PM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> gcc/ChangeLog:
>
> * value-range.cc (get_bound_with_infinite_markers): New static helper.
> (irange::as_string): New definition.
> * value-range.h: New declaration.
>
> ---
> Provide means to print a value range to a newly allocated buffer.
> The caller is responsible to free() the allocated memory.
>
> Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
> Ok for trunk?
>
> Cc: Andrew MacLeod
> Cc: Aldy Hernandez
> ---
> gcc/value-range.cc | 56 ++
> gcc/value-range.h | 3 +++
> 2 files changed, 59 insertions(+)
>
> diff --git a/gcc/value-range.cc b/gcc/value-range.cc
> index a855aaf626c..51cd9a38d90 100644
> --- a/gcc/value-range.cc
> +++ b/gcc/value-range.cc
> @@ -3099,6 +3099,62 @@ debug (const value_range )
>fprintf (stderr, "\n");
> }
>
> +/* Helper for irange::as_string(). Print a bound to an allocated buffer. */
> +static char *
Can we start using std::string instead of char* here?
> +get_bound_with_infinite_markers (tree bound)
> +{
> + tree type = TREE_TYPE (bound);
> + wide_int type_min = wi::min_value (TYPE_PRECISION (type), TYPE_SIGN
> (type));
> + wide_int type_max = wi::max_value (TYPE_PRECISION (type), TYPE_SIGN
> (type));
> +
> + if (INTEGRAL_TYPE_P (type)
> + && !TYPE_UNSIGNED (type)
> + && TREE_CODE (bound) == INTEGER_CST
> + && wi::to_wide (bound) == type_min
> + && TYPE_PRECISION (type) != 1)
> +return xstrdup ("-INF");
> + else if (TREE_CODE (bound) == INTEGER_CST
> + && wi::to_wide (bound) == type_max
> + && TYPE_PRECISION (type) != 1)
> +return xstrdup ("+INF");
> + else
> +return print_generic_expr_to_str (bound);
No reason to do xstrdup any more either.
> +}
> +
> +
> +/* Return an irange as string. Return NULL on failure, an allocated
> + string on success. */
> +char *
Likewise.
Thanks,
Andrew Pinski
> +irange::as_string ()
> +{
> + char *ret = NULL;
This becomes std::string ret;
> + if (undefined_p() || varying_p () || m_num_ranges == 0)
> +return ret;
> +
> + for (unsigned i = 0; i < m_num_ranges; ++i)
> +{
> + tree lb = m_base[i * 2];
> + tree ub = m_base[i * 2 + 1];
> + /* Construct [lower_bound,upper_bound]. */
> + char *lbs = get_bound_with_infinite_markers (lb);
> + char *ubs = get_bound_with_infinite_markers (ub);
> + /* Paranoia mode */
> + if (!lbs)
> + lbs = xstrdup ("");
> + if (!ubs)
> + ubs = xstrdup ("");
> +
> + if (ret)
> + ret = reconcat (ret, ret, "[", lbs, ",", ubs, "]", NULL);
> + else
> + ret = concat ("[", lbs, ",", ubs, "]", NULL);
> +
> + free (lbs);
> + free (ubs);
> +}
> + return ret;
> +}
> +
> /* Create two value-ranges in *VR0 and *VR1 from the anti-range *AR
> so that *VR0 U *VR1 == *AR. Returns true if that is possible,
> false otherwise. If *AR can be represented with a single range
> diff --git a/gcc/value-range.h b/gcc/value-range.h
> index c87734dd8cd..76242e4bf45 100644
> --- a/gcc/value-range.h
> +++ b/gcc/value-range.h
> @@ -160,6 +160,9 @@ public:
>wide_int get_nonzero_bits () const;
>void set_nonzero_bits (const wide_int_ref );
>
> + // For diagnostics.
> + char *as_string ();
> +
>// Deprecated legacy public methods.
>tree min () const; // DEPRECATED
>tree max () const; // DEPRECATED
> --
> 2.38.1
>
Re: gfc_char_t
On Sun, Jan 9, 2022 at 1:46 PM Harald Anlauf via Fortran wrote: > > Dear all, > > while working on a PR related to kind=4 character issues, I saw the > following in gfortran.h: > > > /* We need to store source lines as sequences of multibyte source > characters. We define here a type wide enough to hold any multibyte > source character, just like libcpp does. A 32-bit type is enough. */ > > #if HOST_BITS_PER_INT >= 32 > typedef unsigned int gfc_char_t; > #elif HOST_BITS_PER_LONG >= 32 > typedef unsigned long gfc_char_t; > #elif defined(HAVE_LONG_LONG) && (HOST_BITS_PER_LONGLONG >= 32) > typedef unsigned long long gfc_char_t; > #else > # error "Cannot find an integer type with at least 32 bits" > #endif > > > This seems to have been introduced by FX, but I do not really > understand it. Can't we use a fixed and platform-independent > type that can hold wide chars? Isn't a 32-bit / 4-byte type > sufficient? I suspect HOST_BITS_PER_INT will always be 32bit for all hosts GCC will be supported but who knows. The point of the check is to find a type which is at least 32bits enough to hold the wide character. HOST_BITS_PER_* are defined in hwint.h: #define HOST_BITS_PER_CHAR CHAR_BIT #define HOST_BITS_PER_SHORT (CHAR_BIT * SIZEOF_SHORT) #define HOST_BITS_PER_INT (CHAR_BIT * SIZEOF_INT) #define HOST_BITS_PER_LONG (CHAR_BIT * SIZEOF_LONG) #define HOST_BITS_PER_PTR (CHAR_BIT * SIZEOF_VOID_P) Where SIZEOF_* are defined while doing a configure and CHAR_BIT is defined in limits.h which is defined as a preprocessor constant. Does that help you understand the code better? Thanks, Andrew Pinski > > Thanks for any enlightenment, > Harald >
