On 18 May 2017 at 13:28, Dehao Chen wrote:
> My understanding is that r302938 makes clang generate incorrect code
> (clang itself), which lead to unexpected clang behavior. Is it correct?
>
Yes, I believe so, specifically when the stage2 clang is built with
-fsanitize=memory and (I think) -O2.
My understanding is that r302938 makes clang generate incorrect code (clang
itself), which lead to unexpected clang behavior. Is it correct? If yes,
how can I reproduce this issue so that I can try to triage/fix the problem?
Thanks,
Dehao
On Thu, May 18, 2017 at 1:22 PM, Richard Smith
wrote:
>
On 18 May 2017 1:19 pm, "Richard Smith" wrote:
On 18 May 2017 1:14 pm, "Dehao Chen" wrote:
What's the issue? Build breaking? Performance regression? It's not clear
from the limit info in this thread...
r302938 introduced or exposed a miscompile that causes a stage2 msan build
of Clang to misb
On 18 May 2017 1:14 pm, "Dehao Chen" wrote:
What's the issue? Build breaking? Performance regression? It's not clear
from the limit info in this thread...
r302938 introduced or exposed a miscompile that causes a stage2 msan build
of Clang to misbehave:
http://lab.llvm.org:8011/builders/sanitiz
Clang produces some confusing macro errors.
According to Richard it's miscompilation:
https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg57270.html
On Thu, May 18, 2017 at 1:14 PM Dehao Chen wrote:
> What's the issue? Build breaking? Performance regression? It's not clear
> from the limi
What's the issue? Build breaking? Performance regression? It's not clear
from the limit info in this thread...
Dehao
On Thu, May 18, 2017 at 1:02 PM, Vitaly Buka wrote:
> Local build: r302937 no issue, r302938 has issue.
>
> On Thu, May 18, 2017 at 7:23 AM Dehao Chen wrote:
>
>> Could you give
Local build: r302937 no issue, r302938 has issue.
On Thu, May 18, 2017 at 7:23 AM Dehao Chen wrote:
> Could you give some context on how r302938 is related to this?
>
> Thanks,
> Dehao
>
> On Wed, May 17, 2017 at 11:14 PM, Vitaly Buka
> wrote:
>
>> +Dehao Chen
>> it started from r302938
>>
>>
Could you give some context on how r302938 is related to this?
Thanks,
Dehao
On Wed, May 17, 2017 at 11:14 PM, Vitaly Buka wrote:
> +Dehao Chen
> it started from r302938
>
> On Wed, May 17, 2017 at 8:09 PM Jordan Rose via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Thanks, this is
+Dehao Chen
it started from r302938
On Wed, May 17, 2017 at 8:09 PM Jordan Rose via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Thanks, this is helpful!
>
>
> On May 16, 2017, at 12:26, Richard Smith wrote:
>
> On 15 May 2017 at 10:28, Jordan Rose via cfe-commits <
> cfe-commits@lists.ll
Thanks, this is helpful!
> On May 16, 2017, at 12:26, Richard Smith wrote:
>
> On 15 May 2017 at 10:28, Jordan Rose via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Hi, Richard. Swift was using this information in order to put imported macros
> in a particular context. It wouldn
I grabbed a clang binary from the build bot and have been trying to figure
out what's gone wrong. So far it looks like the msan-enabled stage1
miscompiled some part of clang's lib/Lex/TokenLexer.cpp (but I'm not sure
of that). It *looks* like TokenLexer::ExpandFunctionArguments is corrupting
the Fl
Actually it was not "-w" but -DCMAKE_BUILD_TYPE=Release
Also now I am not sure that it was r302966.
Looking.
On Wed, May 17, 2017 at 2:15 PM Vitaly Buka wrote:
> And looks like "-w" is needed to trigger this.
>
> On Wed, May 17, 2017 at 1:43 PM Vitaly Buka wrote:
>
>> On Tue, May 16, 2017 at 12
And looks like "-w" is needed to trigger this.
On Wed, May 17, 2017 at 1:43 PM Vitaly Buka wrote:
> On Tue, May 16, 2017 at 12:19 PM Richard Smith
> wrote:
>
>> On 16 May 2017 at 11:54, Vitaly Buka wrote:
>>
>>> The patch breaks this test
>>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-
On Tue, May 16, 2017 at 12:19 PM Richard Smith
wrote:
> On 16 May 2017 at 11:54, Vitaly Buka wrote:
>
>> The patch breaks this test
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/1349/steps/check-clang%20msan/logs/stdio
>>
>
> Given the nature of this change, that's
On 15 May 2017 at 10:28, Jordan Rose via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Hi, Richard. Swift was using this information in order to put imported
> macros in a particular context. It wouldn't surprise me to hear that we
> were doing it wrong, and that there's a better way to go fr
On 16 May 2017 at 11:54, Vitaly Buka wrote:
> The patch breaks this test http://lab.llvm.org:8011/
> builders/sanitizer-x86_64-linux-bootstrap/builds/1349/
> steps/check-clang%20msan/logs/stdio
>
Given the nature of this change, that's a surprise, but anything's
possible. How sure are you that i
The patch breaks this test
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/1349/steps/check-clang%20msan/logs/stdio
Script:
--
/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm_build_msan/./bin/clang
-cc1 -internal-isystem
/mnt/b/sanitizer-buildbot2/s
Hi, Richard. Swift was using this information in order to put imported macros
in a particular context. It wouldn't surprise me to hear that we were doing it
wrong, and that there's a better way to go from a macro back to a module, but
is there a recommended replacement?
Thanks,
Jordan
> On Ma
Author: rsmith
Date: Fri May 12 18:40:52 2017
New Revision: 302966
URL: http://llvm.org/viewvc/llvm-project?rev=302966&view=rev
Log:
Remove unused tracking of owning module for MacroInfo objects.
Modified:
cfe/trunk/include/clang/Lex/MacroInfo.h
cfe/trunk/include/clang/Lex/Preprocessor.h
19 matches
Mail list logo
