Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor #82643

Merged
merged 1 commit into from
Feb 22, 2024

Conversation

RoboTux
Copy link
Contributor

@RoboTux RoboTux commented Feb 22, 2024

GCC SFINAE error with decltype was fixed in commit
ac5e28911abdfb8d9bf6bea980223e199bbcf28d which made it into GCC 8.4.
Therefore adjust GCC version test accordingly.

GCC SFINAE error with decltype was fixed in commit
ac5e28911abdfb8d9bf6bea980223e199bbcf28d which made it into GCC 8.4.
Therefore adjust GCC version test accordingly.
@llvmbot
Copy link
Collaborator

llvmbot commented Feb 22, 2024

@llvm/pr-subscribers-llvm-adt

Author: Thomas Preud'homme (RoboTux)

Changes

GCC SFINAE error with decltype was fixed in commit
ac5e28911abdfb8d9bf6bea980223e199bbcf28d which made it into GCC 8.4.
Therefore adjust GCC version test accordingly.


Full diff: https://github.com/llvm/llvm-project/pull/82643.diff

1 Files Affected:

  • (modified) llvm/include/llvm/ADT/iterator_range.h (+2-2)
diff --git a/llvm/include/llvm/ADT/iterator_range.h b/llvm/include/llvm/ADT/iterator_range.h
index 2dc227935984b1..7d288ea4506ba5 100644
--- a/llvm/include/llvm/ADT/iterator_range.h
+++ b/llvm/include/llvm/ADT/iterator_range.h
@@ -43,8 +43,8 @@ class iterator_range {
   IteratorT begin_iterator, end_iterator;
 
 public:
-#if __GNUC__ == 7
-  // Be careful no to break gcc-7 on the mlir target.
+#if __GNUC__ == 7 || (__GNUC__ == 8 && __GNUC_MINOR__ < 4)
+  // Be careful no to break gcc-7 and gcc-8 < 8.4 on the mlir target.
   // See https://github.com/llvm/llvm-project/issues/63843
   template <typename Container>
 #else

@MaskRay
Copy link
Member

MaskRay commented Feb 22, 2024

Is this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748 (8.x regression)?

8.4 is the fourth minor release in the 8.x series. I think it's pretty unfortunate that the issue was noticed and fixed late in the 8.x series. That said, 8.x is also quite old in 2024 and perhaps newer major releases have been better at catching regressions?. @tstellar Is there anything a distribution can help to catch such regressions early?

@tstellar
Copy link
Collaborator

Is this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748 (8.x regression)?

8.4 is the fourth minor release in the 8.x series. I think it's pretty unfortunate that the issue was noticed and fixed late in the 8.x series. That said, 8.x is also quite old in 2024 and perhaps newer major releases have been better at catching regressions?. @tstellar Is there anything a distribution can help to catch such regressions early?

At least for Fedora, we've switched to building clang with clang, so it would be hard to catch this in distribution testing. Maybe we need some more buildbots to test the versions of gcc we support.

@RoboTux
Copy link
Contributor Author

RoboTux commented Feb 22, 2024

Is this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748 (8.x regression)?

Yes it is.

8.4 is the fourth minor release in the 8.x series. I think it's pretty unfortunate that the issue was noticed and fixed late in the 8.x series. That said, 8.x is also quite old in 2024 and perhaps newer major releases have been better at catching regressions?. @tstellar Is there anything a distribution can help to catch such regressions early?

FYI GCC 8.3 is what Debian Buster is using. It's in LTS support so is only seeing security related updates, hence why it is not using GCC 8.4.

@RoboTux RoboTux merged commit 7f71fa9 into llvm:main Feb 22, 2024
6 checks passed
@MaskRay
Copy link
Member

MaskRay commented Feb 22, 2024

/cherry-pick 7f71fa9

@MaskRay MaskRay added this to the LLVM 18.X Release milestone Feb 22, 2024
llvmbot pushed a commit to llvmbot/llvm-project that referenced this pull request Feb 22, 2024
…m#82643)

GCC SFINAE error with decltype was fixed in commit
ac5e28911abdfb8d9bf6bea980223e199bbcf28d which made it into GCC 8.4.
Therefore adjust GCC version test accordingly.

(cherry picked from commit 7f71fa9)
@llvmbot
Copy link
Collaborator

llvmbot commented Feb 22, 2024

/pull-request #82688

@joker-eph
Copy link
Collaborator

joker-eph commented Feb 22, 2024

Maybe we need some more buildbots to test the versions of gcc we support

It's difficult to be comprehensive: for example I have a bot for gcc 7.5, but this kind of fix made it to gcc 8.4 and was back ported to gcc 7.4.
So we won't catch problems with gcc-8.0, gcc-8.1, gcc-8.2, ... unless we test them all.
Do you see another principled solution here?

@tstellar
Copy link
Collaborator

We could also change our policy to only support the latest minor release of gcc-X. That would make it much easier to test.

@loongknown
Copy link

Have you tested on GCC 8.3.0? Even after applying this patch, I'm still getting compilation errors. The error message is as follows:

/home/dongshuai/test/llvm-project/mlir/lib/Transforms/Utils/CFGToSCF.cpp: In function ‘mlir::FailureOr<llvm::SmallVectormlir::Block* > transformToStructuredCFBranches(mlir::Block*, mlir::function_ref<mlir::Value(unsigned int)>, mlir::function_refmlir::Value(mlir::Type), mlir::CFGToSCFInterface&, mlir::DominanceInfo&)’:
/home/dongshuai/test/llvm-project/mlir/lib/Transforms/Utils/CFGToSCF.cpp:1187:61: error: call of overloaded ‘OperandRange(mlir::MutableOperandRange)’ is ambiguous
getMutableSuccessorOperands(user->getBlock(), 0)));
^
In file included from /home/dongshuai/test/llvm-project/mlir/include/mlir/Support/TypeID.h:20,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/MLIRContext.h:13,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/DialectRegistry.h:16,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/Dialect.h:16,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/OpDefinition.h:22,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/Builders.h:12,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/Transforms/CFGToSCF.h:18,
from /home/dongshuai/test/llvm-project/mlir/lib/Transforms/Utils/CFGToSCF.cpp:116:
/home/dongshuai/test/llvm-project/llvm/include/llvm/ADT/STLExtras.h:1273:3: note: candidate: ‘llvm::detail::indexed_accessor_range_base<DerivedT, BaseT, T, PointerT, ReferenceT>::indexed_accessor_range_base(const llvm::iterator_range<llvm::detail::indexed_accessor_range_base<DerivedT, BaseT, T, PointerT, ReferenceT>::iterator>&) [with DerivedT = mlir::OperandRange; BaseT = mlir::OpOperand*; T = mlir::Value; PointerT = mlir::Value; ReferenceT = mlir::Value]’
indexed_accessor_range_base(const iterator_range &range)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/TypeRange.h:18,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/OperationSupport.h:23,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/Dialect.h:17,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/OpDefinition.h:22,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/IR/Builders.h:12,
from /home/dongshuai/test/llvm-project/mlir/include/mlir/Transforms/CFGToSCF.h:18,
from /home/dongshuai/test/llvm-project/mlir/lib/Transforms/Utils/CFGToSCF.cpp:116:
/home/dongshuai/test/llvm-project/mlir/include/mlir/IR/ValueRange.h:44:21: note: inherited here
using RangeBaseT::RangeBaseT;
^~~~~~~~~~
/home/dongshuai/test/llvm-project/mlir/include/mlir/IR/ValueRange.h:41:7: note: candidate: ‘constexpr mlir::OperandRange::OperandRange(const mlir::OperandRange&)’
class OperandRange final : public llvm::detail::indexed_accessor_range_base<
^~~~~~~~~~~~
/home/dongshuai/test/llvm-project/mlir/include/mlir/IR/ValueRange.h:41:7: note: candidate: ‘constexpr mlir::OperandRange::OperandRange(mlir::OperandRange&&)’

