https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633
--- Comment #9 from Dominik Vogt ---
The faulty patch has been reverted in r243256.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78748
--- Comment #4 from Dominik Vogt ---
Regression test of a polished version of the patch is running.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78748
--- Comment #5 from Dominik Vogt ---
Updated and tested patch posted to gcc-patches:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01033.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883
--- Comment #1 from Dominik Vogt ---
Can you please attach a combine dump?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883
--- Comment #3 from Dominik Vogt ---
Simplified test case:
void foo (int *p)
{
int i;
for (i = 0; i < 5; i++)
{
if (p[i] & 1)
return;
}
}
$ avr-gcc -S -O1 pr78883.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883
--- Comment #4 from Dominik Vogt ---
A discussion of the problem starts here:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01776.html
(Looks like a reload problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #17 from Dominik Vogt ---
Can you make sense of these results? The size of gamess has not changed, but
the runtime has but still looks noticeably worse. The astar performance looks
similar to yesterday's result without the change fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #18 from Dominik Vogt ---
(The perlbench result looks like a bad measurement result; we sometimes have
this on devel machine for unknown reasons, possibly when someone compiles or
tests on a different partition.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #25 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #24)
> So is this fixed now?
As far as I know, it's fixed.
> Or is it being kept open because that change broke
> sparc*-* (but that is already tracked in a different
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
Target: s390x
G++ (r244001) generates some pretty weird assembly code on s390x for this test
case. (Note that j is not initialised and I couldn't f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #22 from Dominik Vogt ---
> Is changing one a day enough for periodic testers to catch up?
I'll try to keep up with testing.
> New Revision: 244167
Which numbers do you need r244167 vs. r244166 or vs. 243994 or both? (If I'm
suppo
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
Created attachment 40500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79057
--- Comment #1 from Dominik Vogt ---
Created attachment 40501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40501&action=edit
reload output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069
--- Comment #1 from Dominik Vogt ---
What are the revision and the configure flags that trigger this, please?
r244350 bootstraps without problem here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069
--- Comment #3 from Dominik Vogt ---
> --disable-bootstrap
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069
--- Comment #6 from Dominik Vogt ---
Confirmed; bisecting now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #4 from Dominik Vogt ---
Can you please add the combine dump (and the dump before combine)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #6 from Dominik Vogt ---
I'm trying to build an cross compiler but cannot figure out the --target
configure option to use. Neither --target=arm nor --target=arm-linux nor
--target=arm-gnu-linux work. gcc/configure spits out an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #8 from Dominik Vogt ---
With the cross compiler and the reduced test case, reload generates a coredump.
Is that what you get for the minimized test?
Program received signal SIGSEGV, Segmentation fault.
0x802bb262 in df_ref_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #11 from Dominik Vogt ---
gccint:
> A operand which is read by the instruction can be tied to an earlyclobber
> operand if its only use as an input occurs before the early result is written.
Mabe it's allowed here because of the forc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #14 from Dominik Vogt ---
Isn't this more or less the same problem as the Avr issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883
On Avr, the register allocator would allow r31:HI if the expression is a
paradoxical subreg of me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #15 from Dominik Vogt ---
There's some code to reload such paradoxical subregs in
lra-constraints.c:simplify_operand_subreg():
/* Force a reload for a paradoxical subreg. For paradoxical subreg,
IRA allocates hardreg to the i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #16 from Dominik Vogt ---
Or rather this one which avoids triggering an assertion failure in
in_hard_reg_set_p ():
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #22 from Dominik Vogt ---
That looks like a similar problem. I'm lacking some knowledge about how
register pairs are allocated for paradoxical subregs on bigendian systems
though. Deducing from the code quoted above and from what re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #24 from Dominik Vogt ---
While you're at it ... does it have the same or a similar cause as the Avr bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883
(A HImode quantity got allocated to r31+r32 (r31 is the last hardreg), in
pr
: go
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com, krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
Bootstrapping on s390x fails with these errors:
.../gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146
--- Comment #6 from Dominik Vogt ---
Fixed.
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
Segher asked me to open a bug report for this:
https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79238
--- Comment #1 from Dominik Vogt ---
Note: Reg 67 is
(set (reg:SI 67 [ *f_5(D) ])
(mem:SI (reg:DI 2 %r2 [ f ]) [1 *f_5(D)+0 S4 A32]))
Note 2: Combine tries
(parallel [
(set (reg/i:DI 2 %r2)
(zero_extract:DI (mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79240
--- Comment #1 from Dominik Vogt ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79240
--- Comment #4 from Dominik Vogt ---
> So, either this is a bug in s390_extzv_shift_ok that is should use
> s390_contiguous_bitmask_p (contig, true, bitsize, &start, &end);
> instead of
> s390_contiguous_bitmask_nowrap_p (contig, bitsize, &star
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79240
--- Comment #6 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #5)
> Looking around, I see various spots that need cleanup:
> sizeof (HOST_WIDE_INT) * BITS_PER_UNIT should be IMHO HOST_BITS_PER_WIDE_INT
> 1ULL in unsigned HOST_WIDE_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #5 from Dominik Vogt ---
The tests cases from the first message still fail using a cross compiler and
r244951.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #11 from Dominik Vogt ---
The cross compiler s390x->arm works fine now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #30 from Dominik Vogt ---
(In reply to Eric Botcazou from comment #24)
> The root cause of this mess is actually init_emit:
>
> REGNO_POINTER_ALIGN (VIRTUAL_INCOMING_ARGS_REGNUM) = STACK_BOUNDARY;
> REGNO_POINTER_ALIGN (VIRTUAL_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #34 from Dominik Vogt ---
Some Spec2006 results on s390x (zEC12) for the files:
r243995 vs. r243994 (comment 14)
---
run-old.resultrun-new.result
f410.bwaves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #35 from Dominik Vogt ---
r244167 vs. r244166 (comment 21)
---
run-old.resultrun-new.result
f410.bwaves 1.27s1.27s ( 0.00%, 0.00% )
f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #36 from Dominik Vogt ---
r244207 vs. r244206 (comment 24)
---
run-old.resultrun-new.result
f410.bwaves 1.27s1.27s ( 0.00%, 0.00% )
f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #37 from Dominik Vogt ---
r244260 vs. r244256 (comment 25)
---
run-old.resultrun-new.result
f410.bwaves 1.27s1.27s ( 0.00%, 0.00% )
f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #38 from Dominik Vogt ---
Finally, the total between after the last and before the first patch. Overall,
some tests gain some performance and others lose some. The total number of
instructions has grown somewhat (especially tonto, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #33 from Dominik Vogt ---
I still disagree with reverting the patch. There was plenty of time to
identify and fix affected backends instead of doing nothing for half five
months and then claiming that the patch is potentially too dis
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390
Target: s390
The recent Asan patch for s390x (64 bit) has triggered about 270 Asan test
failures on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #2 from Dominik Vogt ---
No, that does not help.
Meanwhile the Tests on s390x have completed (r244119), and there are > 100 Asan
related FAILs with -m31 as well as -m64. Not anywhere near your or Andreas'
test results. Many FAILs s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #3 from Dominik Vogt ---
For example, use-after-scope-goto-1.c built with -O0 -m31 crashed during exit:
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) up
#1 0x77a65c0a in __interceptor___tls_get_addr_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
--- Comment #10 from Dominik Vogt ---
(In reply to Richard Biener from comment #7)
> Author: rguenth
> Date: Wed Nov 16 08:42:20 2016
> New Revision: 242470
>
> URL: https://gcc.gnu.org/viewcvs?rev=242470&root=gcc&view=rev
> Log:
> 2016-11-16 R
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
2 undesignated symbols
0
_ZSt11__once_call
std::__once_call
version status: compatible
GLIBCXX_3.4.11
type: tls
type size: 8
status: undesignated
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348
--- Comment #1 from Dominik Vogt ---
How do you regenerate the baseline files for s390*?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348
--- Comment #3 from Dominik Vogt ---
(In reply to Jonathan Wakely from comment #2)
> Why have these symbols appeared now? Is TLS enabled by default on this
> target now? Did something change regarding TLS?
Not that I know of.
> Are you using th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348
--- Comment #4 from Dominik Vogt ---
(Also happend without --enable-shared.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348
--- Comment #5 from Dominik Vogt ---
The test failure has started with r238647:
Move allocator in std::string and RB tree move constructors
PR libstdc++/71964
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348
--- Comment #6 from Dominik Vogt ---
Before that the "undesignated symbols" were around already, but the test PASSed
anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #4 from Dominik Vogt ---
From /sysdeps/s390/dl-tls.h:
/* The special thing about the s390 TLS ABI is that we do not have the
standard __tls_get_addr function but the __tls_get_offset function
which differs in two important aspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #5 from Dominik Vogt ---
Okay, the symbol __tls_get_addr_internal exists since Glibc-2.19 on s390*, and
the test machine has Glibc-2.18. Is this something that needs to be fixed in
libsanitizer, or does the test machine need an upgra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #8 from Dominik Vogt ---
The symbol was introduced to Glibc after 2.18 and before 2.19.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #11 from Dominik Vogt ---
Hm, Stefan says that RHEL 7.3 has a Glibc-2.17 with a backport of the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #12 from Dominik Vogt ---
> so it should then for s390*-*-linux* also test for glibc >= 2.19 using
> AC_TRY_COMPILE and preprocessor macros or so?
Or something like
$ nm /lib/ld-*.*.so | grep __tls_get_addr_internal
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #13 from Dominik Vogt ---
The opinion of whoever added the S390 code to sanitizer_common_interceptors.inc
("chefmax") might help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
--- Comment #11 from Dominik Vogt ---
Fails if configured with "--with-arch=zEC12", passes without that.
: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org, msebor at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
The test has two xfails that do pass on s390x with --with-arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
FAIL: gcc.dg/c99-stdint-1.c (test for excess errors)
Excess errors:
.../gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #1 from Dominik Vogt ---
(built with --enable-bootstrap, --enable-multilib and --with-arch=zEC12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Comment
,
||rdapp at linux dot
vnet.ibm.com,
||vogt at linux dot vnet.ibm.com
--- Comment #4 from Dominik Vogt ---
This commit has broken a test case on s390x:
FAIL: gcc.target/s390/loc-1.c scan-assembler \tlocgrne\t%r2,%r4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #3 from Dominik Vogt ---
> The reduced testcase fails with -m31 and -m64 but the original probably only
> with -m31 - right?!
The unreduced testcase fails with -m31 and -m64. I've tried the reduced test
case only with -m64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #4 from Dominik Vogt ---
I.e. this is a Glibc related problem? The test machine has Glibc-2.18.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #35 from Dominik Vogt ---
(In reply to Eric Botcazou from comment #34)
> > I still disagree with reverting the patch. There was plenty of time to
> > identify and fix affected backends instead of doing nothing for half five
> > month
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #6 from Dominik Vogt ---
(In reply to Andreas Krebbel from comment #2)
> The reduced testcase fails with -m31 and -m64 but the original probably only
> with -m31 - right?!
Sorry, you're right. I was doing too many things in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #7 from Dominik Vogt ---
Or even
--
#include
#include
#define FOO(TYPE, EXPR) __typeof__(EXPR) a; __typeof__((TYPE)0 + 0) *b = &a;
void foo (void)
{
FOO(__SIZE_TYPE__, (SIZE_MAX));
}
--
So __typeof__(SIZE_MAX) is differe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #8 from Dominik Vogt ---
Gdb says:
(gdb) ptype __typeof__(size_t)
type = unsigned long
(gdb) ptype __typeof__(SIZE_MAX)
type = unsigned int
Two different types for unsigned 32 bit integers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634
--- Comment #6 from Dominik Vogt ---
It fails with -march=zEC12 but not with -march=z900. It seems to be a tuning
issue of the branch cost in the backend; a colleague is working on that and
will mave a patch at some time in the future. So, I th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348
--- Comment #8 from Dominik Vogt ---
All right, but what is the cause of that? The commit that git-bisect found
seems to be completely unrelated(?)
Examples:
--
4
_ZGTtNSt11range_errorC2EPKc
transaction clone for std::range_error::range_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
--- Comment #13 from Dominik Vogt ---
It still fails with
/* { dg-options "-O3 -fdump-tree-ldist-details --param max-unroll-times=8" } */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
--- Comment #15 from Dominik Vogt ---
Yep. I'll post a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
--- Comment #16 from Dominik Vogt ---
Patch:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00424.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348
--- Comment #10 from Dominik Vogt ---
Created attachment 40679
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40679&action=edit
test outpu
Full test output attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71144
--- Comment #6 from Dominik Vogt ---
This no longer happens with current trunk. The warnings are still present, but
the ICE is gone:
(In reply to Dominik Vogt from comment #1)
> I get (pprobably) the same ICE on s390x with today's devel branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71144
--- Comment #7 from Dominik Vogt ---
The ICE (s390x) has gone away with this commit:
2017-01-31 Richard Biener
PR tree-optimization/77318
* graphite-sese-to-poly.c (extract_affine): Fix assert.
(create_pw_aff_from
: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
Host: s390x
Target: s390x
"make install" of the Ada compiler installs the contests of the adainclude and
adalib directories with
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
The test case trampoline3.adb fails on s390x configured with --march=zEC12,
using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403
--- Comment #1 from Dominik Vogt ---
(Happens with gcc-6.3; 7.0 was *not* tested.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #25 from Dominik Vogt ---
Looks better, but now we get this quite often:
--
==23722==ERROR: Your kernel seems to be vulnerable to CVE-2016-2143. Using
ASa\
n,
MSan, TSan, DFSan or LSan with such kernel can and will crash your
mach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #26 from Dominik Vogt ---
(We cannot upgrade the kernel before end of this or beginning of next week.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #29 from Dominik Vogt ---
$ uname -s -r
Linux 4.2.0-20151029.0.65fcf15.5a12af1.fc20.s390xperformance
I'm quite sure we had a working kernel on that machine at some time because I
believe to remember that I'd been the first one who wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427
--- Comment #3 from Dominik Vogt ---
The xfail was removed from the test because it caused an XPASS on many systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427
--- Comment #4 from Dominik Vogt ---
See here for discussion of this bug report:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00666.html
And here for discussion of the patch:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00446.html
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: ebotcazou at gcc dot gnu.org, krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
On s390x, the test gnat.dg/pack9.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403
--- Comment #3 from Dominik Vogt ---
The files are symlinks in the build tree, mode 640 in the source tree (like
everything else) and are installed with "cp -p" which explains the broken
permissions. Most other things are installed "install -m 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421
--- Comment #2 from Dominik Vogt ---
And on a target not using function descriptors otherwise,
#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1
affects only Ada?
: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com, krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
Currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443
--- Comment #2 from Dominik Vogt ---
Yes, that fixes it. Now there's another one in crypto/sha256. Do you want me
to open another bug report for that?
--
fallback_test.go:19:5: error: reference to undefined name 'useAsm'
if useAsm == false {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421
--- Comment #4 from Dominik Vogt ---
Okay, that change fixes it without regressions. I'll post a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421
--- Comment #5 from Dominik Vogt ---
Patch available here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421
The bug can be closed when the patch is applied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443
--- Comment #4 from Dominik Vogt ---
No more than that, and the fix works.
(Except for the issue with cplx2.go that has been there from the start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #32 from Dominik Vogt ---
On a machine with
* glibc-2.23
* kernel 4.4.0 + patch for the CVE
* CVE environment variable set to allow running the Asan tests
* patch from comment 24 applied
=>
In addition to the FAILs you've listed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #34 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #33)
> (In reply to Dominik Vogt from comment #32)
> > On a machine with
> > * glibc-2.23
>
> :(; I was hoping you could test #c24 patch against glibc 2.18
I'll even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #36 from Dominik Vogt ---
Created attachment 40711
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40711&action=edit
Reduced test for float-cast-overflow-10.c
Test for the float-cast-overflow-10.c failure.
This snippet should d
101 - 200 of 464 matches
Mail list logo
