Re: C++ help needed fixing VXL on 32 bit architectures
On 5/28/19 2:26 PM, Roberto Ragusa wrote: On 5/28/19 1:57 AM, John Reiser wrote: if ((t&=7)==0) *++ib=0; int a; (*vs_) >> a; if (a) *ib|=static_cast(1<<(7-t)); } Such code is an abomination for lack of clarity. Also, the preceding line for (int x=0,t=0; x Isn't t forced into 0..6 by the t&=7 evaluation in the first if? 0..7, sorry for mistyping. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: C++ help needed fixing VXL on 32 bit architectures
On 5/28/19 1:57 AM, John Reiser wrote: if ((t&=7)==0) *++ib=0; int a; (*vs_) >> a; if (a) *ib|=static_cast(1<<(7-t)); } Such code is an abomination for lack of clarity. Also, the preceding line for (int x=0,t=0; x Isn't t forced into 0..6 by the t&=7 evaluation in the first if? -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: C++ help needed fixing VXL on 32 bit architectures
Hi John, On Mon, May 27, 2019 16:57:18 -0700, John Reiser wrote: > > https://github.com/vxl/vxl/issues/638 > > Independent of that particular issue, it is hard to believe the claim > "vxl: A multi-platform collection of C++ software libraries ...". > They're not making a good-faith effort to be portable. From what I've seen, VXL seems to be one of those libraries that was written long long ago and has for most of its life cycle been in "maintenance mode" to somehow keep it running. For example, my PR to version the shared objects was only merged last week (!), and the super spammy nightly commit bot is still active: https://github.com/vxl/vxl/issues/624 https://github.com/vxl/vxl/pull/626 https://github.com/vxl/vxl/issues/97 Most of this is probably because the core dev community is extremely stretched. They don't have the cycles to make required updates, which, for example, is why VXL still uses a dcmtk version from 2002 (and we have no choice but to bundle it): https://github.com/vxl/vxl/issues/550 So, if you do have the time, please file these issues (or PRs if you have even more time). That'll at least make them aware of them and maybe it'll encourage others to help the dev team too. I'd like to look into all of this, but as soon as I get VXL built, I've got to work on all the tools that depend on it and are currently broken also. -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: C++ help needed fixing VXL on 32 bit architectures
Dear Jerry, On Mon, May 27, 2019 15:33:42 -0600, Jerry James wrote: > On Mon, May 27, 2019 at 2:54 PM Jerry James wrote: > > It looks like the first few errors, at least, were fixed the day after > > the last release, in this commit: > > > > https://github.com/vxl/vxl/commit/c3fd27959f51e0469a7a6075e975f245ac306f3d > > > > You might try adding that as a patch and see if that is sufficient, or > > if there are more problems. > > I did a local mock build for i386 with that patch, and it succeeded. FYI. Ah! Thanks so much! This turned out a lot simpler than I'd feared. I hadn't even begun wading through the commit history yet. I'll go patch-build-update now. -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: C++ help needed fixing VXL on 32 bit architectures
https://github.com/vxl/vxl/issues/638
Independent of that particular issue, it is hard to believe the claim
"vxl: A multi-platform collection of C++ software libraries ...".
They're not making a good-faith effort to be portable.
The first hint is that "-Werror" (turn all warnings into errors)
has not been used when compiling.
There are so many basic portability errors, such as:
= portability error 1
v3p/netlib/triangle.c:219: #define TRIANGLE_PTRINT size_t
Using #define is silly when typedef is suitable.
v3p/netlib/triangle.c:3685:23: warning: format '%lx' expects argument of type
'long unsigned int', but argument 2 has type 'unsigned int' [-Wformat=]
printf("triangle x%lx with orientation %d:\n", (TRIANGLE_PTRINT) t->tri,
"%zx" solves this problem and has been available for many years.
= portability error 2
v3p/clipper/clipper.cpp:722:34: warning: 'void* memset(void*, int, size_t)'
clearing an object of non-trivial type 'struct ClipperLib::TEdge'
Learn from the compiler; it is smarter than this programmer.
(Example: if there are any 'virtual' functions [now or later!],
then using memset zaps the vtable pointer.)
== portability error 3
core/vil1/vil1_memory_image_impl.cxx:210:63: warning: suggest parentheses
around assignment used as truth value [-Wparentheses]
return property_value ? (*(bool*)property_value) = true : true;
This is unmaintainable, especially when not explained in a comment.
= portability error 4
core/vil1/file_formats/vil1_pnm.cxx:360:11: warning: this 'if' clause does not
guard... [-Wmisleading-indentation]
if ((t&=7)==0) *++ib=0; int a; (*vs_) >> a; if (a) *ib|=static_cast(1<<(7-t)); }
Such code is an abomination for lack of clarity.
Also, the preceding line
for (int x=0,t=0; xhttps://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: C++ help needed fixing VXL on 32 bit architectures
On Mon, May 27, 2019 at 2:54 PM Jerry James wrote: > It looks like the first few errors, at least, were fixed the day after > the last release, in this commit: > > https://github.com/vxl/vxl/commit/c3fd27959f51e0469a7a6075e975f245ac306f3d > > You might try adding that as a patch and see if that is sufficient, or > if there are more problems. I did a local mock build for i386 with that patch, and it succeeded. FYI. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: C++ help needed fixing VXL on 32 bit architectures
On Mon, May 27, 2019 at 10:14 AM Ankur Sinha wrote: > After spending quite a bit of time fixing VXL to build, I've now run > into errors with it building on 32 bit arches. > > Unfortunately, I don't foresee myself having enough cycles in the near > future to debug the C++ bits to see what's happening here, and while I > have filed a ticket upstream, they seem to be even busier than us (all > issues seem to get a "A PR would be welcome" response) > > https://github.com/vxl/vxl/issues/638 > > Any chance any C++ ninjas here would have some time to look into this > please? A PR fixing the issue upstream would be absolutely fantastic. It looks like the first few errors, at least, were fixed the day after the last release, in this commit: https://github.com/vxl/vxl/commit/c3fd27959f51e0469a7a6075e975f245ac306f3d You might try adding that as a patch and see if that is sufficient, or if there are more problems. Regards, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
C++ help needed fixing VXL on 32 bit architectures
Hi everyone, After spending quite a bit of time fixing VXL to build, I've now run into errors with it building on 32 bit arches. Unfortunately, I don't foresee myself having enough cycles in the near future to debug the C++ bits to see what's happening here, and while I have filed a ticket upstream, they seem to be even busier than us (all issues seem to get a "A PR would be welcome" response) https://github.com/vxl/vxl/issues/638 Any chance any C++ ninjas here would have some time to look into this please? A PR fixing the issue upstream would be absolutely fantastic. -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
On 13/03/2019 17:03, mcatanz...@gnome.org wrote: On Wed, Mar 13, 2019 at 11:53 AM, Jakub Jelinek wrote: calling methods on NULL pointers to objects etc. Chromium probably does this (or, at least, did in the past). Removing -fno-delete-null-pointer-checks could introduce Fedora-specific crashes. Yes v8 (and hence chromium) were well known for triggering crashes when gcc first started assuming that people wouldn't call methods on null pointers. The underlying bugs in v8 where it was doing that may well be fixed by now of course. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
On Wed, Mar 13, 2019 at 11:53 AM, Jakub Jelinek wrote: calling methods on NULL pointers to objects etc. Chromium probably does this (or, at least, did in the past). Removing -fno-delete-null-pointer-checks could introduce Fedora-specific crashes. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
On Wed, Mar 13, 2019 at 12:49:35PM -0400, Tom Callaway wrote: > The odd thing is that this compiler flag is hardcoded into the build by the > upstream. I'm wondering why Fedora hits this when no one else seems to. > > I mean, I'm fine to disable it, because the Chromium codebase is a tomb of > horrors anyway, and if I have to sacrifice that flag to make it happy, so > be it. Most likely the flag has been added to workaround other bugs in the codebase, but maybe those were already fixed and flag forgotten. The flag can be used to workaround bugs like calling memcpy/memset etc. with NULL argument (when the size is 0), or calling methods on NULL pointers to objects etc. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
The odd thing is that this compiler flag is hardcoded into the build by the upstream. I'm wondering why Fedora hits this when no one else seems to. I mean, I'm fine to disable it, because the Chromium codebase is a tomb of horrors anyway, and if I have to sacrifice that flag to make it happy, so be it. ~tom On Wed, Mar 13, 2019 at 10:37 AM Jakub Jelinek wrote: > On Wed, Mar 13, 2019 at 10:28:29AM -0400, Tom Callaway wrote: > > I tried removing some of the compiler flags to see if I could identify > what > > might be triggering this, and removing "-fno-delete-null-pointer-checks" > > seems to make this error vanish. > > -fno-delete-null-pointer-checks is certainly an option that requests that > the compiler does not fold comparisons against NULL at compile time based > on > assumption that objects have non-NULL address, so sure, if it has such > asserts, > it is incompatible with that option, you can't have both. > > Jakub > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
On Wed, Mar 13, 2019 at 10:28:29AM -0400, Tom Callaway wrote: > I tried removing some of the compiler flags to see if I could identify what > might be triggering this, and removing "-fno-delete-null-pointer-checks" > seems to make this error vanish. -fno-delete-null-pointer-checks is certainly an option that requests that the compiler does not fold comparisons against NULL at compile time based on assumption that objects have non-NULL address, so sure, if it has such asserts, it is incompatible with that option, you can't have both. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
I tried removing some of the compiler flags to see if I could identify what
might be triggering this, and removing "-fno-delete-null-pointer-checks"
seems to make this error vanish.
Not sure if that helps or not, but hopefully, I can get this beast building
without it.
Thanks,
Tom
On Mon, Mar 11, 2019 at 1:31 PM Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 01:16:07PM -0400, Tom Callaway wrote:
> > I spent some time this weekend trying to get Chromium 72 building on
> > Fedora, but I kept running into a C++ issue that I was not able to
> resolve.
> > This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
>
> Can you please provide preprocessed source + g++ command line options,
> from the snippets it is hard to see what's going on.
> From the description it seems maybe like:
> template
> struct S {
> static constexpr int a[2] = { 1, 2 };
> };
> static_assert (&S<0>::a[1] != nullptr);
>
> which g++ accepts for -std=c++{11,14} but rejects for -std=c++{17,2a} when
> S<0>::a is an inline variable. I think we have a similar
> http://gcc.gnu.org/PR89074 . The middle-end punts here and doesn't
> optimize
> the != NULL to true because it is address of a comdat variable and thus it
> in the end could come up from any other TU. Though perhaps in these cases
> the standard gives us some guarantees.
>
> Jakub
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
On Tue, Mar 12, 2019 at 7:57 AM Christophe de Dinechin wrote: > > I tried to compile your preprocessed fragment with both clang or gcc. > Interestingly: > > 1) Without your command-line options, I don’t see the same error. > > 2) With your command-line options, I see the error with gcc, but not with > clang. > > So I suspect a compiler bug. > Could chromium be built with clang in fedora? Or does it have to be built with gcc? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
> On 11 Mar 2019, at 18:16, Tom Callaway wrote:
>
> Hi folks,
>
> I spent some time this weekend trying to get Chromium 72 building on Fedora,
> but I kept running into a C++ issue that I was not able to resolve. This
> happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
>
> Here's a sample of the error (it happens in a few places), from Fedora 30:
>
> In file included from
> ../../base/trace_event/trace_event_system_stats_monitor.h:15,
> from ../../base/trace_event/trace_event.h:26,
> from ../../base/threading/scoped_blocking_call.cc:11:
> ../../base/trace_event/trace_log.h: In constructor
> 'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
> ../../base/threading/scoped_blocking_call.cc:88:5: in 'constexpr' expansion
> of 'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
> char*)"base"))'
> ../../base/trace_event/trace_log.h:215:25: error: '((&
> base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a constant
> expression
It looks like the compiler is not smart enough to detect that this is the
address of a static object, defined at line 92744 of your preprocessed file as:
static TraceCategory categories_[kMaxCategories];
whereas it is smart enough to go through GetBuiltnCategoryByName and figure out
index 7 from the name…
I tried to compile your preprocessed fragment with both clang or gcc.
Interestingly:
1) Without your command-line options, I don’t see the same error.
2) With your command-line options, I see the error with gcc, but not with clang.
So I suspect a compiler bug.
> 215 | if (builtin_category)
> | ^
>
> Now, chromium isn't the easiest code base to work with, but what seems to be
> happening is that this code calls one of the TRACE_EVENT macros, like this
> from base/threading/scoped_blocking_call.cc:
>
> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
> static_cast(blocking_type));
>
> Those macros are defined in base/trace_event/common/trace_event_common.h:
>
> #define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val) \
> INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name, \
> TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
>
> INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
>
> / Implementation detail: internal macro to create static category and add
> // event if the category is enabled.
> #define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags, ...) \
> do { \
>INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);\
>if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) { \
> trace_event_internal::AddTraceEvent( \
> phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name, \
> trace_event_internal::kGlobalScope, trace_event_internal::kNoId, \
> flags, trace_event_internal::kNoId, ##__VA_ARGS__); \
>} \
> } while (0)
>
> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
> base/trace_event/trace_event.h:
>
> #define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
> \
> static_assert(
> \
> base::trace_event::BuiltinCategories::IsAllowedCategory(category_group),
> \
> "Unknown tracing category is used. Please register your "
> \
> "category in base/trace_event/builtin_categories.h");
> \
> constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
> \
> k_category_group_enabled) =
> \
> base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group);
> \
> const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
> \
> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
> \
> category_group, INTERNAL_TRACE_EVENT_UID(k_category_group_enabled),
> \
> INTERNAL_TRACE_EVENT_UID(category_group_enabled));
>
> Finally, inside here, it calls
> base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is defined in
> base/trace_event/trace_log.h:
>
> // Called by TRACE_EVENT* macros, don't call this directly.
> // The name parameter is a category group for example:
> // TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
> static const unsigned char* GetCategoryGroupEnabled(const char* name);
> static const char* GetCategoryGroupName(
> const unsigned char* category_group_enabled);
> static constexpr const unsigned char* GetBuiltinCategoryEnabled(
> const char* name) {
>TraceCategory* builtin_category =
>
Re: Chromium C++ help needed
FWIW, I did. There is no fix there.
~tom
On Mon, Mar 11, 2019 at 1:20 PM Vascom wrote:
> Look at chromium-vaapi build in rpmfusion.
>
> пн, 11 мар. 2019 г., 20:17 Tom Callaway :
>
>> Hi folks,
>>
>> I spent some time this weekend trying to get Chromium 72 building on
>> Fedora, but I kept running into a C++ issue that I was not able to resolve.
>> This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
>>
>> Here's a sample of the error (it happens in a few places), from Fedora 30:
>>
>> In file included from
>> ../../base/trace_event/trace_event_system_stats_monitor.h:15,
>> from ../../base/trace_event/trace_event.h:26,
>> from ../../base/threading/scoped_blocking_call.cc:11:
>> ../../base/trace_event/trace_log.h: In constructor
>> 'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
>> ../../base/threading/scoped_blocking_call.cc:88:5: in 'constexpr'
>> expansion of
>> 'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
>> char*)"base"))'
>> ../../base/trace_event/trace_log.h:215:25: error: '((&
>> base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a
>> constant expression
>> 215 | if (builtin_category)
>> | ^
>>
>> Now, chromium isn't the easiest code base to work with, but what seems to
>> be happening is that this code calls one of the TRACE_EVENT macros, like
>> this from base/threading/scoped_blocking_call.cc:
>>
>> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
>> static_cast(blocking_type));
>>
>> Those macros are defined in base/trace_event/common/trace_event_common.h:
>>
>> #define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val)
>> \
>> INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name,
>> \
>>TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
>>
>> INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
>>
>> / Implementation detail: internal macro to create static category and add
>> // event if the category is enabled.
>> #define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags,
>> ...) \
>> do {
>> \
>> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);
>> \
>> if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) {
>> \
>> trace_event_internal::AddTraceEvent(
>> \
>> phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name,
>> \
>> trace_event_internal::kGlobalScope,
>> trace_event_internal::kNoId, \
>> flags, trace_event_internal::kNoId, ##__VA_ARGS__);
>> \
>> }
>> \
>> } while (0)
>>
>> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
>> base/trace_event/trace_event.h:
>>
>> #define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
>> \
>> static_assert(
>> \
>>
>> base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), \
>> "Unknown tracing category is used. Please register your "
>> \
>> "category in base/trace_event/builtin_categories.h");
>> \
>> constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
>> \
>> k_category_group_enabled) =
>> \
>>
>> base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group); \
>> const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
>> \
>> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
>> \
>> category_group,
>> INTERNAL_TRACE_EVENT_UID(k_category_group_enabled), \
>> INTERNAL_TRACE_EVENT_UID(category_group_enabled));
>>
>> Finally, inside here, it
>> calls base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is
>> defined in base/trace_event/trace_log.h:
>>
>> // Called by TRACE_EVENT* macros, don't call this directly.
>> // The name parameter is a category group for example:
>> // TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
>> static const unsigned char* GetCategoryGroupEnabled(const char* name);
>> static const char* GetCategoryGroupName(
>> const unsigned char* category_group_enabled);
>> static constexpr const unsigned char* GetBuiltinCategoryEnabled(
>> const char* name) {
>> TraceCategory* builtin_category =
>> CategoryRegistry::GetBuiltinCategoryByName(name);
>> if (builtin_category)
>> return builtin_category->state_ptr();
>> return nullptr;
>> }
>>
>> Okay, so what seems like is happening here, is that the calls like this:
>>
>> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
>> static_cast(blocking_type));
>>
>> Are passing "base" (that first var) all the way into
>> GetCategoryGroupEnabled, which is finding it via GetBuiltinCategoryByName()
>> in base/trace_event/category_registry.h, checking against the list in
>> INTERNAL_TRACE_LIST_BUILTIN_CATEGORIES(X)
>> from base/trace_event/builtin_categories.h, finding it, then returning this
>> as builtin_category:
>>
Re: Chromium C++ help needed
On Mon, Mar 11, 2019 at 01:16:07PM -0400, Tom Callaway wrote:
> I spent some time this weekend trying to get Chromium 72 building on
> Fedora, but I kept running into a C++ issue that I was not able to resolve.
> This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
Can you please provide preprocessed source + g++ command line options,
from the snippets it is hard to see what's going on.
From the description it seems maybe like:
template
struct S {
static constexpr int a[2] = { 1, 2 };
};
static_assert (&S<0>::a[1] != nullptr);
which g++ accepts for -std=c++{11,14} but rejects for -std=c++{17,2a} when
S<0>::a is an inline variable. I think we have a similar
http://gcc.gnu.org/PR89074 . The middle-end punts here and doesn't optimize
the != NULL to true because it is address of a comdat variable and thus it
in the end could come up from any other TU. Though perhaps in these cases
the standard gives us some guarantees.
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Chromium C++ help needed
Look at chromium-vaapi build in rpmfusion.
пн, 11 мар. 2019 г., 20:17 Tom Callaway :
> Hi folks,
>
> I spent some time this weekend trying to get Chromium 72 building on
> Fedora, but I kept running into a C++ issue that I was not able to resolve.
> This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
>
> Here's a sample of the error (it happens in a few places), from Fedora 30:
>
> In file included from
> ../../base/trace_event/trace_event_system_stats_monitor.h:15,
> from ../../base/trace_event/trace_event.h:26,
> from ../../base/threading/scoped_blocking_call.cc:11:
> ../../base/trace_event/trace_log.h: In constructor
> 'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
> ../../base/threading/scoped_blocking_call.cc:88:5: in 'constexpr'
> expansion of
> 'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
> char*)"base"))'
> ../../base/trace_event/trace_log.h:215:25: error: '((&
> base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a
> constant expression
> 215 | if (builtin_category)
> | ^
>
> Now, chromium isn't the easiest code base to work with, but what seems to
> be happening is that this code calls one of the TRACE_EVENT macros, like
> this from base/threading/scoped_blocking_call.cc:
>
> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
> static_cast(blocking_type));
>
> Those macros are defined in base/trace_event/common/trace_event_common.h:
>
> #define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val) \
> INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name, \
>TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
>
> INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
>
> / Implementation detail: internal macro to create static category and add
> // event if the category is enabled.
> #define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags, ...)
> \
> do {
> \
> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);
> \
> if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) {
> \
> trace_event_internal::AddTraceEvent(
> \
> phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name,
> \
> trace_event_internal::kGlobalScope, trace_event_internal::kNoId,
> \
> flags, trace_event_internal::kNoId, ##__VA_ARGS__);
> \
> }
> \
> } while (0)
>
> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
> base/trace_event/trace_event.h:
>
> #define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
> \
> static_assert(
> \
>
> base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), \
> "Unknown tracing category is used. Please register your "
> \
> "category in base/trace_event/builtin_categories.h");
> \
> constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
> \
> k_category_group_enabled) =
> \
>
> base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group); \
> const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
> \
> INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
> \
> category_group, INTERNAL_TRACE_EVENT_UID(k_category_group_enabled),
> \
> INTERNAL_TRACE_EVENT_UID(category_group_enabled));
>
> Finally, inside here, it
> calls base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is
> defined in base/trace_event/trace_log.h:
>
> // Called by TRACE_EVENT* macros, don't call this directly.
> // The name parameter is a category group for example:
> // TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
> static const unsigned char* GetCategoryGroupEnabled(const char* name);
> static const char* GetCategoryGroupName(
> const unsigned char* category_group_enabled);
> static constexpr const unsigned char* GetBuiltinCategoryEnabled(
> const char* name) {
> TraceCategory* builtin_category =
> CategoryRegistry::GetBuiltinCategoryByName(name);
> if (builtin_category)
> return builtin_category->state_ptr();
> return nullptr;
> }
>
> Okay, so what seems like is happening here, is that the calls like this:
>
> TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
> static_cast(blocking_type));
>
> Are passing "base" (that first var) all the way into
> GetCategoryGroupEnabled, which is finding it via GetBuiltinCategoryByName()
> in base/trace_event/category_registry.h, checking against the list in
> INTERNAL_TRACE_LIST_BUILTIN_CATEGORIES(X)
> from base/trace_event/builtin_categories.h, finding it, then returning this
> as builtin_category:
>
> (& base::trace_event::CategoryRegistry::categories_[7])
>
> When if(builtin_category) is run (trying to check to see if we got a
> buillt-in category or a nullptr, I think), thats when GCC says:
>
> error: '((& base::trace_event::Cat
Chromium C++ help needed
Hi folks,
I spent some time this weekend trying to get Chromium 72 building on
Fedora, but I kept running into a C++ issue that I was not able to resolve.
This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
Here's a sample of the error (it happens in a few places), from Fedora 30:
In file included from
../../base/trace_event/trace_event_system_stats_monitor.h:15,
from ../../base/trace_event/trace_event.h:26,
from ../../base/threading/scoped_blocking_call.cc:11:
../../base/trace_event/trace_log.h: In constructor
'base::ScopedBlockingCall::ScopedBlockingCall(base::BlockingType)':
../../base/threading/scoped_blocking_call.cc:88:5: in 'constexpr'
expansion of
'base::trace_event::TraceLog::GetBuiltinCategoryEnabled(((const
char*)"base"))'
../../base/trace_event/trace_log.h:215:25: error: '((&
base::trace_event::CategoryRegistry::categories_[7]) != 0)' is not a
constant expression
215 | if (builtin_category)
| ^
Now, chromium isn't the easiest code base to work with, but what seems to
be happening is that this code calls one of the TRACE_EVENT macros, like
this from base/threading/scoped_blocking_call.cc:
TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
static_cast(blocking_type));
Those macros are defined in base/trace_event/common/trace_event_common.h:
#define TRACE_EVENT_BEGIN1(category_group, name, arg1_name, arg1_val) \
INTERNAL_TRACE_EVENT_ADD(TRACE_EVENT_PHASE_BEGIN, category_group, name, \
TRACE_EVENT_FLAG_NONE, arg1_name, arg1_val)
INTERNAL_TRACE_EVENT_ADD() is defined in base/trace_event/trace_event.h:
/ Implementation detail: internal macro to create static category and add
// event if the category is enabled.
#define INTERNAL_TRACE_EVENT_ADD(phase, category_group, name, flags, ...) \
do { \
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group);\
if (INTERNAL_TRACE_EVENT_CATEGORY_GROUP_ENABLED()) { \
trace_event_internal::AddTraceEvent( \
phase, INTERNAL_TRACE_EVENT_UID(category_group_enabled), name, \
trace_event_internal::kGlobalScope, trace_event_internal::kNoId, \
flags, trace_event_internal::kNoId, ##__VA_ARGS__); \
} \
} while (0)
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO is also defined in
base/trace_event/trace_event.h:
#define INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO(category_group)
\
static_assert(
\
base::trace_event::BuiltinCategories::IsAllowedCategory(category_group), \
"Unknown tracing category is used. Please register your "
\
"category in base/trace_event/builtin_categories.h");
\
constexpr const unsigned char* INTERNAL_TRACE_EVENT_UID(
\
k_category_group_enabled) =
\
base::trace_event::TraceLog::GetBuiltinCategoryEnabled(category_group); \
const unsigned char* INTERNAL_TRACE_EVENT_UID(category_group_enabled);
\
INTERNAL_TRACE_EVENT_GET_CATEGORY_INFO_MAYBE_AT_COMPILE_TIME(
\
category_group, INTERNAL_TRACE_EVENT_UID(k_category_group_enabled),
\
INTERNAL_TRACE_EVENT_UID(category_group_enabled));
Finally, inside here, it
calls base::trace_event::TraceLog::GetBuiltinCategoryEnabled(), which is
defined in base/trace_event/trace_log.h:
// Called by TRACE_EVENT* macros, don't call this directly.
// The name parameter is a category group for example:
// TRACE_EVENT0("renderer,webkit", "WebViewImpl::HandleInputEvent")
static const unsigned char* GetCategoryGroupEnabled(const char* name);
static const char* GetCategoryGroupName(
const unsigned char* category_group_enabled);
static constexpr const unsigned char* GetBuiltinCategoryEnabled(
const char* name) {
TraceCategory* builtin_category =
CategoryRegistry::GetBuiltinCategoryByName(name);
if (builtin_category)
return builtin_category->state_ptr();
return nullptr;
}
Okay, so what seems like is happening here, is that the calls like this:
TRACE_EVENT_BEGIN1("base", "ScopedBlockingCall", "blocking_type",
static_cast(blocking_type));
Are passing "base" (that first var) all the way into
GetCategoryGroupEnabled, which is finding it via GetBuiltinCategoryByName()
in base/trace_event/category_registry.h, checking against the list in
INTERNAL_TRACE_LIST_BUILTIN_CATEGORIES(X)
from base/trace_event/builtin_categories.h, finding it, then returning this
as builtin_category:
(& base::trace_event::CategoryRegistry::categories_[7])
When if(builtin_category) is run (trying to check to see if we got a
buillt-in category or a nullptr, I think), thats when GCC says:
error: '((& base::trace_event::CategoryRegistry::categories_[7]) != 0)' is
not a constant expression
*
None of the other distros that buil
Re: C++ help needed
On 04/20/2010 12:09 PM, Bernd Stramm wrote: > Can you give me a link? I'll take a look, see if there is anything I can > do. Just checkout xmms2 and esperanza from Fedora CVS, then build the packages in the devel branch. This will help if you're not familiar with Fedora CVS: https://fedoraproject.org/wiki/CVS_access_for_package_maintainers To build the packages, run "make local" in the branch (e.g. cd xmms2/devel && make local ) Thanks in advance, ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: C++ help needed
On Tue, 2010-04-20 at 09:50 -0400, Tom "spot" Callaway wrote: > Sadly, I am facing a task which exceeds my very meager C++ skills. > > I own a package called "esperanza", which is a QT4 xmms2 client written > in C++. With the latest xmms2 update (0.7DrNo, not yet built or pushed > to any branch, but checked into rawhide CVS), the esperanza client no > longer works (it builds, but never launches). Please note that xmms2 > clients use a script launcher to ensure that xmms2 is running, see the > esperanza.desktop file. > > I've updated the esperanza code to the latest set of git fixes in > rawhide CVS (necessary to build), but I really could use the help of > someone with C++ skills to get it working again. I emailed upstream, but > never got a response. > Can you give me a link? I'll take a look, see if there is anything I can do. Bernd > The other xmms2 clients are held up on this, and I'd rather not simply > dead.package this unless I absolutely have to. > > I would be happy to return the favor with work that is in my skillset, > licensing, packaging, reviewing, triage, etc, etc. > > Thanks in advance, > > ~spot -- Bernd Stramm -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
C++ help needed
Sadly, I am facing a task which exceeds my very meager C++ skills. I own a package called "esperanza", which is a QT4 xmms2 client written in C++. With the latest xmms2 update (0.7DrNo, not yet built or pushed to any branch, but checked into rawhide CVS), the esperanza client no longer works (it builds, but never launches). Please note that xmms2 clients use a script launcher to ensure that xmms2 is running, see the esperanza.desktop file. I've updated the esperanza code to the latest set of git fixes in rawhide CVS (necessary to build), but I really could use the help of someone with C++ skills to get it working again. I emailed upstream, but never got a response. The other xmms2 clients are held up on this, and I'd rather not simply dead.package this unless I absolutely have to. I would be happy to return the favor with work that is in my skillset, licensing, packaging, reviewing, triage, etc, etc. Thanks in advance, ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
