rengolin accepted this revision.
rengolin added a reviewer: rengolin.
rengolin added a comment.
This revision is now accepted and ready to land.
Sounds good. Thanks!
https://reviews.llvm.org/D28238
___
cfe-commits mailing list
cfe-commits@lists.llvm
rengolin added inline comments.
Comment at: lib/Driver/ToolChains/Clang.cpp:2452
+ if (!HonorInfs && !HonorNans && !MathErrno && AssociativeMath &&
+ ReciprocalMath && !SignedZeros && !TrappingMath && FpContract == "fast")
+CmdArgs.push_back("-ffast-math");
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.
Ok, with the break fix, this looks goof to me. Thanks!
Comment at: lib/Driver/ToolChains/Clang.cpp:2452
+ if (!HonorInfs && !HonorNans && !MathErrno && AssociativeMath &
rengolin added reviewers: Hahnfeld, carlo.bertolli, arpith-jacob.
rengolin added a comment.
Looks ok to me, but I'm not very knowledgeable in that area. Hopefully some
OpenMP Clang developers I added could give you a more concrete approval. :)
Comment at: lib/CodeGen/CGOpenMPR
rengolin added inline comments.
Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:6821
+ ISADataTy ISAData[] = {
+ {'n', 64}, // double-word Advanced SIMD
+ {'n', 128}, // quad-word Advanced SIMD
fpetrogalli wrote:
> rengolin wrote:
> > No f32?
rengolin added a comment.
This looks like a simple oversight from my perspective, so looks good.
But I'll let the others have a look at it, as I'm not overly familiar with
libcxxabi.
cheers,
--renato
https://reviews.llvm.org/D31178
___
cfe-commit
rengolin added a comment.
Hi Graham,
I don't know much about Clang's machinery, but would it be possible to have
`-fopenmp-simd` generate the same handler, but with restrictions? I fear this
slight duplication could get considerably worse as we support more and more
"non-RT" OMP pragmas.
Alte
rengolin added a comment.
In https://reviews.llvm.org/D31417#713171, @huntergr wrote:
> The other alternative I thought of was to perform the filtering in
> ParseOpenMP.cpp instead, but I need to figure out how to delete or skip
> tokens there without cluttering up the rest of the OpenMP parsin
rengolin added a comment.
Hi Graham,
It looks much simpler now, thanks!
I'm ok with the change, but I'd like @ABataev to confirm that the semantics is
the expected one for all cases and approve.
cheers,
--renato
Comment at: lib/Parse/ParseOpenMP.cpp:174
+ case OMPD_tar
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.
Silly omission. LGTM. Thanks!
https://reviews.llvm.org/D32132
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/c
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.
Seems like a very specific corner case on ARM, but is that attribute guaranteed
to be ARM-only?
If so, LGTM as is. If not, avoid mentioning "VFP" on the error message.
https://reviews.ll
rengolin added a reviewer: t.p.northover.
rengolin added a subscriber: t.p.northover.
rengolin added inline comments.
Comment at: lib/Basic/Targets.cpp:6245
enum FPUModeEnum {
-FPUMode,
-NeonMode
+NeonMode = (1 << 0),
+SveMode = (1 << 1)
Is the
rengolin added a reviewer: jmolloy.
rengolin added a subscriber: jmolloy.
rengolin added a comment.
@jmolloy Can you check this change, please?
Comment at: lib/Basic/Targets.cpp:6245
enum FPUModeEnum {
-FPUMode,
-NeonMode
+NeonMode = (1 << 0),
+SveMode = (1 <
rengolin added a comment.
In https://reviews.llvm.org/D35118#807712, @aemerson wrote:
> In https://reviews.llvm.org/D35118#806730, @rengolin wrote:
>
> > @jmolloy Can you check this change, please?
>
>
> I'm not really removing FPUMode, I'm just converting an enum to a bit field.
> FPUMode, i.e.
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.
Thanks. LGTM.
Repository:
rL LLVM
https://reviews.llvm.org/D35118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llv
rengolin added inline comments.
Comment at: buildbot/osuosl/master/config/builders.py:1196
+lit_extra_opts={'link_flags': '"-lc++abi -lc -lm -lpthread -ldl
-L/opt/llvm/lib/clang/3.9.0/lib/linux -lclang_rt.builtins-armhf"'},
+cmake_extra_opts={'LIBCXX_ENAB
rengolin added inline comments.
Comment at: buildbot/osuosl/master/config/builders.py:1196
+lit_extra_opts={'link_flags': '"-lc++abi -lc -lm -lpthread -ldl
-L/opt/llvm/lib/clang/3.9.0/lib/linux -lclang_rt.builtins-armhf"'},
+cmake_extra_opts={'LIBCXX_ENAB
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.
LGTM, thanks!
I'll add a local task to look into that, but with Connect coming, I'm not sure
how long that will take. :)
https://reviews.llvm.org/D30290
__
rengolin added inline comments.
Comment at: lib/Driver/ToolChains/Clang.cpp:2320
+
+ for (Arg *A : Args)
+ {
format
Comment at: lib/Driver/ToolChains/Clang.cpp:2324
+{
+// Options controlling individual features
+case options::OPT
rengolin added a reviewer: compnerd.
rengolin added inline comments.
Comment at: lib/Driver/ToolChains.cpp:1674
TripleAliases.append(begin(ARMHFTriples), end(ARMHFTriples));
+} else if (TargetTriple.getEnvironment() == llvm::Triple::MuslEABIHF) {
+ TripleAliases.a
rengolin added inline comments.
Comment at: lib/Driver/ToolChains.cpp:1674
TripleAliases.append(begin(ARMHFTriples), end(ARMHFTriples));
+} else if (TargetTriple.getEnvironment() == llvm::Triple::MuslEABIHF) {
+ TripleAliases.append(begin(ARMHFMuslTriples), end(AR
rengolin added inline comments.
Comment at: test/Driver/linux-ld.c:1016
+// CHECK-LD-GENTOO-ARMHF: "-dynamic-linker" "/lib/ld-linux-armhf.so.3"
+// CHECK-LD-GENTOO-ARMHF:
"{{.*}}/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.9.3/crtbegin.o"
+// CHECK-LD-GENTOO-ARMHF:
"-L[[SYSROO
rengolin added a comment.
I think this patch should move to canonicalise the triple as per all the
others, in the right place (vendor/environment).
If you find `hardfloat` or on where the vendor should be, and there are no
other possible vendors, just append `hf` to the environment and mark the
rengolin added a comment.
We already massage the triple in many cases, and what goes into IR is not
always the same as what is used in Clang.
Examples are x86_64's "x32" extension to the ABI, ARM -> Thumb triples, adding
compulsory dashes and unknowns (ex. x86_64--linux-gnu), etc.
You just hav
rengolin resigned from this revision.
rengolin removed a reviewer: rengolin.
rengolin added a comment.
I don't know enough about x86_64's ABI to have a solid opinion.
https://reviews.llvm.org/D26887
___
cfe-commits mailing list
cfe-commits@lists.llv
rengolin added a comment.
Was this abandoned?
Repository:
rL LLVM
https://reviews.llvm.org/D23610
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rengolin added a comment.
Was this abandoned?
Repository:
rL LLVM
https://reviews.llvm.org/D16901
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rengolin added a comment.
Was this abandoned? Merged?
https://reviews.llvm.org/D24083
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rengolin added a comment.
So, we found this issue with the different unwinds between Clang and libunwind:
https://llvm.org/bugs/show_bug.cgi?id=31035
Is this related?
https://reviews.llvm.org/D24084
___
cfe-commits mailing list
cfe-commits@lists.l
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.
LGTM. Thanks!
https://reviews.llvm.org/D27473
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l
rengolin resigned from this revision.
rengolin removed a reviewer: rengolin.
rengolin added a comment.
I don't know enough about the x86 environment to be able to review this patch.
Sorry.
https://reviews.llvm.org/D26796
___
cfe-commits mailing lis
rengolin added a comment.
In https://reviews.llvm.org/D27123#617118, @jroelofs wrote:
> In https://reviews.llvm.org/D27123#616887, @saaadhu wrote:
>
> > Make defines for CHAR16_TYPE, {U,}INT_{LEAST,FAST}16_TYPE use int instead
> > of short.
> >
> > {U,}INT16_TYPE still gets defined as short thou
rengolin added a comment.
Nothing new here, pretty much standard. No "gnueabihf"?
https://reviews.llvm.org/D32347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rengolin added reviewers: rovka, compnerd.
rengolin added a comment.
In https://reviews.llvm.org/D32347#733475, @ismail wrote:
> Yes openSUSE prefers the "hl" prefix to mean HardFloat.
I'm not sure that'll do what you expect it, though. Having the "hf" at the end
of the triple has some magical
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.
Ok, I see no harm in letting you work upstream, since no one should be relying
on the correct behaviour on opensuse for now. LGTM. Thanks!
https://reviews.llvm.org/D32347
_
rengolin added reviewers: compnerd, rovka, joerg.
rengolin added a comment.
I'm not sure this will work at all. Not because it doesn't make sense (it
does), but because of several bugs in the soft vs. hard float implementation in
the Triple related classes all the way to the back-end.
I'm addin
rengolin accepted this revision.
rengolin added a comment.
It's a weird flag, for sure, but if that's the semantics of it, than this
change LGTM. Thanks!
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D100372/new/
https://reviews.llvm.org/D100372
_
401 - 437 of 437 matches
Mail list logo
