[18 regression] Assertion Path->Access <= UnprivilegedAccess && "access along best path worse than direct?" failed.
#80435
Labels
c++
clang:frontend
Language frontend issues, e.g. anything involving "Sema"
confirmed
Verified by a second party
crash-on-invalid
regression
Milestone
Comments
EugeneZelenko
added
clang:frontend
|
@llvm/issue-subscribers-clang-frontend Author: Bernhard Rosenkraenzer (berolinux)
This happens while trying to build kcachegrind 24.01.95:
Unfortunately both creduce and cvise reduce it to invalid code. namespace std {
struct
false_type
template<bool > struct enable_if
template<typename > struct negation ;
template<typename... > bool conjunction_v ;
template<typename _Tp> _Tp __declval(long);
template<typename _Tp> auto declval() -> decltype(__declval<_Tp>(0))
template<typename , typename > struct is_same ;
template<typename _Tp> using decay_t = _Tp;
template<bool _Cond> using enable_if_t = enable_if<_Cond>::type;
template<typename> using void_t = void;
}
namespace QTypeTraits {
namespace detail {
template<typename T> T const_reference();
template<typename T> T reference();
}
template <typename, typename > struct has_ostream_operator ;
template <typename Stream, typename T> has_ostream_operator< T, std::void_t<decltype(detail::reference<Stream>() << detail::const_reference<T>())>> has_ostream_operator_v ;
}
class QDebug;
class QByteArrayView;
namespace {
template <typename _Container> auto data(_Container __cont) -> decltype(__cont.data) template<typename > struct IsCompatibleByteArrayPointer ;
template <typename , typename = void> struct IsContainerCompatibleWithQByteArrayView ;
template <typename T> struct IsContainerCompatibleWithQByteArrayView<T, ::enable_if_t< std::conjunction_v< IsCompatibleByteArrayPointer<decltype(data(std:declval<T >()))>, std::negation<std::is_same<std::decay_t<T>, QByteArrayView>>>>> ;
}
class QByteArrayView {
template <typename T> using if_compatible_container = std::enable_if_t<IsContainerCompatibleWithQByteArrayView<T>::valuebool>;
template <typename Container, if_compatible_container<Container> = true> QByteArrayView(Container ) ;
};
class QIODeviceBase {namespace QtPrivate { class QMetaTypeInterface {} template <typename T> struct MetatypeDecay { using type = T; }; template<typename T, bool = QTypeTraits::has_ostream_operator_v<QDebug, T>> struct QMetaTypeInterfaceWrapper ; template<typename T, typename > struct TypeAndForceComplete { using type = T ; } template<typename , typename TypeCompletePair> QMetaTypeInterface qTryMetaTypeInterfaceForType() { using T = TypeCompletePair:type; using Ty = MetatypeDecay<T>::type ; QMetaTypeInterfaceWrapper<Ty>metaType } }
template<typename Unique,typename... T> QtPrivate::QMetaTypeInterface qt_incomplete_metaTypeArray{ QtPrivate::qTryMetaTypeInterfaceForType<Unique, T>()... };
class QDebug : QIODeviceBase
struct QDebug operator<<(QByteArrayView ) ;
}
class QWidget {
data;
};
class QFrame : QWidget
{};
class QAbstractScrollArea : QFrame
{};
class QGraphicsView : QAbstractScrollArea
{};
class TraceItemView
{
data() };
class CallGraphView : QGraphicsView, TraceItemView;struct qt_meta_stringdata_CLASSCallGraphViewENDCLASS_t CallGraphViewstaticMetaObject {
qt_incomplete_metaTypeArray<qt_meta_stringdata_CLASSCallGraphViewENDCLASS_t,
QtPrivate::TypeAndForceComplete<CallGraphView, std::false_type>
>} I'll try to come up with a more useful (not invalid) test case. |
|
I know you said the reduced code was invalid but I can't get it to crash: https://godbolt.org/z/r4PWYhMzd Are there a set of flags we need? |
|
@berolinux if it's a clang 18 regression and compiles fine with clang 17, you should be able to write your interestingness creduce test such that it returns 1/not interesting if it compiles fine with clang 17, before trying to compiling it with Clang 18 Maybe something like #!/bin/bash -x
GOOD=clang++-17
BAD=clang++-18
$GOOD crash.cpp <FLAGS> -fsyntax-only
if [ $? -ne 0 ]
exit 1
else
$BAD crash.cpp <FLAGS> -fsyntax-only | grep "Path->Access <= UnprivilegedAccess"
if [ $? -eq 0 ]
exit 0
fi
fi
exit 1
|
It crashes here without any flags. This is on a snapshot of release/18.x branch that is a couple of days old; maybe it has already been fixed. Will update and try again. |
|
@berolinux can you upload full reproducer? Both preprocessed source and a script. |
|
callgraphview-a506d5.cpp Verified to still happen with current |
shafik
added
the
needs-reduction
In my experience with |
|
My reduction is at 61570 bytes at the moment (down from 15 MB), so I should be able to post reduced example today. |
|
Here is reduced example, confirmed on post-18 trunk: https://godbolt.org/z/1xEPK6P6f struct QWidget {
void *data;
};
class TraceItemView {
void *data;
};
struct CallGraphView : QWidget, TraceItemView {};
// comment this line and uncomment lines below
// to get the same crash without any errors emitted
decltype(CallGraphView().data) a;
// struct QByteArrayView {
// template <typename Container, decltype(Container().data) = 0 >
// QByteArrayView(Container);
// };
// QByteArrayView a(CallGraphView{});Backtrace: |
Endilll
added
regression
crash-on-invalid
confirmed
|
@llvm/issue-subscribers-c-1 Author: Bernhard Rosenkraenzer (berolinux)
This happens while trying to build kcachegrind 24.01.95:
Unfortunately both creduce and cvise reduce it to invalid code. namespace std {
struct
false_type
template<bool > struct enable_if
template<typename > struct negation ;
template<typename... > bool conjunction_v ;
template<typename _Tp> _Tp __declval(long);
template<typename _Tp> auto declval() -> decltype(__declval<_Tp>(0))
template<typename , typename > struct is_same ;
template<typename _Tp> using decay_t = _Tp;
template<bool _Cond> using enable_if_t = enable_if<_Cond>::type;
template<typename> using void_t = void;
}
namespace QTypeTraits {
namespace detail {
template<typename T> T const_reference();
template<typename T> T reference();
}
template <typename, typename > struct has_ostream_operator ;
template <typename Stream, typename T> has_ostream_operator< T, std::void_t<decltype(detail::reference<Stream>() << detail::const_reference<T>())>> has_ostream_operator_v ;
}
class QDebug;
class QByteArrayView;
namespace {
template <typename _Container> auto data(_Container __cont) -> decltype(__cont.data) template<typename > struct IsCompatibleByteArrayPointer ;
template <typename , typename = void> struct IsContainerCompatibleWithQByteArrayView ;
template <typename T> struct IsContainerCompatibleWithQByteArrayView<T, ::enable_if_t< std::conjunction_v< IsCompatibleByteArrayPointer<decltype(data(std:declval<T >()))>, std::negation<std::is_same<std::decay_t<T>, QByteArrayView>>>>> ;
}
class QByteArrayView {
template <typename T> using if_compatible_container = std::enable_if_t<IsContainerCompatibleWithQByteArrayView<T>::valuebool>;
template <typename Container, if_compatible_container<Container> = true> QByteArrayView(Container ) ;
};
class QIODeviceBase {namespace QtPrivate { class QMetaTypeInterface {} template <typename T> struct MetatypeDecay { using type = T; }; template<typename T, bool = QTypeTraits::has_ostream_operator_v<QDebug, T>> struct QMetaTypeInterfaceWrapper ; template<typename T, typename > struct TypeAndForceComplete { using type = T ; } template<typename , typename TypeCompletePair> QMetaTypeInterface qTryMetaTypeInterfaceForType() { using T = TypeCompletePair:type; using Ty = MetatypeDecay<T>::type ; QMetaTypeInterfaceWrapper<Ty>metaType } }
template<typename Unique,typename... T> QtPrivate::QMetaTypeInterface qt_incomplete_metaTypeArray{ QtPrivate::qTryMetaTypeInterfaceForType<Unique, T>()... };
class QDebug : QIODeviceBase
struct QDebug operator<<(QByteArrayView ) ;
}
class QWidget {
data;
};
class QFrame : QWidget
{};
class QAbstractScrollArea : QFrame
{};
class QGraphicsView : QAbstractScrollArea
{};
class TraceItemView
{
data() };
class CallGraphView : QGraphicsView, TraceItemView;struct qt_meta_stringdata_CLASSCallGraphViewENDCLASS_t CallGraphViewstaticMetaObject {
qt_incomplete_metaTypeArray<qt_meta_stringdata_CLASSCallGraphViewENDCLASS_t,
QtPrivate::TypeAndForceComplete<CallGraphView, std::false_type>
>} I'll try to come up with a more useful (not invalid) test case. |
|
This is due to my change: cc1b666#diff-19c518dbc68b30c66e1a2b6bd523c005fb2050dcf1a0e92305df7ab3e1b9e9f3 I believe I know what the problem is and should have a fix up soon. |
Endilll
changed the title
Path->Access <= UnprivilegedAccess && "access along best path worse than direct?" failed.
shafik
added a commit
to shafik/llvm-project
that referenced
this issue
Feb 5, 2024
…tempting access check. Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: llvm#80435
shafik
added a commit
to shafik/llvm-project
that referenced
this issue
Feb 5, 2024
…tempting access check. Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: llvm#80435
shafik
added a commit
that referenced
this issue
Feb 5, 2024
…tempting access check. (#80730) Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: #80435
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Feb 6, 2024
…tempting access check. (llvm#80730) Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: llvm#80435 (cherry picked from commit a7bc9cb)
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Feb 7, 2024
…tempting access check. (llvm#80730) Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: llvm#80435 (cherry picked from commit a7bc9cb)
tstellar
pushed a commit
to tstellar/llvm-project
that referenced
this issue
Feb 14, 2024
…tempting access check. (llvm#80730) Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: llvm#80435 (cherry picked from commit a7bc9cb)
tstellar
pushed a commit
to tstellar/llvm-project
that referenced
this issue
Feb 14, 2024
…tempting access check. (llvm#80730) Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: llvm#80435 (cherry picked from commit a7bc9cb)
tstellar
pushed a commit
to tstellar/llvm-project
that referenced
this issue
Feb 14, 2024
…tempting access check. (llvm#80730) Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: llvm#80435 (cherry picked from commit a7bc9cb)
tstellar
pushed a commit
to tstellar/llvm-project
that referenced
this issue
Feb 14, 2024
…tempting access check. (llvm#80730) Previously when fixing ambiguous lookup diagnostics in cc1b666 The change refactored `LookupResult` to split out diagnosing access and ambiguous lookups. The call to `getSema().CheckLookupAccess(...)` should have guarded by a check for isAmbiguous(). This change adds that guard. Fixes: llvm#80435 (cherry picked from commit a7bc9cb)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This happens while trying to build kcachegrind 24.01.95:
Unfortunately both creduce and cvise reduce it to invalid code.
I'll try to come up with a more useful (not invalid) test case.
The text was updated successfully, but these errors were encountered: