--- Comment #7 from prafullat at kpitcummins dot com 2010-01-22 07:47
---
We have now posted the updated patch here,
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01141.html
It seems this patch fixes 272 regressions on the H8SX target and overall it
fixes 525 regressions.
--
http:/
--- Comment #1 from iwamatsu at nigauri dot org 2010-01-22 07:12 ---
Created an attachment (id=19687)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19687&action=view)
The source code that can reproduce a problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
--- Comment #4 from mjtruog at fastmail dot ca 2010-01-22 07:10 ---
I can help try to determine the problem if you want since it seems everyone is
either busy, doesn't necessarily care right now, or both. However, if someone
could provide any hints as to what RTLD_DEEPBIND might be doin
I found a bug of pcrel too far in gcc-4.4.3 and gcc-4.3.4 on sh-elf.
Sorry. There is the code to reappear, but cannot lower it.
$ gcc -O2 -fPIC -DPIC -c gong_1424_debug_1.c
/tmp/ccjdeDlE.s: Assembler messages:
/tmp/ccjdeDlE.s:714: Error: pcrel too far
When I don't optimize it, it doesn't become
--- Comment #4 from rmansfield at qnx dot com 2010-01-22 05:37 ---
Rev 156156 breaks the build for targets that do not explicitly define
MOVE_RATIO in their backend (e.g. rs6000).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
--- Comment #4 from hp at gcc dot gnu dot org 2010-01-22 04:53 ---
(In reply to comment #2)
> I was advised to upgrade g77. I did so, to 4.3, and it did not fix my problem.
Forgive me for pointing out the obvious, but are you using the obsolete g77
instead of gfortran, perhaps? (Differ
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2010-01-22 04:30
---
Un-assigning. My approach to resolve this by avoiding the error message based
on the vaiable name did not work. I also am getting short on time again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2010-01-22 04:26
---
Fixed for now, changing summary to reflect the current situation. I want to
leave open until I have time to investigate further.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from navin dot kumar at gmail dot com 2010-01-22 03:39
---
Ignore. Close bug.
Found the issue here:
http://hellewell.homeip.net/phillip/blogs/index.php?entry=entry060314-00
--
navin dot kumar at gmail dot com changed:
What|Removed
--- Comment #1 from navin dot kumar at gmail dot com 2010-01-22 03:32
---
Created an attachment (id=19686)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19686&action=view)
example of code that generates linker error
compiled with ver 4.3.4 g++ and args -std=c++0x
--
http://g
When a static-const primitive is passed as a const-ref argument to function
with a variadic template arglist, GCC generates code that references the
static-const primitive, and optimizes away the static-const primitive,
resulting in a "undefined reference" linker error.
/* Start of Example */
clas
--- Comment #21 from paolo dot carlini at oracle dot com 2010-01-22 02:07
---
Created an attachment (id=19685)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19685&action=view)
Draft patch
Jon, this version regtests fine, it's the simplest solution I have been able to
figure out s
--- Comment #12 from d dot g dot gorbachev at gmail dot com 2010-01-22
01:17 ---
The patch works for mingw. So you can enable lto for it, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
--- Comment #2 from 3dw4rd at verizon dot net 2010-01-22 00:02 ---
The link hack worked.
This isn't really a fix but maybe it isn't a big deal.
Ed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42825
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-01-22 00:01 ---
I can't do any--enable-build-with-cxx bootstraps / test without this patch.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #19 from amylaar at gcc dot gnu dot org 2010-01-21 23:38
---
(In reply to comment #18)
> Yes, marking libgomp as bootstrappable should make a difference. I
> suggest looking at Makefile.in differences from my patches (in the
> dependencies section).
The libgomp bootstrap
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.4.3
trunk revision 155625
$ ../trunk/configure --target=mips64-linux
--with-sysroot=/home/daney/mips64-linux --prefix=/home/daney/mips64-linux
--with-arch=mips64r2 --enable-languages=c,c++ --disable-libmudflap
make check-gcc RUNTESTFLAGS='--target_board=unix/\{,-mabi=64\}
mips.exp=octeon*'
Results i
On Linux/ia64, revision 156103 gave:
FAIL: g++.dg/abi/packed1.C execution test
Revision 156082 is OK.
--
Summary: [4.5 Regression] FAIL: g++.dg/abi/packed1.C execution
test
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
On Linux/ia64, revision 156103 gave:
FAIL: g++.dg/abi/packed1.C execution test
Revision 156082 is OK.
--
Summary: [4.5 Regression] FAIL: g++.dg/abi/packed1.C execution
test
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
On Linux/ia64, revision 156158:
/libdecnumber/libdecnumber.a-lmpc -lmpfr -lgmp -rdynamic -ldl -lz -lelf
libbackend.a(tree-sra.o): In function `analyze_all_variable_accesses':
/export/gnu/import/svn/gcc-test/bld/gcc/../../src-trunk/gcc/tree-sra.c:2034:
undefined reference to `MOVE_RATIO'
colle
--- Comment #4 from jos dot de_laender at telenet dot be 2010-01-21 22:14
---
Your call.
I *don't* think it's fine.
Even if there *is* TLS, it can fail due to the -O2 optimizing.
(it doesn't detect the referring via &).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42829
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||16996
nThis||
St
--- Comment #6 from gary at intrepid dot com 2010-01-21 21:33 ---
(In reply to comment #5)
> >Just to be clear, what aspect of the test case is undefined?
>
> The access of the integer variable via an union. That is the whole point of
> strict aliasing :).
I thought that might be what
--- Comment #4 from anlauf at gmx dot de 2010-01-21 21:11 ---
Created an attachment (id=19684)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19684&action=view)
Slightly improved version of the previous patch
I have improved the patch so that now the following
assignments do not th
--- Comment #2 from simon at pushface dot org 2010-01-21 21:06 ---
Correct results obtained with
COLLECT_GCC=/opt/gcc-4.5.0-x86_64/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.0-x86_64/libexec/gcc/x86_64-apple-darwin10.2.0/4.5.0/lto-wrapper
Target: x86_64-apple-darwin10.2.0
Configured with:
Compile the following code with options -march=armv7-a -mthumb -Os
int foo(int *p, int i )
{
return( (i < 0 && *p == 1)
|| (i > 0 && *p == 2) );
}
Gcc generates:
foo:
cmp r1, #0
bge .L2
ldr r0, [r0, #0]
cmp r0, #1
ite n
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-01-21 20:56 ---
>Just to be clear, what aspect of the test case is undefined?
The access of the integer variable via an union. That is the whole point of
strict aliasing :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4283
--- Comment #4 from gary at intrepid dot com 2010-01-21 20:54 ---
(In reply to comment #3)
> This is by design since the code is undefined.
Just to be clear, what aspect of the test case is undefined?
In any event, my suggestion is only that the warning be enabled in the case
that inli
--- Comment #13 from pault at gcc dot gnu dot org 2010-01-21 20:45 ---
Fixed on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Known to fa
--- Comment #12 from pault at gcc dot gnu dot org 2010-01-21 20:39 ---
Subject: Bug 42736
Author: pault
Date: Thu Jan 21 20:38:51 2010
New Revision: 156161
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156161
Log:
2010-01-21 Paul Thomas
PR fortran/42736
* tr
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-21 20:37 ---
Yeah, the test is certainly fine, if it sporadically fails, there are issues
with the mingw TLS or thread implementation (or both).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42829
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42786
--- Comment #7 from ubizjak at gmail dot com 2010-01-21 20:30 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42833
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #32 from ubizjak at gmail dot com 2010-01-21 20:25 ---
I would like RMs to reconsider the priority of this bug, since it shows
weakness in the generic part of the compiler. Please see comments #20, #25 (and
#26) for the analysis.
--
ubizjak at gmail dot com changed:
--- Comment #11 from paul dot richard dot thomas at gmail dot com
2010-01-21 20:25 ---
Subject: Re: [4.3/4.4/4.5 Regression] Wrong-code with
allocatable or pointer components in elemental functions
Thanks, Tobias.
I am not sure that it is unnecessary - for that reason, I am
--- Comment #6 from uros at gcc dot gnu dot org 2010-01-21 20:10 ---
Subject: Bug 42786
Author: uros
Date: Thu Jan 21 20:10:04 2010
New Revision: 156160
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156160
Log:
PR bootstrap/42786
* config.gcc (i[34567]86-*-*): F
--- Comment #4 from zlogic at gmail dot com 2010-01-21 20:06 ---
This bug is also present in the latest TDM (http://www.tdragon.net/recentgcc/)
builds.
Using OpenMP fails when called from pthreads and Windows native threads.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
--- Comment #5 from uros at gcc dot gnu dot org 2010-01-21 20:04 ---
Subject: Bug 42786
Author: uros
Date: Thu Jan 21 20:03:55 2010
New Revision: 156159
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156159
Log:
PR bootstrap/42786
* config.gcc (i[34567]86-*-*): F
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-01-21 19:48 ---
Oh this test should pass no matter what really as TLS is emulated on mingw via
functions which call pthreads.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42829
--- Comment #11 from davek at gcc dot gnu dot org 2010-01-21 19:46 ---
Today's take 2 produces a ton of decompression stream errors. It turns out(*)
that the original approach probably is the correct one after all, and that
p2align will probably not do what we need here, so I've reinsta
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-21 19:41 ---
This is by designed since the code is undefined.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from jason at gcc dot gnu dot org 2010-01-21 19:09 ---
We describe a template as overloading itself since it represents any number of
actual functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
--- Comment #16 from jwakely dot gcc at gmail dot com 2010-01-21 19:00
---
Shouldn't it get the same error as for this case?
template
T foo() { return T(); }
int main()
{
&foo;
}
That example can be made valid like so:
int (*pf)() = &foo;
Which demonstrates that the
--- Comment #15 from joseph dot h dot garvin at gmail dot com 2010-01-21
18:38 ---
I'm not sure what the standard says, but conceptually, if you only provide a
template generic template foo, with no non-templated foo defined, then
instantiations of foo are *never* 'overloaded.' If I hav
--- Comment #20 from jwakely dot gcc at gmail dot com 2010-01-21 18:20
---
Eurgh - yes, we should disable one overload. I'm getting less and less happy
about overloaded variadics.
I'll look into it later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
--- Comment #19 from paolo dot carlini at oracle dot com 2010-01-21 18:12
---
... or via the usual trick of the defaulted template parameter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
--- Comment #18 from paolo dot carlini at oracle dot com 2010-01-21 18:10
---
Jon, I have to go now, I was testing the obvious patch but apparently we have
more of the same issue with std::bind, besides that in async(_Fn&&,
_Args&&...): the existing 30_threads/async tests are failing at
--
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 #32 from rupp at gnat dot com 2010-01-21 17:36 ---
I'm not sure what Jan is asking for exactly, but in an attempt to be helpful
here is a traceback using the 20091124 sources for the reduced testcase on
alpha-openvms. The debugging info is messed up for me too, but its just t
--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-21
17:11 ---
Subject: Re: [4.5 regression] ICE in function_and_variable_visibility with
static common vars.
> --- Comment #30 from hubicka at ucw dot cz 2010-01-21 16:57 ---
> Subject: Re: [4.5 regression] I
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-21 17:09 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
We fold memcpy to direct assignments based on types of the pointed-to types
of its arguments. This is completely wrong for C++ and wrong for C if
neither source nor destination has a declared type. memcpy transfers the
dynamic type of objects.
int main()
{
int i = 0;
float f = 1.0;
int *p
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-21 16:58
---
Let's add Richard too.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #30 from hubicka at ucw dot cz 2010-01-21 16:57 ---
Subject: Re: [4.5 regression] ICE in function_and_variable_visibility with
static common vars.
>
> Indeed it does: with that chance, a full bootstrap on alpha-dec-osf4.0f
> and alpha-dec-osf5.1b succeeded.
Thanks for con
--- Comment #17 from paolo dot carlini at oracle dot com 2010-01-21 16:57
---
Given our current understanding of the issue, suspended status seems too much:
we can deal with it, reasonably soon, hopefully after Lawrence Crowl feedback.
--
paolo dot carlini at oracle dot com changed:
--- Comment #1 from rth at gcc dot gnu dot org 2010-01-21 16:56 ---
Created an attachment (id=19683)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19683&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42833
The reduced test case compiles down to
xor %eax,%eax
ret
which comes from an invalid transformation in .030t.esra
conv_u.v = vdest;
res_115 = conv_u.i;
->
D.2888_153 = VIEW_CONVERT_EXPR(vdest);
vdest.v1 = vdest$v1_154;
vdest.v2 = vdest$v2_152;
vdest.v3 = vdest$v3_1
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
This is to keep track of this exchange with Richard:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01154.html
--
Summary: Revisit std::function for aliasing issues
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
--- Comment #16 from paolo dot carlini at oracle dot com 2010-01-21 16:35
---
I forgot the one at line 561, that explains it. Fine ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
--- Comment #2 from gary at intrepid dot com 2010-01-21 16:30 ---
(In reply to comment #1)
> Created an attachment (id=19682)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19682&action=view) [edit]
> Test case to demonstate interaction between inlining and strict-aliasing
> optimiz
--- Comment #1 from 3dw4rd at verizon dot net 2010-01-21 16:29 ---
I had to run to work before I could make sure but I think the
ln -s /usr/lib/libgcc_s.1.0.dylib /usr/lib/libgcc_s.10.4.dylib
trick may have "worked".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42825
--- Comment #15 from jwakely dot gcc at gmail dot com 2010-01-21 16:28
---
(In reply to comment #14)
> Anyway, we also have the residual nit that I had to change to public the
> explicit constructor future(const __state_type&). I suppose isn't a big
> issue...
Did you change _Fn::resul
--- Comment #2 from jason at gcc dot gnu dot org 2010-01-21 16:27 ---
I think this is a duplicate of bug 42713.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from jason at gcc dot gnu dot org 2010-01-21 16:25 ---
I have a fix for this that has been waiting for feedback from the ABI
committee. I'll check it in soon if I don't get any.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
--- Comment #14 from paolo dot carlini at oracle dot com 2010-01-21 16:21
---
Great. Indeed, that way works. Actually, I was surprised to see result_of used
with launch named in the template argument?!?
Anyway, we also have the residual nit that I had to change to public the
explicit c
--- Comment #10 from burnus at gcc dot gnu dot org 2010-01-21 16:20 ---
(In reply to comment #9)
> Have posted a fix on the list today.
Latest patch by Paul (which has been approved):
http://gcc.gnu.org/ml/fortran/2010-01/msg00134.html
I have filled PR 42831 regarding the missed optim
--- Comment #13 from jwakely dot gcc at gmail dot com 2010-01-21 16:19
---
(In reply to comment #12)
> Paolo, this is the problem I had with std::bind, I think there might be a
> larger problem with overloaded variadic template functions ... I'll think
> about
> it further.
To be clea
Topic arose during analyzing/fixing PR 42736. For the
Table%RealData(:,1) = Table%RealData(:,1) * CENTIMETER
user-defined operation(*)/assignment an unnecessary temporary is produced. (The
"atmp" in the dump is not needed.)
An initial patch can be found at
http://gcc.gnu.org/ml/fortran/2010-
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-01-21 16:18 ---
Subject: Bug 42585
Author: jamborm
Date: Thu Jan 21 16:18:06 2010
New Revision: 156156
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156156
Log:
2010-01-21 Martin Jambor
PR tree-optimization/425
--- Comment #12 from jwakely dot gcc at gmail dot com 2010-01-21 16:14
---
Aha - I see what's happening.
As well as changing _Fn:result_type everywhere please change line 1327 in
to this:
return async<_Fn, _Args...>(launch::any, std::forward<_Fn>(__fn),
The problem is the wrong
--- Comment #11 from paolo dot carlini at oracle dot com 2010-01-21 16:13
---
No Jonathan, doesn't: that strange error happens (after having made public
explicit future(const __state_type&)).
I'd like only to understand if we have to ask Jason's halp again, or not...
--
http://gcc
--- Comment #10 from jwakely dot gcc at gmail dot com 2010-01-21 16:08
---
(In reply to comment #8)
>
> Is there an easy workaround I can apply locally for this? I tried replacing
> all
> instances of `typename _Fn::result_type` with `typename
> result_of<_Fn(_Args...)>::type` in futu
--- Comment #1 from gary at intrepid dot com 2010-01-21 16:02 ---
Created an attachment (id=19682)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19682&action=view)
Test case to demonstate interaction between inlining and strict-aliasing
optimization
--
http://gcc.gnu.org/bugzi
The attached code demonstrates a test program that will fail when optimized at
-O2 and higher for GCC versions 4.4.1 and later, but only when a particular
procedure is inlined (either explicitly at the request of the user, or
implicitly due to auto-inlining).
% gcc --version | head -1
gcc (GCC) 4.
--- Comment #2 from marekarturpenther at gmail dot com 2010-01-21 15:57
---
Subject: Re: error in building libgcc; error: 'BITS_PER_UNIT' undeclared
No, I building completely outside of source tree:
/home/data/gcc/source/gcc-4.3.4 - that is source
/home/data/gcc/build/gcc-4.3.4 - that
--- Comment #9 from paolo dot carlini at oracle dot com 2010-01-21 15:48
---
Jack, I would ask you to have a bit of patience, because this code is in flux.
Just a few days. In the meantime, if you want to experiment, I would suggest
two things: 1- Always use up to date sources, r156097
--- Comment #1 from jos dot de_laender at telenet dot be 2010-01-21 15:42
---
Created an attachment (id=19681)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19681&action=view)
The test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42829
In attachment, you find the code that is used inside the configure m4 macro for
detecting the presence of TLS.
This check is unreliable.
When compiled with -O2 (as done in configure) the result might be that the
compiler reports same adress due to optimization and decides there is no TLS.
When c
--- Comment #18 from bonzini at gnu dot org 2010-01-21 15:40 ---
Subject: Re: deps on other host libraries incorrect
On 01/21/2010 04:29 PM, amylaar at gcc dot gnu dot org wrote:
> dependencies = { module=all-target-libstdc++-v3;
> on=configure-target-libgomp; };
>
> In fact, I tried
--- Comment #8 from lloyd at randombit dot net 2010-01-21 15:38 ---
Jon (and Paolo) - thanks for doing the work!
Is there an easy workaround I can apply locally for this? I tried replacing all
instances of `typename _Fn::result_type` with `typename
result_of<_Fn(_Args...)>::type` in fut
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42828
--- Comment #1 from jos dot de_laender at telenet dot be 2010-01-21 15:35
---
Created an attachment (id=19680)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19680&action=view)
The test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42828
Background :
-OpenMP started from a pthread doesn't work for regular mingw. This has been
reported in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 and is confirmed.
For that reason I switched to http://sourceforge.net/projects/mingw-w64/ which
has the advantage of working TLS.
My test case
--- Comment #17 from amylaar at gcc dot gnu dot org 2010-01-21 15:29
---
(In reply to comment #16)
> > Wrong submitter's proposal, you mean.
>
> Yes. What I don't understand is, why is anything else than this needed:
>
> -target_modules = { module= libgomp; lib_path=.libs; };
> +targ
--- Comment #16 from bonzini at gnu dot org 2010-01-21 14:45 ---
> Wrong submitter's proposal, you mean.
Yes. What I don't understand is, why is anything else than this needed:
-target_modules = { module= libgomp; lib_path=.libs; };
+target_modules = { module= libgomp;
+
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-21 14:42 ---
works for me. Are you building inside the source tree?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from doko at ubuntu dot com 2010-01-21 14:30 ---
std::basic_ios.3, std::basic_ofstream.3, std::basic_ostream.3,
std::basic_ostringstream.3, std::ios_base.3:
.PP
Definition at line 657 of file ios_base.h.
.SS "\fBstreamsize\fP std::ios_base::width () const\fC [inline, inh
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-21 14:19 ---
The process is to indeed do that, but you can reduce to less files by (assuming
it ICEs during link stage) linking with -r and omit as many object files as
possible. Only preprocessed source for the remaining files
make[4]: Opuszczenie katalogu
`/home/data/gcc/build/gcc-4.3.4/i686-linux-gnu/libgcc'
/home/data/gcc/build/gcc-4.3.4/./gcc/xgcc
-B/home/data/gcc/build/gcc-4.3.4/./gcc/ -B/usr/i686-linux-gnu/bin/
-B/usr/i686-linux-gnu/lib/ -isystem /usr/i686-linux-gnu/include -isystem
/usr/i686-linux-gnu/sys-include
Trying to build MySQL 5.5.1-m2 with gcc 4.5.0 svn 156081 and lto enabled
results in:
x86_64-unknown-linux-gnu-g++ -m64 -O1 -fomit-frame-pointer -fweb
-frename-registers -Wl,-O1 -Wl,-z -Wl,combreloc -Wl,-z -Wl,relro
-Wl,--enable-new-dtags -Wl,--hash-style=gnu -g -flto -felide-constructors
-fno-exc
While bootstrapping on MacOSX 10.3 a link error is found in stage3 while
building libstdc++
The library in question is libgcc_s.10.4.
I've had a look at gcc/config/ and it seems this is supposed to be a
There are several of these in
If a system library is required then we have these:
MacOSX:~/g
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.3 |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42168
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.3 |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41204
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.3 |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38059
1 - 100 of 203 matches
Mail list logo
