[Bug d/90012] New: untranslateable placeholder in expressionsem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90012
Bug ID: 90012
Summary: untranslateable placeholder in expressionsem.c
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From expressionsem.c:
const char *p = v->isParameter() ? "parameter" : "local";
e->error("cannot take address of scope %s %s in @safe function %s",
p, v->toChars(), sc->func->toChars());
As a translator I have no chance of translating the first %s since it is passed
literally.
Please add a check to the diagnostics linter that can detect this case.
Detecting this case is possible since:
* p is only ever assigned a string literal
* that string literal is never passed through _(...)
* that string literal is passed as a replacement for a %s into a message
Translating GCC is a huge amount of work. If only 1% of the messages is broken
like this, this means 130 bug reports. That 1% is a pretty good estimate, based
on my experience. I'd like that rate to be in the order of 0.1%.
[Bug d/90013] New: wrong quotes in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90013 Bug ID: 90013 Summary: wrong quotes in diagnostics Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: roland.illig at gmx dot de Target Milestone: --- The GCC standard for diagnostics is: * placeholders are quoted: use %qs instead of a simple %s * quotes are written % instead of `this' or `this` or 'this' or "this" or similar variants Since the D diagnostics are marked with "gcc-internal-format", as a translator I expect that I can use the full range of these placeholders. The current diagnostics only use the simple %s, therefore my assumption might be wrong. If it is, it's the fault of the program that generates the .pot file. That should be fixed to not mark these strings as gcc-internal-format then.
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 --- Comment #13 from Jonathan Wakely --- (In reply to Steve Kargl from comment #10) > % g++8 -o z a.cpp -lm && ./z > z = (-1.84250315177824e-07,-0) >pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258) > sqrt(z) = (0,0.000429243887758258) > sqrt(conj(z)) = (0,0.000429243887758258) > conj(sqrt(z)) = (0,-0.000429243887758258) > > This looks wrong. I can't reproduce this, I get: z = (-1.84250315177824e-07,-0) pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258) sqrt(z) = (0,-0.000429243887758258) sqrt(conj(z)) = (0,0.000429243887758258) conj(sqrt(z)) = (0,0.000429243887758258)
[Bug fortran/90014] New: Untranslatable Fortran diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90014
Bug ID: 90014
Summary: Untranslatable Fortran diagnostics
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
gcc/po/gcc.pot has:
#. Macros for unified error messages.
#: fortran/frontend-passes.c:3746
msgid "Incorrect extent in argument B in MATMUL intrinsic in dimension "
msgstr ""
#: fortran/frontend-passes.c:3749
msgid "Array bound mismatch for dimension "
msgstr ""
which is what exgettext creates for:
#define B_ERROR(n) _("Incorrect extent in argument B in MATMUL intrinsic in " \
"dimension " #n ": is %ld, should be %ld")
#define C_ERROR(n) _("Array bound mismatch for dimension " #n " of array " \
"(%ld/%ld)")
and
B_ERROR(1) or C_ERROR(1) or C_ERROR(2).
This simply won't work, exgettext isn't able to deal with that kind of
stringification.
Either use %d and somehow propagate the value as another argument, or
use B_ERROR_1, C_ERROR_1 and C_ERROR_2 macros that won't use this kind of
stringification.
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 --- Comment #14 from Jonathan Wakely --- Which is unsurprising because std::sqrt(z) just calls __builtin_csqrt(z.__rep())
[Bug target/90015] New: riscv: typo "intterupt" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90015
Bug ID: 90015
Summary: riscv: typo "intterupt" in diagnostic
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
risvc.c:
error ("%qs function cannot have different intterupt type.", "interrupt");
intterupt should be interrupt
[Bug libstdc++/90008] [9 Regression] variant attempts to copy rhs in comparison operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90008
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1118,7 +1118,7 @@ namespace __variant
{ \
bool __ret = true; \
__do_visit<__detail::__variant::__visit_with_index>( \
-[&__ret, &__lhs, __rhs] \
+[&__ret, &__lhs] \
(auto&& __rhs_mem, auto __rhs_index) mutable \
-> __detail::__variant::__variant_idx_cookie \
{ \
[Bug libstdc++/89851] [9 Regression] std::variant comparison operators violate [variant.relops]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89851 --- Comment #1 from Jonathan Wakely --- This seems to have been fixed recently.
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 --- Comment #15 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #13) > (In reply to Steve Kargl from comment #10) > > % g++8 -o z a.cpp -lm && ./z > > z = (-1.84250315177824e-07,-0) > >pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258) > > sqrt(z) = (0,0.000429243887758258) > > sqrt(conj(z)) = (0,0.000429243887758258) > > conj(sqrt(z)) = (0,-0.000429243887758258) > > > > This looks wrong. > > I can't reproduce this, I get: > > z = (-1.84250315177824e-07,-0) >pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258) > sqrt(z) = (0,-0.000429243887758258) > sqrt(conj(z)) = (0,0.000429243887758258) > conj(sqrt(z)) = (0,0.000429243887758258) My bet now comes to the fact there have been improvements to glibc which changed the behavior here Also I used the wrong term, it is the branch cut that is the issue. Most of the branch cuts were fixed in glibc in 2012; though there might have been some fixed later on.
[Bug target/90015] riscv: typo "intterupt" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90015 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-08 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 46101 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46101&action=edit gcc9-pr90015.patch Untested fix.
[Bug target/90016] New: aarch64: reference to undeclared N in help for command line option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90016 Bug ID: 90016 Summary: aarch64: reference to undeclared N in help for command line option Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From aarch64.opt: -msve-vector-bits= Set the number of bits in an SVE vector register to N. In a previous version, the text was "-msve-vector-bits=N", and in that version the "set to N" made sense. After changing the N to , the N refers to an undefined identifier.
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #16 from Steve Kargl ---
On Mon, Apr 08, 2019 at 07:20:22PM +, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
>
> --- Comment #13 from Jonathan Wakely ---
> (In reply to Steve Kargl from comment #10)
> > % g++8 -o z a.cpp -lm && ./z
> > z = (-1.84250315177824e-07,-0)
> >pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
> > sqrt(z) = (0,0.000429243887758258)
> > sqrt(conj(z)) = (0,0.000429243887758258)
> > conj(sqrt(z)) = (0,-0.000429243887758258)
> >
> > This looks wrong.
>
> I can't reproduce this, I get:
>
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
> sqrt(z) = (0,-0.000429243887758258)
> sqrt(conj(z)) = (0,0.000429243887758258)
> conj(sqrt(z)) = (0,0.000429243887758258)
>
My results are for i585-*-freebsd, which doesn't use glibc.
If Andrew is correct and a builtin is called, you might find
my results if you use -fno-builtins (check spelling).
Looking at ./libstdc++-v3/include/std/complex, one finds.
// 26.2.8/13 sqrt(__z): Returns the complex square root of __z.
// The branch cut is on the negative axis.
template
complex<_Tp>
__complex_sqrt(const complex<_Tp>& __z)
{
_Tp __x = __z.real();
_Tp __y = __z.imag();
if (__x == _Tp())
{
_Tp __t = sqrt(abs(__y) / 2);
return complex<_Tp>(__t, __y < _Tp() ? -__t : __t);
}
else
{
_Tp __t = sqrt(2 * (std::abs(__z) + abs(__x)));
_Tp __u = __t / 2;
return __x > _Tp()
? complex<_Tp>(__u, __y / __t)
: complex<_Tp>(abs(__y) / __t, __y < _Tp() ? -__u : __u);
}
}
Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 --- Comment #17 from Andrew Pinski --- >Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)? No, you missed this part: // The branch cut is on the negative axis. So maybe the bug is inside FreeBSD and Window's libm. Glibc fixed the branch cuts issues back in 2012 for csqrt but the other OS's did not change theirs.
[Bug c/448] -related issues (C99 issues)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 Eric Gallager changed: What|Removed |Added CC||coypu at sdf dot org --- Comment #43 from Eric Gallager --- (In reply to Eric Gallager from comment #39) > (In reply to jos...@codesourcery.com from comment #38) > > I think the correct state is NEW. There is a well-defined set of target > > OSes that lack the target macro definitions describing those targets' > > stdint.h types, each of which should be straightforward to fix for someone > > with access to the target OS in question to examine its headers and run > > tests. > > That's still these ones, right? > > (In reply to jos...@codesourcery.com from comment #31) > > The following targets still appear to be missing this type information in > > GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64), > > VxWorks, SymbianOS, LynxOS, QNX, TPF. Others have either been fixed, or > > obsoleted and removed. > > cc-ing maintainers of those ports coypu at sdf dot org seems to be a de facto maintainer for NetBSD these days so cc-ing them as well
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #18 from Steve Kargl ---
On Mon, Apr 08, 2019 at 08:03:36PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
>
> --- Comment #17 from Andrew Pinski ---
> >Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?
>
> No, you missed this part:
> // The branch cut is on the negative axis.
No, I didn't miss that part.
> So maybe the bug is inside FreeBSD and Window's libm. Glibc fixed the branch
> cuts issues back in 2012 for csqrt but the other OS's did not change theirs.
For the C++ code in comment, on x86_64-*-freebsd.
% g++8 -o z a.cpp -lm && ./z
z = (-1.84250315177824e-07,-0)
pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
sqrt(z) = (0,0.000429243887758258)
sqrt(conj(z)) = (0,0.000429243887758258)
conj(sqrt(z)) = (0,-0.000429243887758258)
The last two lines are definitely wrong.
troutmask:sgk[209] nm z | grep csqrt
troutmask:sgk[210] nm z | grep sqrt
0040156b W _ZSt14__complex_sqrtIdESt7complexIT_ERKS2_
0040143d W _ZSt4sqrtIdESt7complexIT_ERKS2_
U sqrt@@FBSD_1.0
There is no reference to csqrt in the exectuable. If I change
/usr/local/lib/gcc8/include/c++/complex to use copysign
to account for __y = -0 like
template
complex<_Tp>
__complex_sqrt(const complex<_Tp>& __z)
{
_Tp __x = __z.real();
_Tp __y = __z.imag();
if (__x == _Tp())
{
_Tp __t = sqrt(abs(__y) / 2);
// return complex<_Tp>(__t, __y < _Tp() ? -__t : __t);
return complex<_Tp>(__t, copysign(__t, __y));
}
else
{
_Tp __t = sqrt(2 * (std::abs(__z) + abs(__x)));
_Tp __u = __t / 2;
// return __x > _Tp()
//? complex<_Tp>(__u, __y / __t)
//: complex<_Tp>(abs(__y) / __t, __y < _Tp() ? -__u : __u);
return __x > _Tp()
? complex<_Tp>(__u, __y / __t)
: complex<_Tp>(abs(__y) / __t, copysign(__u, __y));
}
}
The C++ code in comment #10 gives
g++8 -o z a.cpp -lm && ./z
z = (-1.84250315177824e-07,-0)
pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
sqrt(z) = (0,-0.000429243887758258)
sqrt(conj(z)) = (0,0.000429243887758258)
conj(sqrt(z)) = (0,0.000429243887758258)
The correct answer. QED.
[Bug c/448] -related issues (C99 issues)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 --- Comment #44 from coypu --- (In reply to jos...@codesourcery.com from comment #31) > GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64), Speaking for NetBSD only: as of https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=253323 , we include netbsd-stdint.h for all netbsd targets.
[Bug fortran/90014] Untranslatable Fortran diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90014 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Dup. *** This bug has been marked as a duplicate of bug 89939 ***
[Bug translation/89939] messages for translation must not contain embedded macro parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89939 Dominique d'Humieres changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Dominique d'Humieres --- *** Bug 90014 has been marked as a duplicate of this bug. ***
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #19 from kargl at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #18)
> On Mon, Apr 08, 2019 at 08:03:36PM +, pinskia at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
> >
> > --- Comment #17 from Andrew Pinski ---
> > >Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?
> >
> > No, you missed this part:
> > // The branch cut is on the negative axis.
>
> No, I didn't miss that part.
>
> > So maybe the bug is inside FreeBSD and Window's libm. Glibc fixed the
> > branch
> > cuts issues back in 2012 for csqrt but the other OS's did not change theirs.
>
> For the C++ code in comment, on x86_64-*-freebsd.
>
> % g++8 -o z a.cpp -lm && ./z
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
> sqrt(z) = (0,0.000429243887758258)
> sqrt(conj(z)) = (0,0.000429243887758258)
> conj(sqrt(z)) = (0,-0.000429243887758258)
>
> The last two lines are definitely wrong.
>
> troutmask:sgk[209] nm z | grep csqrt
> troutmask:sgk[210] nm z | grep sqrt
> 0040156b W _ZSt14__complex_sqrtIdESt7complexIT_ERKS2_
> 0040143d W _ZSt4sqrtIdESt7complexIT_ERKS2_
> U sqrt@@FBSD_1.0
>
> There is no reference to csqrt in the exectuable. If I change
> /usr/local/lib/gcc8/include/c++/complex to use copysign
> to account for __y = -0 like
>
> template
> complex<_Tp>
> __complex_sqrt(const complex<_Tp>& __z)
> {
> _Tp __x = __z.real();
> _Tp __y = __z.imag();
>
> if (__x == _Tp())
> {
> _Tp __t = sqrt(abs(__y) / 2);
> // return complex<_Tp>(__t, __y < _Tp() ? -__t : __t);
> return complex<_Tp>(__t, copysign(__t, __y));
> }
> else
> {
> _Tp __t = sqrt(2 * (std::abs(__z) + abs(__x)));
> _Tp __u = __t / 2;
> // return __x > _Tp()
> //? complex<_Tp>(__u, __y / __t)
> //: complex<_Tp>(abs(__y) / __t, __y < _Tp() ? -__u : __u);
> return __x > _Tp()
> ? complex<_Tp>(__u, __y / __t)
> : complex<_Tp>(abs(__y) / __t, copysign(__u, __y));
> }
> }
>
>
> The C++ code in comment #10 gives
>
> g++8 -o z a.cpp -lm && ./z
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
> sqrt(z) = (0,-0.000429243887758258)
> sqrt(conj(z)) = (0,0.000429243887758258)
> conj(sqrt(z)) = (0,0.000429243887758258)
>
> The correct answer. QED.
BTW, if change /usr/local/lib/gcc8/include/c++/complex back to
no using copysign(), and instead change
#if _GLIBCXX_USE_C99_COMPLEX
inline __complex__ float
__complex_sqrt(__complex__ float __z) { return __builtin_csqrtf(__z); }
to
#if _GLIBCXX_USE_C99_COMPLEX || SOMETHING_UGLY
inline __complex__ float
__complex_sqrt(__complex__ float __z) { return __builtin_csqrtf(__z); }
and do
g++8 -DSOMETHING_UGLY -o z a.cpp -lm && ./z
z = (-1.84250315177824e-07,-0)
pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
sqrt(z) = (0,-0.000429243887758258)
sqrt(conj(z)) = (0,0.000429243887758258)
conj(sqrt(z)) = (0,0.000429243887758258)
I get the expected. So, if you're on a system that has
_GLIBCXX_USE_C99_COMPLEX, you won't see the bug.
It is likely that everywhere that a construct of the
form __y < _Tp() ? -__u : __u appear, it needs to use
copysign.
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #20 from Jonathan Wakely ---
(In reply to Steve Kargl from comment #16)
> If Andrew is correct and a builtin is called,
Wasn't that me, not Andrew?
> you might find
> my results if you use -fno-builtins (check spelling).
No, same results. Calling __builtin_csqrt doesn't necessarily mean GCC
evaluates it. Without optimisation it still generates a call to csqrt from
libc.
> Looking at ./libstdc++-v3/include/std/complex, one finds.
>
> // 26.2.8/13 sqrt(__z): Returns the complex square root of __z.
> // The branch cut is on the negative axis.
> template
> complex<_Tp>
> __complex_sqrt(const complex<_Tp>& __z)
> {
> _Tp __x = __z.real();
> _Tp __y = __z.imag();
>
> if (__x == _Tp())
> {
> _Tp __t = sqrt(abs(__y) / 2);
> return complex<_Tp>(__t, __y < _Tp() ? -__t : __t);
> }
> else
> {
> _Tp __t = sqrt(2 * (std::abs(__z) + abs(__x)));
> _Tp __u = __t / 2;
> return __x > _Tp()
> ? complex<_Tp>(__u, __y / __t)
> : complex<_Tp>(abs(__y) / __t, __y < _Tp() ? -__u : __u);
> }
> }
>
> Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?
Yes, but that code shouldn't be used for modern targets ...
(In reply to kargl from comment #19)
> I get the expected. So, if you're on a system that has
> _GLIBCXX_USE_C99_COMPLEX, you won't see the bug.
Wow, why isn't libstdc++ using the C99 functions on FreeBSD?
I'll have to look into that.
> It is likely that everywhere that a construct of the
> form __y < _Tp() ? -__u : __u appear, it needs to use
> copysign.
That won't always work, because the generic functions should really only get
used when _Tp is not one of float, double or long double. And in that case
there might be no copysign for the type.
For float, double and long double we should be using the libc routines. So the
bug is that FreeBSD isn't using them.
The _original_ bug report is for std::pow though, and on Ubuntu, which does use
glibc. Comment 9 needs more analysis.
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 --- Comment #21 from kargl at gcc dot gnu.org --- Created attachment 46102 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46102&action=edit fix g++ problem with sqrt(z) where z is complex and imag(z) = -0
[Bug d/88150] Use sections_elf_shared.d on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150
--- Comment #10 from Iain Buclaw ---
I've got a (horrible?) hack for getting tls_modid from Solaris.
Looking at dlinfo(RTLD_DI_LINKMAP):
https://github.com/illumos/illumos-gate/blob/4e0c5eff9af325c80994e9527b7cb8b3a1ffd1d4/usr/src/cmd/sgs/rtld/common/dlfcns.c#L1927-L1934
The lmp variable returned is originally an Rt_map*, layout is:
---
struct Rt_map
{
Link_map rt_public;
const char* rt_pathname;
c_ulong rt_padstart;
c_ulong rt_padimlen;
c_ulong rt_msize;
uint rt_flags;
uint rt_flags1;
c_ulong rt_tlsmodid;
}
---
Let's do a little test...
---
case PT_TLS: // TLS segment
assert(!pdso._tlsSize); // is unique per DSO
static if (OS_Have_Dlpi_Tls_Modid)
{
pdso._tlsMod = info.dlpi_tls_modid;
pdso._tlsSize = phdr.p_memsz;
}
else version (Solaris)
{
Rt_map* map;
version (Shared)
dlinfo(handleForName(info.dlpi_name), RTLD_DI_LINKMAP, &map);
else
dlinfo(RTLD_SELF, RTLD_DI_LINKMAP, &map);
pdso._tlsMod = map.rt_tlsmodid;
pdso._tlsSize = phdr.p_memsz;
}
else
{
pdso._tlsMod = 0;
pdso._tlsSize = 0;
}
break;
---
Inspecting this in gdb
---
(gdb) p map
$1 = (struct Rt_map *) 0xfedb001
(gdb) p *map
$2 = {rt_public = {l_addr = 4275896320,
l_name = 0xfc0f02e4
"/mnt/build/i386-pc-solaris2.11/./libphobos/libdruntime/.libs/libgdruntime.so.76",
l_ld = 0xfedd00d4, l_next = 0xfedb0678, l_prev = 0xfef206c8, l_refname = 0x0},
rt_pathname = 0xfc0f0334
"/mnt/build/i386-pc-solaris2.11/libphobos/libdruntime/.libs/libgdruntime.so.76.0.3",
rt_padstart = 4275896320, rt_padimlen = 1272912, rt_msize = 1272912, rt_flags =
272761348,
rt_flags1 = 1155, rt_tlsmodid = 2}
---
And there it is, a valid rt_tlsmodid.
Interestingly, Solaris sets the first tlsmodid to zero.
https://github.com/illumos/illumos-gate/blob/8a06b3d6467c15646e663c05086378f16288af85/usr/src/cmd/sgs/rtld/common/tls.c#L52-L60
This is in stark contrast to what elf_shared expects, given that there's an
assert that it is always non-zero if _tlsSize is set.
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 --- Comment #22 from Steve Kargl --- On Mon, Apr 08, 2019 at 10:17:00PM +, redi at gcc dot gnu.org wrote: > (In reply to kargl from comment #19) > > I get the expected. So, if you're on a system that has > > _GLIBCXX_USE_C99_COMPLEX, you won't see the bug. > > Wow, why isn't libstdc++ using the C99 functions on FreeBSD? > Because it is all or nothing. See comment #8 and #9 in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 If you're too busy to look at PR89125 the upshot is that FreeBSD is missing ccoshl, ccosl, cexpl, csinhl, csinl, ctanhl, and ctanl. I have BSD licensed versions of ccoshl, ccosl, cexpl, csinhl, and csinl, but testing on FreeBSD ran into what I consider to be a very bad bug in clang (FreeBSD system compiler).
[Bug d/88150] Use sections_elf_shared.d on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Iain Buclaw --- > I've got a (horrible?) hack for getting tls_modid from Solaris. Cool, and not really horrible ;-) It's already this way in Solaris 9 (I happen to have access to those sources and just checked), so we can assume this is stable. > Looking at dlinfo(RTLD_DI_LINKMAP): > > https://github.com/illumos/illumos-gate/blob/4e0c5eff9af325c80994e9527b7cb8b3a1ffd1d4/usr/src/cmd/sgs/rtld/common/dlfcns.c#L1927-L1934 I missed that because I initially looked only at public headers for tlsmodid, and Rt_map is private to ld.so.1. This is intentionally missing from dlinfo(3C), too. I only found it in 's rd_loadobj_t, but it seemed hard to apply librtld_db to the current process instead of one being debugged... > Interestingly, Solaris sets the first tlsmodid to zero. > > https://github.com/illumos/illumos-gate/blob/8a06b3d6467c15646e663c05086378f16288af85/usr/src/cmd/sgs/rtld/common/tls.c#L52-L60 > > This is in stark contrast to what elf_shared expects, given that there's an > assert that it is always non-zero if _tlsSize is set. Right: 0 had been used for the tlsmodid of the main executable until dlpi_tls_modid was added to dl_phdr_info for Solaris 11.5 (still in beta) when this would-be incompatibility with the Linux and BSD versions was noticed. It was only changed to 1 once it could be determined that it was safe to do so.
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834 --- Comment #12 from kugan at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #10) > (In reply to kugan from comment #9) > > Created attachment 46040 [details] > > patch > > Wasn't sure whether this patch was WIP or the final version > for review, but we need to do something more generic than > dividing by 4. I think the test will still fail with "int" > changed to "short" for example. > > I also don't think the new candidate should be tied to the > mask/load store functions. Maybe one approach would be to > check when adding a zero-based candidate for a use in: > > /* Record common candidate with initial value zero. */ > basetype = TREE_TYPE (iv->base); > if (POINTER_TYPE_P (basetype)) > basetype = sizetype; > record_common_cand (data, build_int_cst (basetype, 0), iv->step, use); > > whether the use actually benefits from this unscaled iv. > If the use is USE_REF_ADDRESS, we could compare the cost > of an address with an unscaled index with the cost of an address > with a scaled index. I think the natural scale value to try > would be GET_MODE_INNER (TYPE_MODE (mem_type)). Thanks for the comments. I agree this is the right place. But I am not sure if checking the cost at this point is what IV opt generally does. In general, IV-opt adds candidates which can be helpful and later decides the optimal set. If we are to use get_computation_cost to see the costs, we have to create iv_cand and then discard. Since we are adding only one candidate and that too for SVE like targets, I am thinking that it is OK. If you still prefer to check the cost, I will change that. Attached patch (only the ivopt changes) and testcase
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834 kugan at gcc dot gnu.org changed: What|Removed |Added Attachment #46040|0 |1 is obsolete|| --- Comment #13 from kugan at gcc dot gnu.org --- Created attachment 46103 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46103&action=edit ivopt changes alone
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834 --- Comment #14 from kugan at gcc dot gnu.org --- Created attachment 46104 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46104&action=edit testcase
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 --- Comment #23 from kargl at gcc dot gnu.org --- Created attachment 46105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46105&action=edit fix g++ problem with pow(z,0.5) where imag(z) = -0. This patch has only been tested with the original test provided by the reporter.
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834 --- Comment #15 from kugan at gcc dot gnu.org --- (In reply to Wilco from comment #11) > There is also something odd with the way the loop iterates, this doesn't > look right: > > whilelo p0.s, x3, x4 > incwx3 > ptest p1, p0.b > bne .L3 I am not sure I understand this. I tried with qemu using an execution testcase and It seems to work. whilelo p0.s, x4, x5 incwx4 ptest p1, p0.b bne .L3 In my case I have the above (register allocation difference only) incw is correct considering two vector word registers? Am I missing something here?
[Bug debug/90017] New: gcc generates wrong debug information at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90017
Bug ID: 90017
Summary: gcc generates wrong debug information at -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It seems to be a recent regression, starting at r269302.
It only affects "-O3" and trunk.
The correct value is "l=0". With -O3, it generates l=8.
$ gcc-trunk -v
gcc version 9.0.1 20190408 (experimental) [trunk revision 270202] (GCC)
#correct output#
$ gcc-trunk -g abc.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4004a5: file abc.c, line 15.
Breakpoint 1, main () at abc.c:15
15optimize_me_not();
$1 = 0
#wrong output#
$ gcc-trunk -g abc.c -O3
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400470: file abc.c, line 15.
Breakpoint 1, main () at abc.c:15
15optimize_me_not();
$1 = 8
$ cat abc.c
__attribute__((noipa)) optimize_me_not(){
__asm__ volatile ("" : : : "memory");
}
int a, b;
int c[][2] = {{2}, {5}, 2};
int main() {
{
int l;
for (; b <= 1; b++) {
l = 0;
for (; l <= 8; l++) {
a ^= c[b + 1][b];
if (a)
optimize_me_not();
}
}
}
}
$ cat cmds
b 15
r
p l
k
q
[Bug tree-optimization/90018] New: [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90018 Bug ID: 90018 Summary: [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017 Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: rguenther at suse dot de Target Milestone: --- On x86-64 with AVX512, r265453 miscompiled 527.cam4_r in SPEC CPU 2017 with: -march=native -Ofast -funroll-loops 527.cam4_r segfaults immediately. GCC 7 branch and master branch are OK.
[Bug target/90015] riscv: typo "intterupt" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90015 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #2 from Jim Wilson --- I tested Jakub's patch with 32-bit elf and 64-bit linux cross compilers. There were no regressions. The patch is OK.
[Bug middle-end/89977] missing -Wstringop-overflow with an out-of-bounds int128_t range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977 --- Comment #5 from JunMa --- (In reply to Martin Sebor from comment #4) > You're right that the conversion from int128_t to unsigned long can result > in truncation, so the range of the result is that of unsigned long. Yet I > suspect that relying on it is more likely unintentional and a bug. The > question in my mind is whether narrowing int128_t conversions should be > diagnosed just in these contexts (i.e., -Wstringop-overflow) or in others as > well. We have no idea whether these truncations is intentional or not in gcc side, maybe we need a new option such as Wstringop-truncation to do this.
[Bug c++/90019] New: [8 regression] Bogus ambiguous overload error for NTTP pack of disjoint enable_ifs unless there is an unsupplied default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90019
Bug ID: 90019
Summary: [8 regression] Bogus ambiguous overload error for NTTP
pack of disjoint enable_ifs unless there is an
unsupplied default argument
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
This code compiles fine with 7 and trunk but fails with gcc8:
https://godbolt.org/z/v1HN8B
#include
// gcc8 thinks these are ambiguous for <0>
template ...> void foo(){}
template ...> void foo(){}
// but somehow these arn't for <0>, but are for <0,0> !?
template ...> void bar(){}
template ...> void bar(){}
void test() {
bar<0>(); // works
bar<0,0>(); // boom
foo<0>(); // boom
}
[Bug tree-optimization/90020] New: [8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020
Bug ID: 90020
Summary: [8 regression] -O2 -Os x86-64 wrong code generated for
GNU Emacs
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
Created attachment 46106
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46106&action=edit
source code illustrating the bug
In:
https://lists.gnu.org/r/emacs-devel/2019-04/msg00209.html
Madhu reports several crashes when compiling applications with 'gcc -O2 -Os' on
x86-64. Madhu isolated the example to a crash with GNU Emacs, and I narrowed
this down to 'gcc -O2 -Os' generating incorrect code for Emacs. I further
narrowed it down to the attached file x.i. I used gcc 8.3.1 20190223 (Red Hat
8.3.1-2) on x86-64 to compile it like this:
gcc -O2 -Os -S x.i
and am attaching a copy of the input x.i and the output x.s. GCC miscompiled
the subroutine 'select_window'. The source code looks like this:
Lisp_Object
select_window (Lisp_Object window)
{
CHECK_TYPE (WINDOWP (window) && BUFFERP (XWINDOW (window)->contents),
builtin_lisp_symbol (1214), window);
struct window *w = XWINDOW (window);
return w->contents;
}
but the assembly language looks like this:
select_window:
pushq %rbp
pushq %rbx
movq%rdi, %rbx
pushq %rcx
callWINDOWP
movq3(%rbx), %rbp
...
and that last movq is incorrect, because it dereferences %rbx ('window' in the
source code) even though it is not known whether WINDOWP returned true. In the
source code, if WINDOWP(window) returns false then 'window' is never used
except as an undereferenced pointer value, and it is possible for
WINDOWP(window) to return false without dereferencing 'window' so it is not
safe for the caller to assume that 'window' is dereferenceable. The incorrect
code causes GCC to dump core.
This problem does not occur with GCC 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04).
Madhu observed the problem with GCC 8.2 so I suspect the problem was introduced
in GCC 8.
I don't know which GCC component is causing the problem and am guessing
tree-optimization.
[Bug tree-optimization/90020] [8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020 --- Comment #1 from eggert at cs dot ucla.edu --- Created attachment 46107 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46107&action=edit gcc -O2 -Os compiled output for x86-64 The attached x.s file shows the incorrect generated code, compiled with gcc -O2 -Os.
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #40 from Jürgen Reuter --- Are there any news on this?
[Bug tree-optimization/90018] [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90018 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-09 Target Milestone|--- |8.4 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- r265452, which was backported to GCC 8 as r265453, caused the same failure on trunk.
[Bug tree-optimization/90018] [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90018 --- Comment #2 from H.J. Lu --- On trunk, r265457 fixed 527.cam4_r in SPEC CPU 2017 with: -march=native -Ofast -funroll-loops
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #41 from Iain Sandoe --- inconclusive so far, it's agreed that _Atomic is not a C++ keyword, but not clear what is best solution to the SDK use. If you filed a radar, please copy the number here (no-one else can see it, but at least we can point the Apple devs to it - so they can look internally).
[Bug d/90012] untranslateable placeholder in expressionsem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90012 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- It was the fault of the pot generator (well me I guess) that these sources got picked up in the first place. They are no longer part of gcc.pot. I don't know how this gets merged into each individual .po, but they should not be present anymore.
[Bug d/90013] wrong quotes in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90013 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- It was the fault of the pot generator (well me I guess) that these sources got picked up in the first place. They are no longer part of gcc.pot. I don't know how this gets merged into each individual .po, but they should not be present anymore.
[Bug tree-optimization/90021] New: [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021 Bug ID: 90021 Summary: [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- I see following ICE: $ cat ice.f90 MODULE a INTEGER b CONTAINS SUBROUTINE bar(c) REAL c(1) INTEGER d, e, f DO g = 1,3 DO f = 1,1 DO e = 1,3 DO d = 1,1 c(f-1+d) = c(f-1+d)*b END DO END DO END DO END DO END END $ gcc ice.f90 -fno-tree-loop-ivcanon -O1 -floop-interchange -fno-tree-ccp -fno-tree-ch -fipa-pta -c ice.f90:7:7: 7 | DO g = 1,3 | 1 Warning: Deleted feature: Loop variable at (1) must be integer during GIMPLE pass: linterchange ice.f90:4:0: 4 | SUBROUTINE bar(c) | internal compiler error: in index_in_loop_nest, at tree-data-ref.h:587 0x78219b index_in_loop_nest /home/marxin/Programming/gcc/gcc/tree-data-ref.h:587 0x7837a7 index_in_loop_nest /home/marxin/Programming/gcc/gcc/tree.h:3176 0x7837a7 add_multivariate_self_dist /home/marxin/Programming/gcc/gcc/tree-data-ref.c:4392 0x7837a7 add_other_self_distances /home/marxin/Programming/gcc/gcc/tree-data-ref.c:4445 0x7837a7 build_classic_dist_vector /home/marxin/Programming/gcc/gcc/tree-data-ref.c:4565 0x7837a7 subscript_dependence_tester /home/marxin/Programming/gcc/gcc/tree-data-ref.c:4798 0x7837a7 compute_affine_dependence(data_dependence_relation*, loop*) /home/marxin/Programming/gcc/gcc/tree-data-ref.c:4853 0x156cf48 tree_loop_interchange_compute_ddrs /home/marxin/Programming/gcc/gcc/gimple-loop-interchange.cc:1855 0x156cf48 prepare_perfect_loop_nest /home/marxin/Programming/gcc/gcc/gimple-loop-interchange.cc:2031 0x156cf48 execute /home/marxin/Programming/gcc/gcc/gimple-loop-interchange.cc:2072 0x156cf48 execute /home/marxin/Programming/gcc/gcc/gimple-loop-interchange.cc:2060
[Bug tree-optimization/90021] [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed||2019-4-9 CC||amker at gcc dot gnu.org Known to work||8.3.0 Target Milestone|--- |9.0 Known to fail||9.0
[Bug tree-optimization/90021] [9 Regression] ICE in index_in_loop_nest, at tree-data-ref.h:587 since r270203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021 --- Comment #1 from bin cheng --- Sorry for the breakage, I will have a look.
[Bug target/90015] riscv: typo "intterupt" in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90015 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Apr 9 06:38:07 2019 New Revision: 270221 URL: https://gcc.gnu.org/viewcvs?rev=270221&root=gcc&view=rev Log: PR target/90015 * config/riscv/riscv.c (riscv_get_interrupt_type): Fix comment typo. (riscv_merge_decl_attributes): Fix typo in diagnostics. Remove trailing period from it too. * gcc.target/riscv/interrupt-conflict-mode.c (foo): Adjust expected diagnostics. Modified: trunk/gcc/ChangeLog trunk/gcc/config/riscv/riscv.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/riscv/interrupt-conflict-mode.c
[Bug tree-optimization/90020] [8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Let me take a look.
[Bug fortran/90022] New: Issue with CFI_is_contigous and CFI base address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90022 Bug ID: 90022 Summary: Issue with CFI_is_contigous and CFI base address Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: pault at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- See https://gcc.gnu.org/ml/fortran/2019-04/msg00013.html for the issue and a testcase. Paul
[Bug fortran/90022] Issue with CFI_is_contigous and CFI base address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90022 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-09 Ever confirmed|0 |1 --- Comment #1 from Paul Thomas --- I will be submitting a patch for this shortly. Paul
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #33 from 康 珊 ---
(In reply to Martin Liška from comment #32)
> I can confirm it works for me with:
>
> diff --git a/common.gypi b/common.gypi
> index 9502e92..3d8f04f 100644
> --- a/common.gypi
> +++ b/common.gypi
> @@ -195,8 +195,8 @@
> 'ldflags': ['<(pgo_use)'],
>},],
>['enable_lto=="true"', {
> -'cflags': ['<(lto)'],
> -'ldflags': ['<(lto)'],
> +'cflags': ['<(lto) -fno-strict-aliasing'],
> +'ldflags': ['<(lto) -fno-strict-aliasing'],
>},],
> ],
>},],
It seems your solution works. But it doesn't work if I add
"-fno-strict-aliasing" through 'export CFLAGS="$CFLAGS -O3
-fno-strict-aliasing..." export CXXFLAGS="$CXXFLAGS -O3
-fno-strict-aliasing..." ...', maybe they are overridden. Thank you very much
for your help.
