Re: [RFC] Dealing with ODR violations in GCC
On 02/13/2015 07:54 PM, Martin Liška wrote:
On 01/15/2015 06:47 AM, Jan Hubicka wrote:
Hello.
I've just finished successfully chromium LTO build and there's list of mainly
-Wodr warnings.
I think some of them are false positives?
What of those you consider to be false?
I wonder if we can print just type name so we avoid using the wrong "struct" in
place of class...
Thanks,
Martin
../../third_party/WebKit/public/platform/WebCryptoAlgorithmParams.h:295:0:
warning: type ???struct WebCryptoEcKeyImportParams??? violates one definition
rule [-Wodr]
class WebCryptoEcKeyImportParams : public WebCryptoAlgorithmParams {
^
../../third_party/WebKit/public/platform/WebCryptoAlgorithmParams.h:295:0:
note: a different type is defined in another translation unit
class WebCryptoEcKeyImportParams : public WebCryptoAlgorithmParams {
^
../../third_party/WebKit/public/platform/WebCryptoAlgorithmParams.h:307:0:
note: the first difference of corresponding definitions is field
???m_namedCurve???
const WebCryptoNamedCurve m_namedCurve;
^
../../third_party/WebKit/public/platform/WebCryptoAlgorithmParams.h:295:0:
note: a field of same name but different type is defined in another translation
unit
class WebCryptoEcKeyImportParams : public WebCryptoAlgorithmParams {
^
The line info seems wrong here though.
../../third_party/icu/source/common/unicode/bytestream.h:48:0: note: virtual
method ???_ZTIN6icu_528ByteSinkE???
class U_COMMON_API ByteSink : public UMemory {
^
: note: ought to match virtual method ???__cxa_pure_virtual??? but
does not
This message also should be sanitized - we probably want to special case
cxa_pure_virtual...
Honza
In function ???__fread_alias???,
inlined from
???_ZN21SafeBrowsingStoreFile13CheckValidityEv.part.41.constprop??? at
../../chrome/browser/safe_browsing/safe_browsing_store_file.cc:611:0:
/usr/include/bits/stdio2.h:290:0: warning: call to ???__fread_chk_warn???
declared with attribute warning: fread called with bigger size * nmemb than
length of destination buffer
return __fread_chk (__ptr, __bos0 (__ptr), __size, __n, __stream);
^
/usr/include/bits/stdio2.h:290:0: warning: call to ???__fread_chk_warn???
declared with attribute warning: fread called with bigger size * nmemb than
length of destination buffer
In function ???__read_alias???,
inlined from ???GetAppOutputInternal.constprop??? at
../../base/process/launch_posix.cc:613:0:
/usr/include/bits/unistd.h:39:0: warning: call to ???__read_chk_warn???
declared with attribute warning: read called with bigger length than size of
the destination buffer
return __read_chk (__fd, __buf, __nbytes, __bos0 (__buf));
^
Hello.
There's updated list for Chromium built with LTO.
Martin
Hi.
There's current status of ODR warnings for chrome, inkscape and firefox
binaries.
Martin
/home/marxin/Programming/buildbot/slave/gcc-nightly/install/gcc-c8c7d88048486ec942b9718385d7fccd15d06dc3/bin/ld:
warning: hidden symbol 'hb_ot_tags_from_script' in
/home/marxin/Programming/buildbot/slave/source/firefox/obj-x86_64-unknown-linux-gnu/toolkit/library/../../gfx/harfbuzz/src/Unified_cpp_gfx_harfbuzz_src0.o
is referenced by DSO /usr/lib64/libpangoft2-1.0.so
/home/marxin/Programming/buildbot/slave/gcc-nightly/install/gcc-c8c7d88048486ec942b9718385d7fccd15d06dc3/bin/ld:
warning: hidden symbol 'hb_ot_layout_language_get_feature_tags' in
/home/marxin/Programming/buildbot/slave/source/firefox/obj-x86_64-unknown-linux-gnu/toolkit/library/../../gfx/harfbuzz/src/Unified_cpp_gfx_harfbuzz_src0.o
is referenced by DSO /usr/lib64/libpangoft2-1.0.so
/home/marxin/Programming/buildbot/slave/gcc-nightly/install/gcc-c8c7d88048486ec942b9718385d7fccd15d06dc3/bin/ld:
warning: hidden symbol 'hb_ot_tag_to_script' in
/home/marxin/Programming/buildbot/slave/source/firefox/obj-x86_64-unknown-linux-gnu/toolkit/library/../../gfx/harfbuzz/src/Unified_cpp_gfx_harfbuzz_src0.o
is referenced by DSO /usr/lib64/libpangoft2-1.0.so
/home/marxin/Programming/buildbot/slave/gcc-nightly/install/gcc-c8c7d88048486ec942b9718385d7fccd15d06dc3/bin/ld:
warning: hidden symbol 'hb_buffer_get_length' in
/home/marxin/Programming/buildbot/slave/source/firefox/obj-x86_64-unknown-linux-gnu/toolkit/library/../../gfx/harfbuzz/src/Unified_cpp_gfx_harfbuzz_src0.o
is referenced by DSO /usr/lib64/libpangoft2-1.0.so
/home/marxin/Programming/buildbot/slave/gcc-nightly/install/gcc-c8c7d88048486ec942b9718385d7fccd15d06dc3/bin/ld:
warning: hidden symbol 'hb_buffer_get_direction' in
/home/marxin/Programming/buildbot/slave/source/firefox/obj-x86_64-unknown-linux-gnu/toolkit/library/../../gfx/harfbuzz/src/Unified_cpp_gfx_harfbuzz_src0.o
is referenced by DSO /usr/lib64/libpangoft2-1.0.so
/home/marxin/Programming/buildbot/slave/gcc-nightly/install/gcc-c8c7d88048486ec942b9718385d7fccd15d06dc3/bin/ld:
warning: hidden symbol 'hb_ot_layout_script_find_language' in
/home/marxin/Programming/buildbot/slave/source/firefox/obj-x86_64-unknown-linux-gn
Zs
sent from my I Phonek
Re: gcc wiki project
Hi, On Mon, Mar 23, 2015 at 06:14:30PM -0500, David Kunsman wrote: > Hello, I was just reading through the current projects wiki page and I > noticed how out of date pretty much all of them are. So I was > planning on doing "spring cleaning" by going down the list tracking > down what has been and what needs to be down and updating all the > wikis. Do you think this is something that is worthwhile to work on? Yes, I think that even just moving hopelessly outdated stuff to some "Archive" section, looking at what is left and then perhaps re-organizing the sections on the main page (and perhaps a few similar ones) would be great, if you have the time and energy to do it. I do not know how much history is kept in the wiki when moving pages around, so you might want to announce your big re-organization intentions here before actually doing them. Thanks, Martin
Re: gcc wiki project
> On Mon, Mar 23, 2015 at 06:14:30PM -0500, David Kunsman wrote: >> Hello, I was just reading through the current projects wiki page and I >> noticed how out of date pretty much all of them are. So I was >> planning on doing "spring cleaning" by going down the list tracking >> down what has been and what needs to be down and updating all the >> wikis. Do you think this is something that is worthwhile to work on? Yes, I think that would be very useful. On 24 March 2015 at 12:16, Martin Jambor wrote: > Yes, I think that even just moving hopelessly outdated stuff to some > "Archive" section, I don't see any need to move pages (that would break old links). Just add a header to old pages saying they are outdated, and stop linking to them from other pages that imply they are current. There could be a single ArchivedProjects page, or just sub-section of another page, that links to the old projects, but no need to move the old project pages themselves.
Re: gcc wiki project
On Tue, Mar 24, 2015 at 12:20:46PM +, Jonathan Wakely wrote: > > On Mon, Mar 23, 2015 at 06:14:30PM -0500, David Kunsman wrote: > >> Hello, I was just reading through the current projects wiki page and I > >> noticed how out of date pretty much all of them are. So I was > >> planning on doing "spring cleaning" by going down the list tracking > >> down what has been and what needs to be down and updating all the > >> wikis. Do you think this is something that is worthwhile to work on? > > Yes, I think that would be very useful. > > On 24 March 2015 at 12:16, Martin Jambor wrote: > > Yes, I think that even just moving hopelessly outdated stuff to some > > "Archive" section, > > I don't see any need to move pages (that would break old links). You're right, by section I meant the page sections where links to outdated contents are. I do not know why I thought for a moment that changing the URL would happen too. > Just add a header to old pages saying they are outdated, and stop > linking to them from other pages that imply they are current. There > could be a single ArchivedProjects page, or just sub-section of > another page, that links to the old projects, but no need to move the > old project pages themselves. This is exactly what I actually had in mind. Martin
Re: gcc wiki project
On 24 March 2015 at 12:33, Martin Jambor wrote: > This is exactly what I actually had in mind. Ah gotcha - then that's two voices in favour :-) I think as long as you don't actually rename pages then the wiki preserves quite good history, so we will always be able to go back to look at past versions if something gets lost.
Bug with compound literal initializer?
Hi,
I am seeing a strange behavior when a compound initializer is used in a
structure initialization. A test case:
[[[
struct s {
int y;
unsigned long *x;
};
struct s foo = {
.y = 25,
.x = (unsigned long [SZ]){},
};
]]]
If SZ is defined to non-zero, the expected output is produced:
[[[
/tmp$ gcc -S -o- 1.c -Wall -DSZ=1
.file"1.c"
.local__compound_literal.0
.comm__compound_literal.0,8,8
.globlfoo
.data
.align 16
.typefoo, @object
.sizefoo, 16
foo:
.long25
.zero4
.quad__compound_literal.0
.ident"GCC: (Ubuntu 4.9.1-16ubuntu6) 4.9.1"
.section.note.GNU-stack,"",@progbits
]]]
If SZ is zero, the initializer for .y (".y = 25") member is dropped as well:
[[[
/tmp$ gcc -S -o- 1.c -Wall -DSZ=0
.file"1.c"
.globlfoo
.bss
.align 16
.typefoo, @object
.sizefoo, 16
foo:
.zero16
.ident"GCC: (Ubuntu 4.9.1-16ubuntu6) 4.9.1"
.section.note.GNU-stack,"",@progbits
]]]
Is it expected behavior? If so, why?
Tested with GCC 4.6.3 and 4.9.1, both exhibit the same behavior.
Thanks,
Alexey.
Re: gcc wiki project
On 03/24/2015 03:20 PM, Jonathan Wakely wrote: On Mon, Mar 23, 2015 at 06:14:30PM -0500, David Kunsman wrote: Hello, I was just reading through the current projects wiki page and I noticed how out of date pretty much all of them are. So I was planning on doing "spring cleaning" by going down the list tracking down what has been and what needs to be down and updating all the wikis. Do you think this is something that is worthwhile to work on? Yes, I think that would be very useful. On 24 March 2015 at 12:16, Martin Jambor wrote: Yes, I think that even just moving hopelessly outdated stuff to some "Archive" section, I don't see any need to move pages (that would break old links). So why not fix links as well? -Y
