from:"Romanova, Katya via cfe\-commits"

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

2015-10-13 Thread Romanova, Katya via cfe-commits

Thanks! I just committed the patch.
Katya.

> -Original Message-
> From: Jonathan Roelofs [mailto:jonat...@codesourcery.com]
> Sent: Tuesday, October 13, 2015 3:40 PM
> To: Romanova, Katya; al...@leftfield.org; Robinson, Paul;
> echri...@gmail.com; filcab+llvm.phabrica...@gmail.com;
> jonat...@codesourcery.com
> Cc: Bedwell, Greg; pierregoussea...@gmail.com;
> an...@korobeynikov.info; geek4ci...@gmail.com; cfe-
> comm...@lists.llvm.org; chisophu...@gmail.com
> Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain
> 
> jroelofs accepted this revision.
> jroelofs added a reviewer: jroelofs.
> jroelofs added a comment.
> 
> One small suggestion. Otherwise, this still LGTM.
> 
> 
> 
> Comment at: lib/Driver/ToolChains.cpp:4078 @@ +4077,3 @@
> +  // should be /host_tools/bin.
> +  const char *EnvValue = getenv("SCE_PS4_SDK_DIR");  if (EnvValue &&
> + !llvm::sys::fs::exists(EnvValue))
> 
> It might help to structure this:
> 
> const char *EnvValue = getenv("SCE_PS4_SDK_DIR");
> if (EnvValue && !llvm::sys::fs::exists(EnvValue))
>   getDriver().Diag(clang::diag::warn_drv_ps4_sdk_dir) << EnvValue;
> 
> SmallString<512> PS4SDKDir(EnvValue ? EnvValue : getDriver().Dir);
> if (!EnvValue) {
>   llvm::sys::path::append(PS4SDKDir, "/../../");
> }
> 
> 
> as:
> 
> SmallString<512> PS4SDKDir;
> if (const char *EnvValue = getenv("SCE_PS4_SDK_DIR"))
>   if (!llvm::sys::fs::exists(EnvValue))
> getDriver().Diag(clang::diag::warn_drv_ps4_sdk_dir) << EnvValue;
> 
>   PS4SDKDir = EnvValue;
> } else {
>   PS4SDKDir = getDriver().Dir;
>   llvm::sys::path::append(PS4SDKDir, "/../../");
> }
> 
> 
> Repository:
>   rL LLVM
> 
> http://reviews.llvm.org/D13482
> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

2015-10-13 Thread Romanova, Katya via cfe-commits

Sorry for causing the trouble with the build. I will try to look later why my 
partial rebuild didn't catch the issue.
I have fixed the error, rebuilt and ran the tests.

This is a very big patch. Please be understanding, because this patch has a big 
impact. I apologize in advance if it causes some other problems in the future.

Katya.

