Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support
On Wed, Dec 26, 2018 at 7:39 AM Cherry Zhang wrote:
>
> Finally I found an ARM machine and was able to build ARM32 gcc on it, and
> reproduced the failures. The Go programs aborted, in parse_lsda_header,
> called from probestackmaps in the runtime startup. It seems that
> _Unwind_GetLanguageSpecificData doesn't return a valid LSDA when called from
> a callback from _Unwind_Backtrace.
>
> Reading the unwinder's source code in libgcc, it seems that a function may
> have a "predefined" personality function, and in this case an ARM-specific
> "compact" model is used, which doesn't use the standard LSDA.
> _Unwind_GetLanguageSpecificData doesn't distinguish this and simply assumes
> the "generic" model is used, i.e. not used with a "predefined" personality
> function. This works fine if _Unwind_GetLanguageSpecificData is called from a
> non-predefined personality function, but it doesn't work if it is called
> during _Unwind_Backtrace.
>
> The patch below (also CL
> https://go-review.googlesource.com/c/gofrontend/+/155758) will fix the
> problem, by checking which model is used before calling
> _Unwind_GetLanguageSpecificData.
>
> Alternatively, we could change _Unwind_GetLanguageSpecificData in libgcc to
> returning NULL when a predefined personality function is used.
>
> Let me know what you think.
>
> Thanks,
> Cherry
>
> diff --git a/libgo/runtime/go-unwind.c b/libgo/runtime/go-unwind.c
> index f4bbfb60..388d7c70 100644
> --- a/libgo/runtime/go-unwind.c
> +++ b/libgo/runtime/go-unwind.c
> @@ -646,6 +646,17 @@ findstackmaps (struct _Unwind_Context *context,
> _Unwind_Ptr *ip, _Unwind_Ptr *sp
>_sleb128_t index;
>int size;
>
> +#ifdef __ARM_EABI_UNWINDER__
> + {
> +_Unwind_Control_Block *ucbp;
> +ucbp = (_Unwind_Control_Block *) _Unwind_GetGR (context, 12);
> +if (*ucbp->pr_cache.ehtp & (1u << 31))
> + // The "compact" model is used, with one of the predefined
> + // personality functions. It doesn't have standard LSDA.
> + return NOTFOUND_OK;
> + }
> +#endif
> +
>language_specific_data = (const unsigned char *)
> _Unwind_GetLanguageSpecificData (context);
>
Thanks.
Committed to mainline.
Ian
Re: [PATCH/AARCH64] Add OcteonTX for -mcpu=
On Fri, Nov 2, 2018 at 4:06 AM Richard Earnshaw (lists)
wrote:
>
> On 01/11/2018 01:52, Andrew Pinski wrote:
> > On Tue, Oct 30, 2018 at 10:21 AM Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 30/10/2018 17:06, Andrew Pinski wrote:
> >>> Hi all,
> >>> There was a name change of the Products, ThunderX T81 and ThunderX
> >>> T83 to OcteonTX family name. This change was done a few years ago but
> >>> I had not submmitted the change at that time. This is also the first
> >>> patch in a series to add OcteonTX 2 support to GCC.
> >>>
> >>> OK? Bootstrapped and tested on aarch64-linux-gnu with no regression.
> >>>
> >>
> >> You're missing a documentation update.
> >
> > Oops. I knew I missed that too.
> > Here is the updated patch with the doc update included.
> >
> > Thanks,
> > Andrew Pinski
> >
> > gcc/ChangeLog:
> > * config/aarch64/aarch64-cores.def (octeontx): New.
> > (octeontx81): Likewise.
> > (octeontx83): Likewise.
> > * config/aarch64/aarch64-tune.md: Regenerate.
> > * doc/invoke.texi (AArch64 Options) [mtune]: Add octeontx, octeontx81
> > and octeontx83.
> >
>
> OK.
This was what I committed finally. Update for the new cores that was
added after my previous patch.
Thanks,
Andrew Pinski
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 267426)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2018-12-26 Andrew Pinski
+
+ * config/aarch64/aarch64-cores.def (octeontx): New.
+ (octeontx81): Likewise.
+ (octeontx83): Likewise.
+ * config/aarch64/aarch64-tune.md: Regenerate.
+ * doc/invoke.texi (AArch64 Options) [mtune]: Add octeontx, octeontx81
+ and octeontx83.
+
2018-12-24 Martin Sebor
* gimple-fold.c (get_range_strlen_tree): Factored out of
Index: gcc/config/aarch64/aarch64-cores.def
===
--- gcc/config/aarch64/aarch64-cores.def(revision 267426)
+++ gcc/config/aarch64/aarch64-cores.def(working copy)
@@ -58,6 +58,12 @@
this order is required to handle variant correctly. */
AARCH64_CORE("thunderxt88p1", thunderxt88p1, thunderx, 8A,
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO,thunderxt88,
0x43, 0x0a1, 0)
AARCH64_CORE("thunderxt88", thunderxt88, thunderx, 8A,
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderxt88, 0x43,
0x0a1, -1)
+
+/* OcteonTX is the official name for T81/T83. */
+AARCH64_CORE("octeontx", octeontx, thunderx, 8A,
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx, 0x43,
0x0a0, -1)
+AARCH64_CORE("octeontx81",octeontxt81, thunderx, 8A,
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx, 0x43,
0x0a2, -1)
+AARCH64_CORE("octeontx83",octeontxt83, thunderx, 8A,
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx, 0x43,
0x0a3, -1)
+
AARCH64_CORE("thunderxt81", thunderxt81, thunderx, 8A,
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx, 0x43,
0x0a2, -1)
AARCH64_CORE("thunderxt83", thunderxt83, thunderx, 8A,
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx, 0x43,
0x0a3, -1)
Index: gcc/config/aarch64/aarch64-tune.md
===
--- gcc/config/aarch64/aarch64-tune.md (revision 267426)
+++ gcc/config/aarch64/aarch64-tune.md (working copy)
@@ -1,5 +1,5 @@
;; -*- buffer-read-only: t -*-
;; Generated automatically by gentune.sh from aarch64-cores.def
(define_attr "tune"
-
"cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,ares,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
+
"cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,ares,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 267426)
+++ gcc/doc/invoke.texi (working copy)
@@ -15638,6 +15638,7 @@
@samp{cortex-a57}, @samp{cortex-a72}, @samp{cortex-a73}, @samp{cortex-a75},
@samp{cortex-a76}, @samp{ares}, @samp{exynos-m1}, @samp{emag}, @samp{falkor},
@samp{qdf24xx}, @samp{saphira}, @samp{phecda}, @samp{xgene1}, @samp{vulcan},
+@samp{octeontx}, @samp{octeontx81}, @samp{octeontx83},
@samp{thunderx}, @samp{thunderxt88}, @samp{thunderxt88p1},
Re: [PATCH][Arm] Fix FPU configurations for Cortex-R7 and Cortex-R8
On Wed, 28 Nov 2018, Andre Vieira (lists) wrote: > Here are the documentation bits I forgot, I've also opened PR 88224 in > bugzilla for this issue. > > Is this OK for trunk and gcc-8 backport? > > gcc/ChangeLog: > 2018-11-28 Andre Vieira > > PR target/88224 > * config/arm/arm-cpus.in (armv7-r): Add FP16conv configurations. > (cortex-r7, cortex-r8): Update default and add new configuration. > * doc/invoke.texi (armv7-r): Add two new vfp options. > (nofp.dp): Add cortex-r7 and cortex-r8 to the list of targets that > support this option. Should this be covered in the GCC 9 release notes at https://gcc.gnu.org/gcc-9/changes.html ? (See https://gcc.gnu.org/about.html for how to go about web changes.) Gerald
Re: [PATCH][GCC][DOC] Remove obsolete arm and aarch64 CPU names from invoke.texi
On Fri, 23 Nov 2018, Sam Tebbs wrote: > The mtune= documentation in doc/invoke.texi contains some obsolete CPU names > that have been removed from the Arm and AArch64 backends. This patch removes > them. I believe this should also be covered in the GCC 9 release notes at https://gcc.gnu.org/gcc-9/changes.html ? (See https://gcc.gnu.org/about.html for how to go about web changes.) Gerald
[Committed] PR fortran/85357 -- add testcase
After reviewing the PR audit trail, I agree with Janus'
comments #4 and #6, and I have converted his code example
in comment #7 to the committed testcase. The originally
reported ICE is gone on trunk, branch-7, and branch-8.
However, branch-7 and branch-8, the compilation terminates with
(null):0: confused by earlier errors, bailing out
That (null) was the original source of the ICE, but the error
machinery now protects against NULL pointer references.
2018-12-26 Steven G. Kargl
PR fortran/85357
* gfortran.df/pr85357.f90: New test.
--
Steve
Index: gcc/testsuite/gfortran.dg/pr85357.f90
===
--- gcc/testsuite/gfortran.dg/pr85357.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr85357.f90 (working copy)
@@ -0,0 +1,17 @@
+! { dg-do compile }
+module base
+ implicit none
+contains
+ subroutine summation(i)
+ integer, intent(in) :: i
+ end subroutine
+end module
+
+module extended
+ use base
+ implicit none
+contains
+ subroutine summation() ! { dg-error "is already defined" }
+ end subroutine ! { dg-error "Expecting END MODULE statement" }
+end module
+! { dg-prune-output "is already defined at" }
[Committed] PR fortran/85407 -- convert assert to fatal error
Back in April, I told Harald I would get around to committing
the attached patch. Well, "around" has arrived. The patch
has been tested on i586-*-freebsd and x86_64-*-freebsd.
The patch converts an assert into a gfc_fatal_error(), which
gives a user some information about the failure. There is
no testcase as one need to go out of one's way to corrupt
the components in a derived typed in a *.mod file.
2018-12-26 Harald Anlauf
PR fortran/85407
* module.c (read_module): Convert assert to fatal error to give
user a sensible error message.
--
Steve
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c (revision 267418)
+++ gcc/fortran/module.c (working copy)
@@ -5180,7 +5180,13 @@ read_module (void)
if (p->u.pointer == NULL)
associate_integer_pointer (p, c);
mio_pool_string (_name);
- gcc_assert (comp_name == c->name);
+ if (comp_name != c->name)
+ {
+ gfc_fatal_error ("Mismatch in components of derived type "
+ "%qs from %qs at %C: expecting %qs, "
+ "but got %qs", sym->name, sym->module,
+ c->name, comp_name);
+ }
skip_list (1); /* component end. */
}
mio_rparen (); /* component list closing. */
Re: [PATCH] Don't run ident tests on powerpc-darwin
> On 26 Dec 2018, at 16:07, David Edelsohn wrote:
>
> On Sun, Dec 23, 2018 at 6:16 AM Iain Sandoe wrote:
>>
>> Hi
>>
>> The c-c++-common tests fail (or XPASS depending on which) on Darwin
>> because it doesn't currently emit .ident marker.
>>
>> For powerpc darwin (and, I think, AIX - hence copying David), there’s no
>> .ident support in the assembler, and we need to skip the tests.
>>
>> In this case, I suggest that it’s not worth having a target-supports entry.
>> This is because what a target chooses to emit for -fident is controlled by
>> a target hook and therefore there’s no guarantee that a target-supports
>> that triggers off “ .ident” in the asm would be generically useful.
>>
>> OTOH, if the testsuite maintainers prefer a support .. it can be done ;-)
>>
>> OK for trunk?
>> Iain
>>
>> gcc/testsuite/
>>
>>* c-c++-common/ident-0a.c: Skip for powerpc-darwin.
>>* c-c++-common/ident-0b.c: Likewise.
>>* c-c++-common/ident-1a.c: Likewise.
>>* c-c++-common/ident-1b.c: Likewise.
>>* c-c++-common/ident-2a.c: Likewise.
>>* c-c++-common/ident-2b.c: Likewise.
>
> AIX Assembler doesn't support "ident", but GCC doesn't emit an "ident"
> string on AIX. The failure on AIX is the assembler output doesn't
> match the expected result, but it doesn't fail to assemble due to an
> unrecognized pseudo-op.
Right that’s the cause of the XPASSes and FAILs respectively.
>
> Does GCC generate an ident pseudo-op on Darwin?
> Maybe because of
> common code inherited by Darwin that defines TARGET_ASM_OUTPUT_IDENT.
no that is disabled there too.
Darwin was not trying to emit the .ident (TARGET_ASM_OUTPUT_IDENT was
undefined).
That leads to the effect noted above. Since the assembler doesn’t support
.ident we can’t fix the tests by adding TARGET_ASM_OUTPUT_IDENT, so I’ve
skipped them.
If, one day, we fix the assembler to accept .ident (or use a more modern one
that already does) then those skip lines can be removed.
> I had been testing an expected fail for those tests on AIX, e.g.,
Ah, that might be an alternate scheme, indeed. However, for now (on Darwin) I
just settled for the simple one.
Iain
>
> Index: ident-2b.c
> ===
> --- ident-2b.c (revision 267421)
> +++ ident-2b.c (working copy)
> @@ -5,4 +5,4 @@
> /* { dg-skip-if "no assembler .ident support" { powerpc*-*-darwin* } } */
> int ident;
>
> -/* { dg-final { scan-assembler-times "GCC: " 1 } } */
> +/* { dg-final { scan-assembler-times "GCC: " 1 { xfail
> powerpc-ibm-aix* } } } */
>
> Thanks, David
Re: [PATCH] Don't run ident tests on powerpc-darwin
On Sun, Dec 23, 2018 at 6:16 AM Iain Sandoe wrote:
>
> Hi
>
> The c-c++-common tests fail (or XPASS depending on which) on Darwin
> because it doesn't currently emit .ident marker.
>
> For powerpc darwin (and, I think, AIX - hence copying David), there’s no
> .ident support in the assembler, and we need to skip the tests.
>
> In this case, I suggest that it’s not worth having a target-supports entry.
> This is because what a target chooses to emit for -fident is controlled by
> a target hook and therefore there’s no guarantee that a target-supports
> that triggers off “ .ident” in the asm would be generically useful.
>
> OTOH, if the testsuite maintainers prefer a support .. it can be done ;-)
>
> OK for trunk?
> Iain
>
> gcc/testsuite/
>
> * c-c++-common/ident-0a.c: Skip for powerpc-darwin.
> * c-c++-common/ident-0b.c: Likewise.
> * c-c++-common/ident-1a.c: Likewise.
> * c-c++-common/ident-1b.c: Likewise.
> * c-c++-common/ident-2a.c: Likewise.
> * c-c++-common/ident-2b.c: Likewise.
AIX Assembler doesn't support "ident", but GCC doesn't emit an "ident"
string on AIX. The failure on AIX is the assembler output doesn't
match the expected result, but it doesn't fail to assemble due to an
unrecognized pseudo-op.
Does GCC generate an ident pseudo-op on Darwin? Maybe because of
common code inherited by Darwin that defines TARGET_ASM_OUTPUT_IDENT.
I had been testing an expected fail for those tests on AIX, e.g.,
Index: ident-2b.c
===
--- ident-2b.c (revision 267421)
+++ ident-2b.c (working copy)
@@ -5,4 +5,4 @@
/* { dg-skip-if "no assembler .ident support" { powerpc*-*-darwin* } } */
int ident;
-/* { dg-final { scan-assembler-times "GCC: " 1 } } */
+/* { dg-final { scan-assembler-times "GCC: " 1 { xfail
powerpc-ibm-aix* } } } */
Thanks, David
Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support
Finally I found an ARM machine and was able to build ARM32 gcc on it, and
reproduced the failures. The Go programs aborted, in parse_lsda_header,
called from probestackmaps in the runtime startup. It seems that
_Unwind_GetLanguageSpecificData doesn't return a valid LSDA when called
from a callback from _Unwind_Backtrace.
Reading the unwinder's source code in libgcc, it seems that a function may
have a "predefined" personality function, and in this case an ARM-specific
"compact" model is used, which doesn't use the standard LSDA.
_Unwind_GetLanguageSpecificData doesn't distinguish this and simply assumes
the "generic" model is used, i.e. not used with a "predefined" personality
function. This works fine if _Unwind_GetLanguageSpecificData is called from
a non-predefined personality function, but it doesn't work if it is called
during _Unwind_Backtrace.
The patch below (also CL
https://go-review.googlesource.com/c/gofrontend/+/155758) will fix the
problem, by checking which model is used before calling
_Unwind_GetLanguageSpecificData.
Alternatively, we could change _Unwind_GetLanguageSpecificData in libgcc to
returning NULL when a predefined personality function is used.
Let me know what you think.
Thanks,
Cherry
diff --git a/libgo/runtime/go-unwind.c b/libgo/runtime/go-unwind.c
index f4bbfb60..388d7c70 100644
--- a/libgo/runtime/go-unwind.c
+++ b/libgo/runtime/go-unwind.c
@@ -646,6 +646,17 @@ findstackmaps (struct _Unwind_Context *context,
_Unwind_Ptr *ip, _Unwind_Ptr *sp
_sleb128_t index;
int size;
+#ifdef __ARM_EABI_UNWINDER__
+ {
+_Unwind_Control_Block *ucbp;
+ucbp = (_Unwind_Control_Block *) _Unwind_GetGR (context, 12);
+if (*ucbp->pr_cache.ehtp & (1u << 31))
+ // The "compact" model is used, with one of the predefined
+ // personality functions. It doesn't have standard LSDA.
+ return NOTFOUND_OK;
+ }
+#endif
+
language_specific_data = (const unsigned char *)
_Unwind_GetLanguageSpecificData (context);
On Tue, Dec 18, 2018 at 10:24 PM Matthias Klose wrote:
> Cherry, see
> https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg02241.html
> https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg02240.html
>
> still shows ~180 test failures on ARM32. Sorry, no access to an ARM32 box
> until
> next year.
>
> Matthias
>
> On 13.12.18 00:27, Ian Lance Taylor wrote:
> > On Wed, Dec 12, 2018 at 8:10 AM Cherry Zhang
> wrote:
> >>
> >> Thank you, Matthias!
> >>
> >> From the log, essentially all the tests aborted. The only place the new
> code can cause abort on all programs that I can think of is in the runtime
> startup code, probestackmaps, which calls value_size, which aborts due to
> an unhandled case. I haven't been able to try out on an ARM machine, but I
> managed to cross-compile a Go program and visually inspect the exception
> table. The type table's encoding is DW_EH_PE_absptr, which is indeed not
> handled, which will cause abort.
> >>
> >> I send https://go-review.googlesource.com/c/gofrontend/+/153857 (also
> as below). Hopefully this will fix the problem.
> >>
> >> Thanks,
> >> Cherry
> >>
> >> diff --git a/libgo/runtime/go-unwind.c b/libgo/runtime/go-unwind.c
> >> index c44755f9..f4bbfb60 100644
> >> --- a/libgo/runtime/go-unwind.c
> >> +++ b/libgo/runtime/go-unwind.c
> >> @@ -318,6 +318,8 @@ value_size (uint8_t encoding)
> >>case DW_EH_PE_sdata8:
> >>case DW_EH_PE_udata8:
> >> return 8;
> >> + case DW_EH_PE_absptr:
> >> +return sizeof(uintptr);
> >>default:
> >> break;
> >> }
> >
> >
> > Thanks.
> >
> > Committed to mainline.
> >
> > Ian
> >
> >
> >
> >> On Tue, Dec 11, 2018 at 7:03 PM Matthias Klose wrote:
> >>>
> >>> On 11.12.18 22:01, Cherry Zhang wrote:
> On Tue, Dec 11, 2018 at 3:51 PM Ian Lance Taylor
> wrote:
>
> > On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose
> wrote:
> >>
> >> On 10.12.18 16:54, Cherry Zhang wrote:
> >>> On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose
> > wrote:
> >>>
> On 06.12.18 00:09, Ian Lance Taylor wrote:
> > This libgo patch by Cherry Zhang adds support for precise stack
> > scanning to the Go runtime. This uses per-function stack maps
> stored
> > in the exception tables in the language-specific data area. The
> > compiler needs to generate these stack maps; currently this is
> only
> > done by a version of LLVM, not by GCC. Each safepoint in a
> function
> > is associated with a (real or dummy) landing pad, and its "type
> info"
> > in the exception table is a pointer to the stack map. When a
> stack is
> > scanned, the stack map is found by the stack unwinding code.
> >
> > For precise stack scan we need to unwind the stack. There are
> three
> cases:
> >
> > - If a goroutine is scanning its own stack, it can unwind the
> stack
> > and scan the frames.
> >
> > - If a goroutine
Re: [Patch] Bug 88521 - gcc 9.0 from r266355 miscompile x265 for mingw-w64 target
Hi, Here is the patch for the issue. Please let me know your thoughts. On Fri, Dec 21, 2018 at 3:16 PM JonY <10wa...@gmail.com> wrote: > > On 12/21/18 9:08 AM, Uros Bizjak wrote: > > On Thu, Dec 20, 2018 at 1:09 PM Jakub Jelinek wrote: > >> > >> On Thu, Dec 20, 2018 at 01:42:15PM +0530, Lokesh Janghel wrote: > >>> Hi Mateuszb, > >>> > >>> I tested with your proposition patch and it is working right. > >>> I also added the patch with test case. > >>> Please let me know your thoughts/suggestions. > >> > >> ChangeLog entry is missing, please write it (and mention there > >> Mateusz's name/mail as he wrote the i386.c part). > >> > > Patch looks good to me, but please add a ChangeLog. > > -- Thanks & Regards Lokesh Janghel +91-9752984749 88521.patch Description: Binary data
