在 2018-08-10 06:20, Kim Gräsman 写道:
On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely
wrote:
If GCC 4.9.3 thinks there's an aliasing violation it might
misoptimise. It doesn't matter if it's right or not, it matters if it
treats the code as undefined or not.
And apparently GCC does think ther
Snapshot gcc-7-20180809 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180809/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely
wrote:
>
> If GCC 4.9.3 thinks there's an aliasing violation it might
> misoptimise. It doesn't matter if it's right or not, it matters if it
> treats the code as undefined or not.
>
> And apparently GCC does think there's a violation, because it w
On Thu, 9 Aug 2018 at 22:59, Kim Gräsman wrote:
>
> Thanks all for pitching in to help!
>
> On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall wrote:
> >
> > Obviously if there really is something illegal here we should fix it in
> > LLVM, but it looks like this warning is a false positive (anyone disagr
Thanks all for pitching in to help!
On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall wrote:
>
> Obviously if there really is something illegal here we should fix it in
> LLVM, but it looks like this warning is a false positive (anyone disagree?)
The little I've read about strict aliasing rules leaves
On 08/09/2018 02:38 AM, daro...@o2.pl wrote:
Hello, I wanted to ask what model for
branch coverage does gcov use?
There is a comment at the start of gcc/profile.c that gives some details
on how it works. It is computing execution counts for edges in the
control flow graph. As for which ed
Wcoverage-mismatch is meant to "Warn in case profiles in -fprofile-use do not
match"
Currently, gcc compiler warns about the following two cases of source code
changes which alert the programmer to re-generate the profiles :
1. Control flow mismatch
If functions' control flow has been altered
Hi Sam,
Thanks for your response!
Please review it, thanks a lot!
A patch by Loongson!
diff --git a/include/llvm/Support/JSON.h b/include/llvm/Support/JSON.h
index da3c5ea..fd60b40 100644
--- a/include/llvm/Support/JSON.h
+++ b/include/llvm/Support/JSON.h
@@ -452,7 +452,10 @@ private:
new
Author of the problematic code here. Thanks everyone, and sorry to have
caused difficulty!
Obviously if there really is something illegal here we should fix it in
LLVM, but it looks like this warning is a false positive (anyone disagree?)
Still if there's a simple source-level workaround, or we c
On Thu, 9 Aug 2018 at 12:04, Leslie Zhai wrote:
>
> Hi Jonathan,
>
> Thanks for your response!
>
> So workaround for Kim's issue is bootstrap old version LLVM with GCC 4/5
> to build old clang, then bootstrap latest LLVM with old clang.
It would be much easier to just use -fno-strict-aliasing with
Hi Jonathan,
Thanks for your response!
So workaround for Kim's issue is bootstrap old version LLVM with GCC 4/5
to build old clang, then bootstrap latest LLVM with old clang.
在 2018年08月09日 17:16, Jonathan Wakely 写道:
On Thu, 9 Aug 2018 at 03:09, Leslie Zhai wrote:
Could you test to compile
Hello, I wanted to ask what model for
branch coverage does gcov use? Would it be branch, decision, condition
coverage or some modification like branch condition, branch condition
combination or modified condition decision coverage (MCDC)? Also for a simple
example as below: uint8 Func(uint8
On Thu, 9 Aug 2018 at 03:09, Leslie Zhai wrote:
> Could you test to compile LLVM with GCC old versions 4/5/6? Does it need
> to backport your patch to GCC old version?
GCC versions before 6.4 are not supported, so no backports will happen
to 4.x or 5 releases and I doubt anybody's going to routine
13 matches
Mail list logo