> -Original Message-
> From: Ed Maste [mailto:ema...@freebsd.org]
> Sent: Tuesday, October 13, 2015 5:13 PM
> To: Romanova, Katya; al...@leftfield.org; Robinson, Paul;
> echri...@gmail.com; filcab+llvm.phabrica...@gmail.com;
> jonat...@codesourcery.com
> Cc: ema...@freebsd.org; Bedwell, Greg; pierregoussea...@gmail.com;
> an...@korobeynikov.info; geek4ci...@gmail.com; cfe-
> comm...@lists.llvm.org; chisophu...@gmail.com
> Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain
> 
> emaste added a subscriber: emaste.
> 
> 
> Comment at: cfe/trunk/lib/Driver/ToolChains.cpp:4080
> @@ +4079,3 @@
> +  SmallString<512> PS4SDKDir;
> +  if (const char *EnvValue = getenv("SCE_PS4_SDK_DIR"))
> +if (!llvm::sys::fs::exists(EnvValue))
> 
> Looks like a missing { here
> 
> 
> Repository:
>   rL LLVM
> 
> http://reviews.llvm.org/D13482
> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

2015-10-14 Thread Romanova, Katya via cfe-commits

Hi Sean,

I don’t think that the whole patch should have been reverted. There were much 
easier way to make the PS4 bot green. A single test could have been marked as 
“XFAIL: ps4” for a few hours until a better solution is implemented. Reverting 
this huge patch is more drastic measure that might cause more problems later.

As you saw in my previous email, I kept an eye on the bots, noticed the failure 
on PS4 buildbot, explained why it happened in the email and ask community for 
an opinion if it could be temporarily marked as “XFAIL” for ps4 only. I had to 
leave work at certain point. When I got home, I saw that you reverted the whole 
fix. Now I will have to go through all the pain with maintaining a huge commit, 
instead of making one line change affecting one of the tests on PS4 platform 
only… But, I guess, if it’s a general practice,  then it’s a different story. I 
was not aware of this practice and I thought that the other solution was much 
more reasonable.

Thank you for letting me know about LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4. 
I will definitely run it before the next commit.

Katya.


From: Sean Silva [mailto:chisophu...@gmail.com]
Sent: Tuesday, October 13, 2015 11:56 PM
To: Eric Christopher
Cc: reviews+d13482+public+a1a9627af638c...@reviews.llvm.org; Romanova, Katya; 
Alex Rosenberg; Robinson, Paul; filcab+llvm.phabrica...@gmail.com; Jonathan 
Roelofs; Bedwell, Greg; pierregoussea...@gmail.com; Anton Korobeynikov; Takumi 
NAKAMURA; cfe-commits
Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain



On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
mailto:echri...@gmail.com>> wrote:

On Tue, Oct 13, 2015 at 11:38 PM Sean Silva 
mailto:chisophu...@gmail.com>> wrote:
On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
mailto:echri...@gmail.com>> wrote:
It was already reverted, but I agree, let's get this fixed first.

It was reintroduced in r250252. It is breaking 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362


Ah, I missed that. Yeah, please go ahead and revert for now.

reverted in r250273
(bot is back to green: 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1363
 )

Katya - remember to run the tests with 
LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 (and also remember to keep an eye on 
the bots after committing)

-- Sean Silva


Thanks!

-eric

-- Sean Silva


Thanks!

-eric

On Tue, Oct 13, 2015 at 11:33 PM Sean Silva 
mailto:chisophu...@gmail.com>> wrote:
On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova 
mailto:katya_roman...@playstation.sony.com>>
 wrote:
kromanova added a comment.

Hi,

The initial PS4 patch caused a test failure (debug-options.c) on the PS4 bot. I 
suspect that I know why the problem happens, but I'm not sure what will be the 
best way to handle it. If someone knows how to fix this test more "elegantly", 
I would appreciate their advice.

FAIL: Clang :: Driver/debug-options.c (3509 of 24708)

- TEST 'Clang :: Driver/debug-options.c' FAILED 

Script:
---

/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
  -### -c -g 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 -target x86_64-linux-gnu 2>&1  | 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-


/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
  -### -g 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 2>&1 | 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=CI 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c


Exit Code: 1

Command Output (stderr):


/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c:139:8:
 error: expected string not found in input
// CI: "-dwarf-column-info"

  ^

:1:1: note: scanning from here
clang version 3.8.0 (trunk 250262)
^
:5:438: note: possible intended match here
 
"/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-3.8"
 "-cc1" "-triple" "x86_64-scei-ps4" "-em

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

2015-10-14 Thread Romanova, Katya via cfe-commits

Thank you, Filipe!
Katya.

Sent from my iPhone

On Oct 14, 2015, at 6:12 AM, "Filipe Cabecinhas" 
mailto:filcab+llvm.phabrica...@gmail.com>> 
wrote:

Hi all,

I have harnessed the powers of time zones and did the last tweak we needed to 
get it comitted.
It's still going through some bots, but I don't foresee big problems. The fast 
bots liked it.

Thanks to everyone that reviewed it and worked on it!

  Filipe

On Wed, Oct 14, 2015 at 8:54 AM, Romanova, Katya 
mailto:katya_roman...@playstation.sony.com>>
 wrote:
Hi Sean,

I don’t think that the whole patch should have been reverted. There were much 
easier way to make the PS4 bot green. A single test could have been marked as 
“XFAIL: ps4” for a few hours until a better solution is implemented. Reverting 
this huge patch is more drastic measure that might cause more problems later.

As you saw in my previous email, I kept an eye on the bots, noticed the failure 
on PS4 buildbot, explained why it happened in the email and ask community for 
an opinion if it could be temporarily marked as “XFAIL” for ps4 only. I had to 
leave work at certain point. When I got home, I saw that you reverted the whole 
fix. Now I will have to go through all the pain with maintaining a huge commit, 
instead of making one line change affecting one of the tests on PS4 platform 
only… But, I guess, if it’s a general practice,  then it’s a different story. I 
was not aware of this practice and I thought that the other solution was much 
more reasonable.

Thank you for letting me know about LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4. 
I will definitely run it before the next commit.

Katya.


From: Sean Silva [mailto:chisophu...@gmail.com]
Sent: Tuesday, October 13, 2015 11:56 PM
To: Eric Christopher
Cc: 
reviews+d13482+public+a1a9627af638c...@reviews.llvm.org;
 Romanova, Katya; Alex Rosenberg; Robinson, Paul; 
filcab+llvm.phabrica...@gmail.com; 
Jonathan Roelofs; Bedwell, Greg; 
pierregoussea...@gmail.com; Anton 
Korobeynikov; Takumi NAKAMURA; cfe-commits
Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain



On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
mailto:echri...@gmail.com>> wrote:

On Tue, Oct 13, 2015 at 11:38 PM Sean Silva 
mailto:chisophu...@gmail.com>> wrote:
On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
mailto:echri...@gmail.com>> wrote:
It was already reverted, but I agree, let's get this fixed first.

It was reintroduced in r250252. It is breaking 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362


Ah, I missed that. Yeah, please go ahead and revert for now.

reverted in r250273
(bot is back to green: 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1363
 )

Katya - remember to run the tests with 
LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 (and also remember to keep an eye on 
the bots after committing)

-- Sean Silva


Thanks!

-eric

-- Sean Silva


Thanks!

-eric

On Tue, Oct 13, 2015 at 11:33 PM Sean Silva 
mailto:chisophu...@gmail.com>> wrote:
On Tue, Oct 13, 2015 at 7:51 PM, Katya Romanova 
mailto:katya_roman...@playstation.sony.com>>
 wrote:
kromanova added a comment.

Hi,

The initial PS4 patch caused a test failure (debug-options.c) on the PS4 bot. I 
suspect that I know why the problem happens, but I'm not sure what will be the 
best way to handle it. If someone knows how to fix this test more "elegantly", 
I would appreciate their advice.

FAIL: Clang :: Driver/debug-options.c (3509 of 24708)

- TEST 'Clang :: Driver/debug-options.c' FAILED 

Script:
---

/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
  -### -c -g 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 -target x86_64-linux-gnu 2>&1  | 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=G /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-


/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/clang
  -### -g 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
 2>&1 | 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
 -check-prefix=CI 
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/debug-options.c
---

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

2015-10-14 Thread Romanova, Katya via cfe-commits

Filipe,
I have one question regarding the change in debug-option.c that you made to get 
the builds green again… (r250294).

Basically you changed the generic run line that used to test the drivers for 
every single platform
// RUN: %clang -### -g %s 2>&1 | FileCheck -check-prefix=CI %s

into the run line that tests x86_64 drivers only.
// RUN: %clang -### -g -target x86_64-unknown-unknown %s 2>&1 \
// | FileCheck -check-prefix=CI %s

By making this change, we reduced driver coverage for the other platforms, e.g. 
AMD.  This run line will continue to pass for AMD irrespective of whether the 
AMD driver enabled or disabled emitting column information by default. I 
suspect that *non*-x86_64 developers won't be happy that we reduced their 
drivers’ test coverage without letting them know.

Is there a better way to address this issue?

From what I understand, it’s impossible now to execute a specific RUN line for 
all the platforms, except platform . However, it’s easy to do it for the 
whole file (XFAIL: ). Does anyone know how hard it would be to expand lit 
functionality to do XFAIL:  for a block of RUN lines in a file (e.g. XFAIL 
: begin:  …. XFAIL : end : ? Or, even a simpler approach: force XFAIL 
to take effect only for the RUN lines that follow XFAIL line. It will 
definitely add much more power/flexibility to FAIL functionality in lit. It 
might also reduce test code duplication. What do you think?

But for now (for our specific problem)  maybe it’s better to remove the run 
lines that work differently for PS4 and for the rest of the world from 
debug_options.c  file and place them into a ps4 specific file (e.g. 
ps4-Gcolumn-info.c) and into non-ps4 generic file (e.g gcolumn-info.c) and make 
gcolumn-info.c to XFAIL for PS4. We could do this extraction for gcolumn_info, 
debug_aranges, and anything else that is different for PS4 and everyone else,

Katya.


From: fil...@gmail.com [mailto:fil...@gmail.com] On Behalf Of Filipe Cabecinhas
Sent: Wednesday, October 14, 2015 6:11 AM
To: Romanova, Katya
Cc: Sean Silva; Eric Christopher; 
reviews+d13482+public+a1a9627af638c...@reviews.llvm.org; Alex Rosenberg; 
Robinson, Paul; Jonathan Roelofs; Bedwell, Greg; pierregoussea...@gmail.com; 
Anton Korobeynikov; Takumi NAKAMURA; cfe-commits
Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

Hi all,

I have harnessed the powers of time zones and did the last tweak we needed to 
get it comitted.
It's still going through some bots, but I don't foresee big problems. The fast 
bots liked it.

Thanks to everyone that reviewed it and worked on it!

  Filipe

On Wed, Oct 14, 2015 at 8:54 AM, Romanova, Katya 
mailto:katya_roman...@playstation.sony.com>>
 wrote:
Hi Sean,

I don’t think that the whole patch should have been reverted. There were much 
easier way to make the PS4 bot green. A single test could have been marked as 
“XFAIL: ps4” for a few hours until a better solution is implemented. Reverting 
this huge patch is more drastic measure that might cause more problems later.

As you saw in my previous email, I kept an eye on the bots, noticed the failure 
on PS4 buildbot, explained why it happened in the email and ask community for 
an opinion if it could be temporarily marked as “XFAIL” for ps4 only. I had to 
leave work at certain point. When I got home, I saw that you reverted the whole 
fix. Now I will have to go through all the pain with maintaining a huge commit, 
instead of making one line change affecting one of the tests on PS4 platform 
only… But, I guess, if it’s a general practice,  then it’s a different story. I 
was not aware of this practice and I thought that the other solution was much 
more reasonable.

Thank you for letting me know about LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4. 
I will definitely run it before the next commit.

Katya.


From: Sean Silva [mailto:chisophu...@gmail.com]
Sent: Tuesday, October 13, 2015 11:56 PM
To: Eric Christopher
Cc: 
reviews+d13482+public+a1a9627af638c...@reviews.llvm.org;
 Romanova, Katya; Alex Rosenberg; Robinson, Paul; 
filcab+llvm.phabrica...@gmail.com; 
Jonathan Roelofs; Bedwell, Greg; 
pierregoussea...@gmail.com; Anton 
Korobeynikov; Takumi NAKAMURA; cfe-commits
Subject: Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain



On Tue, Oct 13, 2015 at 11:40 PM, Eric Christopher 
mailto:echri...@gmail.com>> wrote:

On Tue, Oct 13, 2015 at 11:38 PM Sean Silva 
mailto:chisophu...@gmail.com>> wrote:
On Tue, Oct 13, 2015 at 11:33 PM, Eric Christopher 
mailto:echri...@gmail.com>> wrote:
It was already reverted, but I agree, let's get this fixed first.

It was reintroduced in r250252. It is breaking 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362


Ah, I missed that. Yeah, please go ahead and revert for now.

RE: [PATCH] D16913: Adding doxygen comments to the LLVM intrinsics (part 4, pmmintrin.h)

2016-02-04 Thread Romanova, Katya via cfe-commits

Thank you!
Paul Robinson did a very detailed code review yesterday, so I suspect that this 
doxygen comment patch is of very good quality. ☺
Katya.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Thursday, February 04, 2016 6:47 PM
To: reviews+d16913+public+13cb39057c425...@reviews.llvm.org; Romanova, Katya; 
Gao, Yunzhong; jonat...@codesourcery.com; griboz...@gmail.com; 
craig.top...@gmail.com; Robinson, Paul
Cc: cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D16913: Adding doxygen comments to the LLVM intrinsics 
(part 4, pmmintrin.h)

(Without looking)

Please go ahead and feel free to commit any documentation to the intrinsic 
files. :)

On Thu, Feb 4, 2016, 5:59 PM Katya Romanova 
mailto:katya_roman...@playstation.sony.com>>
 wrote:
kromanova created this revision.
kromanova added reviewers: ygao, echristo, jroelofs, gribozavr, craig.topper, 
probinson.
kromanova added a subscriber: cfe-commits.
kromanova set the repository for this revision to rL LLVM.

Hello,

Here is the patch with the doxygen comments for the intrinsincs in the header 
file pmmintrin.h.
The doxygen comments are automatically generated based on SCE internal 
intrinsics document using DCG tool that I wrote.

I will submit more doxygen comments for the other intrinsic header files as 
soon as this patch is approved.

Here is the link to the general discussion about adding comments to x86 
intrinsics headers.
http://permalink.gmane.org/gmane.comp.compilers.clang.devel/42032

Here are the links to the similar code reviews for the doxygen comments other 
header files.

http://reviews.llvm.org/D8762 (closed)
http://reviews.llvm.org/D15999 (closed)
http://reviews.llvm.org/D16562 (closed)

Katya.

Repository:
  rL LLVM

http://reviews.llvm.org/D16913

Files:
  pmmintrin.h
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D17021: Adding doxygen comments to the LLVM intrinsics (part 5, f16cintrin.h)

2016-02-10 Thread Romanova, Katya via cfe-commits

My apologies…

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Tuesday, February 09, 2016 4:42 PM
To: reviews+d17021+public+89c4dbb2f75e8...@reviews.llvm.org; Romanova, Katya
Cc: Gao, Yunzhong; Robinson, Paul; Eric Christopher; Dmitri Gribenko; Craig 
Topper; Jonathan Roelofs; cfe-commits
Subject: Re: [PATCH] D17021: Adding doxygen comments to the LLVM intrinsics 
(part 5, f16cintrin.h)

It's best not to commit things without approval once they've been sent for 
review (the assumption being that if you asked for review it's because the 
change needed review - time doesn't change that fact) - if approval was given 
off-list (eg: on IRC) it's best to mention who gave it & where (& ideally the 
person should provide it on-list just for record keeping)

On Tue, Feb 9, 2016 at 4:16 PM, Katya Romanova via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
This revision was automatically updated to reflect the committed changes.
Closed by commit rL260333: This patch adds doxygen comments for all the 
intrinsincs in the header file… (authored by kromanova).

Changed prior to commit:
  http://reviews.llvm.org/D17021?vs=47299&id=47394#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17021

Files:
  cfe/trunk/lib/Headers/f16cintrin.h


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r260333 - This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

2016-02-10 Thread Romanova, Katya via cfe-commits

Hi Eric,
Everywhere else in this file formal parameter “a” is used. This one “__a”  was 
inconsistent.
However, if you don’t like it, I could change it back.

Katya.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Wednesday, February 10, 2016 3:16 PM
To: Romanova, Katya; cfe-commits@lists.llvm.org
Subject: Re: r260333 - This patch adds doxygen comments for all the intrinsincs 
in the header file f16cintrin.h. The doxygen comments are automatically 
generated based on Sony's intrinsics document.

On Tue, Feb 9, 2016 at 4:16 PM Ekaterina Romanova via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: kromanova
Date: Tue Feb  9 18:12:24 2016
New Revision: 260333

URL: http://llvm.org/viewvc/llvm-project?rev=260333&view=rev
Log:
This patch adds doxygen comments for all the intrinsincs in the header file 
f16cintrin.h. The doxygen comments are automatically generated based on Sony's 
intrinsics document.

-_mm_cvtph_ps(__m128i __a)
+_mm_cvtph_ps(__m128i a)
 {
-  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)__a);
+  return (__m128)__builtin_ia32_vcvtph2ps((__v8hi)a);
 }

