https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #9 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 35059 [details]
> gcc5-pr65400.patch
>
> Untested fix for the first issue.
patch looks good!
and a really nice test case.
one minor nit on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449
--- Comment #1 from Bernd Edlinger ---
Hi Richard,
the invalid/different code for -O2 -fstrict-volatile-bitfields will be
fixed with my proposed patch, because the misalignedness of mm should
be visible at -O2 and prevent the strict_volatile bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457
--- Comment #2 from Bernd Edlinger ---
When I look at tree.h:3346, I do not understand why the
operand check failed. From the message it appears that
__i==2 and TREE_OPERAND_LENGTH (__u)==4:
inline tree *
tree_operand_check (tree __t, int __i,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457
--- Comment #1 from Bernd Edlinger ---
these are my configure flags:
../gcc-5-20150315/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=all,ada,go,obj-c++ --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --wit
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
libtool: compile: /home/ed/gnu/gcc-build-arm-linux-gnueabihf/./gcc/gfortran
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./gcc/
-B/home/ed/gnu/arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #7 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #6)
> Both patches look wrong to me.
> For the first change, it is wrong to add TSAN_FUNC_EXIT (), you should never
> add it out of nothing. First of all, you might c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65435
--- Comment #3 from Bernd Edlinger ---
FYI, I've now opened an issue in the OpenSSL bug tracker:
http://rt.openssl.org/Ticket/Display.html?id=3751
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Hi,
I am not quite sure if this is a bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #5 from Bernd Edlinger ---
Created attachment 35033
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35033&action=edit
stripped down second test case
For completeness, here is the stripped down test case for the tail call flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #4 from Bernd Edlinger ---
ok,
this should fix the second regression:
Index: tsan.c
===
--- tsan.c(revision 221355)
+++ tsan.c(working copy)
@@ -682,6 +682,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #3 from Bernd Edlinger ---
Hmm,
I tried this:
--- gcc/ipa-split.c.jj2015-02-08 21:13:01.0 +0100
+++ gcc/ipa-split.c2015-03-13 11:29:08.878923384 +0100
@@ -1509,6 +1509,16 @@ split_function (struct split_point *spli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #2 from Bernd Edlinger ---
Jakub,
at that time we do not have the __tsan_func_entry calls, only
the __TSAN_FUNC_EXIT thing.
in opcua_string.c.038t.local-pure-const1
OpcUa_String_Clear looks like it has OpcUa_String_Clear.part.0
at t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #1 from Bernd Edlinger ---
I think the trouble starts at opcua_string.c.039t.fnsplit :
OpcUa_String_Clear (struct OpcUa_String * a_pString)
{
...
:
# _25 = PHI <0(2), 1(3), 0(4)>
if (_25 == 0)
goto ;
else
goto ;
:
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Created attachment 35018
--> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067
--- Comment #10 from Bernd Edlinger ---
(In reply to Tony Liu from comment #9)
> (In reply to Bernd Edlinger from comment #8)
> > Created attachment 34955 [details]
> > Proposed Fix
> >
> > Well, I noticed that the first version of this patch ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067
--- Comment #8 from Bernd Edlinger ---
Created attachment 34955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34955&action=edit
Proposed Fix
Well, I noticed that the first version of this patch caused
a small but measurable decrease of co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067
--- Comment #6 from Bernd Edlinger ---
Ok, I think I understand now, what is wrong.
r216989 did just cause the strict-alignment code path to be executed,
which was not the case before.
Actually the extract_bit_field code is also wrong, but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #20 from Bernd Edlinger ---
(In reply to Dominique d'Humieres from comment #12)
> In addition Bernd's patch fixes/hides the ICE for pr61960.
this pr is fixed by this hunk alone:
--- gcc/fortran/trans-expr.c(revision 220662)
+++ g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #18 from Bernd Edlinger ---
(In reply to Dominique d'Humieres from comment #17)
> > I think this updated patch fixes all mentioned test cases.
>
> Confirmed, bootstrapped and regtested cleanly.
>
> > but there are many regressions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #16 from Bernd Edlinger ---
(In reply to Mikael Morin from comment #14)
> Bernd, do you have a reliable way to test a patch, checking for aliasing
> violations?
No, all I can do is run the test suite on my armv7l-unknown-linux-gnueab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #15 from Bernd Edlinger ---
Created attachment 34758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34758&action=edit
Updated patch that also fixes pr64230.f90
(In reply to Dominique d'Humieres from comment #12)
> With any of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #10 from Bernd Edlinger ---
(In reply to Mikael Morin from comment #9)
>
> (In reply to Bernd Edlinger from comment #8)
> > The call of get_d_position is now rewritten as follows:
> >
> > this.22 = VIEW_CONVERT_EXPR > __class_muli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #8 from Bernd Edlinger ---
Created attachment 34751
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34751&action=edit
Proposed Fix
OK, now I see the original test case exposes an aliasing violation
when node is passed to node._v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718
Bernd Edlinger changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
This program should probably be rejected, but actually it compiles correctly
and
without warning, the resulting code "works".
Same behaviour with current trunk and 4.6.2
cat test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #64 from Bernd Edlinger ---
(In reply to Mikael Pettersson from comment #63)
> The backport request has been posted:
>
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02192.html
OK, fine.
If you want I can commit that for you now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718
--- Comment #22 from Bernd Edlinger ---
Hmm
I tried to boot-strap a clean gcc 4.9.2 with this patch, but it did not make
it. Looks like some one spoiled the armv7l-unknown-linux-gnueabihf target.
So it is currently pointless to fix this for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #61 from Bernd Edlinger ---
(In reply to Mikael Pettersson from comment #60)
> FWIW I've been including backports of r202778 and r206437 (which I think are
> the two relevant fixes) in my 4.8-based GCCs on x86_64, sparc64, powerpc64,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718
--- Comment #21 from Bernd Edlinger ---
(In reply to Dominique d'Humieres from comment #20)
> > 4.9 should be easy, because I missed the deadline for 4.9.0 just
> > by a few days. What I applied was just the original patch for 4.9.
>
> Could yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718
--- Comment #19 from Bernd Edlinger ---
(In reply to Dominique d'Humieres from comment #18)
> Any project to back port r218584 to 4.9/8?
4.9 should be easy, because I missed the deadline for 4.9.0 just
by a few days. What I applied was just the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #13 from Bernd Edlinger ---
ok, now I see.
the binutils-2.25.tar.gz works,
but if we build directly from the git it does not.
is this a new check that makes this problem?
regarding my patch on pr26255.c, this happens:
m32c-elf-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #10 from Bernd Edlinger ---
Hmm...
I use this configuration:
binutils-build:
../binutils-2.25/configure --prefix=/home/ed/gnu/m32c-rtems --target=m32c-rtems
--disable-werror
gcc-build:
../gcc-trunk/configure --prefix=/home/ed/gnu/m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645
--- Comment #7 from Bernd Edlinger ---
(In reply to Richard Henderson from comment #6)
> No. In that case this unwind info would simply be ignored.
> Anyway, fixed in r219860.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645
--- Comment #5 from Bernd Edlinger ---
(In reply to Richard Henderson from comment #4)
> (In reply to Bernd Edlinger from comment #3)
> > AFAIK Cygwin-32 does not support the unwind info at all, right?.
>
> Wrong. This should be enough to fix i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645
--- Comment #3 from Bernd Edlinger ---
OK.
AFAIK Cygwin-32 does not support the unwind info at all, right?.
Cygwin-64 does support Windows-SEH style unwind info.
libjava uses a kind of hack to get the stack trace:
see libjava/sysdep/i386/backt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64640
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645
--- Comment #1 from Bernd Edlinger ---
Created attachment 34473
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34473&action=edit
possible fix
BTW: I used binutils-2.25 here.
This patch seems to work, and I can build libjava with it.
Excl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64640
--- Comment #1 from Bernd Edlinger ---
Created attachment 34468
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34468&action=edit
possible fix
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
I used r219767:
depbase=`echo src/x86/sysv.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ./libtool --mode=compile /home/ED/gcc-build/./gcc/xgcc
-B/home/ED/gcc-build/./gcc/ -B/home/E
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
I used r219767:
/home/ED/gcc-build/./gcc/xgcc -B/home/ED/gcc-build/./gcc/
-B/home/ED/install/i686-pc-cygwin/bin/ -B/home/ED/install/i686-pc-cygwin/lib/
-isystem /home/ED/install/i686-pc-cygwin/include -isystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #58 from Bernd Edlinger ---
IIRC it was first fixed in 4.9.0.
The known to fail above includes 4.9.0 but that is wrong.
Do you think this is still worth to be fixed in 4.8.5 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64310
--- Comment #3 from Bernd Edlinger ---
(In reply to Ramana Radhakrishnan from comment #2)
> Preprocessed file - command line options etc something that can help
> people reproduce this issue would be useful.
>
> This still an issue ?
It wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64350
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63288
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #18 from Bernd Edlinger ---
Hi Eric,
if I use kill -11, I would be really surprised to see
the process freeze.
It would be good to look at siginfo->si_code
and _not_ continue the normal exception handling
when the si_code is SI_USER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #16 from Bernd Edlinger ---
Well, it is at least not my opinion.
I see this bug as a security risk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #13 from Bernd Edlinger ---
(In reply to Eric Botcazou from comment #9)
> Not worth fixing until we have a bug report for real-life software.
So it looks like this not fixed yet.
I checked that my patch is still working.
Should I p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62060
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64566
--- Comment #1 from Bernd Edlinger ---
gcc-5-20150104 aka r219175 was working.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
I try to build this:
../gcc-5-20150111/configure --prefix=/home/ed/gnu/arm-v5te-linux-gnueabi
--target=arm-v5te-linux-gnueabi
--with-sysroot=/home/ed/gnu/sysroot-arm-v5te-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55441
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63251
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #17 from Bernd Edlinger ---
Oh, I see: I forgot to add -fstack-check.
After re-compiling with -fstack-check the modified test case passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #15 from Bernd Edlinger ---
you could avoid that scenario by probing say 4K of stack in __gnat_malloc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #14 from Bernd Edlinger ---
hmm, ok, but how about this:
--- ../gcc-trunk/gcc/testsuite/ada/acats/tests/cb/cb1010d.ada2014-05-24
19:26:45.338568486 +0200
+++ cb1010d.adb2015-01-04 12:55:21.458653242 +0100
@@ -29,14 +29,23 @@
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Hi,
with my TSAN Ada patch I see a lock-order-inversion in three test cases:
ed@w-ed:~/gnu/gcc-test$ TSAN_OPTIONS=second_deadlock_stack=1 ./c940006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Bernd Edlinger changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #11 from Bernd Edlinger ---
Sorry.
again the test case c380004
just with this little addition
begin
Test ("C380004",
"Check evaluation of discriminant expressions " &
"when the constraint depends on a disc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #9 from Bernd Edlinger ---
Sorry, Andrew,
a deadlock in the Ada exception handler is an Ada BUG
by definition.
Even if YOU can't fix it easily.
The memory could be pre-allocated as the call stack
and we should make it to the point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Bernd Edlinger changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #5 from Bernd Edlinger ---
but I cant see why a potential deadlock in an exception
handler is not a bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
Bernd Edlinger changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478
--- Comment #1 from Bernd Edlinger ---
I found this initially with TSAN:
RUN c52104x
^M
,.,. C52104X ACATS 2.5 15-01-03 04:12:21^M
C52104X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,^M
THE LENGTHS MUST MATCH; A
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
for instance c52104x:
gdb ./c52104x
b s-memory.adb:92
r
Starting program: /home/ed/gnu/gcc-test/c52104x
,.,. C52104X ACATS 2.5 15-01-03 04:40:03
C52104X CHECK THAT IN ARRAY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422
Bernd Edlinger changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #14 from Bernd Edlinger ---
Well,
that happened only once. and the problem did never ever repeat.
But my gut feeling is still that there is a race conditition.
However I have been recently working on TSAN a bit, and I have an
experi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422
Bernd Edlinger changed:
What|Removed |Added
Attachment #34341|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422
--- Comment #2 from Bernd Edlinger ---
Created attachment 34341
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34341&action=edit
Proposed Fix
this fixes string::erase(iterator, iterator)
and a few more templates that are missing as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422
--- Comment #1 from Bernd Edlinger ---
with -std=gnu++03 we get
call
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5eraseEN9__gnu_cxx17__normal_iteratorIPKcS4_EES9_
aka std::__cxx11::basic_string,
std::allocator >::erase(__gnu_cxx::__n
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
starting with around r218964, "New std::string implementation."
the following program does no longer link correctly:
cat test1.cc
#include
int
main()
{
std::string x;
x.erase(x.begi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64350
--- Comment #2 from Bernd Edlinger ---
(In reply to Dmitry Vyukov from comment #1)
> I've fixed a bunch of bugs in deadlock detector just few hours ago.
>
> Please re-test with these fixes:
>
> http://llvm.org/viewvc/llvm-project/compiler-rt/tr
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Hello,
I see this fatal error from the thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64336
--- Comment #3 from Bernd Edlinger ---
Yes, this patch seems to work...
But why did this only cause problems with template expansions and nothing else
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64336
--- Comment #1 from Bernd Edlinger ---
hmm...
in this example at tsan.c, instrument_expr()
is exiting twice here:
if (TREE_READONLY (base)
|| (TREE_CODE (base) == VAR_DECL
&& DECL_HARD_REGISTER (base)))
return false;
be
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
I noticed that all template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64310
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #19 from Bernd Edlinger ---
oh, I see now, in tsan/tsan_rtl.cc
// Shadow stack maintenance can be replaced with
// stack unwinding during trace switch (which presumably must be faster).
DCHECK_GE(thr->shadow_stack_pos, thr->sha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #18 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #15)
> I've been running the tests for quite a while and RSS didn't increase in top
> at all.
>
> As for "and no calls to other functions", sure, I haven't changed a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #14 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #7)
> Note, I don't see any kind of memory leak on any of the testcases.
> Sure, calling __tsan_func_entry many times is of course wrong.
> As for #c5, clang doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #4 from Bernd Edlinger ---
and now I see that his example is mis-compiled too:
cat test1.cpp
int test1(int x)
{
abc:
x=x+1;
__builtin_printf("Test %d\n", x);
if (x<9)
goto abc;
return 0;
}
is transformed to this in test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265
--- Comment #1 from Bernd Edlinger ---
with current trunk we get this in test.cpp.176t.cplxlower0:
static void std::_Destroy_aux< >::__destroy(_ForwardIterator,
_ForwardIterator) [with _ForwardIterator = std::basic_string*; bool
= false] (struc
: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Created attachment 34249
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34249&action=edit
test case
starting with r217669 tsan instrumentation gets wrong code:
g++ -g -fsanitize=thread test.cpp
./a.out
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049
Bernd Edlinger changed:
What|Removed |Added
Attachment #34094|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049
Bernd Edlinger changed:
What|Removed |Added
Attachment #34092|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049
Bernd Edlinger changed:
What|Removed |Added
Attachment #34090|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049
Bernd Edlinger changed:
What|Removed |Added
Attachment #34091|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049
--- Comment #5 from Bernd Edlinger ---
(In reply to Andrew Pinski from comment #4)
> v.value.LocalizedText = (LocalizedTextStruct*) "Localized Text";
>
>
> if you access v.value.LocalizedText as a LocalizedTextStruct the above
> causes undefin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049
--- Comment #3 from Bernd Edlinger ---
Created attachment 34092
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34092&action=edit
ValueHelper.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049
--- Comment #2 from Bernd Edlinger ---
Created attachment 34091
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34091&action=edit
ValueHelper2.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049
--- Comment #1 from Bernd Edlinger ---
Created attachment 34090
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34090&action=edit
ValueHelper1.cpp
: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
the attached C++ program is mis-compiled with recent GCC trunk at -O3
g++ -O3 ValueHelper1.cpp ValueHelper2.cpp
./a.out
Assertion failed at ValueHelper1.cpp(9): Unexpected null pointer
Segmentation fault (core dumped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63917
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Obtained from SVN: trunk revision 217020
../gcc-5-20141102/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=all,ada,go,obj-c++ --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63574
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564
--- Comment #3 from Bernd Edlinger ---
In the original example (it was ported from windows,
and the windows semaphores are completely immune
against this kind of error) the sem_post were in
*another* thread and there were several milliseconds
bet
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Created attachment 33737
--> ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439
--- Comment #2 from Bernd Edlinger ---
Created attachment 33652
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33652&action=edit
vect-33.c.116t.vect
601 - 700 of 958 matches
Mail list logo
