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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146
Richard PALO changed:
What|Removed |Added
CC||richard at netbsd dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61820
Richard PALO changed:
What|Removed |Added
CC||richard at netbsd dot org
--- Comment #2
ormal
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 needin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64030
--- Comment #1 from Richard PALO ---
kind reminder to commit this patchset
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?
: 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 return
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/pkgsr
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
> @@
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 ha
: 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&
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 p
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(__STD
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52168
Richard PALO changed:
What|Removed |Added
CC||richard at netbsd dot org
--- Comment #9
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
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
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
Med
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?
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
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(
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
/us
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
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.
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--
#ifnde
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:
> > #ifnde
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
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/
y: 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 __att
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
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 de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352
Richard PALO changed:
What|Removed |Added
Attachment #33676|0 |1
is obsolete|
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
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
dem
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
> > m
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) el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332
--- Comment #6 from Richard PALO ---
sorry, I meant to say M_gd2._M_saved
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_m
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) <<
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
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
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
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:", "'"
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
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
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).
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
: 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
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
: 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
: 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 f
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?
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.
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
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*"
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 releva
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
ion: 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.
58 matches
Mail list logo