Ur? What's with this change?

-eric
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r260333 - This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

2016-02-11 Thread Romanova, Katya via cfe-commits

Sure. I’ll change it. Do you mind if I do it when I’m back from vacation (i.e. 
a couple of weeks from now)?
I will send a patch.
Thank you!
Katya.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Wednesday, February 10, 2016 5:08 PM
To: Romanova, Katya; cfe-commits@lists.llvm.org
Subject: Re: r260333 - This patch adds doxygen comments for all the intrinsincs 
in the header file f16cintrin.h. The doxygen comments are automatically 
generated based on Sony's intrinsics document.

On Wed, Feb 10, 2016 at 5:07 PM Joerg Sonnenberger 
mailto:jo...@britannica.bec.de>> wrote:
On Thu, Feb 11, 2016 at 12:18:49AM +, Eric Christopher via cfe-commits 
wrote:
> Mostly that you didn't mention it in your commit message.
>
> I'd rather prefer the rest of the file be changed to match the __ rather
> than the other way around :)

Depends. If it is a macro, not using __ is fine. If it is an inline
function, it *must* use the protected namespace, since an application can
#define a fancy junk here.

Yep. Which is why I'd prefer the rest of the file changed to match the __. I 
was just trying to get Katya to do it :)

-eric
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)

