https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80281
--- Comment #18 from Dominik Vogt ---
Fixed.
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&action=edit
dumpfile
,
||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=79487
Dominik Vogt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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
--- 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
Alth
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 ass
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 old
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=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=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 integ
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 9fd45d1..e
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=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 });
(in
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 ...
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=79904
--- 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 #1 from Dominik Vogt ---
Confirmed.
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 --enable-gnu-indirect
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
~/src/gcc/gcc/testsuite/gcc
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=79341
--- Comment #74 from Dominik Vogt ---
With the pending patches/fixes, the *san testsuites are clean on s390x biarch
and s390. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356
--- Comment #7 from Dominik Vogt ---
Patch with all reported targets in a negative list:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01006.html
Can you please double check that the xfail selectors are correct for your
targets?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #72 from Dominik Vogt ---
I wanted to refer to the funny pc value. The line information is actually
correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #70 from Dominik Vogt ---
If funny line information is the only consequence, no. Is it safe to assume
that libsanitizer won't crash or produce garbege because of this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #68 from Dominik Vogt ---
Okay, that fixes the test failure, but the addresses further up in the
backtrace are still bad, e.g.
#0 0x10008d2 in NullDeref
#1 0x1000759 in main
#2 0x3fffce23069 in
#3 0x10007d5
Maybe it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #66 from Dominik Vogt ---
Compiled from scratch to make sure it's not a build dependency problem, but the
tests still fail because of the odd backtrace addresses. Can I provide some
information from single stepping in Gdb?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #65 from Dominik Vogt ---
That patch does not compile, and fixing the compiler error (context -> ctx)
doesn't help either.
> but I also can't reproduce the nullptr-1.c failure myself
An example command line is
$ .../gcc/build-fixe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #62 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #61)
> It is true that libasan calls just _Unwind_GetIP rather than
> _Unwind_GetIPInfo,
> but I don't see where there is that subtraction of 1, so it shouldn't matter;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #57 from Dominik Vogt ---
libsanitizer miscalculates the Pcs in the backtrace:
#0 0x1000839 in NullDeref
#1 0x10006c1 in main
#2 0x3fff6e23069 in __libc_start_main
#3 0x100073d
These are all odd addresses, pointing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #56 from Dominik Vogt ---
null-deref-1.c fails because the test expects this message in source line 10
but gets it for line 11:
#0 0x1000853 in NullDeref .../c-c++-common/asan/null-deref-1.c:11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749
--- Comment #14 from Dominik Vogt ---
Thanks. Patch is here:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00975.html
With that, the test is fine on s390 and s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #55 from Dominik Vogt ---
(In reply to Dominik Vogt from comment #53)
> no fails with -m31; with -m64 null-deref-1.c fails with c and
> c++, and memcmp-1.c with c++ only.
memcmp-1.c is not reproducible.
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
Target Milestone: ---
Some discussion on that issue is here.
https://gcc.gnu.org/ml/gcc/2015-12/msg00064.html
This should be fixed in the backend at some point in the future.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421
Dominik Vogt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421
--- Comment #6 from Dominik Vogt ---
(In reply to Dominik Vogt from comment #5)
> Patch available here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421
Wrong link. Patch is here:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00692.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #24 from Dominik Vogt ---
No regressions on s390x biarch, and s390 on a zEC12 configured with
-with-arch=zEC12. The "volatile"-patch to float-cast-overflow-8.c is no longer
necessary. Thanks for the help!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #23 from Dominik Vogt ---
Same result on s390x (on a zEC12 using -with-arch=zEC12):
Without patch:
* -O0 -> PASS
* -O2 -> FAIL
With patch:
* -O0 -> PASS
* -O2 -> PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #19 from Dominik Vogt ---
It fixes the local test case extracted from float-cast-overflow-10.c. The
patch probably should also add a test case; the one I have is very specific to
s390x; would something like the code in comment 17 wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #16 from Dominik Vogt ---
> the REAL_CSTs already contain the right rounded values for their type
Is there a way to see these values in the dumps?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #14 from Dominik Vogt ---
To me, it looks like the same bug does not happen with float just because there
is no need to convert this to 64 bit format for the comparison.
simplify_const_unary_operation is not executed - if it was the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #13 from Dominik Vogt ---
From the "optimize" dump:
With float:
if (tem.1_3 != -9.223372036854775808e+18)
With _Decimal32:
if (tem.1_3 != -9223372036854775808)
This precision of the constant and the representation as floating p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #11 from Dominik Vogt ---
Well, then, what is the place where the constant should be truncated to what
its mode can represent?
Right at the start of the Tree dumps there seems to be a difference between
float and _Decimal32. Float c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #9 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #8)
> This isn't truncation, but extension (SDmode to DDmode). I presume all
> SDmode values are representable in DDmode, so I don't see anything wrong on
> that.
But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #7 from Dominik Vogt ---
(In reply to Andreas Krebbel from comment #5)
> Perhaps we have to do the real_convert unconditionally?!
The real_convert to "mode" is not enough. Before converting to the target
mode, the constant needs to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #6 from Dominik Vogt ---
This experimental patch fixes the problem:
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index aa45973..2e67cff 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -1897,6 +1897,8 @@ simplify_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #4 from Dominik Vogt ---
What happens in Cse1 is that the constant is propagated into the FLOAT_EXTEND
expression, resulting in
(float_expand:DD (const_double:SD -9223372036854775808))
which is eventually simplified using simplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403
Dominik Vogt changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #53 from Dominik Vogt ---
(In reply to Dominik Vogt from comment #51)
> With r245382 plus the patch from comment 43, only the failure in
> null-deref-1.c is left.
Ah, not quite; no fails with -m31; with -m64 null-deref-1.c fails with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348
--- Comment #14 from Dominik Vogt ---
Yep, fixed.(In reply to Jakub Jelinek from comment #13)
> Should be fixed now.
Yep, fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
--- Comment #10 from Dominik Vogt ---
(In reply to Matthias Klose from comment #8)
> I prepared a patch for the distro builds. Any reason that this can't go to
> the gcc-5-branch?
Ping?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403
Dominik Vogt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
Dominik Vogt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403
--- Comment #5 from Dominik Vogt ---
Fixed, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #2 from Dominik Vogt ---
Ah, no, the first Rtl pass that produces an incorrect expression is Cse1.
Before:
--
(insn 22 21 23 3 (set (reg:SD 75)
(const_double:SD -9223372036854775808 [N/A])) "decimal32.c":23 1121
{movsd}
(ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
--- Comment #1 from Dominik Vogt ---
It seems that the pass ccp1 eliminates all information about the type of "min"?
Before ccp1:
_Decimal32 min;
...
if (min_8 != tem.1_3)
After ccp1:
if (tem.1_3 != -9223372036854775808)
(Or is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
Dominik Vogt changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: jakub at gcc dot gnu.org, krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
This is a finding from an Asan test case failure reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #51 from Dominik Vogt ---
With r245382 plus the patch from comment 43, only the failure in null-deref-1.c
is left.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #42 from Dominik Vogt ---
With glibc-2.18 and the various patches, the following tets fail:
-m31:
* deep-stack-uaf-1.C
-m64:
* null-deref-1.c
* deep-stack-uaf-1.C
* overflow-vec-1.c
* overflow-vec-2.c
* float-cast-overflow-10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #41 from Dominik Vogt ---
> The first loop loops until add is -1.00E+12, at which point for the
> first time tem is -9.223373E+18 and thus different from -9.223372E+18, and
> -9.223373E+18 should not be representable in signed lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #13 from Dominik Vogt ---
Same without vectors:
long foo (long a, long b)
{
return a > b;
}
=>
cgr %r2,%r3
lghi%r1,1
locghinh%r1,0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #38 from Dominik Vogt ---
(And if it does generate messages, does it take the if or the else bodies? For
me it's the if-bodies.)
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
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 #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=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=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=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=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 {
: 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=79421
--- Comment #2 from Dominik Vogt ---
And on a target not using function descriptors otherwise,
#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1
affects only Ada?
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
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=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
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=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=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 #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=79403
--- Comment #1 from Dominik Vogt ---
(Happens with gcc-6.3; 7.0 was *not* tested.)
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
: 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
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
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=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=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=78348
--- Comment #15 from Dominik Vogt ---
Yep. I'll post a patch.
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=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=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=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=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 #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=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 #4 from Dominik Vogt ---
I.e. this is a Glibc related problem? The test machine has Glibc-2.18.
1 - 100 of 464 matches
Mail list logo
