[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146 Richard PALO changed: What|Removed |Added CC||richard at netbsd dot org --- Comment #2 from Richard PALO --- I'm curious if something like this could help certain similar situations encountered in SunOS as well...
[Bug preprocessor/60022] New: macro _(Text) generates warning: implicit declaration of function '_' [-Wimplicit-function-declaration]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
Bug ID: 60022
Summary: macro _(Text) generates warning: implicit
declaration of function '_'
[-Wimplicit-function-declaration]
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: richard at netbsd dot org
I believe I'm up against a regression in gcc 4.8.3 building the package
rpm-4.11.1
I witness the following:
rpmfileutil.c: In function 'rpmMkTempFile':
rpmfileutil.c:255:2: warning: implicit declaration of function '_'
[-Wimplicit-function-declaration]
rpmlog(RPMLOG_ERR, _("error creating temporary file %s: %m\n"), tempfn);
^
rpmfileutil.c:255:2: warning: passing argument 2 of 'rpmlog' makes pointer from
integer without a cast [enabled by default]
In file included from rpmfileutil.c:26:0:
../include/rpm/rpmlog.h:225:6: note: expected 'const char *' but argument is of
type 'int'
void rpmlog (int code, const char *fmt, ...) RPM_GNUC_PRINTF(2, 3);
^
...
naturally giving the following during link-editing:
Undefinedfirst referenced
symbol in file
_ rpmio/.libs/librpmio.so
ld: fatal: symbol referencing errors. No output written to .libs/rpm2cpio
collect2: error: ld returned 1 exit status
Makefile:936: recipe for target 'rpm2cpio' failed
gmake[2]: *** [rpm2cpio] Error 1
extract from configure'd system.h:
/* Take care of NLS matters. */
#if ENABLE_NLS
# include
# include
# define _(Text) dgettext (PACKAGE, Text)
#else
# define _(Text) Text
#endif
#define N_(Text) Text
ENABLE_NLS is defined, and the macro '_(Text)' seems to be ignored
(turning off NLS changes nothing, as can be expected.
I also tried building with CFLAGS+=-no-integrated-cpp to no avail.
Is this a regression, or does gcc 4.8.x enforce new rules as to macro names?
NB: This program builds fine with gcc 4.7.3.
I'm building using pkgsrc with gcc configured as follows:
$ /opt/local/gcc48/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/local/gcc48/bin/gcc
COLLECT_LTO_WRAPPER=/opt/local/gcc48/libexec/gcc/x86_64-sun-solaris2.11/4.8.2/lto-wrapper
Target: x86_64-sun-solaris2.11
Configured with: ../gcc-4.8.2/configure --enable-languages='c obj-c++ objc go
fortran c++' --enable-shared --enable-long-long
--with-local-prefix=/opt/local/gcc48 --enable-libssp --enable-threads=posix
--with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/opt/local/lib '
--disable-nls --with-cloog=/opt/local --enable-cloog-backend=isl
--enable-__cxa_atexit --with-gxx-include-dir=/opt/local/gcc48/include/c++/
--with-gnu-as --with-as=/usr/gnu/bin/as --without-gnu-ld --with-ld=/usr/bin/ld
--prefix=/opt/local/gcc48 --build=x86_64-sun-solaris2.11
--host=x86_64-sun-solaris2.11 --infodir=/opt/local/gcc48/info
--mandir=/opt/local/gcc48/man
Thread model: posix
gcc version 4.8.2 (GCC)
[Bug preprocessor/60022] macro _(Text) generates warning: implicit declaration of function '_' [-Wimplicit-function-declaration]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022 --- Comment #3 from Richard PALO --- (In reply to Andreas Schwab from comment #1) > If the macro isn't defined then nothing defined it. Most likely > rpmfileutil.c failed to include the right headers in the correct order. The order is correct as #include "system.h" is first line.
[Bug preprocessor/60022] macro _(Text) generates warning: implicit declaration of function '_' [-Wimplicit-function-declaration]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022
--- Comment #4 from Richard PALO ---
(In reply to Jakub Jelinek from comment #2)
> You can preprocess with -E -dD and look at what exactly was defined where
> and how the preprocessed line containing call to rpmlog looks like.
Here are the relevant parts:
==
# 1 "/usr/include/libintl.h" 1 3 4
# 28 "/usr/include/libintl.h" 3 4
#define _LIBINTL_H
#pragma ident "%Z%%M% %I% %E% SMI"
# 53 "/usr/include/libintl.h" 3 4
#define _WCHAR_T
typedef int wchar_t;
#define TEXTDOMAINMAX 256
#define __GNU_GETTEXT_SUPPORTED_REVISION(m) m) == 0) || ((m) == 1)) ? 1 :
-1)
extern char *dcgettext(const char *, const char *, const int);
extern char *dgettext(const char *, const char *);
extern char *gettext(const char *);
extern char *textdomain(const char *);
extern char *bindtextdomain(const char *, const char *);
and
=
# 37 "/usr/include/locale.h" 2 3 4
# 53 "/usr/include/locale.h" 3 4
#define _LastCategory LC_MESSAGES
#define _ValidCategory(c) (((int)(c) >= LC_CTYPE) && ((int)(c) <=
_LastCategory) || ((int)c == LC_ALL))
# 132 "../system.h" 2
#define _(Text) dgettext (PACKAGE, Text)
#define N_(Text) Text
=
an extract from rpmfileio.c using the macro:
if (tfd == NULL || Ferror(tfd)) {
rpmlog(RPMLOG_ERR, _("error creating temporary file %s: %m\n"), tempfn);
goto exit;
[Bug preprocessor/60022] macro _(Text) generates warning: implicit declaration of function '_' [-Wimplicit-function-declaration]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022 --- Comment #5 from Richard PALO --- I should add, that for grins, I tried changing this invocation from '_()' to N_()' and the got over this one, but naturally blew on the next invocation later in the source code. Is this perhaps a "const char*" issue?
[Bug preprocessor/60022] macro _(Text) generates warning: implicit declaration of function '_' [-Wimplicit-function-declaration]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022 --- Comment #7 from Richard PALO --- Created attachment 32009 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32009&action=edit output from -E -dD
[Bug preprocessor/60022] macro _(Text) generates warning: implicit declaration of function '_' [-Wimplicit-function-declaration]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022 --- Comment #8 from Richard PALO --- (In reply to Richard PALO from comment #7) > Created attachment 32009 [details] > output from -E -dD I'll see if I can make a concise test program to reproduce the issue.
[Bug preprocessor/60022] macro _(Text) generates warning: implicit declaration of function '_' [-Wimplicit-function-declaration]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60022 --- Comment #10 from Richard PALO --- (In reply to Jakub Jelinek from comment #9) > In any case, not a GCC bug. Great, is there an explanation as to why it works with gcc 4.7.3?
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #17 from Richard PALO --- Created attachment 33675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33675&action=edit c test program for snprintf I tried the attached test program and post the following results from my system demonstrating that the 'f' format does indeed seem erroneous, at least for the particular case in hand involving '1/3': $ /opt/local/gcc49/bin/gcc -std=c99 cflt.c $ ./a.out FLT_EVAL_METHOD = 2 (e) 1/3 => +3.33312e-01 (f) 1/3 => +0.2 (e) 1/7 => +1.42857142857142848e-01 (f) 1/7 => +0.14285714285714284 (e) 1/9 => +1.11104e-01 (f) 1/9 => +0.0
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #18 from Richard PALO --- Created attachment 33676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33676&action=edit another test program after coming across http://stackoverflow.com/questions/16839658/printf-width-specificer-to-maintain-precision-of-floating-point-value I modified the test program to the attached, and here is the output: FLT_EVAL_METHOD = 2 DBL_MANT_DIG = 53 DECIMAL_DIG = 21 DBL_DIG = 15 e precision 10 => +3.33e-01 f precision 10 => +0.33 e precision 11 => +3.333e-01 f precision 11 => +0.333 e precision 12 => +3.e-01 f precision 12 => +0. e precision 13 => +3.3e-01 f precision 13 => +0.3 e precision 14 => +3.33e-01 f precision 14 => +0.33 e precision 15 => +3.333e-01 f precision 15 => +0.333 e precision 16 => +3.3332e-01 f precision 16 => +0. e precision 17 => +3.33312e-01 f precision 17 => +0.2 e precision 18 => +3.333148e-01 f precision 18 => +0.12 e precision 19 => +3.3331483e-01 f precision 19 => +0.148 e precision 20 => +3.33314830e-01 f precision 20 => +0.1483 e precision 21 => +3.333148296e-01 f precision 21 => +0.14830 e precision 22 => +3.3331482962e-01 f precision 22 => +0.148296 e precision 23 => +3.33314829616e-01 f precision 23 => +0.1482962 e precision 24 => +3.333148296163e-01 f precision 24 => +0.14829616 e precision 25 => +3.3331482961626e-01 f precision 25 => +0.148296163
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 Richard PALO changed: What|Removed |Added Attachment #33676|0 |1 is obsolete|| --- Comment #19 from Richard PALO --- Created attachment 33680 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33680&action=edit -std= agnostic version
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #20 from Richard PALO --- >From what I've been able to gather, 'f' precision 17 & 18 incorrectly terminate with a '2' where they seemingly need be '1' and '5' respectfully (along with corresponding 'e' with precision 16 & 17). The default rounding is FE_TONEAREST on illumos. The other modes seem okay. Therefore I filed https://www.illumos.org/issues/5224 (with an updated version of the test program). BTW, on a sidenote, with the test program on NetBSD (6.1) I notice that rounding mode seems to be completely ignored. Does gnu-c runtime expect correct behaviour? (NB I made a version of the test program to avoid any constant 1.0/3.0 being used)... It would be interesting to know about other platforms... I came across a sourceware bug where this was supposedly fixed (https://sourceware.org/bugzilla/show_bug.cgi?id=5044)
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #21 from Richard PALO --- The problem has been isolated in illumos with a preliminary patch available. This test now passes with the fix applied, therefore I believe the issue can be closed as an OS issue and not a bug. cheers
[Bug c++/63650] New: conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
Bug ID: 63650
Summary: conflicting type attributes specified for ‘virtual..'
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard at netbsd dot org
came across this issue trying to build xulrunner192 on gcc 4.8.1 or 4.9.1
with this test program:
--->8--
#ifndef HIDDEN
#define HIDDEN __attribute__((visibility("hidden")))
#ifndef CDECL
#define CDECL __attribute__((regparm(0),cdecl))
#endif
class A
{
virtual HIDDEN int CDECL foo( void *nok) = 0;
};
class B : public A
{
virtual HIDDEN int CDECL foo(void *nok); /* implicitly virtual */
};
class C : public B
{
int foo(void *nok); /* implicitly virtual */
};
--->8--
I get :
richard@omnis:/home/richard/src/tvir$ /opt/gcc-4.8.1/bin/g++ -c tvir1.cpp
tvir1.cpp:20:7: error: conflicting type attributes specified for ‘virtual int
C::foo(void*)’
int foo(void *nok); /* implicitly virtual */
^
tvir1.cpp:15:28: error: overriding ‘virtual int B::foo(void*)’
virtual HIDDEN int CDECL foo(void *nok); /* implicitly virtual */
^
compiling with '-DCDECL=' avoids the problem.
This builds with gcc 4.4.4 and I believe with gcc 4.7.3 so I ask:
Is this a problem with the recent g++ versions or with the older ones?
[Bug c++/63650] conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650 --- Comment #2 from Richard PALO --- Created attachment 33812 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33812&action=edit nsFastLoadFile.ii this is the original error: > gmake[4]: Entering directory > '/tmp/pkgsrc/devel/xulrunner192/work/mozilla-1.9.2/xpcom/io' > nsFastLoadFile.cpp > g++ -o nsFastLoadFile.o -c -I../../dist/system_wrappers -include > ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -DOSTYPE=\"SunOS5\" > -DOSARCH=SunOS -D_IMPL_NS_COM -I.. -I. -I. -I../../dist/include > -I../../dist/include/nsprpub > -I/tmp/pkgsrc/devel/xulrunner192/work/mozilla-1.9.2/dist/include/nspr > -I/tmp/pkgsrc/devel/xulrunner192/work/mozilla-1.9.2/dist/include/nss > -I/opt/local/include -fPIC -I/usr/include -I/opt/local/include > -I/opt/local/include/libdrm -I/opt/local/include/freetype2 > -I/opt/local/include -fno-rtti -fno-exceptions -Wno-long-long -O2 > -I/usr/include -I/opt/local/include -I/opt/local/include/libdrm > -I/opt/local/include/freetype2 -fno-strict-aliasing -fshort-wchar -pthread > -DNDEBUG -DTRIMMED -O2 -I/usr/include -I/opt/local/include > -I/opt/local/include/libdrm -I/opt/local/include/freetype2 > -I/opt/local/include -DMOZILLA_CLIENT -include ../../mozilla-config.h > -Wp,-MD,.deps/nsFastLoadFile.pp nsFastLoadFile.cpp > nsFastLoadService.cpp > g++ -o nsFastLoadService.o -c -I../../dist/system_wrappers -include > ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -DOSTYPE=\"SunOS5\" > -DOSARCH=SunOS -D_IMPL_NS_COM -I.. -I. -I. -I../../dist/include > -I../../dist/include/nsprpub > -I/tmp/pkgsrc/devel/xulrunner192/work/mozilla-1.9.2/dist/include/nspr > -I/tmp/pkgsrc/devel/xulrunner192/work/mozilla-1.9.2/dist/include/nss > -I/opt/local/include -fPIC -I/usr/include -I/opt/local/include > -I/opt/local/include/libdrm -I/opt/local/include/freetype2 > -I/opt/local/include -fno-rtti -fno-exceptions -Wno-long-long -O2 > -I/usr/include -I/opt/local/include -I/opt/local/include/libdrm > -I/opt/local/include/freetype2 -fno-strict-aliasing -fshort-wchar -pthread > -DNDEBUG -DTRIMMED -O2 -I/usr/include -I/opt/local/include > -I/opt/local/include/libdrm -I/opt/local/include/freetype2 > -I/opt/local/include -DMOZILLA_CLIENT -include ../../mozilla-config.h > -Wp,-MD,.deps/nsFastLoadService.pp nsFastLoadService.cpp > In file included from nsFastLoadService.cpp:47:0: > nsFastLoadFile.h:298:19: error: conflicting type attributes specified for > 'virtual nsresult nsFastLoadFileReader::ReadSegments(nsWriteSegmentFun, > void*, PRUint32, PRUint32*)' > NS_IMETHODIMP ReadSegments(nsWriteSegmentFun aWriter, void* aClosure, >^ > In file included from ../../dist/include/nsIBinaryInputStream.h:10:0, > from ../../dist/include/nsIObjectInputStream.h:10, > from nsBinaryStream.h:44, > from nsFastLoadFile.h:49, > from nsFastLoadService.cpp:47: > nsBinaryStream.h:113:5: error: overriding 'virtual nsresult > nsBinaryInputStream::ReadSegments(nsWriteSegmentFun, void*, PRUint32, > PRUint32*)' > NS_DECL_NSIINPUTSTREAM > ^ > In file included from nsFastLoadFile.cpp:58:0: > nsFastLoadFile.h:298:19: error: conflicting type attributes specified for > 'virtual nsresult nsFastLoadFileReader::ReadSegments(nsWriteSegmentFun, > void*, PRUint32, PRUint32*)' > NS_IMETHODIMP ReadSegments(nsWriteSegmentFun aWriter, void* aClosure, >^ > In file included from ../../dist/include/nsIBinaryInputStream.h:10:0, > from ../../dist/include/nsIObjectInputStream.h:10, > from nsBinaryStream.h:44, > from nsFastLoadFile.cpp:57: > nsBinaryStream.h:113:5: error: overriding 'virtual nsresult > nsBinaryInputStream::ReadSegments(nsWriteSegmentFun, void*, PRUint32, > PRUint32*)' > NS_DECL_NSIINPUTSTREAM > ^ > ../../config/rules.mk:1408: recipe for target 'nsFastLoadService.o' failed > gmake[4]: *** [nsFastLoadService.o] Error 1 > gmake[4]: *** Waiting for unfinished jobs > ../../config/rules.mk:1408: recipe for target 'nsFastLoadFile.o' failed
[Bug c++/63650] conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #3 from Richard PALO ---
I initially replied that there was an error in my original, please
correct the first three lines to:
#ifndef HIDDEN
#define HIDDEN __attribute__((visibility("hidden")))
#endif
[Bug c++/63650] conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #5 from Richard PALO ---
(In reply to Daniel Krügler from comment #4)
> (In reply to Richard PALO from comment #3)
> > I initially replied that there was an error in my original, please
> > correct the first three lines to:
> > #ifndef HIDDEN
> > #define HIDDEN __attribute__((visibility("hidden")))
> > #endif
>
> This now leads to another error in regard to #endif without #if.
>
> Please provide a complete code that demonstrates the error.
you are kidding, no? here it is complete:
--->8--
#ifndef HIDDEN
#define HIDDEN __attribute__((visibility("hidden")))
#endif
#ifndef CDECL
#define CDECL __attribute__((regparm(0),cdecl))
#endif
class A
{
virtual HIDDEN int CDECL foo( void *nok) = 0;
};
class B : public A
{
virtual HIDDEN int CDECL foo(void *nok); /* implicitly virtual */
};
class C : public B
{
int foo(void *nok); /* implicitly virtual */
};
--->8--
[Bug c++/63650] conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #6 from Richard PALO ---
For that matter, the following is sufficient to
reproduce the problem, the rest is mostly to simulate
the xulrunner environment that is failing to build.
--->8--
#ifndef CDECL
#define CDECL __attribute__((regparm(0),cdecl))
#endif
class A
{
virtual int CDECL foo( void *nok) = 0;
};
class B : public A
{
int foo(void *nok); /* implicitly virtual */
};
--->8--
I should perhaps mention that this is on SunOS 5.11 (illumos) i386.
[Bug c++/63650] conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650 --- Comment #7 from Richard PALO --- Further testing indicates that 'cdecl' is okay and that keeping 'regparm(0)' causes the error.
[Bug c++/63650] conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650 --- Comment #8 from Richard PALO --- (In reply to Richard PALO from comment #7) > Further testing indicates that 'cdecl' is okay and that keeping 'regparm(0)' > causes the error. Is there perhaps a hint where I could checkout in the code, or is this a case of a faulty program (in this case xulrunner)... since this test code compiles without errors/warnings with clang++ 3.5, it would seem that it should be okay.
[Bug c++/63779] New: g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779
Bug ID: 63779
Summary: g++ 4.9 generates invalid object provoking a GOT
relative relocation must reference a local symbol
linker error on SunOS
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard at netbsd dot org
I'm getting with gcc4.9.2 the following link error using the illumos native
/usr/bin/ld building libxul from firefox 31:
>ld: fatal: relocation error: R_386_GOTOFF: file
>../../../content/media/MediaDecoderReader.o: symbol
mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*): a GOT relative
relocation must reference a local symbol
>ld: fatal: relocation error: R_386_GOTOFF: file
>../../../content/media/MediaDecoderReader.o: symbol
>mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*): a GOT relative
>relocation must reference a local symbol
>collect2: error: ld returned 1 exit status
/tmp/pkgsrc/devel/xulrunner31/work/mozilla-esr31/config/rules.mk:883: recipe
for target 'libxul.so' failed
The following is the code section (from content/media/MediaDecoderReader.cpp)
(slightly modified to show code is identical):
class VideoQueueMemoryFunctor : public nsDequeFunctor {
public:
VideoQueueMemoryFunctor() : mSize(0) {}
MOZ_DEFINE_MALLOC_SIZE_OF(MallocSizeOf);
virtual void* operator()(void* aObject) {
const VideoData* v = static_cast(aObject);
mSize += v->SizeOfIncludingThis(MallocSizeOf);
return nullptr;
}
size_t mSize;
};
class AudioQueueMemoryFunctor : public nsDequeFunctor {
public:
AudioQueueMemoryFunctor() : mSize(0) {}
MOZ_DEFINE_MALLOC_SIZE_OF(MallocSizeOf);
virtual void* operator()(void* aObject) {
const AudioData* v = static_cast(aObject);
mSize += v->SizeOfIncludingThis(MallocSizeOf);
return nullptr;
}
size_t mSize;
};
where MOZ_DEFINE_MALLOC_SIZE_OF is defined as (in
xpcom/base/nsIMemoryReporter.idl):
#define MOZ_DEFINE_MALLOC_SIZE_OF(fn) \
static size_t fn(const void* aPtr) \
{ \
MOZ_REPORT(aPtr); \
return moz_malloc_size_of(aPtr);\
}
As one can see, the two classes are nearly identical.
but nm shows the following differences in the generated object :
richard@omnis:/home/richard/src/txul$ nm -C MediaDecoderReader.o.gcc49 |grep
MallocSizeOf
[161]| 0| 0|NOTY |GLOB |0|UNDEF
|mozilla::AudioQueueMemoryFunctor::MallocSizeOf(const void*)
[_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv]
[149]| 0|34|FUNC |WEAK |2|90
|mozilla::VideoQueueMemoryFunctor::MallocSizeOf(const void*)
[_ZN7mozilla23VideoQueueMemoryFunctor12MallocSizeOfEPKv]
richard@omnis:/home/richard/src/txul$ nm -C MediaDecoderReader.o.gcc48 |grep
MallocSizeOf
[135]| 0|35|FUNC |WEAK |2|87
|mozilla::AudioQueueMemoryFunctor::MallocSizeOf(const void*)
[_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv]
[132]| 0|35|FUNC |WEAK |2|85
|mozilla::VideoQueueMemoryFunctor::MallocSizeOf(const void*)
[_ZN7mozilla23VideoQueueMemoryFunctor12MallocSizeOfEPKv]
or if you prefer gnm:
richard@omnis:/home/richard/src/txul$ gnm -C MediaDecoderReader.o.gcc49 |grep
MallocSizeOf
U mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)
W mozilla::VideoQueueMemoryFunctor::MallocSizeOf(void const*)
richard@omnis:/home/richard/src/txul$ gnm -C MediaDecoderReader.o.gcc48 |grep
MallocSizeOf
W mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)
W mozilla::VideoQueueMemoryFunctor::MallocSizeOf(void const*)
I attach the .ii and .s temps for both gcc48 and gcc49
The primary build environment is on:
richard@omnis:/home/richard/src/txul$ uname -a
SunOS omnis 5.11 illumos-gate-c40eb28 i86pc i386 i86pc
and snippet from this pkgsrc trunk build with '-v':
Using built-in specs.
COLLECT_GCC=/opt/local/gcc49/bin/g++
Target: i386-sun-solaris2.11
Configured with: ../gcc-4.9.2/configure --enable-languages='c obj-c++ objc go
fortran c++' --enable-shared --enable-long-long
--with-local-prefix=/opt/local/gcc49 --enable-libssp --enable-threads=posix
--with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/opt/local/lib '
--with-system-zlib --disable-nls --with-isl=/opt/local
--disable-isl-version-check --with-cloog=/opt/local --enable-__cxa_atexit
--with-gxx-include-dir=/opt/local/gcc
[Bug c++/63789] New: g++ -m32 on solaris has trouble finding abs with int64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789
Bug ID: 63789
Summary: g++ -m32 on solaris has trouble finding abs with
int64_t
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard at netbsd dot org
with the following simplified test program (tabs.cc):
==>8===
#include
#include
int64_t tabs(int64_t foo)
{
returnabs(foo);
}
=>8
building with g++ -m32 -c tabs.cc gives the following error:
>tabs.cc: In function ‘int64_t tabs(int64_t)’:
>tabs.cc:6:16: error: call of overloaded ‘abs(int64_t&)’ is ambiguous
> return abs(foo);
>^
>tabs.cc:6:16: note: candidates are:
>In file included from /usr/include/stdlib.h:37:0,
> from tabs.cc:2:
>/usr/include/iso/stdlib_iso.h:165:16: note: long int std::abs(long int)
> inline long abs(long _l) { return labs(_l); }
>^
>/usr/include/iso/stdlib_iso.h:119:12: note: int std::abs(int)
> extern int abs(int);
>^
there is no error specifying -m64.
Also, copying tabs.cc to tabs.c and building with gcc gives no error either
('gcc -m32 -c tabs.c' or to be pedantic with -std=c99 added).
I should mention that this seems to work okay with gcc4.4.4, but reproducible
with the compilers accessible, namely gcc47..gcc49.
The test program seems to work fine on NetBSD and FreeBSD.
This platform is SunOS 5.11 (illumos).
[Bug c++/63789] g++ -m32 on solaris has trouble finding abs with int64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789 --- Comment #1 from Richard PALO --- I should mention that rendering the test program pure c++ by replacing the first two lines with: >#include >#include allows the snippet build with both -m32 and -m64. It should be able to build as is, though.
[Bug c++/63789] g++ -m32 on solaris has trouble finding abs with int64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789 --- Comment #3 from Richard PALO --- Apparently with gcc 4.8.2 on Or*acle Solaris 11.2 the error manifests itself as well. Perhaps there is something [in the works] for s12?
[Bug c++/63779] g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779 --- Comment #2 from Richard PALO --- Sorry. Given the size, I'll use the following directory for any information needed: http://www.netbsd.org/~richard/xulrunner31-g++-issue/ Index of /~richard/xulrunner31-g++-issue Parent Directory MediaDecoderReader.cpp MediaDecoderReader.h MediaDecoderReader.ii MediaDecoderReader.o MediaDecoderReader.o.gkd MediaDecoderReader.s ld-debug.txt.gz I included the gzip'd output of the link with: LD_OPTIONS=-Dfiles,detail,reloc,got,sections,output=ld-debug.txt Anything else useful to provide?
[Bug testsuite/63899] New: WARNING: Could not compile g++.dg/compat/struct-layout-1 generator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63899 Bug ID: 63899 Summary: WARNING: Could not compile g++.dg/compat/struct-layout-1 generator Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Created attachment 33988 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33988&action=edit g++.dg/compat/struct-layout-1 run output Never noticed this with 4.8.x, but with 4.9.2 the testsuite has some new warnings of the sort: >WARNING: Could not compile g++.dg/compat/struct-layout-1 generator and >WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator Is this something to be concerned about? I attach the gcc and g++ individual test run details.
[Bug testsuite/63899] WARNING: Could not compile g++.dg/compat/struct-layout-1 generator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63899 --- Comment #1 from Richard PALO --- Created attachment 33989 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33989&action=edit gcc.dg/compat/struct-layout-1 run output
[Bug other/52168] fixinclude test failure for complex.h on netbsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52168 Richard PALO changed: What|Removed |Added CC||richard at netbsd dot org --- Comment #9 from Richard PALO --- (In reply to Jonathan Wakely from comment #8) > priority -> minor because it doesn't really matter if a fixinclude for > Solaris doesn't work on netbsd, except for causing a test faulre Except that this issue is also present for solaris pkgsrc developers. +1 for the patch
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 --- Comment #8 from Richard PALO --- As far as the test as it currently is written, I now get: >PASS: ext/random/k_distribution/operators/serialize.cc (test for excess errors) >PASS: ext/random/k_distribution/operators/serialize.cc execution test after the illumos platform fix : https://www.illumos.org/issues/5224 So this can probably be closed. Thanks
[Bug c++/61649] fixincludes update for solaris___restrict in sys/feature_tests.h on Illumos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649 --- Comment #1 from Richard PALO --- given https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52168, it seems necessary to update the test_text line with a newline appended as follows so that check.sh doesn't balk: >+test_text = "#if (defined(__STDC__) && defined(_STDC_C99))\n" >+ "#define_RESTRICT_KYWD restrict";
[Bug testsuite/63899] WARNING: Could not compile g++.dg/compat/struct-layout-1 generator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63899 --- Comment #2 from Richard PALO --- I can't seem to recreate this now, although I'm not that sure it had to do with an issue involving the compiler on illumos where the native libm 'complex.h' was being erroneously fixed up causing precompiler problems with missing closing brace. https://www.illumos.org/issues/5367 updated as well was fixincludes for 4.9.2 with: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52168 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649 if I come across this issue again I'll post back.
[Bug target/64030] New: some libiberty sources includes stdio.h prior to config.h causing redefined symbol warnings on i?86-*-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64030 Bug ID: 64030 Summary: some libiberty sources includes stdio.h prior to config.h causing redefined symbol warnings on i?86-*-solaris2.11 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Created attachment 34075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34075&action=edit patches to hex.c and xstrerror.c Please find two patches attached to reduce large-file related warnings on SunOS i386 when building the libiberty component...
[Bug c++/61649] fixincludes update for solaris___restrict in sys/feature_tests.h on Illumos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649 --- Comment #3 from Richard PALO --- No. Prior to fixincludes, sys/feature_tests.h in SunOS looks like the following: #if (defined(__STDC__) && defined(_STDC_C99)) #define _RESTRICT_KYWD restrict #else #define _RESTRICT_KYWD #endif Illumos has since https://www.illumos.org/issues/2941 the following: #if (defined(__STDC__) && defined(_STDC_C99)) && !defined(__cplusplus) #define _RESTRICT_KYWD restrict #else #define _RESTRICT_KYWD #endif The net effect of my patch is to support both variants in producing the following: #if (defined(__STDC__) && defined(_STDC_C99)) #ifdef __cplusplus #define _RESTRICT_KYWD __restrict #else #define _RESTRICT_KYWD restrict #endif #else #define _RESTRICT_KYWD #endif
[Bug c++/61649] fixincludes update for solaris___restrict in sys/feature_tests.h on Illumos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649 --- Comment #4 from Richard PALO --- > > The test/base/sys/feature_tests.h patch is as follows: > --- fixincludes/tests/base/sys/feature_tests.h.orig 2010-06-21 > 15:27:29.0 + > +++ fixincludes/tests/base/sys/feature_tests.h > @@ -10,6 +10,7 @@ > > > #if defined( SOLARIS___RESTRICT_CHECK ) > +#if (defined(__STDC__) && defined(_STDC_C99)) > #ifdef __cplusplus > #define _RESTRICT_KYWD __restrict > #else Perhaps I should remind as well that the file is a diff with only a certain number of lines as context... so in that respect, it isn't necessary either.
[Bug c++/63779] g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779 --- Comment #3 from Richard PALO --- Well, apparently this was affecting many using gcc 4.9.x and a workaround was given here https://bugzilla.mozilla.org/show_bug.cgi?id=999496 I tested it and now have (as with 4.8.x): >richard@omnis:/tmp/pkgsrc/devel/xulrunner31/work/build/content/media$ nm -C >MediaDecoderReader.o |grep MallocSizeOf >[148] | 0|29|FUNC |WEAK |2|90 >|mozilla::AudioQueueMemoryFunctor::MallocSizeOf(const void*) > > [_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv] >[145] | 0|29|FUNC |WEAK |2|87 >|mozilla::VideoQueueMemoryFunctor::MallocSizeOf(const void*) > > [_ZN7mozilla23VideoQueueMemoryFunctor12MallocSizeOfEPKv] Is there any further information I can provide now to find this nasty problem?
[Bug c++/61649] New: fixincludes update for solaris___restrict in sys/feature_tests.h on Illumos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649 Bug ID: 61649 Summary: fixincludes update for solaris___restrict in sys/feature_tests.h on Illumos Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Created attachment 33031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33031&action=edit patch to existing fixincludes/inclhack.def from gcc-4.7.3 Due to an update to sys/feature_tests.h as indicated here (https://illumos.org/issues/2941), Illumos has "broken" the fixincludes solaris___restrict hack as is evident by the current result in $PREFIX/gcc47/lib/.../include-fixed/sys/feature_tests.h /* * The following macro defines a value for the ISO C99 restrict * keyword so that _RESTRICT_KYWD resolves to "restrict" if * an ISO C99 compiler is used and "" (null string) if any other * compiler is used. This allows for the use of single prototype * declarations regardless of compiler version. */ #if (defined(__STDC__) && defined(_STDC_C99)) && !defined(__cplusplus) #ifdef __cplusplus #define_RESTRICT_KYWD__restrict #else #define_RESTRICT_KYWDrestrict #endif #else #define_RESTRICT_KYWD #endif The attached patch seem to work around this by allowing both the standard and the Illumos forms to be updated. The test/base/sys/feature_tests.h patch is as follows: --- fixincludes/tests/base/sys/feature_tests.h.orig2010-06-21 15:27:29.0 + +++ fixincludes/tests/base/sys/feature_tests.h @@ -10,6 +10,7 @@ #if defined( SOLARIS___RESTRICT_CHECK ) +#if (defined(__STDC__) && defined(_STDC_C99)) #ifdef __cplusplus #define_RESTRICT_KYWD__restrict #else
[Bug testsuite/63332] New: problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 Bug ID: 63332 Summary: problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Created attachment 33531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33531&action=edit testsuite module updated with couts showing issue is with VERIFY Working with gcc49 on SunOS 5.11 i386 (Omnios) and pkgsrc (32-bit trunk) I came across the following failure: FAIL: ext/random/k_distribution/operators/serialize.cc execution test scratching my head a bit, I added some outputs and found that the problem is with VERIFY and not with the functions being tested. here is my output with the attached (modified) serialize.cc: $ ./a.out u: 2.0e+00 1.5e+00 3.0e+00 2.0e+00 5.0e-01 0.0e+00 1.0e+00 1 -1.08681804426135680e+00 3.0e+00 5.0e-01 0.0e+00 1.0e+00 1 1.89131873404367808e-01 v: 2.0e+00 1.5e+00 3.0e+00 2.0e+00 5.0e-01 0.0e+00 1.0e+00 1 -1.08681804426135680e+00 3.0e+00 5.0e-01 0.0e+00 1.0e+00 1 1.89131873404367808e-01 Assertion failed: u == v, file serialize.cc, line 48, function test01 Abort (core dumped)
[Bug testsuite/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 --- Comment #1 from Richard PALO --- BTW, I'm curious if the problem is related to float rounding in I/O, as in FAIL: ext/random/hypergeometric_distribution/operators/values.cc execution test
[Bug testsuite/63352] New: problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 Bug ID: 63352 Summary: problem with fmt_g0_1.f08 on i386-pc-solaris2.11 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Running the testsuite for gcc 4.9.1 I notice the following gfortran failures: === gfortran tests === Running target unix FAIL: gfortran.dg/default_format_1.f90 -O0 execution test FAIL: gfortran.dg/default_format_1.f90 -O1 execution test FAIL: gfortran.dg/default_format_1.f90 -O2 execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -g execution test FAIL: gfortran.dg/default_format_1.f90 -Os execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O0 execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O1 execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O2 execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -g execution test FAIL: gfortran.dg/fmt_g0_1.f08 -Os execution test Concerning the fmt_g0_1.f08 cases, I notice in particular that while debugging the following bits are the problem: 10 write(buffer, string) ':',1.0_8/3.0_8,':' │ 11 if (buffer.ne.":.1:") call abort │ after 10, the value of buffer is: (gdb) print buffer $1 = ':.', '3' , '2:', ' ' Testsuite problem or no? This is running on SunOS 5.11 (illumos) pkgsrc trunk Compiler version: 4.9.1 (GCC) Platform: i386-sun-solaris2.11 configure flags: --enable-languages='c obj-c++ objc go fortran c++' --enable-shared --enable-long-long --with-local-prefix=/opt/local/gcc49 --enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3 -Wl,-R/opt/local/gcc47/lib -Wl,-R/opt/local/lib ' --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpc=/opt/local --with-mpfr=/opt/local --with-isl=/opt/local --disable-isl-version-check --with-cloog=/opt/local --enable-__cxa_atexit --with-gxx-include-dir=/opt/local/gcc49/include/c++/ --with-gnu-as --with-as=/opt/local/bin/gas --without-gnu-ld --with-ld=/usr/bin/ld --with-libiconv-prefix=/opt/local --prefix=/opt/local/gcc49 --build=i386-sun-solaris2.11 --host=i386-sun-solaris2.11 --infodir=/opt/local/gcc49/info --mandir=/opt/local/gcc49/man
[Bug testsuite/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352
--- Comment #1 from Richard PALO ---
This seems to be a bug in the write formatting for g0
Here is the compile with -fdump-parse-tree showing that the constant expression
is calculated exactly as '3.3331e-1_8'
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = MAIN__
symtree: 'MAIN__' || symbol: 'MAIN__'
type spec : (UNKNOWN 0)
attributes: (PROGRAM PUBLIC SUBROUTINE)
symtree: 'abort' || symbol: 'abort'
type spec : (UNKNOWN 0)
attributes: (PROCEDURE SUBROUTINE)
symtree: 'buffer' || symbol: 'buffer'
type spec : (CHARACTER 50 1)
attributes: (VARIABLE )
symtree: 'string' || symbol: 'string'
type spec : (CHARACTER 25 1)
attributes: (VARIABLE IMPLICIT-SAVE)
value: '(g0,g0,g0) '
code:
WRITE UNIT=MAIN__:buffer FMT='(g0,g0,g0)'
TRANSFER ':'
TRANSFER 12340
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':12340:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT=MAIN__:string
TRANSFER ':'
TRANSFER 0
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':0:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT=MAIN__:string
TRANSFER ':'
TRANSFER 3.3331e-1_8
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':.1:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT='(1x,a,g0,a)'
TRANSFER ':'
TRANSFER 3.3331e-1_8
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ' :.1:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT=MAIN__:string
TRANSFER ':'
TRANSFER 'hello'
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':hello:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT='(g0,g0,g0,g0)'
TRANSFER ':'
TRANSFER .true.
TRANSFER .false.
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':TF:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT='(g0,g0,'','',g0,g0)'
TRANSFER '('
TRANSFER (complex 1.2344_8 2.45670001_8)
TRANSFER ')'
DT_END
IF (/= MAIN__:buffer '(1.2344,2.45670001)')
CALL _gfortran_abort ()
ENDIF
[Bug testsuite/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #2 from Richard PALO --- FWIW, just checked ... this is a regression introduce after 4.7.3 (where this test seems to work fine...can't test 4.8.3 any more, sorry).
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #4 from Richard PALO --- Just checked with the native omnios gcc 4.8.1 and the problem already exists there. I commented as indicated to be able to get debugger output for 2nd part: diff --git a/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 b/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 index ead6f81..3cceae6 100644 --- a/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 +++ b/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 @@ -8,7 +8,7 @@ write(buffer, string) ':',0,':' if (buffer.ne.":0:") call abort write(buffer, string) ':',1.0_8/3.0_8,':' -if (buffer.ne.":.1:") call abort +!if (buffer.ne.":.1:") call abort write(buffer, '(1x,a,g0,a)') ':',1.0_8/3.0_8,':' if (buffer.ne." :.1:") call abort write(buffer, string) ':',"hello",':' with 4.9.1 buffer is as follows for the two writes with 1/3: (gdb) p buffer $1 = ':.', '3' , '2:', ' ' (gdb) n (gdb) p buffer $2 = ' :.', '3' , '2:', ' ' under 4.7.3: (gdb) p buffer $1 = ':.', '3' , '1:', ' ' (gdb) n (gdb) p buffer $2 = ' :.', '3' , '1:', ' '
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #5 from Richard PALO --- Created attachment 33550 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33550&action=edit output from --save-temps
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #7 from Richard PALO --- $ cat test.f08 character(25) :: string = "(g0,g0,g0)" character(50) :: buffer write(buffer, string) ':',1.0_8/3.0_8,':' print *, "'", buffer, "'" print *, "'", " :.1:", "'" write(buffer, '(1x,a,g0,a)') ':',1.0_8/3.0_8,':' print *, "'", buffer, "'" print *, "'", " :.1:", "'" end $ gfortran test.f08 -o test $ ./test ':.2: ' ' :.1:' ' :.2: ' ' :.1:' Output the same with/without attached is the .s
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #8 from Richard PALO --- Created attachment 33553 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33553&action=edit test.s
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #9 from Richard PALO --- output from 4.7.3: ':.1: ' ' :.1:' ' :.1: ' ' :.1:' and test.s.4.7.3 attached
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #10 from Richard PALO --- Created attachment 33554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33554&action=edit test.s from 4.7.3
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 --- Comment #4 from Richard PALO --- >>Could you please add -fno-access-control to the "dg-options" flags at the top >>of the file and replace the VERIFY check with the following: >>std::cout << (u._M_param._M_lambda == v._M_param._M_lambda) << '\n'; >>std::cout << (u._M_param._M_mu == v._M_param._M_mu) << '\n'; >>std::cout << (u._M_param._M_nu == v._M_param._M_nu) << '\n'; >>std::cout << (u._M_gd1 == v._M_gd1) << '\n'; >>std::cout << (u._M_gd2 == v._M_gd2) << '\n'; Hi, seems I needed to add an #include but anyway, the output is: 1 1 1 1 0 BTW, I did this manually as I'm not very proficient with `runtest`, isn't there a shortcut to somehow run only this test?
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
--- Comment #5 from Richard PALO ---
By the way, in gdb, here are the complete u and v variables after
serialisation:
gdb) p u
$1 = {_M_param = {_M_lambda = 2, _M_mu = 1.5, _M_nu = 3}, _M_gd1 = {
_M_param = {_M_alpha = 2, _M_beta = 0.5, _M_malpha = 2,
_M_a2 = 0.25819888974716108}, _M_nd = {_M_param = {_M_mean = 0,
_M_stddev = 1}, _M_saved = -1.0868180442613568,
_M_saved_available = true}}, _M_gd2 = {_M_param = {_M_alpha = 3,
_M_beta = 0.5, _M_malpha = 3, _M_a2 = 0.20412414523193152}, _M_nd = {
_M_param = {_M_mean = 0, _M_stddev = 1}, _M_saved = 0.18913187340436784,
_M_saved_available = true}}}
(gdb) p v
$2 = {_M_param = {_M_lambda = 2, _M_mu = 1.5, _M_nu = 3}, _M_gd1 = {
_M_param = {_M_alpha = 2, _M_beta = 0.5, _M_malpha = 2,
_M_a2 = 0.25819888974716108}, _M_nd = {_M_param = {_M_mean = 0,
_M_stddev = 1}, _M_saved = -1.0868180442613568,
_M_saved_available = true}}, _M_gd2 = {_M_param = {_M_alpha = 3,
_M_beta = 0.5, _M_malpha = 3, _M_a2 = 0.20412414523193152}, _M_nd = {
_M_param = {_M_mean = 0, _M_stddev = 1}, _M_saved = 0.1891318734043678,
_M_saved_available = true}}}
I notice _M_saved in v is truncated by 1 (the trailing '4')...
that is, 16 and not 17 digits after the decimal are copied.
[Bug libstdc++/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 --- Comment #6 from Richard PALO --- sorry, I meant to say M_gd2._M_saved
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #13 from Richard PALO --- Since this regresses on the same omnios (illumos) platform between gcc 4.7.3 and 4.8.1 are there some pointers on how to identify the issue in illumos? (the fact the 4.8.1 tested is native omnios (R151012) eliminates any eventual pkgsrc issue, for me at least). that is, 'git diff local-4.7.3 local-4.8.1` seems like quite a bit of work. otherwise, I'll have to port a more recent gdb because 7.6.1 balks under gcc 4.9.1 may be awhile before I have the time... cheers
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #15 from Richard PALO --- (In reply to r...@cebitec.uni-bielefeld.de from comment #14) > > --- Comment #13 from Richard PALO --- > [...] > > otherwise, I'll have to port a more recent gdb because 7.6.1 balks under gcc > > 4.9.1 > > may be awhile before I have the time... > > What porting is there to do? For me, configure; make; make install just > works on Solaris. > > Rainer Well, I get this, for example: In file included from opncls.c:26:0: opncls.c: In function 'bfd_fopen': bfd.h:529:65: error: right-hand operand of comma expression has no effect [-Werror=unused-value] #define bfd_set_cacheable(abfd,bool) (((abfd)->cacheable = bool), TRUE) ^ opncls.c:263:5: note: in expansion of macro 'bfd_set_cacheable' bfd_set_cacheable (nbfd, TRUE); ^
[Bug other/66722] New: libiberty/pex-unix.c warning: initialization from incompatible pointer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66722 Bug ID: 66722 Summary: libiberty/pex-unix.c warning: initialization from incompatible pointer type Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Target Milestone: --- Created attachment 35886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35886&action=edit pex_unix_wait returns pid_t (as does wait()) noticed while building: >../../gcc-4.9.3/libiberty/pex-unix.c:325:3: warning: initialization from >incompatible pointer type >../../gcc-4.9.3/libiberty/pex-unix.c:325:3: warning: (near initialization for >'funcs.wait') >../../gcc-4.9.3/libiberty/pex-unix.c:325:3: warning: initialization from >incompatible pointer type >../../gcc-4.9.3/libiberty/pex-unix.c:325:3: warning: (near initialization for >'funcs.wait') attached patch get over the int/pid_t confusion: Also, from inspection I noticed waitpid() needs correction too.
[Bug c++/61649] fixincludes update for solaris___restrict in sys/feature_tests.h on Illumos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649 --- Comment #5 from Richard PALO --- kind reminder to push these two patches: 1) https://gcc.gnu.org/bugzilla/attachment.cgi?id=33031 2) and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649#c1 (*) * NB https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52168 I believe I already answered Jonathan's question in that since only a [preceeding] line of context is being added, there is no additional '#endif' to add. BTW, this line of context is necessary anyway, because if either Oracle Solaris or Illumos change this code section, for example by fixing it as gcc currently does here, it will prevent fixincl.x from action which would actually *break* the file.
[Bug target/64030] some libiberty sources includes stdio.h prior to config.h causing redefined symbol warnings on i?86-*-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64030 --- Comment #1 from Richard PALO --- kind reminder to commit this patchset
[Bug other/66753] New: contrib/make_sunver.pl doesn't digest libraries very well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66753
Bug ID: 66753
Summary: contrib/make_sunver.pl doesn't digest libraries very
well
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: richard at netbsd dot org
Target Milestone: ---
The following patch gets over issues with libraries (on pkgsrc for SunOS)
where,
for example, '-lrt' is passed (not needing any treatment whatsoever).
diff --git a/contrib/make_sunver.pl b/contrib/make_sunver.pl
index 8a90b1f..bfd1260 100644
--- a/contrib/make_sunver.pl
+++ b/contrib/make_sunver.pl
@@ -43,6 +43,8 @@ foreach $file (@ARGV) {
if (($so = $file) =~ s/\.a$/.so/ && -e $so) {
printf STDERR "omitted $file -> $so\n";
push (@SHAREDOBJS, $so);
+} elsif ( $file =~ /^-l/ ) {
+ printf STDERR "omitted $file\n";
} else {
push (@OBJECTS, $file);
}
[Bug ipa/61820] 32-bit g++.dg/ipa/pr61160-3.C execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61820 Richard PALO changed: What|Removed |Added CC||richard at netbsd dot org --- Comment #2 from Richard PALO --- I have this as well on SunOS 5.11 illumos with 4.9* (on pkgsrc)
[Bug target/63789] g++ -m32 on solaris has trouble finding abs with int64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789 --- Comment #5 from Richard PALO --- Created attachment 39510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39510&action=edit tabs.ii No, I still see the issue with both v5 and 4.9.4 attached is tabs.ii using -save-temps