2016-02-24 Thread Romanova, Katya via cfe-commits

Hello,

I don’t think it will too hard to convert C++ style doxygen comments into C 
style doxygen comments by writing a post-processing python script. However, at 
first we need to decide if we really want to do that. If so, we need to settle 
on the exact format. After that, I need to make sure that the comments in the 
new format will be rendered correctly in MS Tooltips, XCode, online 
documentation and PS4 internal documentation. This discussion + investigation 
might take a few days.

Before we start discussing the exact format, I want to make sure that we really 
want to change to C-style doxygen comments.
Here are my not-so-strong arguments against it:

-There currently are 257 occurrences C++ style comments in 14 other 
header files in /llvm/tools/clang/lib/Headers directory (I’m talking about the 
files that I didn’t touch). C++ style comments were there for AGES and nobody 
complained so far. If we decide to change C++ style doxygen comments -> 
C-style, we also need to change all regular C++ comments to C-style in these 
header files.

-c99 (and later) supports C++ style comments, while I c89 doesn’t. I’m 
not sure if we have users that still use c89 format and x86 intrinsic headers 
at the same time.

-C++ style doxygen comments are more pretty and readable compared to 
C-style comment (though it might be my subjective opinion).

Let me know what you think.

I will try to get Dmitri Gribenko’s opinion. He did a lot of work on doxygen in 
LLVM. I’m curious what he thinks about Javadoc style format.

