--- Comment #19 from burnus at gcc dot gnu dot org 2010-09-10 06:02 ---
Subject: Bug 45186
Author: burnus
Date: Fri Sep 10 06:01:50 2010
New Revision: 164143
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164143
Log:
2010-09-10 Tobias Burnus bur...@net-b.de
PR
--- Comment #20 from jv244 at cam dot ac dot uk 2010-09-10 06:36 ---
Tobias,
many thanks for working on this... I mentioned this before in the PR, but it
would be very good if some line number testcases were added to the regression
tests. Both for performance measurements and
Querying the position in a file uses filebuf::seekoff( 0, ios::cur ). Although
the Standard specifies that this combination of parameters does not flush
putback or the output sequence, it does anyway, which results in a performance
hit. (§27.8.1.4/11)
Regression:
--- Comment #1 from potswa at mac dot com 2010-09-10 07:09 ---
Created an attachment (id=21762)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21762action=view)
simple testcase
This little program attempts to read three characters from its own source,
checking the position each
--- Comment #21 from burnus at gcc dot gnu dot org 2010-09-10 07:25 ---
(In reply to comment #20)
many thanks for working on this... I mentioned this before in the PR, but it
would be very good if some line number testcases were added to the regression
tests.
I concur - with
At least on MinGW64 (as reported by nightstrike), the following warning is
printed when compiling libgfortran:
libgfortran/io/list_read.c:1872:10: warning: variable 'elem' might be clobbered
by 'longjmp' or 'vfork' [-Wclobbered]
If one looks at the source, one sees:
1869 list_formatted_read
Revision 164050 breaks bootstrap on powerpc-apple-darwin9
...
/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem
Following simple example:
#include stdio.h
static void a(void)
{
printf(a\n);
}
static void b(void)
{
printf(b\n);
}
static void __attribute__((noinline)) do_call(void (*p)(void))
{
p();
}
int main(void)
{
int i;
for (i = 0; i 30; i++)
The attached test case is testing inlining of const function pointers
in a typical OO code written in C situation.
The code shows two optimization problems:
- a_foo is inlined into main, b_foo is not.
The only difference is that new_a() returns a const pointer
and new_b() does not. I would have
--- Comment #1 from andi-gcc at firstfloor dot org 2010-09-10 08:50 ---
Created an attachment (id=21763)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21763action=view)
testcase, compiled with -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
--- Comment #6 from tkoenig at gcc dot gnu dot org 2010-09-10 09:15 ---
(In reply to comment #5)
I agree that the front-end is missing a statement walker to infer information
out of the code.
I have a patch for a more general statement walker, which I will probably
submit after the
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45630
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Segfault in |[4.6 Regression] Segfault in
--- Comment #41 from rguenth at gcc dot gnu dot org 2010-09-10 09:33
---
(In reply to comment #40)
A test installation based on a copy of the GCC Bugzilla database (snapshot
taken today, September 9) and upgraded to Bugzilla 3.6.2 is now live at
http://gcc.gnu.org/bugzilla-test/.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-10 09:42 ---
Subject: Bug 45605
Author: hubicka
Date: Fri Sep 10 09:42:20 2010
New Revision: 164148
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164148
Log:
PR tree-optimization/45605
* cp/class.c
--- Comment #1 from charlet at gcc dot gnu dot org 2010-09-10 09:47 ---
Fixed by revision 164149
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from redi at gcc dot gnu dot org 2010-09-10 09:55 ---
There certainly is a race condition: there's no ordering between pthread_cancel
and pthread_testcancel so the main thread can run f2(50) before thread2 calls
pthread_cancel, which is why you see it sometimes run
--- Comment #42 from jv244 at cam dot ac dot uk 2010-09-10 09:58 ---
(In reply to comment #40)
Please give it a look, and file bugs related to missing or broken
customizations in the new Bugzilla product on the test installation, i.e.
using this link:
--- Comment #17 from redi at gcc dot gnu dot org 2010-09-10 10:11 ---
(In reply to comment #15)
In particular, it does not appear that the thread is being reliably cancelled
at the pthread_testcancel call - sometimes f2 seems to run beyond the
pthread_testcancel,
As I said above,
--- Comment #43 from burnus at gcc dot gnu dot org 2010-09-10 10:29 ---
The attachment is not viewable in your browser due to security restrictions
enabled by Bugzilla. In order to view the attachment, you first have to
download it.
I think at least text/* attachments should be shown.
--- Comment #44 from LpSolit at netscape dot net 2010-09-10 10:34 ---
(In reply to comment #43)
I think at least text/* attachments should be shown.
Ah yes, sorry, I forgot to enable the allow_attachment_display parameter (which
is off by default). This is now fixed. Thanks for
--- Comment #45 from jakub at gcc dot gnu dot org 2010-09-10 10:46 ---
The Log In line in elinks looks quite weird. There is
a text field Bugzilla_login, then Bugzilla_password (both expected), but then
there is another text field prefilled with password:
input
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-10 10:52 ---
Subject: Bug 45630
Author: jakub
Date: Fri Sep 10 10:52:16 2010
New Revision: 164163
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164163
Log:
PR bootstrap/45630
* dwarf2out.c
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-10 10:55
---
_M_terminate_output, correctly, does nothing in this case, cannot be the
problem, and there is nothing wrong wrt the standard mandated behavior. The
problem is that in our implementation, similarly to
-languages=c,c++,lto --with-win32-nlsapi=unicode
--enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions
--enable-gomp
Thread model: posix
gcc version 4.6.0 20100910 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-MMD' '-MF' 'libmpcodecs/vd_ffmpeg.d' '-MT'
'libmpcodecs/vd_ffmpeg.o
--- Comment #1 from jojelino at gmail dot com 2010-09-10 11:19 ---
Created an attachment (id=21764)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21764action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45633
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-10 11:29 ---
Are you really using the fortran-dev branch?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from burnus at gcc dot gnu dot org 2010-09-10 12:09 ---
Created an attachment (id=21765)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21765action=view)
Updated patch
Updated patch to fix review issues and the Cray patch issue. I won't be able to
work on this (i.e.
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-10 12:09
---
I *think* it can work to minimally change what we have now to not reset the get
area buffers when (0, ios::cur) and we have been reading: as far as I can see,
if in that specific case we get back to reading
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #22 from burnus at gcc dot gnu dot org 2010-09-10 12:12 ---
(In reply to comment #21)
Created an attachment (id=21765)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21765action=view) [edit]
Updated patch
Note: I forgot to include the test case from attachment 21265
--- Comment #3 from jojelino at gmail dot com 2010-09-10 12:13 ---
(In reply to comment #2)
Are you really using the fortran-dev branch?
$ git branch
* trunk
it is trunk.
i don't recognize how fortran-dev version have been selected. maybe i've
mistaken.
--
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-10 12:20
---
Does not work: when we reach the end of the buffer and we access again the file
to refill it, we start reading from the wrong position, the position we seeked
to.
--
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-10 12:36
---
To clarify: when we start reading in a buffered mode, the first underflow reads
the buffer and leaves the physical file at the first char beyond the buffer. If
we do afterwards a seek to the current reading
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-10 12:59 ---
The test in comment #0 has been fixed by revision 164111. However it seems that
191.fma3d in
SPEC CPU 2K is not fixed by this revision (see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00913.html ).
--
On Linux/x86-64, revision 163997 failed to build 191.fma3d in
SPEC CPU 2K:
[...@gnu-27 0001]$ /export/gnu/import/svn/gcc-test/usr/bin/gfortran -c -o
getirv.o -DSPEC_CPU2000_LP64 -O3 -funroll-loops -ffast-math
getirv.f90
getirv.f90: In function #65533;rcrdrd#65533;:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45634
--- Comment #5 from dominiq at lps dot ens dot fr 2010-09-10 13:24 ---
Since pr45634 has been opened for the failure of 191.fma3d in SPEC CPU 2K, I am
closing this one as fixed. Thanks for the commit.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45593
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45470
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-09-10 13:26 ---
(In reply to comment #6)
(In reply to comment #5)
I see before SLP:
bb 2:
MEM[(struct A *)this_1(D)].a = 0;
MEM[(struct A *)this_1(D)].b = 0;
MEM[(struct A *)this_1(D)].c = 0;
[LP 2]
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-10 13:39 ---
[...@gnu-16 0001]$ cat pr45634.f90
SUBROUTINE RCRDRD (VTYP)
CHARACTER(4), INTENT(OUT) :: VTYP
CHARACTER(1), SAVE :: DBL = D
VTYP = DBL
END
[...@gnu-16 0001]$
--- Comment #6 from don dot wakefield at gmail dot com 2010-09-10 14:06
---
Re: comment 5 - what is needed is for filebuf::seekoff(0,ios::cur) to:
1) *not* invalidate the buffer
2) *not* move the file pointer
since all that special case asks is where am I in the 'logical' file?
On Linux/ia64, revision 164164 gave
../../../../src-trunk/libstdc++-v3/libsupc++/array_type_info.cc:33:1: internal
compiler error: tree check: expected tree that contains 'decl with RTL'
structure, have 'addr_expr' in output_constant, at varasm.c:4408
Please submit a full bug report,
with
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-10 14:22 ---
Subject: Bug 44115
Author: rguenth
Date: Fri Sep 10 14:22:22 2010
New Revision: 164179
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164179
Log:
2010-09-10 Richard Guenther rguent...@suse.de
PR
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-10 14:38 ---
Fixed for 4.6.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-10 14:39 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00951.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-10 14:39
---
Then, seekoff would also return a position beyond the buffer, right? Or you
want it to return 1 anyway? Actually, I think the standard want us to use width
* off for the underlying fseek anyway, not only for
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-10 14:40 ---
For the interprocedural analysis I believe static points-to is the only
reasonable thing to do, anything else would have too big complexity (both space
and time). Within one function, sure, you have the code, but not
--- Comment #3 from hjl at gcc dot gnu dot org 2010-09-10 14:44 ---
Subject: Bug 45634
Author: hjl
Date: Fri Sep 10 14:44:20 2010
New Revision: 164183
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164183
Log:
Check that result of string folding is of integral type.
gcc/
:
.size rcrdrd_, .-rcrdrd_
.section.rodata
.type dbl.1557, @object
.size dbl.1557, 1
dbl.1557:
.ascii D
.ident GCC: (GNU) 4.6.0 20100910 (experimental)
.section.note.GNU-stack,,@progbits
IFORT generates:
[...@gnu-6 pr45634]$ cat
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-10 14:52 ---
It may be caused by revision 164148:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00440.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
--- Comment #8 from don dot wakefield at gmail dot com 2010-09-10 14:54
---
Paolo, yes, _M_file.seekoff(0,cur) would return the current physical file
position, and then filebuf::seekoff would adjust the returned pos_type to
reflect the position within the *logical* file, framed by the
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-10 15:00
---
Ok. I don't think we should change the code to deal such specially with off ==
0, if we are going to change it we should decouple the return value from what
the underlying seek returns, and always call
Please have a look at this test case:
#include stdint.h
struct type1 {
union {
uint8_t reg;
struct {
uint8_t : 7;
uint8_t b : 1;
} bit;
} foo [1];
uint8_t bar;
};
volatile
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-10 15:12 ---
I have a slightly different result with your code.
troutmask:sgk[212] gfc4x -c -O g.f90
g.f90: In function 'rcrdrd':
g.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218
Please submit a full bug
--- Comment #10 from don dot wakefield at gmail dot com 2010-09-10 15:15
---
(In reply to comment #9)
Ok. I don't think we should change the code to deal such specially with off ==
0, if we are going to change it we should decouple the return value from what
the underlying seek
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10
15:15 ---
Subject: Re: [4.6 regression] Reference to undefined label building libada no
Solaris 2/SPARC
A reghunt identified that the regression was caused by this patch:
2010-09-07 Jan Hubicka j...@suse.cz
--- Comment #4 from ro at gcc dot gnu dot org 2010-09-10 15:19 ---
Jan, could you please have a look.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from paolo dot carlini at oracle dot com 2010-09-10 15:19
---
Sure. What I meant - contrary to wait you said, I think - is that an elegant
and complete solution to this issue involves changing much more generally our
code to *always* behave as if fseek(off * width) were
--- Comment #2 from kargl at gcc dot gnu dot org 2010-09-10 15:20 ---
The -fdump-tree-original for HJ's original code look like
rcrdrd (character(kind=1)[1:4] restrict vtyp, integer(kind=4) _vtyp)
{
static character(kind=1) dbl[1:1] = D;
(MEM[(c_char * {ref-all})vtyp] =
--- Comment #12 from don dot wakefield at gmail dot com 2010-09-10 15:24
---
(In reply to comment #11)
Sure. What I meant - contrary to wait you said, I think - is that an elegant
and complete solution to this issue involves changing much more generally our
code to *always* behave
: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk/configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-164162-lto-fortran-checking-yes-rtl-df/
Thread model: posix
gcc version 4.6.0 20100910 (experimental) (GCC)
I think this never
--- Comment #24 from tstarling at wikimedia dot org 2010-09-10 15:25
---
Created an attachment (id=21766)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21766action=view)
dynamic_cast hack
The attached patch uses a dynamic_cast hack to avoid the need to break the
ABI. I added
cd rts; ../../xgcc -B../../ -shared -g -O2 \
-fPIC -frandom-seed=fixed-seed \
-o libgnat-4.6.sl \
a-assert.o a-calari.o a-calcon.o a-caldel.o a-calend.o
a-calfor.
o a-catizo.o a-cdlili.o a-cgaaso.o a-cgarso.o a-cgcaso.o a-chacon.o a-chahan.o
a
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 15:30 ---
1. index is constant or variable, and
Yes that is correct.
2. the 'bar' field type.
The alignment of the access is different in those cases.
In any case byte accesses should be used.
Why, word access is just
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-10 15:32 ---
(In reply to comment #1)
I have a slightly different result with your code.
troutmask:sgk[212] gfc4x -c -O g.f90
g.f90: In function 'rcrdrd':
g.f90:1:0: internal compiler error: in build_int_cst_wide, at
--- Comment #4 from kargl at gcc dot gnu dot org 2010-09-10 15:34 ---
(In reply to comment #3)
(In reply to comment #1)
I have a slightly different result with your code.
troutmask:sgk[212] gfc4x -c -O g.f90
g.f90: In function 'rcrdrd':
g.f90:1:0: internal compiler error: in
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-10 15:35 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:43 ---
(In reply to comment #1)
1. index is constant or variable, and
Yes that is correct.
2. the 'bar' field type.
The alignment of the access is different in those cases.
Sorry, the test case
--- Comment #13 from paolo dot carlini at oracle dot com 2010-09-10 15:45
---
Good, I think we are close to a fix, I'm already testing something. So, do we
have a symmetric issue with the put area or not? I'm not sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 15:46 ---
For volatile fields we should use accesses of the appropriate width.
The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC it
says they should be doing the largest available (up to the
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-10 15:47 ---
For arbitrary lengths (both of the constant string and of the padding) the
memmove (which will be optimized to memcpy as the source is read-only) + memset
is the best thing to do, replacing say
memmove (x, 900 bytes
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10
15:48 ---
Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris
2/SPARC
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-09 13:27
---
I don't have access to
--- Comment #6 from rguenther at suse dot de 2010-09-10 15:51 ---
Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file
on Solaris 2/SPARC
On Fri, 10 Sep 2010, ro at CeBiTec dot Uni-Bielefeld dot DE wrote:
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:59 ---
(In reply to comment #3)
For volatile fields we should use accesses of the appropriate width.
The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC
it
says they should
--- Comment #14 from potswa at mac dot com 2010-09-10 15:59 ---
(In reply to comment #13)
Good, I think we are close to a fix, I'm already testing something. So, do we
have a symmetric issue with the put area or not? I'm not sure.
I believe so. tellg and tellp are both handled by
--- Comment #25 from paolo dot carlini at oracle dot com 2010-09-10 16:01
---
Good. Please give me a couple of days to come to your code. Note, since you
don't have a Copyright Assignment on file, it will be difficult to fully
acknowledge your work in the ChangeLog. Thus, I would
--- Comment #5 from leftynm at umich dot edu 2010-09-10 16:06 ---
Thanks guys. Yeah, I guess my use of PARAMETER wasn't consistent with how it
works. I was using it to set a variable such that it cannot be changed. I
found a work around though lets me keep it as a PARAMETER, but
--- Comment #8 from mikael at gcc dot gnu dot org 2010-09-10 16:11 ---
In the patch there is a small mistake :
+ if (symtree-n.sym-attr.flavor == FL_PARAMETER
+ symtree-n.sym-attr.intent != INTENT_OUT)
+symtree-n.sym-points_to = gfc_pt_dummy;
Parameters in the fortran
--- Comment #15 from potswa at mac dot com 2010-09-10 16:15 ---
(In reply to comment #14)
(The result doesn't depend on
the pointers, it comes from fseek.)
I re-read Comment 5 and understand it this time ;v) . Well, any solution should
fix both tellg and tellp, since the pointers
Compiler output:
$ gcc -mno-mmx -m3dnow -flto gcc.c-torture/execute/20050316-2.c
In file included from gcc.c-torture/execute/20050316-2.c:34:0,
from :0:
gcc.c-torture/execute/20050316-2.c: In function 'main':
gcc.c-torture/execute/20050316-2.c:45:15: internal compiler error: in
--- Comment #16 from paolo dot carlini at oracle dot com 2010-09-10 17:11
---
Actually, however, I don't think we can really always call fseek(off * width)
as the Standard want us to do. In a sense I'm happy because the change is gonna
be less invasive, on the other hand I'm a bit
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-09-10 17:14 ---
Hi,
would be possible to have preprocessed source for a cross compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
Have problem to make fortran work in x64 environment.
Linux test1.us.icap.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux
gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-10 17:20 ---
libmpfr.so.1: undefined symbol: __gmp_get_memory_functions
That means libmpfr is finding the incorrect GMP. This is not a GCC bug but
rather a bug in your LD_LIBRARY_PATH or ld.so configuration.
--
pinskia at
--- Comment #17 from potswa at mac dot com 2010-09-10 17:25 ---
(In reply to comment #16)
Actually, however, I don't think we can really always call fseek(off * width)
as the Standard want us to do. In a sense I'm happy because the change is
gonna
be less invasive, on the other
--- Comment #18 from paolo dot carlini at oracle dot com 2010-09-10 17:29
---
I'm almost ready for the patch, please be patient ;) If look at the standard,
it says that the last step of seekoff is *always* as if calling fseek(..., off
* width, ...). If look at the current code, we have
--- Comment #19 from paolo dot carlini at oracle dot com 2010-09-10 17:30
---
Of course here I'm always under the assumption width 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #1 from tbptbp at gmail dot com 2010-09-10 17:34 ---
Created an attachment (id=21767)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21767action=view)
large fugly testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
away.
I've failed to reduce both manually and with delta (mismatched prototypes are
too easily produced). Sorry.
$ /usr/local/gcc-4.6-20100910/bin/g++ -std=c++0x -c synth.ii
src/audio/synth_voice_impl.h:140:6: error: prototype for 'bool
synth::voice::voice_t::produce_chunk(const synth
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-09-10 17:34 ---
I think you need __attribute((aligned(16))) on the original forward declared
class too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-10 17:35 ---
This seems related to PR 45112.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45642
--- Comment #20 from potswa at mac dot com 2010-09-10 17:35 ---
(In reply to comment #17)
The task is to call fseek(0,cur), and then subtract the number of bytes in the
put area plus the external characters, right?
Er, I don't mean bytes in the put area exactly, but you know what I
1 - 100 of 145 matches
Mail list logo
