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.
,
||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=448
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Comment
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)
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=70478
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
: 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=78348
--- Comment #11 from Dominik Vogt ---
Fails if configured with "--with-arch=zEC12", passes without that.
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=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 #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 #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 #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
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
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=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]
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 #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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348
--- Comment #1 from Dominik Vogt ---
How do you regenerate the baseline files for s390*?
: 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=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=gcc=rev
> Log:
> 2016-11-16 Richard
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=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
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
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=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
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,
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% )
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% )
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% )
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=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
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=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=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
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, , );
> instead of
> s390_contiguous_bitmask_nowrap_p (contig, bitsize, , );
> and
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=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
: 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=79146
--- Comment #6 from Dominik Vogt ---
Fixed.
: 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=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
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
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 #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
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
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
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
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
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=79069
--- Comment #6 from Dominik Vogt ---
Confirmed; bisecting now.
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 #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=79057
--- Comment #1 from Dominik Vogt ---
Created attachment 40501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40501=edit
reload output
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=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
: 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 find
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
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=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
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=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=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 #1 from Dominik Vogt ---
Can you please attach a combine dump?
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=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=78468
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
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=78633
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #20 from Dominik Vogt ---
(In reply to Eric Botcazou from comment #19)
> I think that the patch is simply incorrect and should be reverted, it very
> likely breaks other ports than PowerPC and SPARC and the failure more is
> quite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #18 from Dominik Vogt ---
Another approach may be to make the middleend ask the backend for the actual
value of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM). Since on Sparc
the address is always 4 mod 8, we'd get an additional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #16 from Dominik Vogt ---
In emit-rtl.c:init_emit(), the alignment of the virtual_stack_dynamic pointer
is hard coded to STACK_BOUNDARY:
REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY;
The backend must make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #14 from Dominik Vogt ---
Is the dynamic variable stack area properly aligned? Since sparc.h does not
define STACK_DYNAMIC_OFFSET it should be aligned to STACK_BONDARY, i.e. 64
bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #11 from Dominik Vogt ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> > 2) Replace "p7" in foo with just "7". If it still fails we know the bug is
> > not
> > triggered by the dynamic allocation of a or b.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
--- Comment #31 from Dominik Vogt ---
No more backports, but the S390 fix for trunk is still in the queue. After it
gets the bug can be resolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #8 from Dominik Vogt ---
Some things to try with reduction-10.c:
1) Remove all OMP pragmas from the code. If it still fails it's not a limbgomp
bug.
2) Replace "p7" in foo with just "7". If it still fails we know the bug is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #7 from Dominik Vogt ---
The dumps show some differences I'd expect, but debugging libgomp testcases is
awkward because they are so complicated. In the pre-patched era, Gcc's dynamic
allocation on the stack was a bit too large most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #4 from Dominik Vogt ---
Could you provide assembly dumps of the function foo() in the testcase, both,
with and without the "culprit" patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #3 from Dominik Vogt ---
That very liekely means that libgomp has a buffer overflow in memory allocated
dynamically on the stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433
--- Comment #9 from Dominik Vogt ---
... and I think the buffer allocated in __execvpe() is also one byte too small:
char buffer[path_len + file_len + 1];
...
char *pend = mempcpy (buffer, p, subp - p); <-- path_len
*pend = '/';
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433
--- Comment #8 from Dominik Vogt ---
This code from maybe_script_execute() writes past the allocated array bounds:
/* Construct an argument list for the shell. */
char *new_argv[argc + 1];
new_argv[0] = (char *)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433
--- Comment #5 from Dominik Vogt ---
Is that with any specific version of Glibc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #25 from Dominik Vogt ---
A quick regression test with both patches; s390x with just -m64 and
-languages=c has only two failures left:
+FAIL: gcc.target/s390/risbg-ll-1.c scan-assembler
f43:\\n\\trisbg\\t%r2,%r2,32,128+61,64-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #22 from Dominik Vogt ---
Does this patch replace the one in comment 8 or should they both be used?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #21 from Dominik Vogt ---
(In reply to Michael Matz from comment #16)
> Uhh:
>
> Successfully matched this instruction:
> (set (subreg:DI (reg:SI 73) 0)
> -(lshiftrt:DI (reg/v:DI 63 [ X ])
> -(const_int 56 [0x38])))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #19 from Dominik Vogt ---
(In reply to Segher Boessenkool from comment #17)
> Combine should probably not try to generate this extract, I wonder if it
> can exist on any target. So where is it coming from?
>
> Of course the target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #14 from Dominik Vogt ---
With the fix I couldn't reproduce the error message in four attempts, but
genattrtab still hangs. Maybe this is bad luck, but maybe the error is gone.
Running a regression test without bootstrapping on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #13 from Dominik Vogt ---
I'm doing this on s390x right now. Just takes some more time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #9 from Dominik Vogt ---
On Thu, Nov 17, 2016 at 03:03:03PM +, matz at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
>
> --- Comment #8 from Michael Matz ---
> The aarch64 fail is fixed by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #5 from Dominik Vogt ---
(In reply to Andreas Schwab from comment #3)
> Does it help to revert r242414?
Yep. r242414 has introduced the problem.
(Happens only with --with-arch=zEC12.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #4 from Dominik Vogt ---
There's another error that our dailybuild system found yesterday. May have the
same cause.
build/genmatch --gimple
/home/dailybuild/gnu-dailybuild/arena/20161116/gcc-head/src/gcc/match.pd \
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #2 from Dominik Vogt ---
Both, the hang in genattrtab and the error message happen in stage 2.
Priority: P3
Component: other
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
With the recent trunk I get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
--- Comment #26 from Dominik Vogt ---
Patch for s390[x], gcc-6:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00745.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78250
--- Comment #3 from Dominik Vogt ---
After throwing away the build dir I cannot reproduce the failure anymore.
: 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
Build: s390
Gcc-6 (rev 241836) does not bootstrap on s390 (31-bit system) because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
--- Comment #25 from Dominik Vogt ---
I see.
This test verifies that a negative "pos" is indeed rejected:
--
#include
int g;
void foo(int64_t b)
{
if (b >> 65 & 1)
g = b;
}
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
--- Comment #23 from Dominik Vogt ---
Regarding the ARM patch:
+ {
+if (!IN_RANGE (INTVAL (operands[2]) + INTVAL (operands[3]),
+ 1, GET_MODE_BITSIZE (DImode) - 1))
+ FAIL;
+ }
Isn't this patch too simple? On s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78197
--- Comment #1 from Dominik Vogt ---
(... does it use a different condition *on purrpose* ...)
101 - 200 of 464 matches
Mail list logo
