Re: fatal error: gnu/stubs-32.h: No such file
On 07/06/13 11:53, Andreas Schwab wrote: Bruce Korb writes: Why is it that configure worked but stubs-32.h was not found? This is testing the host compiler which doesn't need that file. You need to build the target compiler before you can test it. Sorry, I'm still confused. I had a fresh openSuSE distro and I was trying to build GCC from SVN source. If doing that requires the installation of 32 bit development package, then I think I am trying to say that configure should go look for the needed 32 bit dev package and complain. I am hoping that the developer responsible for the code trying to include the header would fiddle the configure script. I confess to trying to avoid that kind of fiddling.
Re: List of typos.
On Sat, Jul 06, 2013 at 01:14:38PM +0100, Jonathan Wakely wrote: > I decided to grep for all the misspelled words beginning with A from > your list and fix the ones that were real errors. That took me an hour > to produce this patch. It doesn't include changes to java or fortran, > as I don't have them checked out in my tree. After a bootstrap and > another review I'm going to commit most of these as obvious, but I > don't really want to spend another ~25 hours doing the rest of the > alphabet! :) I updated my list to be less noisy. I worked how to make this more efficient. I created patch with obvious cases in hour. (only comments in c files though.) http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch This approach would benefit from scaling. I could collect sources of more projects, then fix spelling mistakes repeated thousand times at once. Also I would like to find how easily share what we train aspell for usage in hooks. My original idea was to run aspell on file containing only comment which does not work yet as I do not know how make aspell read stdin (perhaps I will write custom frontend.). As alternative I created program on https://github.com/neleai/stylepp that changes comments in c files in current subtree based on file ./dictionary (content below). Now usage is bit complicated, in subtree you want to check you need do following PATH/script/stylepp_spellcheck # collect misspells into /tmp/misspells file cp /tmp/misspells /tmp/replace aspell /tmp/replace # Now replace misspellings. PATH/bin/stylepp_make_dictionary /tmp/misspells /tmp/replace > dictionary PATH/script/stylepp_skeleton stylepp_fix_comment # now fix source tree. dictionary used is below abiove above accceptedaccepted accees access acceses accesses accesor accessor accestor accessor accidently accidentally accomodate accommodate accompagning accompanying accordinly accordingly accout account accretingaccrediting accumlator accumulator accummulatingaccumulating accummulatorsaccumulators acessableaccessible acknowledgement acknowledgment actullay actually acualactual addesses addresses additionnal additional addreses addresses addresse addressee addressibility addressability addressings addressing adjusmentadjustment adjustement adjustment adjustements adjustments aggegate aggregate agggregate aggregate aggragateaggregate aggreagate aggregate aggreate aggregate aggreggate aggregate algoritmsalgorithms algorthm algorithm aligment alignment alignement alignment alignemntalignment allcoatedallocated allocatbale allocatable allocatoor allocator alltogether altogether allways always alocatable allocatable alocationallocation alogrithmalgorithm alrady already alreadh already alredy already alsoneedsalso_needs alwayalways amendement amendment amoutamount analagousanalogous analoguous analogous analysed analyzed analyser analyzer anwayanyway apilogue epilogue appearantly apparently apperances appearances appereance appearance applytingapplying appoximately approximately appplyingapplying approprite appropriate approriate appropriate arbitary arbitrary archtiecture architecture arguements arguments arguemtnsarguments argumet argument aribtraryarbitrary arithmatic arithmetic aritmeticarithmetic arugment argument arument argument assigmentassignment assigments assignments assignemnt assignment assignmenassignment assinmentassignment associatied associated assotiated associated asssume assume assumpation assumption assumtions assumptions astericesasterisks astheticsaesthetics aswell as_well atributesattributes atrributeattribute autmatically automatically avaiable available availablity availability avoidpaste avoid_paste awrning warning barrer barrier beacuse because becaause because becacdd because becase because becasue because becauae because becaue
Re: fatal error: gnu/stubs-32.h: No such file
On 7 July 2013 15:00, Bruce Korb wrote: > On 07/06/13 11:53, Andreas Schwab wrote: >> >> Bruce Korb writes: >> >>> Why is it that configure worked but stubs-32.h was not found? >> >> >> This is testing the host compiler which doesn't need that file. You >> need to build the target compiler before you can test it. > > > Sorry, I'm still confused. I had a fresh openSuSE distro and I > was trying to build GCC from SVN source. If doing that requires > the installation of 32 bit development package, then I think I > am trying to say that configure should go look for the needed 32 > bit dev package and complain. I am hoping that the developer > responsible for the code trying to include the header would > fiddle the configure script. I confess to trying to avoid that > kind of fiddling. There is no code trying to include the header, GCC doesn't include it directly, it is included by glibc's which is included by other headers GCC uses. The point is, how do you test for "the needed 32 bit dev package"? The only way is to try compiling a program as 32-bit, but that can only be done by the target compiler once it's built, because the host compiler might not be capable of 32-bit output.
Re: List of typos.
On 7 July 2013 15:21, Ondřej Bílka wrote: > > I worked how to make this more efficient. I created patch with obvious cases > in hour. (only comments in c files though.) > > http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch Some of the code fixed by that (boehm-gc, zlib, libsanitizer) is maintained outside GCC so your patches should go upstream. I'll apply some of the other fixes though, thanks for the patch.
Re: List of typos.
On 7 July 2013 15:21, Ondřej Bílka wrote: > > discontiguousdiscontinuous This one is incorrect - the libstdc++ header is talking about contiguous memory, not continuous memory (arguably it should be non-contiguous, but leaving it alone is better than changing it to discontinuous.)
Re: List of typos.
Ondrej Bilka schrieb:
http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch
This is wrong:
@@ -10834,7 +10834,7 @@ avr_convert_to_type (tree type, tree expr)
XOP[2] # Bytes to copy
Return TRUE if the expansion is accomplished.
- Return FALSE if the operand compination is not supported. */
+ Return FALSE if the operand compilation is not supported. */
Should be "combination" not "compilation".
index 406617f..c7a7f7b 100644
--- a/gcc/config/frv/frv-opts.h
+++ b/gcc/config/frv/frv-opts.h
@@ -1,4 +1,4 @@
-/* Frv option-handling defitions.
+/* Frv option-handling deviations.
Should be "definitions" instead of "deviations".
-/* Expand SYMBOL into its corresponding far-addresse symbol.
+/* Expand SYMBOL into its corresponding far-addressee symbol.
Is this correct or should be "far-address"?
@@ -5336,7 +5336,7 @@ pa_print_operand (FILE *file, rtx x, int code)
&& GET_CODE (XEXP (XEXP (x, 0), 1)) == REG)
{
/* Because the REG_POINTER flag can get lost during reload,
-pa_legitimate_address_p canonicalizes the order of the
+pa_legitimate_address_p canonizes the order of the
I am not sure about this one and many others. "canonicalize" sounds ok
to me, so does "canonicalization". "canonize" sounds odd to me. For
example the following which should change none or both:
-/* Canonicalize the filename NAME by canonicalizing directory
+/* Canonicalize the filename NAME by canonizing directory
- * Unique vinsn derivates from CALL, ASM, JUMP (for a while) and other
+ * Unique vinsn derivatives from CALL, ASM, JUMP (for a while) and other
Shouldn't this be "derives"?
- /* Merge c_expres found or unify live register sets from different
+ /* Merge c_express found or unify live register sets from different
Some lines above in sel-sched.c there is "C_EXPRes". Again, change none
or both (none seems fine here):
- /* Test exponentials and their signs. A buggy lexer is more likely
+ /* Test exponential and their signs. A buggy lexer is more likely
Should both be plural or singular. "exponents" sounds good to me.
- Roger Sayle <...@eyesopen.com>
+ Roger Sayle <...@eyes open.com>
Don't change email addresses!
Johann
Re: List of typos.
On Sun, 2013-07-07 at 19:54 +0200, Georg-Johann Lay wrote:
> Ondrej Bilka schrieb:
>
> > http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch
>
Below are some other hunks that look suspicious...
(trying not to duplicate the things already mentioned by others)
- * 1) It means that finalizers, and all methods calle by them,
+ * 1) It means that finalizers, and all methods callee by them,
-> 'called'
- /* SET_ACCESS, we want to set an explicte set of permissions, do not
+ /* SET_ACCESS, we want to set an explicate set of permissions, do not
-> 'explicit'
In Objective-C, there are two additional variants:
foreach-statement:
- for ( expression in expresssion ) statement
+ for ( expression in expressions ) statement
for ( declaration in expression ) statement
Really? I'm not so sure.
- configury */
+ configure */
-> 'configury'
- calll#gettlsoff(ADDR)@(gr8, gr0)
+ call#gettlsoff(ADDR)@(gr8, gr0)
- calll #gettlsoff(ADDR)@(gr8, gr0)
+ call #gettlsoff(ADDR)@(gr8, gr0)
The original 'calll' is correct (see frv.md).
- have the same priority - candidate is best if its dependees were
+ have the same priority - candidate is best if its dependencies were
-> 'dependees'
- does not look at other present displacement addressings around it.
+ does not look at other present displacement addressing around it.
-> 'addressings' (as in addressing modes)
- CM_SMALL,/* Makes various assumpation about sizes of code and
+ CM_SMALL,/* Makes various assumption about sizes of code and
- CM_SMALL_PIC,/* Makes various assumpation about sizes of code and
+ CM_SMALL_PIC,/* Makes various assumption about sizes of code and
-> 'assumptions'
/* If we had fewer function args than explicit template args,
- just use the explicits. */
+ just use the explicit. */
-> 'explicit ones'
-array reference if the where and elswhere destinations
+array reference if the where and Elsinore destinations
-> 'elsewhere'
- We provide accestor to the inline_summary datastructure and
+ We provide accessor to the inline_summary datastructure and
-> probably 'ancestor'
-/* The array used to find duplications in conflict vectors of
+/* The array used to find duplication in conflict vectors of
-/* Remove duplications in conflict vector of OBJ. */
+/* Remove duplication in conflict vector of OBJ. */
-/* Process operator duplications in insn with ID. We do it after the
+/* Process operator duplication in insn with ID. We do it after the
-> 'duplicates' maybe?
- function we iterate decompressions until no data remains. */
+ function we iterate decompression's until no data remains. */
-> 'decompressions'
- TODO: Make into some kind of configury-generated table. */
+ TODO: Make into some kind of configure-generated table. */
-> 'configury-generated'
-point of view as prefetch withouth dependecies will have a
+point of view as prefetch withouth dependencies will have a
-> missed 'without'
- * Unique vinsn derivates from CALL, ASM, JUMP (for a while) and other
+ * Unique vinsn derivatives from CALL, ASM, JUMP (for a while) and other
-> maybe 'deviates' ?
-/* Find the set of registers that are unavailable for storing expres
+/* Find the set of registers that are unavailable for storing express
- that are not available for storing expres while moving ORIG_OPS up on the
+ that are not available for storing express while moving ORIG_OPS up on the
- /* Merge c_expres found or unify live register sets from different
+ /* Merge c_express found or unify live register sets from different
-> maybe 'expression' ?
-/* { dg-final { scan-assembler "calll.*#gettlsoff\\(0\\)" } } */
+/* { dg-final { scan-assembler "call.*#gettlsoff\\(0\\)" } } */
-> see above for the 'calll' frv case. This breaks the test case.
Do not change things inside /* { } */ comments in test cases.
-/* PR target/50749: Verify that subsequent post-increment addressings
+/* PR target/50749: Verify that subsequent post-increment addressing
-/* PR target/50749: Verify that subsequent pre-decrement addressings
+/* PR target/50749: Verify that subsequent pre-decrement addressing
-/* PR target/50749: Verify that subsequent post-increment addressings
+/* PR target/50749: Verify that subsequent post-increment addressing
-/* PR target/50749: Verify that subsequent pre-decrement addressings
+/* PR target/50749: Verify that subsequent pre-decrement addressing
-> 'addressings' (as in addressing modes)
- /* For buitins that are likely expanded to nothing or
+ /* For builtin's that are likely expanded to nothing or
-> 'builtins'
BASE must be either a declaration or a memory reference that has correct
- alignment ifformation embeded in it (e.g. a pre-existing one in SRA). */
+ alignment ifformation embedded in it (e.g.
ingilizce konuşma eğitimleri
istanbul english club profesyonel ingilizce konuşma eğitimi merkezi konuşma kulübü haricinde birebir(özel)eğitimler yine kayıt ve devam sistemi olmadan devam ediyor... eğitmenlerin tümü ingiliz ve amerikalı... 2 kişi gel 1 kişi öde sistemi devam etmektedir. 1 saat birebir(özel)ders sadece 45 TL ingilizce konuşma kulübü devam etmektedir.kayıt ve devam sistemi yoktur.bir kez katılım(2 saat)ücreti 30 TL dir. İstanbul English Club Temmuz 2013 Programı Pazartesi 18:30-20:30 Howell(USA) Salı 18:30-20:30 Jennifer(USA) Çarşamba 18:30-20:30 Howell(USA) Perşembe 18:30-20:30 Lynn(UK) Cuma 18:30-20:30 Jennifer(USA) Cumartesi 14:00-16:00 Ronald(USA) Pazar 14:00-16:00 Zachary(USA) istanbulenglishclub.com 0 212 232 75 54
Re: fatal error: gnu/stubs-32.h: No such file
On Sun, Jul 7, 2013 at 9:00 AM, Bruce Korb wrote: > On 07/06/13 11:53, Andreas Schwab wrote: >> >> Bruce Korb writes: >> >>> Why is it that configure worked but stubs-32.h was not found? >> >> >> This is testing the host compiler which doesn't need that file. You >> need to build the target compiler before you can test it. > > > Sorry, I'm still confused. I had a fresh openSuSE distro and I > was trying to build GCC from SVN source. If doing that requires > the installation of 32 bit development package, then I think I > am trying to say that configure should go look for the needed 32 > bit dev package and complain. I am hoping that the developer > responsible for the code trying to include the header would > fiddle the configure script. I confess to trying to avoid that > kind of fiddling. I have been having this problem since 2001 on SuSE or openSUSE. For some reason, GCC's build machinery does not want to detect at configuration type that there is no stub-32.h file, therefore there is absolutely no point in trying to do a multilib which would fail. I have to provide explicitly --disable-multilib; like you, I think we should not have to do that. -- Gaby
Re: fatal error: gnu/stubs-32.h: No such file
On Sun, Jul 7, 2013 at 12:44 PM, Jonathan Wakely wrote: > On 7 July 2013 15:00, Bruce Korb wrote: >> On 07/06/13 11:53, Andreas Schwab wrote: >>> >>> Bruce Korb writes: >>> Why is it that configure worked but stubs-32.h was not found? >>> >>> >>> This is testing the host compiler which doesn't need that file. You >>> need to build the target compiler before you can test it. >> >> >> Sorry, I'm still confused. I had a fresh openSuSE distro and I >> was trying to build GCC from SVN source. If doing that requires >> the installation of 32 bit development package, then I think I >> am trying to say that configure should go look for the needed 32 >> bit dev package and complain. I am hoping that the developer >> responsible for the code trying to include the header would >> fiddle the configure script. I confess to trying to avoid that >> kind of fiddling. > > There is no code trying to include the header, GCC doesn't include it > directly, it is included by glibc's which is included by > other headers GCC uses. > > The point is, how do you test for "the needed 32 bit dev package"? > The only way is to try compiling a program as 32-bit, but that can > only be done by the target compiler once it's built, because the host > compiler might not be capable of 32-bit output. How about not enabling multi lib build by default on targets we now that will fail anyway? I have the suspicion this problem is unique to openSUSE, so we can take care of that. -- Gaby
gcc-4.9-20130707 is now available
Snapshot gcc-4.9-20130707 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20130707/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 200744 You'll find: gcc-4.9-20130707.tar.bz2 Complete GCC MD5=66ad3f762e7ac34c6a941010c5157892 SHA1=75c6724424630e8e7d9581422d2f0a8bec215975 Diffs from 4.9-20130630 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: fatal error: gnu/stubs-32.h: No such file
On 7 July 2013 21:33, Gabriel Dos Reis wrote: > How about not enabling multi lib build by default on targets we now that > will fail anyway? I have the suspicion this problem is unique to openSUSE, > so we can take care of that. I'm pretty sure I've seen it happen with RHEL and Fedora, and Ubuntu users have asked about the same thing on the gcc-help list.
Re: List of typos.
On Sun, 07 Jul 2013 21:57:05 +0200 Oleg Endo wrote: > - // Randomize the colour, just for asthetics =) > + // Randomize the colour, just for aesthetics =) > > -> missed 'color' (in a couple of places actually) Because that's the correct way of spelling colour. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Inline virtual call puzzling behaviour
Hi,
I've been playing around gcc -flto flag and inlining functionnalities for a
while in search of both optimized performance and full understanding of g++
behavious.
Right now, I'm puzzled by the assembly output produced for that piece of code:
#include
using namespace std;
class A
{
public:
inline virtual void blah()
{
cout << "A" << endl;
}
};
class B : public A
{
public:
inline virtual void blah()
{
cout << "B" << endl;
}
};
class C
{
public:
void blah()
{
cout << "C" << endl;
}
};
int main(int argc, char** argv)
{
A* ptr = 0;
if(argc == 1)
ptr = new B();
else
ptr = new A();
ptr->blah();
B().blah();
C().blah();
}
I would expect the compiler to be able to inline function blah() when it is
statically called for class B and C but have a VTable resolution for the call
ptr->blah. Here's the relevant assembly code produced by g++ with flags -O3 and
-S:
main:
.LFB976:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
cmpl$1, %edi
movl$8, %edi
je .L18
call_Znwm
movq%rax, %rdi
movq$_ZTV1A+16, (%rax)
movl$_ZTV1A+16, %eax
.L16:
call*(%rax)
movq%rsp, %rdi
movq$_ZTV1B+16, (%rsp)
call_ZN1B4blahEv
movl$.LC2, %esi
movl$_ZSt4cout, %edi
call_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
movq%rax, %rdi
call_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
xorl%eax, %eax
addq$24, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L18:
.cfi_restore_state
call_Znwm
movq%rax, %rdi
movq$_ZTV1B+16, (%rax)
movl$_ZTV1B+16, %eax
jmp .L16
.cfi_endproc
The puzzling part is to find that the call for C().blah() is indeed inlined and
the ptr->blah() uses a VTable resolution, but the code for B.blah() uses
neither: the static adress is resolved but the code is not inlined! (The same
behaviour occurs if there would be a static-typed pointer to an object of class
B). I understand the compiler propagates the types properly, but even after
determining the correct type for the object of type B, it only resolves the
vtable reference (hence no call *(%..x) ), but cannot perform the inlining.
Question: why ? Can someone explain me the exact order in which the optimization
of g++ are performed and how they interact with each other ? I know this might
be tricky but any small shed of light could be helpfull. Also, did I miss a
flag which would enable g++ to proceed to do the inlining after the resolution
?
>From a practical point of view, I understand this example does not justify by
itself the absolute need for inlining. However, I do have a time-critical
application that would get 25-30% increase in speed if I could solve this
issue. Also, I'm just curious to understand why is this the behaviour of g++
(or if it's actually a bug) because it counter my most primitive intuition and
the beliefs of many people I know.
Thanks in advance for any answer to come.
Kind Regards
--
Thierry Lavoie, B.Ing., M.scA.
PhD. Student, Polytechnique Montreal
Lecturer INF2010: Data Structures and Algorithm
Lecturer LOG3210: Languages and Compilers
Re: fatal error: gnu/stubs-32.h: No such file
On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely wrote: > On 7 July 2013 21:33, Gabriel Dos Reis wrote: >> How about not enabling multi lib build by default on targets we now that >> will fail anyway? I have the suspicion this problem is unique to openSUSE, >> so we can take care of that. > > I'm pretty sure I've seen it happen with RHEL and Fedora, and Ubuntu > users have asked about the same thing on the gcc-help list. Ha, if it is that spread then we might have even more reasons to have it work more generally, for example, by disabling multilib by default. I think the situation we are in now is very different from the situation we were in more than a decade ago. -- Gaby
Re: fatal error: gnu/stubs-32.h: No such file
On Sun, Jul 7, 2013 at 10:17 PM, Gabriel Dos Reis wrote: > On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely wrote: >> On 7 July 2013 21:33, Gabriel Dos Reis wrote: >>> How about not enabling multi lib build by default on targets we now that >>> will fail anyway? I have the suspicion this problem is unique to openSUSE, >>> so we can take care of that. >> >> I'm pretty sure I've seen it happen with RHEL and Fedora, and Ubuntu >> users have asked about the same thing on the gcc-help list. > > Ha, if it is that spread then we might have even more reasons to > have it work more generally, for example, by disabling multilib by default. > I think the situation we are in now is very different from the situation > we were in more than a decade ago. I think disable multilib by default is a mistake and is a broken choice for broken distros which don't install the 32bit development by default when you install the development part. Thanks, Andrew
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 8, 2013 at 12:19 AM, Andrew Pinski wrote: > On Sun, Jul 7, 2013 at 10:17 PM, Gabriel Dos Reis > wrote: >> On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely >> wrote: >>> On 7 July 2013 21:33, Gabriel Dos Reis wrote: How about not enabling multi lib build by default on targets we now that will fail anyway? I have the suspicion this problem is unique to openSUSE, so we can take care of that. >>> >>> I'm pretty sure I've seen it happen with RHEL and Fedora, and Ubuntu >>> users have asked about the same thing on the gcc-help list. >> >> Ha, if it is that spread then we might have even more reasons to >> have it work more generally, for example, by disabling multilib by default. >> I think the situation we are in now is very different from the situation >> we were in more than a decade ago. > > I think disable multilib by default is a mistake and is a broken > choice for broken distros which don't install the 32bit development by > default when you install the development part. Why do you think it is a broken choice? Personally, I don't see anything broken with that. The world we are in today is very different from a decade ago. More than a decade ago, a multilib build by default -probably- made sense; I don't see that today. -- Gaby
Re: fatal error: gnu/stubs-32.h: No such file
On Sun, Jul 7, 2013 at 10:55 PM, Gabriel Dos Reis wrote: > On Mon, Jul 8, 2013 at 12:19 AM, Andrew Pinski wrote: >> On Sun, Jul 7, 2013 at 10:17 PM, Gabriel Dos Reis >> wrote: >>> On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely >>> wrote: On 7 July 2013 21:33, Gabriel Dos Reis wrote: > How about not enabling multi lib build by default on targets we now that > will fail anyway? I have the suspicion this problem is unique to > openSUSE, > so we can take care of that. I'm pretty sure I've seen it happen with RHEL and Fedora, and Ubuntu users have asked about the same thing on the gcc-help list. >>> >>> Ha, if it is that spread then we might have even more reasons to >>> have it work more generally, for example, by disabling multilib by default. >>> I think the situation we are in now is very different from the situation >>> we were in more than a decade ago. >> >> I think disable multilib by default is a mistake and is a broken >> choice for broken distros which don't install the 32bit development by >> default when you install the development part. > > Why do you think it is a broken choice? > > Personally, I don't see anything broken with that. The world we are > in today is very different from a decade ago. More than a decade ago, > a multilib build by default -probably- made sense; I don't see that today. Maybe on x86 it does not make sense (until x32 comes into play) but for other targets like MIPS64 or soon AARCH64 it does make sense because the they both have a 32bit ABI which sites over the 64bit ISA. I think the problem is still in the distros rather than GCC. Thanks, Andrew Pinski
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 8, 2013 at 12:59 AM, Andrew Pinski wrote: > On Sun, Jul 7, 2013 at 10:55 PM, Gabriel Dos Reis > wrote: >> On Mon, Jul 8, 2013 at 12:19 AM, Andrew Pinski wrote: >>> On Sun, Jul 7, 2013 at 10:17 PM, Gabriel Dos Reis >>> wrote: On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely wrote: > On 7 July 2013 21:33, Gabriel Dos Reis wrote: >> How about not enabling multi lib build by default on targets we now that >> will fail anyway? I have the suspicion this problem is unique to >> openSUSE, >> so we can take care of that. > > I'm pretty sure I've seen it happen with RHEL and Fedora, and Ubuntu > users have asked about the same thing on the gcc-help list. Ha, if it is that spread then we might have even more reasons to have it work more generally, for example, by disabling multilib by default. I think the situation we are in now is very different from the situation we were in more than a decade ago. >>> >>> I think disable multilib by default is a mistake and is a broken >>> choice for broken distros which don't install the 32bit development by >>> default when you install the development part. >> >> Why do you think it is a broken choice? >> >> Personally, I don't see anything broken with that. The world we are >> in today is very different from a decade ago. More than a decade ago, >> a multilib build by default -probably- made sense; I don't see that today. > > Maybe on x86 it does not make sense (until x32 comes into play) but x86 constitutes a large share of GCC community. > for other targets like MIPS64 or soon AARCH64 it does make sense > because the they both have a 32bit ABI which sites over the 64bit ISA. In that case enable multilib by default for those targets for which it makes sense by default and you know for sure it won't result into a build failure, instead of the reverse situation of "well, if it blows, it blows; good luck, we are crossing our fingers for you." > I think the problem is still in the distros rather than GCC. I strongly disagree. We (GCC) are at fault here. We implicitly enable a feature at configure time without knowing its builds will succeed (despite having repeated reports that it does often fail) without much input from the builder (who might be ignorant of real reason of failures.) Usually we do the opposite. -- Gaby
[PATCH] fix typos mandated by conventions.
On Sun, Jul 07, 2013 at 04:21:15PM +0200, Ondřej Bílka wrote: > On Sat, Jul 06, 2013 at 01:14:38PM +0100, Jonathan Wakely wrote: > > I decided to grep for all the misspelled words beginning with A from > > your list and fix the ones that were real errors. That took me an hour > > to produce this patch. It doesn't include changes to java or fortran, > > as I don't have them checked out in my tree. After a bootstrap and > > another review I'm going to commit most of these as obvious, but I > > don't really want to spend another ~25 hours doing the rest of the > > alphabet! :) > Hi now, when I have infrastructure ready I made another patch (its 500kb so link not to overload list). It is here; http://kam.mff.cuni.cz/~ondra/gcc_misspell_conventions.patch It uses dictionary made by reading gcc conventions. http://gcc.gnu.org/codingconventions.html Only obvious cases are there I could add warning for cases that need decide if word is noun or adjective etc. This patch was generated by command script/stylepp_skeleton stylepp_fix_comment whose version is following https://github.com/neleai/stylepp/commit/23ddb7c5857964861abdb524971071488c1a83ba and following dictionary. 32_bit 32-bit alpha_numeric alphanumeric bitfield bit-field bit_field bit-field coldfire ColdFire Coldfire ColdFire command_line_option command-line_option enumeral enumerated epilog epilogue lower_case lowercase lower-case lowercase mips MIPS Mips MIPS non-zero nonzero non_zero nonzero Objective_C Objective-C prolog prologue powerpc PowerPC powerPC PowerPC PowerPc PowerPC Redhat Red_Hat RedHat Red_Hat sparc SPARC Sparc SPARC test_case testcase test-case testcase test_suite testsuite test-suite testsuite upper_case uppercase upper-case uppercase vax VAX Vax VAX vaxen VAXen microvax MicroWAX