Katya.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Tuesday, February 23, 2016 10:51 PM
To: reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org; Romanova, Katya; 
Gao, Yunzhong; griboz...@gmail.com; craig.top...@gmail.com; Robinson, Paul
Cc: Bedwell, Greg; cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics 
(part 6, popcntintrin.h)

Yeah, we should be doing this. Nice catch Paul and Greg.

On Tue, Feb 23, 2016, 10:34 PM Greg Bedwell 
mailto:greg_bedw...@sn.scee.net>> wrote:
gbedwell added a subscriber: gbedwell.
gbedwell added a comment.

In http://reviews.llvm.org/D17550#360177, @probinson wrote:

> One question I have, which shouldn't block this (as we've done several like 
> this already):
>  Is is okay to be using C++ style comments in these headers?
>  (Is there a C-style comment that Doxygen recognizes?)

There are a few various formats that Doxygen supports.  Looking at headers from 
llvm-c the most common convention appears to be JavaDoc style, although there 
are a few examples of other supported styles floating around the codebase.  
E.g. from include/llvm-c/lto.h using JavaDoc style:

/**

- Diagnostic handler type.
- \p severity defines the severity.
- \p diag is the actual diagnostic.
- The diagnostic is not prefixed by any of severity keyword, e.g., 'error: '.
- \p ctxt is used to pass the context set with the diagnostic handler. *
- \since LTO_API_VERSION=7 */

-Greg

Repository:
  rL LLVM

http://reviews.llvm.org/D17550

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: D20468: [X86][AVX] Ensure zero-extension of _mm256_extract_epi8 and _mm256_extract_epi16

2016-05-20 Thread Romanova, Katya via cfe-commits

Hi Simon,
Thank you for the patch and for fixing the doxygen comments. There is no need 
to update Sony's intrinsics document. Very soon our  documentation team is 
planning to release the documentation based on the doxygen headers in the  
upstream headers, so your change will funnel through automatically.

Thank you !
Katya.

