Re: [Patch] (general Fortran + OpenMP) [Fortran] Fix/modify present() handling for assumed-shape optional (PR 94672)
Hi Tobias,
For assumed shape, gfortran generates an "arg.0 = arg->data"
artificial variable – and with optional one has something like
if (arg != NULL && arg->data != NULL)
{
arg.0 = arg->data;
lbound.0 = ...
}
And an "if (present(arg))" becomes
"if (arg != NULL && arg->data != NULL)".
The proposed change changes the init to:
if (arg != NULL && arg->data != NULL)
{
arg.0 = arg->data;
lbound.0 = ...
}
else
arg.0 = NULL; // <-- new
I think this is a good idea in general. We later use the arg.0
variable to access the contents of the argument, so this generates
a clear segfault for all cases where the user accesses non-present
opiontal arguments instead of something random.
Also, this avoids potential warnings about undefined variables.
Thus: I think either variant (checking arg directly vs. checking arg.0
plus setting it to NULL) works equally well with normal Fortran code;
Like I said, I think it is better :-)
one can probably design code where one or the other is slightly faster,
but at the end it should not matter.
And for OpenMP/OpenACC, the new variant avoids several problems.
Hence:
OK for the trunk – and GCC 10 (regression, rejects valid code)?
OK for both, and thanks for the patch!
Regards
Thomas
Re: [Patch] PR fortran/93499 - ICE on division by zero in declaration statements
Hi Harald, the attached should be mostly self-explaining. Division by zero handling appeared to be incomplete. It was not dealt with properly when occurring in declaration statements. We now try to handle this. OK for mainline? OK. Thanks for the patch! Regards Thomas
Ping: [PATCH] libiberty: Update D symbol demangling for latest ABI spec.
Ping
On 03/05/2020 09:37, Iain Buclaw via Gcc-patches wrote:
> Ping.
>
> There is a new mangle string "Nm" in the abi to denote the @live attribute,
> however will add support in a follow up patch.
>
>
> On 15 April 2020 12:04:29 CEST, Iain Buclaw via Gcc-patches
> wrote:
>> Ping.
>>
>> On 04/04/2020 13:33, Iain Buclaw wrote:
>>> Hi,
>>>
>>> Some small improvements and clarifications have been done in the D ABI
>>> specification to remove all ambiguities found in the current grammar,
>>> this implementation now more closely resembles the spec, whilst
>>> maintaining compatibility with the old ABI.
>>>
>>> Three new rules have been added to the ABI.
>>>
>>> 1. Back references using 'Q', analogous to C++ substitutions, compresses
>>>repeated identifiers, types, and template symbol and value parameters.
>>>
>>> 2. Template aliases to externally mangled symbols are prefixed with 'X'.
>>>This includes any symbol that isn't extern(D), or has its name
>>>overriden with pragma(mangle). This fixes an ambiguity where it was
>>>not clear whether 'V' was an encoded calling convention, or the next
>>>template value parameter.
>>>
>>> 3. Alias parameters, templates, and tuple symbols no longer encode the
>>>symbol length of its subpart. Tuples are now terminated with 'Z'.
>>>This fixes another ambiguity where the first character of the mangled
>>>name can be a digit as well, so the demangler had to figure out where
>>>to split the two adjacent numbers by trying out each combination.
>>>
>>> This patch was originally written by Rainer Schuetze, with clean-ups and
>>> backwards compatibility added by myself.
>>>
>>> Bootstrapped and regression tested on x86_linux-gnu, OK for mainline?
>>>
>>> Regards
>>> Iain.
>>>
>>> ---
>>>
>>> libiberty/ChangeLog:
>>>
>>> 2019-04-04 Rainer Schuetze
>>> Iain Buclaw
>>>
>>> * d-demangle.c (enum dlang_symbol_kinds): Remove enum.
>>> (struct dlang_info): New struct
>>> (dlang_decode_backref): New function.
>>> (dlang_backref): New function.
>>> (dlang_symbol_backref): New function.
>>> (dlang_type_backref): New function.
>>> (dlang_symbol_name_p): New function.
>>> (dlang_function_type_noreturn): New function.
>>> (dlang_function_type): Add 'info' parameter. Decode function type
>>> with dlang_function_type_noreturn.
>>> (dlang_function_args): Add 'info' parameter.
>>> (dlang_type): Add 'info' parameter. Handle back referenced types.
>>> (dlang_identifier): Replace 'kind' parameter with 'info'. Handle back
>>> referenced symbols. Split off decoding of plain identifiers to...
>>> (dlang_lname): ...here.
>>> (dlang_parse_mangle): Replace 'kind' parameter with 'info'. Decode
>>> function type and return with dlang_type.
>>> (dlang_parse_qualified): Replace 'kind' parameter with 'info', add
>>> 'suffix_modifier' parameter. Decode function type with
>>> dlang_function_type_noreturn.
>>> (dlang_parse_tuple): Add 'info' parameter.
>>> (dlang_template_symbol_param): New function.
>>> (dlang_template_args): Add 'info' parameter. Decode symbol parameter
>>> with dlang_template_symbol_param. Handle back referenced values, and
>>> externally mangled parameters.
>>> (dlang_parse_template): Add 'info' parameter.
>>> (dlang_demangle_init_info): New function.
>>> (dlang_demangle): Initialize and pass 'info' parameter.
>>> * testsuite/d-demangle-expected: Add new tests.
>>>
>>> ---
>>> libiberty/d-demangle.c | 769
>>> libiberty/testsuite/d-demangle-expected | 72 +++
>>> 2 files changed, 580 insertions(+), 261 deletions(-)
>>>
>>> diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
>>> index a9702858a6e..5856bc2930f 100644
>>> --- a/libiberty/d-demangle.c
>>> +++ b/libiberty/d-demangle.c
>>> @@ -160,37 +160,42 @@ string_prepend (string *p, const char *s)
>>> }
>>> }
>>>
>>> -/* What kinds of symbol we could be parsing. */
>>> -enum dlang_symbol_kinds
>>> +/* Demangle information structure we pass around. */
>>> +struct dlang_info
>>> {
>>> - /* Top-level symbol, needs it's type checked. */
>>> - dlang_top_level,
>>> - /* Function symbol, needs it's type checked. */
>>> - dlang_function,
>>> - /* Strongly typed name, such as for classes, structs and enums. */
>>> - dlang_type_name,
>>> - /* Template identifier. */
>>> - dlang_template_ident,
>>> - /* Template symbol parameter. */
>>> - dlang_template_param
>>> + /* The string we are demangling. */
>>> + const char *s;
>>> + /* The index of the last back reference. */
>>> + int last_backref;
>>> };
>>>
>>> +/* Pass as the LEN to dlang_parse_template if symbol length is not known.
>>> */
>>> +enum { TEMPLATE_LENGTH_UNKNOWN = -1 };
>>> +
>>> /* Prototypes for forward referenced functions */
>>> -static const char *dlang_function_args (string *, const char *);
>>> +static const char *dla
[committed] wwwdocs: Move refspecs.linuxbase.org to https.
Pushed. Gerald --- htdocs/readings.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index 0dd27368..086baaa1 100644 --- a/htdocs/readings.html +++ b/htdocs/readings.html @@ -313,8 +313,8 @@ names. Manufacturer: IBM http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf";>z/Architecture Principles of Operation http://publibfp.dhe.ibm.com/epubs/pdf/dz9ar008.pdf";>ESA/390 Principles of Operation - http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_zSeries.html";>Linux for z Systems ABI - http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_s390.html";>Linux for S/390 ABI + https://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_zSeries.html";>Linux for z Systems ABI + https://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_s390.html";>Linux for S/390 ABI -- 2.26.2
[PATCH] rs6000: Add vec_extracth and vec_extractl
From: Kelvin Nilsen Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and vextddvhx, along with built-in access and overloaded built-in access to these insns. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions, using a Power9 configuration. Is this okay for master? Thanks, Bill [gcc] 2020-05-10 Kelvin Nilsen * config/rs6000/altivec.h (vec_extractl): New #define. (vec_extracth): Likewise. * config/rs6000/altivec.md (UNSPEC_EXTRACTL): New constant. (UNSPEC_EXTRACTR): Likewise. (VEXTRACT_LR): New int iterator. (LR): New int attribute. (lr): Likewise. (rl): Likewise. (vextract_): New expansion. (vextract_insn_): New insn. * config/rs6000/rs6000-builtin.def (__builtin_altivec_vextdubvlx): New built-in function. (__builtin_altivec_vextduhvlx): Likewise. (__builtin_altivec_vextduwvlx): Likewise. (__builtin_altivec_vextddvlx): Likewise. (__builtin_altivec_vextdubvhx): Likewise. (__builtin_altivec_vextduhvhx): Likewise. (__builtin_altivec_vextduwvhx): Likewise. (__builtin_altivec_vextddvhx): Likewise. (__builtin_vec_extractl): New overloaded built-in function. (__builtin_vec_extracth): Likewise. * config/rs6000/rs6000-call.c (altivec_overloaded_builtins): Define overloaded forms of __builtin_vec_extractl and __builtin_vec_extracth. (builtin_function_type): Add cases to mark arguments of new built-in functions as unsigned. (rs6000_common_init_builtins): Add opaque_ftype_opaque_opaque_opaque_opaque. * config/rs6000/rs6000.md (du_or_d): New mode attribute. * doc/extend.texi (PowerPC AltiVec Built-in Functions Available for a Future Architecture): Add description of vec_extractl and vec_extractr built-in functions. [gcc/testsuite] 2020-05-10 Kelvin Nilsen * gcc.target/powerpc/vec-extracth-0.c: New. * gcc.target/powerpc/vec-extracth-1.c: New. * gcc.target/powerpc/vec-extracth-2.c: New. * gcc.target/powerpc/vec-extracth-3.c: New. * gcc.target/powerpc/vec-extracth-4.c: New. * gcc.target/powerpc/vec-extracth-5.c: New. * gcc.target/powerpc/vec-extracth-6.c: New. * gcc.target/powerpc/vec-extracth-7.c: New. * gcc.target/powerpc/vec-extracth-be-0.c: New. * gcc.target/powerpc/vec-extracth-be-1.c: New. * gcc.target/powerpc/vec-extracth-be-2.c: New. * gcc.target/powerpc/vec-extracth-be-3.c: New. * gcc.target/powerpc/vec-extractl-0.c: New. * gcc.target/powerpc/vec-extractl-1.c: New. * gcc.target/powerpc/vec-extractl-2.c: New. * gcc.target/powerpc/vec-extractl-3.c: New. * gcc.target/powerpc/vec-extractl-4.c: New. * gcc.target/powerpc/vec-extractl-5.c: New. * gcc.target/powerpc/vec-extractl-6.c: New. * gcc.target/powerpc/vec-extractl-7.c: New. * gcc.target/powerpc/vec-extractl-be-0.c: New. * gcc.target/powerpc/vec-extractl-be-1.c: New. * gcc.target/powerpc/vec-extractl-be-2.c: New. * gcc.target/powerpc/vec-extractl-be-3.c: New. --- gcc/config/rs6000/altivec.h | 3 + gcc/config/rs6000/altivec.md | 47 gcc/config/rs6000/rs6000-builtin.def | 13 + gcc/config/rs6000/rs6000-call.c | 39 - gcc/config/rs6000/rs6000.md | 10 gcc/doc/extend.texi | 56 +++ .../gcc.target/powerpc/vec-extracth-0.c | 34 +++ .../gcc.target/powerpc/vec-extracth-1.c | 32 +++ .../gcc.target/powerpc/vec-extracth-2.c | 32 +++ .../gcc.target/powerpc/vec-extracth-3.c | 30 ++ .../gcc.target/powerpc/vec-extracth-4.c | 32 +++ .../gcc.target/powerpc/vec-extracth-5.c | 30 ++ .../gcc.target/powerpc/vec-extracth-6.c | 32 +++ .../gcc.target/powerpc/vec-extracth-7.c | 30 ++ .../gcc.target/powerpc/vec-extracth-be-0.c| 33 +++ .../gcc.target/powerpc/vec-extracth-be-1.c| 31 ++ .../gcc.target/powerpc/vec-extracth-be-2.c| 31 ++ .../gcc.target/powerpc/vec-extracth-be-3.c| 31 ++ .../gcc.target/powerpc/vec-extractl-0.c | 34 +++ .../gcc.target/powerpc/vec-extractl-1.c | 32 +++ .../gcc.target/powerpc/vec-extractl-2.c | 32 +++ .../gcc.target/powerpc/vec-extractl-3.c | 30 ++ .../gcc.target/powerpc/vec-extractl-4.c | 32 +++ .../gcc.target/powerpc/vec-extractl-5.c | 30 ++ .../gcc.target/powerpc/vec-extractl-6.c | 32 +++ .../gcc.target/powerpc/vec-extractl-7.c | 30 ++ .../gcc.target/powerpc/vec-extractl-be-0.c| 33 +++ .../gcc.target/powerpc/vec-extract
New Swedish PO file for 'gcc' (version 10.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-10.1.0.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] make minmax detection work with FMIN/FMAX IFNs
On Fri, May 8, 2020 at 4:38 PM Richard Biener wrote: > > On May 8, 2020 4:28:24 PM GMT+02:00, Alexander Monakov > wrote: > >On Fri, 8 May 2020, Uros Bizjak wrote: > > > >> > Am I missing something? > >> > >> Is the above enough to declare min/max as IEEE compliant? > > > >No. SSE min/max instructions semantics match C expression x < y ? x : > >y. > >IEEE min/max operations are commutative when exactly one operand is a > >NaN, > >and so are C fmin/fmax functions: > > > >fmin(x, NaN) == fmin(NaN, x) == x // x is not a NaN > > > >In contrast, (x < y ? x : y) always returns y when x or y is a NaN, and > >likewise the corresponding SSE instructions are not commutative. > > > >Therefore they are explicitly non-compliant in presence of NaNs. > > > >I don't know how GCC defines the semantics of GIMPLE min/max IFNs. > > The IFNs are supposed to match fmin and fmax from the C standard which IIRC > have IEEE semantics. > > Note the ISA likely behaves this way because it matches open coded C > semantics. > > Arm folks added the IFNs so I have to dig up what exactly they were after... > > I'd hate to add a third variant here... So, I found [1], that tries to explain this issue. [1] https://2pi.dk/2016/05/ieee-min-max Uros.
Re: [PATCH] make minmax detection work with FMIN/FMAX IFNs
On Sun, 10 May 2020, Uros Bizjak wrote: > So, I found [1], that tries to explain this issue. > > [1] https://2pi.dk/2016/05/ieee-min-max I would also recommend reading this report that covers a few more architectures and issues with IEEE754 definitions: http://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/minNum_maxNum_Removal_Demotion_v3.pdf Alexander
New German PO file for 'gcc' (version 10.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: https://translationproject.org/latest/gcc/de.po (This file, 'gcc-10.1.0.de.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Fix Debug mode Undefined Behavior
I just committed this patch.
François
On 03/03/20 10:11 pm, François Dumont wrote:
After the fix of PR 91910 I tried to consider other possible race
condition and I think we still have a problem.
Like stated in the PR when a container is destroyed all associated
iterators are made singular. If at the same time another thread try to
access this iterator the _M_singular check will face a data race when
accessing _M_sequence member. In case of race condition the program is
likely to abort but maybe because of memory access violation rather
than a clear singular iterator assertion.
To avoid this I rework _M_sequence manipulation to use atomic read
when necessary and make sure that otherwise container mutex is locked.
* src/c++/debug.cc
(_Safe_sequence_base::_M_attach_single): Set attached
iterator
sequence pointer and version.
(_Safe_sequence_base::_M_detach_single): Reset detached
iterator.
(_Safe_iterator_base::_M_attach): Remove attached iterator
sequence
pointer and version assignments.
(_Safe_iterator_base::_M_attach_single): Likewise.
(_Safe_iterator_base::_M_detach_single): Remove detached
iterator
reset.
(_Safe_iterator_base::_M_singular): Use atomic load to
access parent
sequence.
(_Safe_iterator_base::_M_can_compare): Likewise.
(_Safe_iterator_base::_M_get_mutex): Likewise.
(_Safe_local_iterator_base::_M_attach): Remove attached
iterator container
pointer and version assignments.
(_Safe_local_iterator_base::_M_attach_single): Likewise.
(_Safe_unordered_container_base::_M_attach_local_single):
Set attached iterator container pointer and version.
(_Safe_unordered_container_base::_M_detach_local_single): Reset detached
iterator.
Running tests in Debug mode.
Ok to commit if successful ?
François
diff --git a/libstdc++-v3/src/c++11/debug.cc b/libstdc++-v3/src/c++11/debug.cc
index 18da9da9c52..032e0b50b91 100644
--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -318,6 +318,8 @@ namespace __gnu_debug
_Safe_sequence_base::
_M_attach_single(_Safe_iterator_base* __it, bool __constant) throw ()
{
+__it->_M_sequence = this;
+__it->_M_version = _M_version;
_Safe_iterator_base*& __its =
__constant ? _M_const_iterators : _M_iterators;
__it->_M_next = __its;
@@ -345,6 +347,7 @@ namespace __gnu_debug
_M_const_iterators = __it->_M_next;
if (_M_iterators == __it)
_M_iterators = __it->_M_next;
+__it->_M_reset();
}
void
@@ -355,11 +358,7 @@ namespace __gnu_debug
// Attach to the new sequence (if there is one)
if (__seq)
- {
- _M_sequence = __seq;
- _M_version = _M_sequence->_M_version;
- _M_sequence->_M_attach(this, __constant);
- }
+ __seq->_M_attach(this, __constant);
}
void
@@ -370,11 +369,7 @@ namespace __gnu_debug
// Attach to the new sequence (if there is one)
if (__seq)
- {
- _M_sequence = __seq;
- _M_version = _M_sequence->_M_version;
- _M_sequence->_M_attach_single(this, __constant);
- }
+ __seq->_M_attach_single(this, __constant);
}
void
@@ -400,10 +395,7 @@ namespace __gnu_debug
_M_detach_single() throw ()
{
if (_M_sequence)
- {
- _M_sequence->_M_detach_single(this);
- _M_reset();
- }
+ _M_sequence->_M_detach_single(this);
}
void
@@ -419,20 +411,32 @@ namespace __gnu_debug
bool
_Safe_iterator_base::
_M_singular() const throw ()
- { return !_M_sequence || _M_version != _M_sequence->_M_version; }
+ {
+auto seq = __atomic_load_n(&_M_sequence, __ATOMIC_ACQUIRE);
+return !seq || _M_version != seq->_M_version;
+ }
bool
_Safe_iterator_base::
_M_can_compare(const _Safe_iterator_base& __x) const throw ()
{
-return (!_M_singular()
- && !__x._M_singular() && _M_sequence == __x._M_sequence);
+auto seq = __atomic_load_n(&_M_sequence, __ATOMIC_ACQUIRE);
+if (seq && _M_version == seq->_M_version)
+ {
+ auto xseq = __atomic_load_n(&__x._M_sequence, __ATOMIC_ACQUIRE);
+ return xseq && __x._M_version == xseq->_M_version && seq == xseq;
+ }
+
+return false;
}
__gnu_cxx::__mutex&
_Safe_iterator_base::
_M_get_mutex() throw ()
- { return _M_sequence->_M_get_mutex(); }
+ {
+auto seq = __atomic_load_n(&_M_sequence, __ATOMIC_ACQUIRE);
+return get_safe_base_mutex(seq);
+ }
_Safe_unordered_container_base*
_Safe_local_iterator_base::
@@ -447,11 +451,8 @@ namespace __gnu_debug
// Attach to the new container (if there is one)
if (__cont)
- {
- _M_sequence = __cont;
- _M_version = _M_sequence->_M_version;
- _M_get_container()->_M_attach_local(this, __constant);
- }
+ static_cast<_Safe_unordered_container_base*>(__cont)
+ ->_M_attach_local(this, __constant);
}
void
@@ -462,
Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.
On 1/10/20, Jason Merrill wrote: > Back in 2009 Manuel sent a patch to avoid useless -Wconversion warnings > on compound assignment of types that get promoted to int: > > https://gcc.gnu.org/ml/gcc-patches/2009-08/msg00582.html > > Joseph argued that those warnings are sometimes useful, and that they > should be controlled by a separate flag. So this patch introduces > -Warith-conversion, which is off by default in this patch. > > Joseph, is that default OK with you? If not, can you explain your > reasoning more about why the warnings are desirable? It seems to me > that even in cases where you don't know the ranges involved, it's wrong > for e.g. 'mychar += 1' to warn when 'myint += 1' doesn't. In both > cases, the addition might overflow the range of the target type, but > that isn't about the conversion; the result is the same as if the > operation had been done in the operand/target type rather than the > promoted type. > > The change to cp/typeck.c is a placeholder to use if the default setting > changes; even if we end up warning by default for mychar = mychar + 1, I > really don't want to warn about mychar += 1. > > sign.diff is a prerequisite tidying that moves the warnings from > unsafe_conversion_p back into conversion_warning with the others. > > rshift.diff restores the short_shift code to the C++ front end so that C > and C++ give the same warnings with -Warith-conversion. > > Tested x86_64-pc-linux-gnu. Comments? > Hi Jason, thanks for this new flag. Now that GCC 10 has been released I was checking the release notes to review everything new in GCC 10, and I didn't see any mention of -Warith-conversion on it. Could you add a quick note about -Warith-conversion to changes.html please? Thanks, Eric
[PATCH PR94969]Add unit distant vector to DDR in case of invariant access functions
Hi, As analyzed in PR94969, data dependence analysis now misses dependence vector for specific case in which DRs in DDR have the same invariant access functions. This simple patch fixes the issue by also covering invariant cases. Bootstrap and test on x86_64, is it OK? Thanks, bin 2020-05-11 Bin Cheng PR tree-optimization/94969 * tree-data-dependence.c (constant_access_functions): Rename to... (invariant_access_functions): ...this. Add parameter. Check for invariant access function, rather than constant. (build_classic_dist_vector): Call above function. * tree-loop-distribution.c (pg_add_dependence_edges): Add comment. gcc/testsuite 2020-05-11 Bin Cheng PR tree-optimization/94969 * gcc.dg/tree-ssa/pr94969.c: New test. pr94969-20200511.txt Description: Binary data
