--- Comment #5 from steven at gcc dot gnu dot org 2010-01-22 08:07 ---
Problem here, is that the default MOVE_RATIO is in expr.h. It is really a
default definition of a target macro so it should be defined in defaults.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-01-22 08:11 ---
I've confirmed that the test case also fails on 4.5.0 and doesn't on 4.2.4.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from burnus at gcc dot gnu dot org 2010-01-22 08:19 ---
(In reply to comment #14)
Fixed for now, changing summary to reflect the current situation. I want to
leave open until I have time to investigate further.
? The PR is now closed (as you wrote in the first
--- Comment #12 from chris at bubblescope dot net 2010-01-22 09:11 ---
Just for anyone who comes to this bug, it can be worked around by doing
something like:
templatetemplate typename... T, typename... Args
struct Join
{ typedef TArgs... type; }
Although of course that isn't a fix
--- Comment #5 from mario-baumann at web dot de 2010-01-22 09:24 ---
Hi Paolo, thanks for the hint about the delta tool. I attached the file as
foo.delta.ii
g++ -c foo.delta.ii
foo.delta.ii: In member function 'void EvalT::eval(mpl_::int_0) [with int V
= 0, T = Mtrl]':
--- Comment #6 from mario-baumann at web dot de 2010-01-22 09:25 ---
Created an attachment (id=19688)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19688action=view)
preprocessed cpp file of foo.cpp mangled by delta
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
ranlib: file: libbackend.a(graphite-scop-detection.o) has no symbols
ranlib: file: libbackend.a(graphite-sese-to-poly.o) has no symbols
ranlib: file: libbackend.a(vmsdbgout.o) has no symbols
ranlib: file: libbackend.a(xcoffout.o) has no symbols
Undefined symbols:
_MOVE_RATIO, referenced from:
--- Comment #15 from developer at sandoe-acoustics dot co dot uk
2010-01-22 09:38 ---
successful tests on darwin8/darwin9 and no further reported issues.
--
developer at sandoe-acoustics dot co dot uk changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-22 09:39 ---
*** This bug has been marked as a duplicate of 42585 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-22 09:39 ---
*** Bug 42842 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2010-01-22
09:42 ---
this has been resolved without any specific action - presumably as a byproduct
of fixing other issues.
--
developer at sandoe-acoustics dot co dot uk changed:
What|Removed
--- Comment #63 from developer at sandoe-acoustics dot co dot uk
2010-01-22 09:59 ---
this is fixed AFAIK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #13 from davek at gcc dot gnu dot org 2010-01-22 10:46 ---
(In reply to comment #12)
The patch works for mingw. So you can enable lto for it, too.
Thanks for that, I'll update the patch in the next day or three to include
MinGW. (I'll also clean it up a bit and add more
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-01-22 10:48 ---
A patch is here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01168.html
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from amylaar at gcc dot gnu dot org 2010-01-22 10:55
---
(In reply to comment #19)
I have a patch to hack the dependency of libstdc++-v3 on libgomp into
configure.ac .
I have posted this patch together with the other Makefile* / configure*
patches for PR
When configuring with --enable-build-with-cxx, most of the exported symbols
in cc1 / cc1plus etc end up with the c++ mangled name.
As the testsuite still compiles plugins with gcc to link against these
compiler binaries, the dso load fails with unresolved symbols:
[amyl...@laria bld-gcc-cxx19]$
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42837
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-22 11:20 ---
*** This bug has been marked as a duplicate of 42837 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-22 11:20 ---
*** Bug 42838 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42837
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-22 11:21 ---
Reopen
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-22 11:21 ---
*** Bug 42842 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-22 11:21 ---
To mark as dup of PR42836 instead.
*** This bug has been marked as a duplicate of 42836 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-22 11:23 ---
Probably a missed cross-jumping opportunity
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #33 from rguenth at gcc dot gnu dot org 2010-01-22 11:25
---
Well, w/o a way to reproduce the problem (read: execute code) I think you
have to do a better job analyzing the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
I believe the following c++ code is incorrect:
struct A
{
A(){}
};
struct B : public A
{
};
int main()
{
const B b;
return 0;
}
It fails with Comeau with the following error:
ComeauTest.c, line 13: error: const variable b requires an initializer --
class
B has no explicitly
There should be a fancy way to copy/swap raw data with a known alignment.
See PR42832 where one has to resort to memcpy and a temporary object
for {str,tr1}::functional::swap
--
Summary: Want __gnu_cxx::uninitialized_aligned_{copy,swap}
Product: gcc
Version:
--- Comment #2 from mathieu dot malaterre at gmail dot com 2010-01-22
11:43 ---
Any update ?
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40816
--- Comment #3 from christian dot bruel at st dot com 2010-01-22 11:47
---
Hello,
I had a similar problem a while ago, but was never able to reproduce on trunk.
I was a phasing problem between branch_shortening from sh_reorg and the
delayed branch scheduler, that would change the
--- Comment #7 from jwakely dot gcc at gmail dot com 2010-01-22 11:50
---
Is Boost.MPL needed? I haven't tried, but it looks like you could remove mpl
entirely as it isn't directly involved where the error occurs. That would make
the testcase MUCH smaller
--
--- Comment #1 from redi at gcc dot gnu dot org 2010-01-22 11:57 ---
Confirmed, not a regression.
[dcl.init]/9:
If no initializer is specified for an object, and the object is of (possibly
cv-qualified) non-POD class type (or array thereof), the object shall be
default-initialized; if
--- Comment #3 from jwakely dot gcc at gmail dot com 2010-01-22 12:00
---
N.B. duplicate of Bug 14404
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42840
--- Comment #4 from christian dot bruel at st dot com 2010-01-22 12:06
---
Created an attachment (id=19689)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19689action=view)
Conservative fix.
Conservatively increase length of undelayed conditional branches to prevent a
problem with
--- Comment #2 from redi at gcc dot gnu dot org 2010-01-22 12:27 ---
N.B. the wording has moved in C++0x but the requirement is similar:
6 ... If a program calls for the default initialization of an object of a
const-qualified type T, T shall be a class type with a user-provided
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-22 12:29 ---
/* With memcpy, it is possible to bypass aliasing rules, so without
this check i.e. execute/20060930-2.c would be misoptimized,
because it use conflicting alias set to hold
--- Comment #34 from ubizjak at gmail dot com 2010-01-22 12:33 ---
(In reply to comment #33)
Well, w/o a way to reproduce the problem (read: execute code) I think you
have to do a better job analyzing the problem.
This is:
FAIL: gcc.c-torture/execute/stdarg-1.c execution, -O3
--- Comment #5 from kkojima at gcc dot gnu dot org 2010-01-22 12:33 ---
(In reply to comment #4)
Conservatively increase length of undelayed conditional branches to prevent a
problem with the ds scheduler inserting an instruction in the slot.
Looks fine. A very minor nit, JUMP_P and
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-22 12:36 ---
Another possible way is to have a block-copy operation in gimple that
would do the copy with alias-set zero and avoids the address-taking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42834
--- Comment #6 from christian dot bruel at st dot com 2010-01-22 12:58
---
(In reply to comment #5)
(In reply to comment #4)
Conservatively increase length of undelayed conditional branches to prevent
a
problem with the ds scheduler inserting an instruction in the slot.
--- Comment #16 from sfilippone at uniroma2 dot it 2010-01-22 13:20 ---
I have found a compiled version of the library dating back to Nov. 10, one of
the modules has this header:
GFORTRAN module version '3' created from psb_base_mod.f90 on Tue Nov 10
13:02:06 2009
--- Comment #7 from kkojima at gcc dot gnu dot org 2010-01-22 13:21 ---
(In reply to comment #6)
Anyway, OK for trunk ? (just need to fix the date in the ChangeLog).
regtesting
done.
OK. And the patch is pre-approved for branches too after one week or so.
BTW, I mean JUMP_P(x)
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-01-22 13:35 ---
Subject: Bug 42813
Author: amylaar
Date: Fri Jan 22 13:35:38 2010
New Revision: 156172
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156172
Log:
PR libstdc++/36101, PR libstdc++/42813
[toplevel]:
--- Comment #21 from amylaar at gcc dot gnu dot org 2010-01-22 13:35
---
Subject: Bug 36101
Author: amylaar
Date: Fri Jan 22 13:35:38 2010
New Revision: 156172
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156172
Log:
PR libstdc++/36101, PR libstdc++/42813
[toplevel]:
--- Comment #8 from christian dot bruel at st dot com 2010-01-22 13:49
---
Created an attachment (id=19690)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19690action=view)
and cleanup with JUMP_TABLE_DATA_P
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
--- Comment #9 from christian dot bruel at st dot com 2010-01-22 13:51
---
(In reply to comment #7)
(In reply to comment #6)
Anyway, OK for trunk ? (just need to fix the date in the ChangeLog).
regtesting
done.
OK. And the patch is pre-approved for branches too after one
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-22 14:06 ---
Created an attachment (id=19691)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19691action=view)
patch #0
Fix INDIRECT_REFs.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-22 14:07 ---
Created an attachment (id=19692)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19692action=view)
patch #1
Don't throw away points-to information needlessly.
Remaining: expand TARGET_MEM_REFs in a more
--- Comment #35 from rguenth at gcc dot gnu dot org 2010-01-22 14:17
---
(In reply to comment #34)
(In reply to comment #33)
Well, w/o a way to reproduce the problem (read: execute code) I think you
have to do a better job analyzing the problem.
This is:
FAIL:
--- Comment #10 from kkojima at gcc dot gnu dot org 2010-01-22 14:28
---
(In reply to comment #9)
So I took the opportunity to cleanup every other
occurrences of the same idioms in the file. OK ?
OK. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
--- Comment #33 from hubicka at ucw dot cz 2010-01-22 14:52 ---
Subject: Re: [4.5 regression] ICE in
function_and_variable_visibility with static common vars.
I'm not sure what Jan is asking for exactly, but in an attempt to be helpful
here is a traceback using the 20091124
GCC sometimes loses alignment information.
If we declare an aligned pointer type:
// These two lines work (together)
typedef real aligned_real __attribute__((aligned(16)));
typedef const aligned_real* SSE_PTR;
Then gcc generates aligned access here:
// This function uses ALIGNED accesses
real
--- Comment #1 from bredelin at ucla dot edu 2010-01-22 15:14 ---
Created an attachment (id=19693)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19693action=view)
Several simple examples for alignment in vectorization.
The notes in the file about which functions contain aligned
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-22 15:21 ---
Created an attachment (id=19694)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19694action=view)
patch #2
Fix for expanding TARGET_MEM_REFs.
The patch series is queued for early GCC 4.6 because of its
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-22 15:24 ---
With these patches I get for
void foo(int * __restrict__ a, int * __restrict__ b, int * __restrict__ c,
int N)
{
int i;
for (i = 0; i N; ++i)
a[i] = b[i] + c[i];
}
and -O2 -funroll-all-loops all
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-22 15:56 ---
Related to PR 25811.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-22 15:56 ---
And PR 29043.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
configuring libstdc++ fails:
error: No support for this host/target combination
This is a regression at least against gcc-4.4.
I'm not really sure, but I think sometime last year this even worked for
gcc-4.5.0.
Rainer
--
Summary: [4.5 Regression] failure while configuring libstdc++
--- Comment #1 from rainer at emrich-ebersheim dot de 2010-01-22 16:18
---
Created an attachment (id=19695)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19695action=view)
libstdc++ config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42847
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-22 16:30 ---
Yep. I always fail to see why the vectorizer doesn't use the alignment
information present in from data-ref analysis:
t.i:9: note: === vect_analyze_data_refs ===
Creating dr for *D.2752_12
...
(res = {p_4, +,
Compiling a file with -c option (no exec)with gfortran lets the compiler output
an internal error message.
The file:
! Demoprogramm:
! Aufrufen einer C-Routine von Fortran aus
! Die C-Routine wird innerhalb eines Modules deklariert
module cproc
interface ! definierte Schnittstelle
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-22 17:02 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-22 17:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #36 from ubizjak at gmail dot com 2010-01-22 17:26 ---
(In reply to comment #35)
That doesn't make me have an alpha machine or a proper reduced testcase.
Note that it now only fails at -O3.
Please paste a reduced testcase that still fails and track down what
is the
--- Comment #1 from burnus at gcc dot gnu dot org 2010-01-22 17:44 ---
Thanks for the bug report. However, I think this a duplicate of PR 40195 which
was fixed 2009-05-22.
Thus, the solution is to use any GCC 4.4.x or 4.5.x newer than 22 May 2009 such
as 4.4.1, 4.4.2, or 4.4.3 - or a
--- Comment #5 from jos dot de_laender at telenet dot be 2010-01-22 18:24
---
I drafted a potential patch one can find at
http://jdlraw.sourceforge.net/GompPatch.shtml
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-22 18:51
---
I'm adding in CC some cygwin experts, hopefully they will be able to help
you...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from rth at gcc dot gnu dot org 2010-01-22 18:52 ---
Subject: Bug 42833
Author: rth
Date: Fri Jan 22 18:52:01 2010
New Revision: 156176
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156176
Log:
PR tree-opt/42833
* tree-sra.c (sra_modify_assign):
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-22 18:54
---
Confirmed. My plan wrt PR42832 would be first using both in std and tr1 memcpy,
as a minimal safe goal for 4.5.0. We may even try to implement this, for use in
std, in time for 4.5.0, but seems unlikely at
I'm trying a bootstrap build of 4.4.3 on a i686-Slackware-12.2 box. I
successfully built on a similar box. I'm using default CFLAGS and configure
with:
--host=i686-pc-linux-gnu --prefix=/usr --with-gnu-as --enable-shared
--with-gnu-ld --enable-threads=posix
--- Comment #22 from paolo dot carlini at oracle dot com 2010-01-22 19:00
---
I see that the patch is in. Excellent. I understand the other PR is completely
fixed by now, thus I would suggest closing it as fixed. I would also suggest
writing a oouple of sentences in the audit trail
--- Comment #37 from jakub at gcc dot gnu dot org 2010-01-22 19:05 ---
Well, as alpha is the only affected platform, it is a target problem.
The thing is, alpha unfortunately doesn't define va_list the same as x86_64 or
s390 or rs6000 - a single member array of structs. So, in a
--- Comment #23 from amylaar at gcc dot gnu dot org 2010-01-22 19:09
---
(In reply to comment #22)
I see that the patch is in. Excellent. I understand the other PR is completely
fixed by now, thus I would suggest closing it as fixed.
No, it isn't. In fact, --enable-build-with-cxx
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-01-22 19:09 ---
Note that testcase mises static in front of one/two. This is something I
plan to implement for next release. Last release has some preparation work for
it, but at the moment we don't really build may edges nor
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-01-22 19:11 ---
really an enhancement rather than bug.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from paolo dot carlini at oracle dot com 2010-01-22 19:16
---
So I misinterpreted your ChangeLog, the adjective partial is referred to both
;)
Still, some sort of summary together with the partial commit could be useful.
--
--- Comment #25 from amylaar at gcc dot gnu dot org 2010-01-22 19:17
---
Created an attachment (id=19696)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19696action=view)
patch to make --enable-build-with-cxx bootstrap work
I am currently using this patch in addition to the patch
--- Comment #38 from jakub at gcc dot gnu dot org 2010-01-22 19:17 ---
In 4.4 the apY = apX; assignment isn't optimized out, because the code after it
reads from the apY's fields (apY is the struct from the inline, apX in the
caller). But in 4.5 FRE replaces them by whatever is written
--- Comment #26 from amylaar at gcc dot gnu dot org 2010-01-22 19:23
---
(In reply to comment #24)
So I misinterpreted your ChangeLog, the adjective partial is referred to
both
;)
The 'partial' was in my patch submission to gcc-patches, and that
patch completely fixed pr42813,
--- Comment #3 from davek at gcc dot gnu dot org 2010-01-22 19:25 ---
I haven't tried a whole lot of cross compiler building. There's no reference
to cygwin anywhere in crossconfig.m4, so perhaps we need --with-newlib?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42847
--- Comment #5 from jacob dot benoit dot 1 at gmail dot com 2010-01-22
19:29 ---
Sorry for the probably uninformed question, but this bug was just tagged
enhancement, and I thought that enhancement meant not really a bug but
rather a feature request. I would like to understand?
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-01-22 19:34 ---
(In reply to comment #5)
Sorry for the probably uninformed question, but this bug was just tagged
enhancement, and I thought that enhancement meant not really a bug but
rather a feature request. I would like to
--- Comment #4 from rainer at emrich-ebersheim dot de 2010-01-22 20:16
---
(In reply to comment #3)
I haven't tried a whole lot of cross compiler building. There's no reference
to cygwin anywhere in crossconfig.m4, so perhaps we need --with-newlib?
The identical setup works for
--- Comment #5 from anlauf at gmx dot de 2010-01-22 20:43 ---
There is also a lot of noise when a derived type with default
initialization is instantiated. Moreover, the warnings point
to an unexpected locus. Consider:
module bla
implicit none
integer, parameter :: i1 = 1, i2 = 2
--- Comment #39 from rguenther at suse dot de 2010-01-22 21:47 ---
Subject: Re: [4.5 Regression] stdarg pass
produces wrong code
On Fri, 22 Jan 2010, jakub at gcc dot gnu dot org wrote:
--- Comment #38 from jakub at gcc dot gnu dot org 2010-01-22 19:17
---
In 4.4 the
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-22 22:10 ---
You need to fix your host gjar tool.
*** This bug has been marked as a duplicate of 39177 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #40 from steven at gcc dot gnu dot org 2010-01-22 22:49 ---
Running tree-stdarg earlier would introduce non-obvious pass ordering
requirements IIUC. I don't think that's a good idea...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
--- Comment #41 from rguenth at gcc dot gnu dot org 2010-01-22 22:57
---
(In reply to comment #40)
Running tree-stdarg earlier would introduce non-obvious pass ordering
requirements IIUC. I don't think that's a good idea...
Well given that practically we moved stdarg towards the
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-22 23:53 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-22 23:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42797
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-01-23 00:00 ---
A patch is here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01200.html
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ami_stuff at o2 dot pl 2010-01-23 03:26 ---
Looks like -mnobitfield option increases object's size more than 100%. I don't
know if so big file size increase is correct. Another problem can be noticed
with GCC 4.4.2 which generated 45% bigger object than the rest of
94 matches
Mail list logo