> -Original Message-
> From: Simon Pilgrim [mailto:llvm-...@redking.me.uk]
> Sent: Friday, May 20, 2016 6:17 AM
> To: llvm-...@redking.me.uk; mku...@google.com;
> craig.top...@gmail.com; Romanova, Katya; spa...@rotateright.com
> Cc: cfe-commits@lists.llvm.org
> Subject: [PATCH] D20468: [X86][AVX] Ensure zero-extension of
> _mm256_extract_epi8 and _mm256_extract_epi16
> 
> RKSimon created this revision.
> RKSimon added reviewers: mkuper, craig.topper, kromanova, spatel.
> RKSimon added a subscriber: cfe-commits.
> RKSimon set the repository for this revision to rL LLVM.
> 
> Ensure _mm256_extract_epi8 and _mm256_extract_epi16 zero extend their
> i8/i16 result to i32. This matches _mm_extract_epi8 and _mm_extract_epi16.
> 
> Fix for PR27594
> 
> Katya - I've updated the doxygen comments for _mm256_extract_epi8 and
> _mm256_extract_epi16, I guess this will need to be updated in Sony's
> intrinsics document for the next regeneration?
> 
> Repository:
>   rL LLVM
> 
> http://reviews.llvm.org/D20468
> 
> Files:
>   lib/Headers/avxintrin.h
>   test/CodeGen/avx-builtins.c
> 
> Index: test/CodeGen/avx-builtins.c
> ===
> --- test/CodeGen/avx-builtins.c
> +++ test/CodeGen/avx-builtins.c
> @@ -314,21 +314,19 @@
>return _mm256_dp_ps(A, B, 7);
>  }
> 
> -// FIXME: ZEXT instead of SEXT
>  int test_mm256_extract_epi8(__m256i A) {
>// CHECK-LABEL: test_mm256_extract_epi8
>// CHECK: and i32 %{{.*}}, 31
>// CHECK: extractelement <32 x i8> %{{.*}}, i32 %{{.*}}
> -  // CHECK: ext i8 %{{.*}} to i32
> +  // CHECK: zext i8 %{{.*}} to i32
>return _mm256_extract_epi8(A, 32);
>  }
> 
> -// FIXME: ZEXT instead of SEXT
>  int test_mm256_extract_epi16(__m256i A) {
>// CHECK-LABEL: test_mm256_extract_epi16
>// CHECK: and i32 %{{.*}}, 15
>// CHECK: extractelement <16 x i16> %{{.*}}, i32 %{{.*}}
> -  // CHECK: ext i16 %{{.*}} to i32
> +  // CHECK: zext i16 %{{.*}} to i32
>return _mm256_extract_epi16(A, 16);
>  }
> 
> Index: lib/Headers/avxintrin.h
> ===
> --- lib/Headers/avxintrin.h
> +++ lib/Headers/avxintrin.h
> @@ -1875,13 +1875,13 @@
>  /// \param __imm
>  ///An immediate integer operand with bits [3:0] determining which
> vector
>  ///element is extracted and returned.
> -/// \returns A 32-bit integer containing the extracted 16 bits of extended
> +/// \returns A 32-bit integer containing the extracted 16 bits of zero
> +extended
>  ///packed data.
>  static __inline int __DEFAULT_FN_ATTRS
>  _mm256_extract_epi16(__m256i __a, const int __imm)  {
>__v16hi __b = (__v16hi)__a;
> -  return __b[__imm & 15];
> +  return (unsigned short)__b[__imm & 15];
>  }
> 
>  /// \brief Takes a [32 x i8] vector and returns the vector element value @@
> -1897,13 +1897,13 @@  /// \param __imm
>  ///An immediate integer operand with bits [4:0] determining which
> vector
>  ///element is extracted and returned.
> -/// \returns A 32-bit integer containing the extracted 8 bits of extended
> packed
> -///data.
> +/// \returns A 32-bit integer containing the extracted 8 bits of zero
> extended
> +///packed data.
>  static __inline int __DEFAULT_FN_ATTRS
>  _mm256_extract_epi8(__m256i __a, const int __imm)  {
>__v32qi __b = (__v32qi)__a;
> -  return __b[__imm & 31];
> +  return (unsigned char)__b[__imm & 31];
>  }
> 
>  #ifdef __x86_64__
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)

2016-02-29 Thread Romanova, Katya via cfe-commits

Hi Dmitri,
Could you please let us know your opinion about C++ vs C-style doxygen 
comments. Read this thread for ‘pro’ and ‘con’ arguments about using C++ 
headers. Will LLVM online documentation look proper if we decide to use C-style 
headers? Which style do you personally prefer to see?

Note, that if there is any complaint in the future, it will take a couple of 
hours to write a python script to convert from C++ to C style doxygen comments.

Katya.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Wednesday, February 24, 2016 6:40 PM
To: Romanova, Katya; reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org; 
Gao, Yunzhong; griboz...@gmail.com; craig.top...@gmail.com; Robinson, Paul
Cc: Bedwell, Greg; cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics 
(part 6, popcntintrin.h)

Those are all compelling reasons for me. Let's go with whatever you and Dmitri 
think would be best for now. :)

-eric

On Wed, Feb 24, 2016 at 12:41 PM Romanova, Katya 
mailto:katya_roman...@playstation.sony.com>>
 wrote:
Hello,

I don’t think it will too hard to convert C++ style doxygen comments into C 
style doxygen comments by writing a post-processing python script. However, at 
first we need to decide if we really want to do that. If so, we need to settle 
on the exact format. After that, I need to make sure that the comments in the 
new format will be rendered correctly in MS Tooltips, XCode, online 
documentation and PS4 internal documentation. This discussion + investigation 
might take a few days.

Before we start discussing the exact format, I want to make sure that we really 
want to change to C-style doxygen comments.
Here are my not-so-strong arguments against it:

-There currently are 257 occurrences C++ style comments in 14 other 
header files in /llvm/tools/clang/lib/Headers directory (I’m talking about the 
files that I didn’t touch). C++ style comments were there for AGES and nobody 
complained so far. If we decide to change C++ style doxygen comments -> 
C-style, we also need to change all regular C++ comments to C-style in these 
header files.

-c99 (and later) supports C++ style comments, while I c89 doesn’t. I’m 
not sure if we have users that still use c89 format and x86 intrinsic headers 
at the same time.

-C++ style doxygen comments are more pretty and readable compared to 
C-style comment (though it might be my subjective opinion).

Let me know what you think.

I will try to get Dmitri Gribenko’s opinion. He did a lot of work on doxygen in 
LLVM. I’m curious what he thinks about Javadoc style format.

