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=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 #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=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 #51 from Dominik Vogt ---
With r245382 plus the patch from comment 43, only the failure in null-deref-1.c
is left.
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
Dominik Vogt changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=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=79403
--- Comment #5 from Dominik Vogt ---
Fixed, thanks.
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
Dominik Vogt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=79403
Dominik Vogt changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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=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 #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 #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 #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 #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 #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 #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 #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 #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 #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=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=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
Dominik Vogt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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.
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 #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=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 #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 #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 #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 #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 #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 #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=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 #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=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 #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 #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=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=79904
--- 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=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=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
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 #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
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 #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=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 #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
--- 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 #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=79441
--- Comment #4 from Dominik Vogt ---
Any chance of fixing that before gcc7?
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=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=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|---
,
||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=80281
--- Comment #14 from Dominik Vogt ---
Created attachment 41135
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41135&action=edit
dumpfile
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=77359
--- Comment #14 from Dominik Vogt ---
Okay, it looks like outgoing_args_size is rounded up to a multiple of
preferred_stack_boundary, so there's no problem on s390 or other targets with a
stack allocation size smaller than STACK_BOUNDARY. So, wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #16 from Dominik Vogt ---
There's nothing wrong with applying that change, but it does not fix the
problem. I'm still debugging this and have it narrowed down to being related
with functions that use alloca() and call another functio
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=77822
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
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 w
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;
}
--
: 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=78250
--- Comment #3 from Dominik Vogt ---
After throwing away the build dir I cannot reproduce the failure anymore.
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
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 a
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.
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 \
> tmp-gimple-
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 #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 below
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 #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 s390
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 s
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 #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 #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=78433
--- Comment #5 from Dominik Vogt ---
Is that with any specific version of Glibc?
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=78468
--- Comment #3 from Dominik Vogt ---
That very liekely means that libgomp has a buffer overflow in memory allocated
dynamically on the stack.
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
>From an email discussion between me and with Ian Lance Taylor about the
function statements.cc:build_thunk():
Ian Lance Taylor wrote:
> On Fri, Mar 28, 2014 at 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60728
Dominik Vogt changed:
What|Removed |Added
See Also||http://gcc.gnu.org/bugzilla
Assignee: ian at airs dot com
Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
With current code from gcc_5_branch, the Go test bug347.go crashes by
dereferencing a null pointer:
-- snip --
$ gdb ./bug347.x
(gdb) run
Starting program: /home/vogt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813
Dominik Vogt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #60 from Dominik Vogt ---
Works on s390x.
201 - 300 of 464 matches
Mail list logo
