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 #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 #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=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 #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 #5 from Dominik Vogt ---
Is that with any specific version of Glibc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #21 from Dominik Vogt ---
Patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00266.html
This needs to pass the AIX testsuite which I cannot run with the available
resources.
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: dje at gcc dot gnu.org
Target Milestone: ---
Target: AIX, Power
The file rs6000.h contains the macros
--
#define STACK_BOUNDARY \
((TARGET_32BIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056
--- Comment #18 from Dominik Vogt ---
Seems to be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78197
--- Comment #1 from Dominik Vogt ---
(... does it use a different condition *on purrpose* ...)
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=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=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=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 #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 #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
@@
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=edit
reload output
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=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=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=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=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=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)
: 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=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
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 #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=80080
--- Comment #7 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #6)
> I think it depends on what
> (success, old_reg) = compare-and-swap(mem, old_reg, new_reg)
> sets if success is true. Is there a guarantee that old_reg will be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981
Dominik Vogt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
Dominik Vogt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356
--- Comment #13 from Dominik Vogt ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01468.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356
--- Comment #12 from Dominik Vogt ---
Still XPASSes on s390 (but not s390x with -m31 or -m64).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79441
--- Comment #4 from Dominik Vogt ---
Any chance of fixing that before gcc7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080
--- Comment #8 from Dominik Vogt ---
The patch has a performance regression on s390x.
.L1
lr %r3,%r1
cs %r1,%r4,0(%r2)
jne .L1
becomes
.L1
cs %r1,%r3,0(%r2)
ipm %r4
sra %r4,28
cijne %r4,0,.L1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80281
--- Comment #14 from Dominik Vogt ---
Created attachment 41135
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41135=edit
dumpfile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80281
--- Comment #18 from Dominik Vogt ---
Fixed.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
Trying to figure out why this sample program results on not so good Rtl code on
s390x:
--
extern void locked (void *lock);
extern void not_locked (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981
--- Comment #5 from Dominik Vogt ---
The knowledge that the integer can only assume the values 0 and 1 seems to be
hard coded. Is it possible to add value range information? With that, all
conditions and arithmetics could be done with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981
--- Comment #3 from Dominik Vogt ---
(In reply to Richard Biener from comment #2)
> of course needs to be conditional on oldlhs being bool and lhs being
> integral.
Like so?
--
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981
--- Comment #10 from Dominik Vogt ---
Thanks for the fix; I'll regression test it soon, just need some time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890
--- Comment #3 from Dominik Vogt ---
Not reproduceable here with r245913. Is it gone with a recent Gcc?
Gcc configured with --with-arch=zEC12 and compiled without explicit options:
$ ~/src/gcc/install-master/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904
--- Comment #1 from Dominik Vogt ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893
--- Comment #1 from Dominik Vogt ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79895
--- Comment #1 from Dominik Vogt ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893
--- Comment #2 from Dominik Vogt ---
A small test program that reproduces the crash:
--
#include
void foo(signed char *p, int i) {
vec_load_bndry(p, i);
}
--
$ gcc -mzvector -mvx -march=z13 -S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890
--- Comment #1 from Dominik Vogt ---
The ICE needs to be fixed, of course, by what is the idea behind executing the
mips testsuite on s390?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890
--- Comment #5 from Dominik Vogt ---
Reproduceable on a zEC12 with
$ ./configure --enable-languages=c --disable-bootstrap --disable-multilib
--enable-checking --with-system-zlib --enable-threads=posix
--enable-__cxa_atexit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904
--- Comment #3 from Dominik Vogt ---
Not sure what that means:
When UBSAN_CHECK_MUL is expanded, the generated Rtl wants the vector constant
"3" in the litaral pool (insn 30):
--
;; _2 = UBSAN_CHECK_MUL (_1, { 11, 22, 33, 44, 0, 0, 0, 0 });
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904
--- Comment #2 from Dominik Vogt ---
Reduced test:
--
typedef signed char V __attribute__((vector_size (8)));
void foo (V *a)
{
*a = *a * 3;
}
--
$ gcc -fsanitize=undefined ...
,
||vogt at linux dot vnet.ibm.com
--- Comment #13 from Dominik Vogt ---
This commit breaks tree-ssa/pr40921.c on s390x (-m31 and -m64) and s390:
.../build/gcc/xgcc -B.../build/gcc/ .../testsuite/gcc.dg/tree-ssa/pr40921.c
-fno-diagnostics-show-caret -fdiagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080
--- Comment #5 from Dominik Vogt ---
What case do you mean? The
+ if (oldval != old_reg)
+emit_move_insn (old_reg, oldval);
at the end should make sure that the oldval-rtx is either not changed by the
call, or its value is copied into
401 - 464 of 464 matches
Mail list logo