Katya.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Tuesday, February 23, 2016 10:51 PM
To: 
reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org;
 Romanova, Katya; Gao, Yunzhong; 
griboz...@gmail.com; 
craig.top...@gmail.com; Robinson, Paul
Cc: Bedwell, Greg; cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics 
(part 6, popcntintrin.h)

Yeah, we should be doing this. Nice catch Paul and Greg.

On Tue, Feb 23, 2016, 10:34 PM Greg Bedwell 
mailto:greg_bedw...@sn.scee.net>> wrote:
gbedwell added a subscriber: gbedwell.
gbedwell added a comment.

In http://reviews.llvm.org/D17550#360177, @probinson wrote:

> One question I have, which shouldn't block this (as we've done several like 
> this already):
>  Is is okay to be using C++ style comments in these headers?
>  (Is there a C-style comment that Doxygen recognizes?)

There are a few various formats that Doxygen supports.  Looking at headers from 
llvm-c the most common convention appears to be JavaDoc style, although there 
are a few examples of other supported styles floating around the codebase.  
E.g. from include/llvm-c/lto.h using JavaDoc style:

/**

- Diagnostic handler type.
- \p severity defines the severity.
- \p diag is the actual diagnostic.
- The diagnostic is not prefixed by any of severity keyword, e.g., 'error: '.
- \p ctxt is used to pass the context set with the diagnostic handler. *
- \since LTO_API_VERSION=7 */

-Greg

Repository:
  rL LLVM

http://reviews.llvm.org/D17550

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)

2016-03-01 Thread Romanova, Katya via cfe-commits

Hi Dmitri,
Thank you for your reply. I have double-checked that compiling a test invoking 
an intrinsic that has C++ style doxygen comments in the corresponding header 
doesn't cause compile-time errors/warnings in 
-std=c89 (and in  gnu89, c99, gnu99, c11, gnu11) modes.

I will continue committing the rest of the x86 inrinsics header files with 
C++-style doxygen comments, unless there are any other objections.
Katya.



> -Original Message-
> From: Dmitri Gribenko [mailto:griboz...@gmail.com]
> Sent: Tuesday, March 01, 2016 1:47 AM
> To: Romanova, Katya
> Cc: Eric Christopher;
> reviews+d17550+public+bc8ce213fd9db...@reviews.llvm.org; Robinson,
> Paul; Bedwell, Greg; cfe-commits@lists.llvm.org
> Subject: Re: [PATCH] D17550: Adding doxygen comments to the LLVM
> intrinsics (part 6, popcntintrin.h)
> 
> On Mon, Feb 29, 2016 at 10:59 AM, Romanova, Katya
>  wrote:
> > Hi Dmitri,
> >
> > Could you please let us know your opinion about C++ vs C-style doxygen
> > comments. Read this thread for ‘pro’ and ‘con’ arguments about using
> > C++ headers. Will LLVM online documentation look proper if we decide
> > to use C-style headers? Which style do you personally prefer to see?
> 
> There are C comments that both Doxygen and Clang recognize well, equally
> well to C++ comments.
> 
> But I don't think that a change is necessary here.  The reason is that these
> are compiler-internal header files, so they will only be ever parsed by Clang.
> No matter which mode Clang is in, it supports //-style comments, either as a
> part of the language, or as an extension, I believe.
> 
> While it is true that a pure c89 compiler won't be able to parse these
> headers, we are not concerned about these builtin headers used by any
> compiler other than Clang.
> 
> Dmitri
> 
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

2016-01-20 Thread Romanova, Katya via cfe-commits

I see. I was hoping that if you were, I could have used the same benchmark and 
compare what build time increase caused by using target attributes (might be 
much more substantial) and  by adding doxygen comments.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Wednesday, January 20, 2016 3:09 PM
To: reviews+d15999+public+772a9901b981d...@reviews.llvm.org; Romanova, Katya; 
griboz...@gmail.com; jonat...@codesourcery.com; Gao, Yunzhong; Sean Silva
Cc: cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics 
(part 2, _wmmintrin_pclmul.h)

On Wed, Jan 20, 2016 at 2:32 PM Katya Romanova via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
kromanova added a comment.

In http://reviews.llvm.org/D15999#330794, @silvas wrote:

> This may sound stupid, but: can you benchmark the time it takes to build some 
> project (that actually uses intrinsics in most translation units, e.g. a 
> game) with the headers w/ and w/o the doxygen comments to check that all the 
> extra comment skipping doesn't affect compilation time? I.e. run your script 
> to add the comments for "all" the intrinsic headers (similar to what you 
> expect the final state to be after all these patches) and test the build time 
> of a game (and compare with the unmodified headers).
>
> Also, can you post a patch that changes "all" the headers to have doxygen 
> comments like you intend, so that others can test and verify?

Out of curiosity, do you know if the impact to the build time for Eric's change 
of starting to use the target attributes instead of conditional inclusion was 
measured (r239883) on a large scale application. If so, what were the results? 
I should probably include Eric.

I did not as the feature compatibility was fairly important here. That said, I 
don't really expect the compile time difference for the comment skipping to 
matter in any large way and having documentation seems pretty nice.

-eric
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r255281 - Do not generate DW_TAG_imported_module for anonymous namespaces (even nested) for all the platforms except PS4.

2015-12-21 Thread Romanova, Katya via cfe-commits

Hi David,