@RoboTux
Copy link
Contributor Author

RoboTux commented Feb 23, 2024

Have you tested on GCC 8.3.0? Even after applying this patch, I'm still getting compilation errors.

I had tested a build of my project that uses MLIR with GCC 8.3 (built from the corresponding git release branch) and it built fine (it wasn't without this patch). I've just tried building just MLIR and I'm seeing a similar error.

@RoboTux
Copy link
Contributor Author

RoboTux commented Feb 23, 2024

Alright, found a fix that seems to work. Bear with me while I do a full mlir build.

@RoboTux
Copy link
Contributor Author

RoboTux commented Feb 23, 2024

Nope sorry, it fixed one issue but there are more cases of decltype involved in SFINAE and it's hard to fix all of them. The current patch works for some users of MLIR at least, though clearly not all of them since building all of MLIR doesn't.

If people don't mind I'd like to keep the current patch in while we support GCC 8 because it helps my usecase and doesn't break any build not already broken (if it does I'm happy to revert it myself).

@RoboTux
Copy link
Contributor Author

RoboTux commented Feb 27, 2024

@loongknown The patch at RoboTux@8d161cb fixes the upstream build failures when compiling with GCC 8.3 for me. Can you confirm me it works for you and I'll make a PR.

@loongknown
Copy link

@loongknown The patch at RoboTux@8d161cb fixes the upstream build failures when compiling with GCC 8.3 for me. Can you confirm me it works for you and I'll make a PR.

Yes, it works. Tank you!

@RoboTux
Copy link
Contributor Author

RoboTux commented Feb 28, 2024

@loongknown The patch at RoboTux@8d161cb fixes the upstream build failures when compiling with GCC 8.3 for me. Can you confirm me it works for you and I'll make a PR.

Yes, it works. Tank you!

Great, I've created #83266

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging this pull request may close these issues.

7 participants