--- Comment #18 from dominiq at lps dot ens dot fr 2010-08-05 07:04 ---
> Unverified but I am told that this issue should be fixed in Xcode 3.2.3.
AFAICT it is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-08-05 07:05 ---
Confirmed, also fails with current trunk.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
---
> gfortran --version
GNU Fortran (GCC) 4.5.1
> uname -a
Linux tiree.nag.co.uk 2.6.27.25-170.2.72.fc10.x86_64 #1 SMP Sun Jun 21 18:39:34
EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
> cat cfpointerstress.f90
MODULE NAG_J_TYPES
USE ISO_C_BINDING, ONLY : C_PTR
IMPLICIT NONE
TYPE
current implementation has issues with namespace scopes and allows unqualified
access, ie:
#include
int main()
{
atomic_int ai;
return 0;
}
this should require std::atomic_int
--
Summary: unqualified atomic access
Product: gcc
Version: unknown
I have an OpenMP code segment:
#pragma omp parallel for
for (i = 0; i < size; i++)
Built with mingw gcc 4.4.0. Run on Windows XP SP3, AMD 64 Athlon FX62 dual
core.
Run in an exe application it works fine, however when invoked as code in a DLL
the for loop threads do not increment properly and th
current implementation has issues with namespace scopes and allows unqualified
access, ie:
#include
int main()
{
atomic_int ai;
return 0;
}
this should require std::atomic_int
--
Summary: unqualified atomic access
Product: gcc
Version: unknown
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-05 09:34
---
*** This bug has been marked as a duplicate of 45191 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-05 09:34
---
*** Bug 45193 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45191
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-05 09:42 ---
You probably have to build applications that use the DLL thread-aware.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45192
--
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=45189
--
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=45188
--- Comment #2 from jv244 at cam dot ac dot uk 2010-08-05 11:13 ---
confirmed with 4.5/4.6, works with 4.3/4.4. Compiling with
-fdump-tree-all-lineno and looking into tx_f90_pointers.f90.003t.original shows
that most of the lineno info has disappeared in 4.5.
--
jv244 at cam dot ac d
--- Comment #56 from bernds at gcc dot gnu dot org 2010-08-05 11:31 ---
Created an attachment (id=21400)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21400&action=view)
A patch to aid debugging
This patch should help pinpoint exactly what went wrong. It adds a dbg-cnt to
the cod
With gcc trunk revision 162816 I am unable to compile Firefox with
WHOPR (or LTO, for that matter) because I get the following ICE:
lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:292
I will attach preprocessed versions of four source files which are
necessary to repro
--- Comment #1 from jamborm at gcc dot gnu dot org 2010-08-05 11:53 ---
Created an attachment (id=21401)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21401&action=view)
Original testcase
After extracting, set CC and CXX variables to paths to c and c++
compilers respectively and r
--- Comment #14 from janus at gcc dot gnu dot org 2010-08-05 11:58 ---
(In reply to comment #13)
> On x86_64-apple-darwin10.4.0 at r162881, I have tested all the codelets I have
> for the PRs fixed by r162879 with both -m32 and -m64 without linking error.
Great. So I guess we can close
--- Comment #23 from janus at gcc dot gnu dot org 2010-08-05 12:11 ---
For me all the test cases seems to be working now. Mikael, can we close this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
Using GCC 4.4.1 and the following command, test generates an "array subscript
is above array bounds" warning.
gcc -S -Os test.c -Wall
void foo (int b[2][6])
{
int i = 0;
for (i = 0; i < 6; i++)
{
int *pb = &b[1][i];
*pb = 0;
}
}
Output from VRP looks like
foo (int[6] *
--- Comment #2 from john at quivinco dot com 2010-08-05 12:39 ---
Thanks, but how is that done? Is it in the documentation?
(In reply to comment #1)
> You probably have to build applications that use the DLL thread-aware.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45192
--- Comment #24 from mikael at gcc dot gnu dot org 2010-08-05 12:59 ---
(In reply to comment #23)
> For me all the test cases seems to be working now. Mikael, can we close this?
>
I'll backport the fixes to 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
--- Comment #17 from clerman at fuse dot net 2010-08-05 13:03 ---
Subject: Re: [4.6 Regression] ICE in
output_constructor_regular_field, at varasm.c:4996
Hello,
Your fix worked fine, and I am now again able to build my application. Thanks
again.
Yours truly,
Norm
Norman S. Clerm
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-05 13:16 ---
Fixed in 4.4.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-08-05 13:36 ---
Subject: Bug 42855
Author: jamborm
Date: Thu Aug 5 13:36:18 2010
New Revision: 162913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162913
Log:
2010-08-05 Martin Jambor
PR testsuite/42855
The cleanups to i386 prologue/epilogue generation (r162882 -r162891) cause 161
libstdc++ failures at -m32 on *86*-apple-darwin10 due to new warnings of the
form...
Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/g++
-shared-libgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/da
--- Comment #4 from siarhei dot siamashka at gmail dot com 2010-08-05
13:40 ---
Looks like this missed optimization regression was introduced in gcc 4.5
Are any similar fixes possible in 4.5 branch?
--
siarhei dot siamashka at gmail dot com changed:
What|Removed
--- Comment #5 from bmei at broadcom dot com 2010-08-05 13:44 ---
I tried to apply the patches (this one alone is not enough) Richard suggested.
It becomes a chain of too many patches in the end. I am confident any more to
apply them to 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #21 from janus at gcc dot gnu dot org 2010-08-05 13:56 ---
Subject: Bug 44929
Author: janus
Date: Thu Aug 5 13:56:00 2010
New Revision: 162914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162914
Log:
2010-08-05 Janus Weil
Steven G. Kargl
--- Comment #22 from janus at gcc dot gnu dot org 2010-08-05 13:57 ---
Fixed on trunk an 4.5. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-05 14:04 ---
It is caused by revision 162888:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00099.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45189
--- Comment #1 from iains at gcc dot gnu dot org 2010-08-05 14:23 ---
does this solve the problem?
(it's a hack - we should ensure that the debug sections do not appear in
between our program sections, but that's for another day).
Index: gcc/config/darwin.c
===
--- Comment #5 from paolo dot carlini at oracle dot com 2010-08-05 14:38
---
Ian, is this a libgcc issue? Can you suggest the best wa to triage it? Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
In Fortran 2008, an ELEMENTAL procedure needs not necessarily be PURE.
Procedures can now be specified to be IMPURE, and if this is applied to an
ELEMENTAL procedure it is not automatically PURE as it otherwise is.
For instance, the following code will fill b(n) with cumulative sum of elements
in
When building g++.dg/torture/pr36445.C at -O2 you can see
call_Z5func2v
movaps %xmm0, (%rsp)
movq(%rsp), %rdx
movq8(%rsp), %rax
movq%rdx, 16(%rsp)
movl%eax, 24(%rsp)
where the stack-slot spills are caused by
(insn 26 5 27 2 (se
--- Comment #1 from domob at gcc dot gnu dot org 2010-08-05 15:02 ---
Mine.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-05 15:03 ---
Created an attachment (id=21402)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21402&action=view)
patch needed
Patch needed to trigger this exact situation with that exact testcase.
--
http://gcc.gnu.org/
--- Comment #2 from rth at gcc dot gnu dot org 2010-08-05 15:40 ---
Subject: Bug 45189
Author: rth
Date: Thu Aug 5 15:39:54 2010
New Revision: 162917
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162917
Log:
PR 45189
Unbreak ia64 build after last dwarf2out.c change.
Modified:
--- Comment #4 from danglin at gcc dot gnu dot org 2010-08-05 15:43 ---
Also seen on darwin9.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-05 15:46 ---
The problem also occurs with 4.6.0.
Note, if you remove the ', only : c_ptr' in NAG_J_TYPES,
the code compiles and produces
laptop:kargl[214] gfc4x -o z tr.f90
laptop:kargl[215] ./z
C_ASSOCIATED = T
ASSOCIATED = T
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-05 15:53 ---
Sth like
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 162913)
+++ config/i386/i386.md (working copy)
@@ -1957,6 +1957,30 @@ (define
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-05 15:55 ---
(subreg:DI
+ (match_operand:V4SF 1 "register_operand"
+ "x,x") 0)
That is not a valid subreg and should have be rejected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-05 15:58 ---
How did you get that subreg in the first place; it should have produced a
vec_extract there instead of a subreg.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-05 16:03 ---
> The problem also occurs with 4.6.0.
As well as with 4.4.4.
Note that an other pr related to the use of ONLY (pr44702) has been fixed by
Tobias Burnus: I CCed him.
--
dominiq at lps dot ens dot fr changed:
--- Comment #5 from rguenther at suse dot de 2010-08-05 16:16 ---
Subject: Re: Unnecessary spill slot for highpart extraction
of xmm reg
On Thu, 5 Aug 2010, pinskia at gcc dot gnu dot org wrote:
> --- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-05 15:58
> ---
> H
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-05 16:38 ---
-fpic is broken. On Fedora 13, I got:
[...@gnu-15 gcc]$ ./xgcc -B./
/net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-thiscall-1.C
-mstackrealign -mpreferred-stack-boundary=5 -O -c
[..
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-05 16:44 ---
Unlike integer modes, middle-end only knows memory when moving with
subreg on vector mode.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-05 16:58 ---
Can we add direct support for moving with (subreg:DI (reg:TI)) and
(subreg:TI (reg:OI))?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
--- Comment #13 from rwild at gcc dot gnu dot org 2010-08-05 17:01 ---
config.log excerpt from zlib:
configure:7903: result: yes
configure:7936: checking whether the gcc -m64 linker (ld) supports shared
libraries
configure:9020: result: yes
configure:9265: checking dynamic linker chara
--- Comment #13 from mikael at gcc dot gnu dot org 2010-08-05 17:51 ---
*** Bug 45190 has been marked as a duplicate of this bug. ***
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mikael at gcc dot gnu dot org 2010-08-05 17:51 ---
I think it is the same as pr37829.
*** This bug has been marked as a duplicate of 37829 ***
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-08-05
17:55 ---
This bug doesn't occur with the actual committed version of the cleanups to
i386 prologue/epilogue generation (as opposed to the proposed patches). Let's
leave this open for now in case it reappears.
--
--- Comment #1 from rth at gcc dot gnu dot org 2010-08-05 17:59 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from rth at gcc dot gnu dot org 2010-08-05 18:01 ---
I've now reproduced this on a 64-bit host with -m32,
though still not on the 32-bit host.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from rth at gcc dot gnu dot org 2010-08-05 18:05 ---
Subject: Bug 45189
Author: rth
Date: Thu Aug 5 18:04:58 2010
New Revision: 162919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162919
Log:
PR target/45189
Fix unwind for i386 stack re-alignment.
Modified:
--- Comment #6 from rth at gcc dot gnu dot org 2010-08-05 18:13 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #57 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05
19:26 ---
Subject: Re: [4.6 regression] Revision 162270 failed
to bootstrap
On Thu, 05 Aug 2010, bernds at gcc dot gnu dot org wrote:
> If you could experiment with passing -fdbg-cnt=bug:N to the compiler,
--- Comment #66 from bernds at gcc dot gnu dot org 2010-08-05 19:56 ---
(In reply to comment #57)
> Failure occurs for N = 0. N = 1 compiles successfully. Attached files.
Argh. I seem to have swapped the logic of the dbg_cnt test. Still, this
result appears useful.
I think initial
When compiled with -O3 the following code ICEs on amd64-linux.
parameter(numlev=3,numoblev=1000)
integer i_otyp(numoblev,numlev), i_styp(numoblev,numlev)
logical l_numob(numoblev,numlev)
do ixe=1,numoblev
do iye=1,numlev
i_otyp(ixe,iye)=0
i_
--- Comment #67 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05
20:54 ---
Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap
> I think initial RTL generation is fine, so it looks like my change has exposed
> a latent bug. What seems to happen is that some pass b
The attached code leads to segfaults when compiled with gcc-4.5.0 or gcc-4.5.1.
gcc-4.4.1 accepts the code.
I have absolutely no idea what is actually causing the segfault, as the very
same instantiation does not segfault in another context.
--
Summary: ICE in template instantiation
--- Comment #1 from mr dot chr dot schmidt at online dot de 2010-08-05
21:02 ---
Created an attachment (id=21411)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21411&action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
--- Comment #2 from mr dot chr dot schmidt at online dot de 2010-08-05
21:04 ---
Created an attachment (id=21412)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21412&action=view)
g++ -v / g++ reverse.cpp output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
--- Comment #15 from mikael at gcc dot gnu dot org 2010-08-05 21:08 ---
Subject: Bug 44064
Author: mikael
Date: Thu Aug 5 21:08:36 2010
New Revision: 162921
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162921
Log:
2010-08-05 Mikael Morin
Janus Weil
P
--- Comment #16 from mikael at gcc dot gnu dot org 2010-08-05 21:08 ---
Subject: Bug 45151
Author: mikael
Date: Thu Aug 5 21:08:36 2010
New Revision: 162921
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162921
Log:
2010-08-05 Mikael Morin
Janus Weil
P
--- Comment #25 from mikael at gcc dot gnu dot org 2010-08-05 21:08 ---
Subject: Bug 42051
Author: mikael
Date: Thu Aug 5 21:08:36 2010
New Revision: 162921
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162921
Log:
2010-08-05 Mikael Morin
Janus Weil
P
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-05 21:08 ---
Trunk gives:
..\..\..\..\../boost/fusion/view/reverse_view/detail/end_impl.hpp:39:13:
internal compiler error: tree check: accessed elt 2 of tree_vec with 1 elts in
tsubst, at cp/pt.c:10167
Please submit a full bug r
--- Comment #26 from mikael at gcc dot gnu dot org 2010-08-05 21:11 ---
Done
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from dominiq at lps dot ens dot fr 2010-08-05 21:11 ---
Confirmed on x86_64-apple-darwin10 (for both -m32 and -m64) and the code
compiles with -O2 -ftree-vectorize. Revision 162490 is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45199
--- Comment #4 from mr dot chr dot schmidt at online dot de 2010-08-05
21:14 ---
A workaround is to wrap the faulting template instantiation in a thin wrapper:
typename detail::forward_as_lref<
Seq
, typename detail::remove_reference::type::seq_type
>::type
... does not work, wher
--- Comment #21 from mikael at gcc dot gnu dot org 2010-08-05 21:38 ---
Subject: Bug 44660
Author: mikael
Date: Thu Aug 5 21:38:36 2010
New Revision: 162922
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162922
Log:
2010-08-05 Mikael Morin
PR fortran/44660
*
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-05 21:40 ---
Backtrace
#0 find_uses_to_rename_use (bb=0x141f28138, use=0x141f13058, use_blocks=, need_phis=) at
../../work/gcc/tree-ssa-loop-manip.c:1242
#1 0x000100780838 in find_uses_to_rename_bb (bb=, use_blocks=0x14192
--- Comment #22 from mikael at gcc dot gnu dot org 2010-08-05 21:40 ---
Only 4.4 left.
Let's not weaken now.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
The attached code will lead to a stack overflow if compiled with -std=c++0x and
-g . The code compiles fine without -g. gcc-4.5.0 accepts the code just fine as
well, even when compiled with -g.
--
Summary: ICE: stack overflow during debug information generation
Product: gcc
--- Comment #1 from mr dot chr dot schmidt at online dot de 2010-08-05
21:53 ---
Created an attachment (id=21413)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21413&action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
--- Comment #2 from mr dot chr dot schmidt at online dot de 2010-08-05
21:54 ---
Created an attachment (id=21414)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21414&action=view)
g++ -v / g++ proto_fusion.cpp -std=c++0x -g output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
The following code (as small as I can get but I'm not sure its minimal)
#include
struct X{
unsigned a;
X(){}
bool operator<(const X& i)const { return a < i.a; }
};
struct R{
std::set getSet() const{
std::set result;
result.insert(X());
return result;
}
};
void bug(){
fo
--- Comment #1 from eric_moyer at yahoo dot com 2010-08-05 22:02 ---
Created an attachment (id=21415)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21415&action=view)
Test case: original source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45202
--- Comment #2 from eric_moyer at yahoo dot com 2010-08-05 22:03 ---
Created an attachment (id=21416)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21416&action=view)
Test case: preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45202
--- Comment #3 from eric_moyer at yahoo dot com 2010-08-05 22:04 ---
Created an attachment (id=21417)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21417&action=view)
Test case: output of g++ 4.4.1-ubutntu9 with -v switch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45202
--- Comment #4 from eric_moyer at yahoo dot com 2010-08-05 22:18 ---
This is not a duplicate of bug# 39390 because my copy of g++ compiles the test
case for that bug without complaint.
It may be related to 42032 since that does not compile correctly but (1) the
error messages are diff
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-05 22:42 ---
It is caused by revision 145440:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
I am requesting a pragma to suppress warnings that match a given regular
expression. (Really I'd be happy with any way to suppress arbitrary warnings
for small sections of code. This is just my proposal of a simple way to do
it.)
I propose adding two new pragmas:
#pragma start_no_warn_regex [re
--
eric_moyer at yahoo dot com changed:
What|Removed |Added
Severity|normal |enhancement
Summary|[Feature request] #pragma |[Feature req
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-05 23:17 ---
Starting with 4.5 you can disable a class of warnings in the source. This is
better than a regular expression as it is safe for internationalization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45203
--- Comment #11 from lacombar at gmail dot com 2010-08-05 23:29 ---
I encountered that issue with gcc 4.3.4 on the following target:
mips-unknown-linux-uclibc. I'm currently confirming with gcc 4.3.5. If it still
happen, would it be worth pulling to the 4.3 branch ?
--
http://gcc.gn
Apologies in advance for not being able to create a small code sample.
The code is in SourceForge GIT repository for treedb.
To build treedb you will need v3c - the GIT version.
First download v3c and "make prefix=[install-location] && [sudo] make install".
cd [treedb-dir]
"make debug check" works
--- Comment #12 from lacombar at gmail dot com 2010-08-06 00:01 ---
ok, 3.4.5, same target is bad too:
./mips-unknown-linux-uclibc/libstdc++-v3/config.log:
error while loading shared libraries:
/targets/mips-unknown-linux-uclibc/build/build-cc/./gcc/libgcc_s.so.1: ELF file
data encoding
The following code should print "18014398509481983.0" but it prints
"36028797018963967.0" instead .
long double a = 18014398509481984.0;
long double b = -1.0;
long double c = a + b;
printf("%.1Lf\n", c);
I used "gcc -v -save-temps -Wall main.c"
--
S
--- Comment #1 from kmmertes at gmail dot com 2010-08-06 00:41 ---
Created an attachment (id=21418)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21418&action=view)
short program that demonstrates the problem and possible cause
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45
--- Comment #2 from kmmertes at gmail dot com 2010-08-06 00:44 ---
Created an attachment (id=21419)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21419&action=view)
preprocessed file for main.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-06 01:13 ---
Can you provide the output of "gcc -v" ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from eric_moyer at yahoo dot com 2010-08-06 02:09 ---
If you are talking about "#pragma GCC diagnostic" that looks good. Turning off
error classes is sufficiently fine grained. However the pragma is only
guaranteed to work on a file-wide scope. The 4.5 manual says,
"A
--- Comment #4 from kmmertes at gmail dot com 2010-08-06 03:15 ---
Sorry I forgot to include output of gcc -v:
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-08-06 03:17 ---
You should report this to Apple and here. We don't support 4.0.x any more.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from kmmertes at gmail dot com 2010-08-06 04:17 ---
Can you compile and run the program on a PowerPC computer with a version of gcc
that you do support to see if the problem persists? Here is the output from my
system:
a -> 18014398509481984.0 : 43 50 00 00 00 0
--- Comment #7 from kmmertes at gmail dot com 2010-08-06 04:21 ---
Prettier version of output (I hope):
a -> 18014398509481984.0 : 43 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+b -> -1.0 : bf f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=c -> 36028797018963967.0 :
The error is:
/home/eric/gnat/gnat-head/native32/./gcc/xgcc
-B/home/eric/gnat/gnat-head/native32/./gcc/
-B/home/eric/install/gnat-head/i586-suse-linux/bin/
-B/home/eric/install/gnat-head/i586-suse-linux/lib/ -isystem
/home/eric/install/gnat-head/i586-suse-linux/include -isystem
/home/eric/install/
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-08-06 06:21
---
Created an attachment (id=21420)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21420&action=view)
Preprocessed file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
--- Comment #5 from paolo dot carlini at oracle dot com 2010-08-06 06:53
---
*** This bug has been marked as a duplicate of 42032 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #9 from paolo dot carlini at oracle dot com 2010-08-06 06:53
---
*** Bug 45202 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
99 matches
Mail list logo