Thank you so much for the review.
I copied and pasted the diff file. Let me know if it’s OK to commit.


>> Could/should this ^ just be: Opts.DebugExplicitImport = Triple.isPS4CPU(); ?
Done.

>> Extra semicolon here ^
Done.

>> And is there any reason not to just use nullptr here and elsewhere? Anything 
>> with the substring "PtrTy" in the name seems like it should be pointer-like 
>> and be convertible from nullptr_t, no? (what is DeclGroupPtrTy?)
No, it's not convertible from nullptr_t.

/home/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:68:12: error: could not 
cnvert ‘nullptr’ from ‘std::nullptr_t’ to ‘clang::Parser::DeclGroupPtrTy {aka 
clang::OpaquePtr}’
 return nullptr;



Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp (revision 256140)
+++ lib/Frontend/CompilerInvocation.cpp (working copy)
@@ -1,4 +1,4 @@
-//===--- CompilerInvocation.cpp 
---===//
+//===---
//
// The LLVM Compiler Infrastructure
//
@@ -417,8 +417,7 @@
   Opts.EmitCodeView = Args.hasArg(OPT_gcodeview);
   Opts.SplitDwarfFile = Args.getLastArgValue(OPT_split_dwarf_file);
   Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
-  if (Triple.isPS4CPU())
-Opts.DebugExplicitImport = true;
+  Opts.DebugExplicitImport = Triple.isPS4CPU();

   for (const auto &Arg : Args.getAllArgValues(OPT_fdebug_prefix_map_EQ))
 Opts.DebugPrefixMap.insert(StringRef(Arg).split('='));
Index: lib/Parse/ParseDeclCXX.cpp
===
--- lib/Parse/ParseDeclCXX.cpp  (revision 256140)
+++ lib/Parse/ParseDeclCXX.cpp  (working copy)
@@ -65,7 +65,7 @@
   if (Tok.is(tok::code_completion)) {
 Actions.CodeCompleteNamespaceDecl(getCurScope());
 cutOffParsing();
-return DeclGroupPtrTy();;
+return DeclGroupPtrTy();
   }

   SourceLocation IdentLoc;


Thank you!
Katya.



From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Sunday, December 13, 2015 3:46 PM
To: Romanova, Katya
Cc: cfe-commits
Subject: Re: r255281 - Do not generate DW_TAG_imported_module for anonymous 
namespaces (even nested) for all the platforms except PS4.



On Thu, Dec 10, 2015 at 10:52 AM, Ekaterina Romanova via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: kromanova
Date: Thu Dec 10 12:52:50 2015
New Revision: 255281

URL: http://llvm.org/viewvc/llvm-project?rev=255281&view=rev
Log:
Do not generate DW_TAG_imported_module for anonymous namespaces (even nested) 
for all the platforms except PS4.
For PS4, generate explicit import for anonymous namespaces and mark it by 
DW_AT_artificial attribute.

Differential Revision: http://reviews.llvm.org/D12624


Added:
cfe/trunk/test/CodeGenCXX/debug-info-anon-namespace.cpp
Modified:
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Parse/ParseDeclCXX.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=255281&r1=255280&r2=255281&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Thu Dec 10 12:52:50 2015
@@ -166,6 +166,10 @@ CODEGENOPT(DebugColumnInfo, 1, 0) ///< W
 CODEGENOPT(DebugTypeExtRefs, 1, 0) ///< Whether or not debug info should 
contain
///< external references to a PCH or module.

+CODEGENOPT(DebugExplicitImport, 1, 0)  ///< Whether or not debug info should
+   ///< contain explicit imports for
+   ///< anonymous namespaces
+
 CODEGENOPT(EmitLLVMUseLists, 1, 0) ///< Control whether to serialize use-lists.

 /// The user specified number of registers to be used for integral arguments,

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=255281&r1=255280&r2=255281&view=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Thu Dec 10 12:52:50 2015
@@ -2337,8 +2337,8 @@ private:

   void DiagnoseUnexpectedNamespace(NamedDecl *Context);

-  Decl *ParseNamespace(unsigned Context, SourceLocation &DeclEnd,
-   SourceLocation InlineLoc = SourceLocation());
+  DeclGroupPtrTy ParseNamespace(unsigned Context, SourceLocation &DeclEnd,
+SourceLocation InlineLoc = SourceLocation());

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

Re: [PATCH] D13482: Revised Initial patch for PS4 toolchain

RE: [PATCH] D13482: Revised Initial patch for PS4 toolchain

RE: [PATCH] D16913: Adding doxygen comments to the LLVM intrinsics (part 4, pmmintrin.h)

RE: [PATCH] D17021: Adding doxygen comments to the LLVM intrinsics (part 5, f16cintrin.h)

RE: r260333 - This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

RE: r260333 - This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

RE: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)

RE: D20468: [X86][AVX] Ensure zero-extension of _mm256_extract_epi8 and _mm256_extract_epi16

RE: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)

RE: [PATCH] D17550: Adding doxygen comments to the LLVM intrinsics (part 6, popcntintrin.h)

RE: [PATCH] D15999: Adding doxygen comments to the LLVM intrinsics (part 2, _wmmintrin_pclmul.h)

RE: r255281 - Do not generate DW_TAG_imported_module for anonymous namespaces (even nested) for all the platforms except PS4.

15 matches

Site Navigation

Mail list logo

Footer information