Integration of transactional memory support into a data-flow extension of OpenMP
Hi,
I am Ismail KURU, accepted by Google Summer of Code 2011.
My study mainly focuses on integration of transactional memory support
into data-flow extension of OpenMP that is
aiming increased expressiveness and performance while preserving the
paradigms' properties.
My project combines development and research components and can be
decomposed into 5 phases.
1. Study the compatibility of the transactional memory and OpenMP
constructs in the
transmem development branch of GCC and propose solutions to the possible
technical
difficulties.
2. Study the desgin and implementation of both data-flow (streaming) and
transmem branches
of GCC, interacting with their maintainers.
3. Address the infrastructure limitations, software engineering and
version management issues
related to the integration of both code bases into a single experimental
branch.
4. Contribute to the design and implementation for a semantics of
transactions nested within
OpenMP tasks.
5. Write and rewrite relevant benchmarks leveraging the new programming
model, performing
systematic evaluations and detailed characterizations of the performance
behavior.
I have finished the research part of the project related
with compatibility of the transactional memory and OpenMP constructs
with integrating the OpenMP constructs
and trans-mem constructs of GCC on LeeTM benchmark from University of
Manchester.
Note : Just an example code from LeeTM for compatibility research of
OpenMP and trans-mem .
#define MEMSET _ITM_memsetW
#define MEMCPY _ITM_memcpyRtWt
#define BEGIN_TRANSACTION \
_ITM_beginTransaction (pr_instrumentedCode | pr_hasNoIrrevocable\
| pr_hasNoAbort)
#define END_TRANSACTION \
_ITM_commitTransaction ()
void run_benchmark() {
.
_ITM_Initialize();
// create Lee benchmark
Lee *lee = new Lee(cmdl_args.input_file_name, false, false, false);
// initialize thread arguments
for(unsigned i = 0;i < cmdl_args.thread_count;i++) {
targs[i].lee = lee;
targs[i].id = i;
targs[i].commits = 0;
targs[i].aborts = 0;
targs[i].private_buffer= create_private_buffer(lee);
}
long start_time_ms;
if(targs->id==0)
start_time_ms = get_time_ms();
omp_set_num_threads(cmdl_args.thread_count);
#pragma omp parallel private(nthreads, thread_id)
{
/* Only master thread does this */
if (thread_id == 0)
{
nthreads = omp_get_num_threads();
printf("Number of threads = %d\n", nthreads);
}
run_transactions(&targs[thread_id]);
#pragma omp barrier
}
}
void run_transactions(thread_args *targ) {
Lee *lee = targ->lee;
while(true) {
WorkQueue *track = lee->getNextTrack();
if(track == NULL) {
break;
}
// check for aborts
if(!first) {
targ->aborts++;
} else {
first = false;
}
BEGIN_TRANSACTION;
#ifdef IRREGULAR_ACCESS_PATTERN
// perform an update or read of contention object
if(should_irregular_write(&targs->seed)) {
lee->update_contention_object();
} else if(should_irregular_read(&targs->seed)) {
lee->read_contention_object();
}
#endif // IRREGULAR_ACCESS_PATTERN
// transaction body
lee->layNextTrack(track, targ->private_buffer);
END_TRANSACTION;
targs->commits++;
}
}
There is not a big performance difference between our approach (OpenMP +
trans-mem) and (pthreads + tinySTM).
I am trying to find out a pipeline (regarding data-flow) structure for
transactional region in LeeTM for benchmarking my study.
Also transaction's size, scaling contention on shared data are my other
issues.
More important thing is that I would like to ask whether you (GCC
developers) have your own suggestions and priorities regarding the
proposed topic and the interaction between TM and OpenMP.
Regards
Ismail KURU
Integration of transactional memory support into a data-flow extension of OpenMP
Hi, I have thought that my first email can be seen as too long. I have done experiments regarding compatibility of OpenMP pramas + trans-mem constructs. (It is fine, working. I have a primitive interface (combined constructs of trans-mem and OpenMP)) Any suggestions for benchmarks would be great especially including: * transactions that can be pipelined with concerns of targeting data-flow parallelism. * I have studied on LeeTM but it does not include pipelined structure for transactions. I will be trying to structure this benchmark as pipelined BUT any other suggestions would be great!! regards Ismail KURU
Re: Integration of transactional memory support into a data-flow extension of OpenMP
On Tue, 2011-05-03 at 23:09 +0200, ismail kuru wrote: > > > On 3 May 2011 17:02, Patrick Marlier wrote: > Hi Ismail! > > > My study mainly focuses on integration of > transactional memory support > into data-flow extension of OpenMP that is > aiming increased expressiveness and performance while > preserving the > paradigms' properties. > > > I am really happy to see people working with transactional > memory. I will try to follow your work. > > > ++ Thanks a lot for your attention to my project. Yes , it also > really makes me happy to have people interested in Transactional > memory and my project. > > My project combines development and research > components and can be > decomposed into 5 phases. > > 1. Study the compatibility of the transactional memory > and OpenMP > constructs in the > transmem development branch of GCC and propose > solutions to the possible > technical > difficulties. > > > In the Velox project, one application named QuakeTM was using > TM and OpenMP without problem but I know that the OpenMP was > not used extensively. So probably you will find some problems. > > ++ I have not worked on QuakeTM before . Thanks a lot for > suggestion. > > 2. Study the desgin and implementation of both > data-flow (streaming) and > transmem branches > of GCC, interacting with their maintainers. > > > I am not a maintainer (not yet at least) of the trans-mem > branch but I know quite well TM and some part of > implementation details in gcc. So if you post questions, I > will try to answer them. > > ++ Having contact with some experienced people on > Transactional Memory is really so important for me . It would > be great for me. > > > Note : Just an example code from LeeTM for > compatibility research of > OpenMP and trans-mem . > > #define MEMSET _ITM_memsetW > #define MEMCPY _ITM_memcpyRtWt > #define BEGIN_TRANSACTION \ > _ITM_beginTransaction (pr_instrumentedCode | > pr_hasNoIrrevocable\ > | pr_hasNoAbort) > > #define END_TRANSACTION \ > _ITM_commitTransaction () > > > Why did you use explicit calls to _ITM_* functions? why not > using the __transaction semantic? > ++ I was trying to do experiments with different passing > parameters (instrumentedCode , uninstrumentedCode, > hasNoAbort, hasNoRetry, hasNoIrrevocable,doesGoIrrevocabl ) to > "_ITM_beginTransaction" and try to scale the compatibility > with ++OpenMP constructs. I have also used "__transaction" > semantic. There is no problem. This is what I have put here. > >// transaction body >lee->layNextTrack(track, > targ->private_buffer); > > > Did you transactify accesses in this function? or does it use > only MEMSET and MEMCPY? > (I have tried LeeTM only one time and I can't remember > implementation details.) > > > ++ I have tried both. I am having problems on this part because of not > being experienced and I think I have to make experiments again on > LeeTM. > ++ First of all, MEMCPY and MEMSET functions do not include any > transaction identifier (id) and transactions inside the LeeTM fails > during transactional access to the memory. I think this case is also > for tinySTM-0.9.9 and tinySTM-1.0. > > > ++ tinySTM-0.9.9 has mem access functions with transaction handlers as > the following > ++stm_word_t stm_load(stm_tx_t *tx, volatile stm_word_t *addr); > ++void stm_store(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t > value); > ++void stm_store2(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t > value, stm_word_t mask); > > > ++but tinySTM-1.0 does not . Your opinions on these different version
Re: Integration of transactional memory support into a data-flow extension of OpenMP
On Wed, 2011-05-04 at 12:03 +0200, Patrick Marlier wrote: ---Sorry for the late response. > Dear Ismail, > > On 05/03/2011 11:18 PM, ismail wrote: > >> ++ First of all, MEMCPY and MEMSET functions do not include any > >> transaction identifier (id) and transactions inside the LeeTM fails > >> during transactional access to the memory. I think this case is also > >> for tinySTM-0.9.9 and tinySTM-1.0. > >> > >> ++ tinySTM-0.9.9 has mem access functions with transaction handlers as > >> the following > >> ++stm_word_t stm_load(stm_tx_t *tx, volatile stm_word_t *addr); > >> ++void stm_store(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t > >> value); > >> ++void stm_store2(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t > >> value, stm_word_t mask); > >> > >> > >> ++but tinySTM-1.0 does not . Your opinions on these different version > >> of mem-access functions would be great. > > TinySTM 1.0 uses implicit transaction descriptor by default (same as > 0.9.9) but you can compile it with EXPLICIT_TX_PARAMETER (Makefile) and > then the transaction descriptor is explicit. > But functions are the same from 0.9.9 to 1.0.0 so I don't really see the > problem. --- Yes . thanks for update , I remembered . Also I wrote the version wrong it is "0.9.0b1 release". There should be a parameter like EXPLICIT_TX_PARAMETER in trans-mem. Did you need a kind of parameter --- while compiling the trans-mem branch ? For example to use trans-mem to transactify LeeTM (I am especially talking about the MEMSET and MEMCPY funcs. of trans-mem do not have transaction identifier while accessing to the mem.). --- I am currently using the explicit function calls when I need transaction identifier as the following. > >> ++My idea to convert from one version of mem-access function to > >> another is as the following: > >> > >> > >> ++ I think I have to make some explicit function calls as the > >> following: > >> ++ _ITM_transaction * td = _ITM_getTransaction(); > >> ++int doWhat = > >> _ITM_beginTransaction(td,pr_instrumentedCode,&txn_start_loc); > >> ++ . > >> ++_ITM_transactionId cur_id = _ITM_getTransactionId(); > > I do not understand that... > --- I tried to get transaction handler which does not ---have explicit ---descriptor where another function needs transaction ---descriptor as ---a parameter. > >> ++ Of course , It would be great to share the study and results with > >> you when I organize my study and all other things. > > I guess we will meet together at the EuroTM meeting in Paris. > ---Yes that will be great for me to have a chance to talk and discuss topics with you > Patrick Marlier. ---Ismail KURU
Re: Integration of transactional memory support into a data-flow extension of OpenMP
On Fri, 2011-05-06 at 17:51 +0200, Patrick Marlier wrote: >>>Dear Patrick, >>> I am currently searching for a pipeline in a TM-Benchmarks but I can >>>not overlap the concept of transactions with pipeline in current TM >>>benchmarks. I think I will write a new one. > Dear Ismail, > > On Fri, 6 May 2011, ismail wrote: > >> TinySTM 1.0 uses implicit transaction descriptor by default (same as > >> 0.9.9) but you can compile it with EXPLICIT_TX_PARAMETER (Makefile) and > >> then the transaction descriptor is explicit. > >> But functions are the same from 0.9.9 to 1.0.0 so I don't really see the > >> problem. > > --- Yes . thanks for update , I remembered . Also I wrote the version > > wrong it is "0.9.0b1 release". There should be a parameter like > > EXPLICIT_TX_PARAMETER in trans-mem. Did you need a kind of parameter > > --- while compiling the trans-mem branch ? For example to use trans-mem to > > transactify LeeTM (I am especially talking about the MEMSET and MEMCPY > > funcs. of trans-mem do not have transaction identifier while accessing to > > the mem.). > > --- I am currently using the explicit function calls when I need > > transaction identifier as the following. > > Humm... libitm is always using implicit transaction descriptor and there > is no such flag as in TinySTM. >>>I am clear with tx-iden. and tx-desc. Do you think that not having explicit tx_desc. is a handicap while converting conventional locking systems to the TM model? (I am having some trouble while dealing with benchmarks) > > Don't confuse transaction descriptor and transaction identifier. > I think it is better to use always implicit transaction descriptor it > avoids the burden to manage it. > > > --- I tried to get transaction handler which does not ---have explicit > > ---descriptor where another function needs transaction ---descriptor as > > ---a parameter. > > Hummm... which one has explicit tx descriptor? > All ITM functions are using implicit transaction descriptor as far as I > remember, otherwise it is a bit odd. >>> I have mixed tx_descriptor because of IntelTM ABI's specification. Yes there is just the following in the libitm: >>>typedef uint64_t _ITM_transactionId_t;/* Transaction identifier */ >>>#define _ITM_noTransactionId 1 /* Id for non-transactional code. */ >>>extern _ITM_transactionId_t _ITM_getTransactionId(void) >>>ITM_REGPARM; >>>BTW It may seem a general question but we are trying to figure out >>>several issues related with following question . It would be great If >>>you can share your opinion: >>>what are the main challenges right now w.r.t. transmem in C (we do >>>not care much about C++ at this point), and what are his expectations >>>and plans about exploitation of OpenMP with TM. > >>>THANKS A LOT >>> Ismail KURU > Patrick.
Re: GSOC - Student Roundup
y contributions have been modest, but now that I've crossed much of the learning curve, I feel optimistic. To an extent the progress has to be a bit slow because we are looking at the new Fortran standard and thinking about the best way to add features. Cheers, Daniel. Hi all, I am one of GSOC students. We have started the project with doing some experiments for checking the compatibility of OpenMP threads with [trans-mem] branch of GCC. We made a presentation (http://www.gsd.inesc-id.pt/~mcouceiro/eurotm/1stmeeting/16-IsmailKuru.pdf <http://www.gsd.inesc-id.pt/%7Emcouceiro/eurotm/1stmeeting/16-IsmailKuru.pdf>) at EuroTM meeting at Paris (http://www.eurotm.org/1st-plenary-meeting-in-paris/program). It was very useful for project's future perspective. However, I got accepted as a PhD and I have lots of urgent organizational and administrative issues and pre-requisite exams for PhD program to completed before the mid of August so I have no chance to go on with project until mid of August. But I am optimistic for the project and contribution to GCC even if I do not have an overlapping time-schedule with GSOC. Best Regards Ismail KURU
Interesting build failure on trunk
Hi all, I am getting this when I try to compile gcc trunk: ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include -I../../libcpp/include -c -o files.o -MT files.o -MMD -MP -MF .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function 'read_name_map': ../../libcpp/files.c:1238: internal compiler error: Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [files.o] Error 1 Did anyone hit this before? Regards, ismail
Re: Interesting build failure on trunk
On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote: > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > I am getting this when I try to compile gcc trunk: > > > > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe > > -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > > -Wold-style-definition -Wmissing-format-attribute -pedantic > > -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include > > -I../../libcpp/include -c -o files.o -MT files.o -MMD -MP -MF > > .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function > > 'read_name_map': > > ../../libcpp/files.c:1238: internal compiler error: Floating point > > exception Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > libcpp/files.c:1238 seems to be a call to memcpy. I don't see > anyplace a floating point exception might come from. I've certainly > never seen anything like that. FWIW I configure like this: ../configure --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-libssp --disable-nls --enable-ssp --enable-libstdcxx-allocator=new --enable-version-specific-runtime-libs --without-included-gettext --with-system-zlib --prefix=/usr/share/gcc-snapshot --enable-languages=c,c++ And make with : make STAGE1_CFLAGS="-O" BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE" profiledbootstrap Regards, ismail
Re: Interesting build failure on trunk
On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote: > > make STAGE1_CFLAGS="-O" > > BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer > > -U_FORTIFY_SOURCE" profiledbootstrap > > Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler. Ok btw bootstrapping compiler is, Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/pisi/gcc-4.2.0-15/work/gcc-4.2-20070102/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.2.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include --datadir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0 --mandir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/man --infodir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj --disable-libssp --disable-multilib --disable-nls --disable-werror --enable-clocale=gnu --enable-__cxa_atexit --enable-languages=c,c++,objc,fortran --enable-libstdcxx-allocator=new --enable-shared --enable-ssp --enable-threads=posix --enable-version-specific-runtime-libs --without-included-gettext --without-system-libunwind --with-system-zlib Thread model: posix gcc version 4.2.0 20070124 (prerelease) (Pardus Linux) Regards, ismail
Re: Interesting build failure on trunk
On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote: > > make STAGE1_CFLAGS="-O" > > BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer > > -U_FORTIFY_SOURCE" profiledbootstrap > > Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler. And I am still getting floating point exception even with a bare make. Any way to debug this? Regards, ismail
Re: Interesting build failure on trunk
On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote: > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > I am getting this when I try to compile gcc trunk: > > > > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe > > -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > > -Wold-style-definition -Wmissing-format-attribute -pedantic > > -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include > > -I../../libcpp/include -c -o files.o -MT files.o -MMD -MP -MF > > .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function > > 'read_name_map': > > ../../libcpp/files.c:1238: internal compiler error: Floating point > > exception Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > libcpp/files.c:1238 seems to be a call to memcpy. I don't see > anyplace a floating point exception might come from. I've certainly > never seen anything like that. I think this is an hardware error recently got a Bus Error when doing an rm -rf, I hope to change laptop's RAMs soon. I will report back. Thank you for your replies. Regards, ismail
Re: Interesting build failure on trunk
On Wednesday 31 January 2007 11:26:38 Ismail Dönmez wrote: > On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote: > > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > > I am getting this when I try to compile gcc trunk: > > > > > > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe > > > -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall > > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > > > -Wold-style-definition -Wmissing-format-attribute -pedantic > > > -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include > > > -I../../libcpp/include -c -o files.o -MT files.o -MMD -MP -MF > > > .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function > > > 'read_name_map': > > > ../../libcpp/files.c:1238: internal compiler error: Floating point > > > exception Please submit a full bug report, > > > with preprocessed source if appropriate. > > > See http://gcc.gnu.org/bugs.html> for instructions. > > > > libcpp/files.c:1238 seems to be a call to memcpy. I don't see > > anyplace a floating point exception might come from. I've certainly > > never seen anything like that. > > I think this is an hardware error Ok its not, I tried to build on AMD64 3500+ 1GB RAM ( unlike my Centrino laptop, totally different hardware ) and it crashes in the same exact way. now my guess is host compiler is somehow hosed , bad news for gcc 4.2 I guess. Regards, ismail
Re: Bitfield conversion bug in 4.2?
On Monday 19 March 2007 23:00:09 Eric Lemings wrote:
> Hi,
>
> The following code compiles fine in GCC 4.1.
>
> enum E { e };
> struct S {
> E v:5;
> };
> S s;
> int main() { if (!s.v) return 0; }
>
> In 4.2 (20070307), it gives the following error:
>
> test.cpp: In function 'int main()':
> test02.cpp:6: error: could not convert 's.S::v' to 'bool'
> test02.cpp:6: error: in arguument to unary !
>
> Is this a bug or new behavior? If the latter, what is this attributed
> to?
It should be fixed in 4.2 branch now, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31157 .
--
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)
Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer
pgpF7tmwa88It.pgp
Description: PGP signature
Re: Potential bug with g++ and OpenMP
On Monday 16 April 2007 20:02:33 Theodore Papadopoulo wrote: > The piece of code attached to this mail does not compile with 4.3.0 > 20070113 (sorry this is rather old, but that's what I had available). The > architecture (although not relevant IMHO) > is i686-pc-linux-gnu. > > [ Even though this is not relevant here, a similar error happens with > the redhat version gcc-4.1.1 (although the message is slightly > different and more confusing). ] > > I get the following error message: > > -> g++ -fopenmp Test.C > > Test.C: In constructor ‘R::R()’: > Test.C:18: error: invalid use of incomplete type ‘struct R::R()::B’ > Test.C:9: error: declaration of ‘struct R::R()::B’ FWIW it gives the same error with gcc version 4.2.0 20070317 (prerelease) and gcc version 4.3.0 20070414 (experimental) Regards, ismail -- Life is a game, and if you aren't in it to win, what the heck are you still doing here? -- Linus Torvalds (talking about open source development) signature.asc Description: This is a digitally signed message part.
Changes in C++ FE regarding pedwarns to be errors are harmful
Hi all, Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the latest trunk. Lets see with an example : [~]> cat test.cpp #define foo bar #define foo baz [~]> g++ -c test.cpp test.cpp:2:1: error: "foo" redefined test.cpp:1:1: error: this is the location of the previous definition I don't know the reasoning behind this change but this breaks many C++ programs unless -fpermissive is used. Why? Because everybody loves to install their own config.h (Python, libmp4v2 being nice examples) which just carelessly #define anything its asked for with ifndef ... endif . Now flash back to real world: this breaks any C++ application that uses Python, libmp4v2, libjpeg and possibly many others. And I think this is a real bad behaviour change and I am not sure if its worth all the trouble. So I am asking, would C++ FE maintainers would agree to revert this into a warning as in C FE now. I welcome and value your comments, so please speak up. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Tuesday 08 January 2008 23:34:13 tarihinde Joe Buck şunları yazmıştı: > There's certainly an argument that this change is ill-advised. However, > your statements in the last paragraph aren't true: most quality open > source projects have a "no warnings" rule (or at least try to eliminate > warnings), and most programmers know about #undef. Interesting assumption because knowing about #undef doesn't cut it because autoconf will happily #define without ifndef etc. > Since people have already built whole distros with the gcc from the trunk, > clearly theyare managing to build C++ applications that use > Python,libmp4v2, libjpeg etc. Yes true because they use -fpermissive which will let this error into a warning, which also suggests this change is not good. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Hi Manuel, Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları yazmıştı: > I implemented the change as the fix to a bug that was reported by > fellow (and more senior) GCC developers. Let me try to explain > (although, I hoped that it will be fairly clear from > gcc.gnu.org/gcc-4.3/changes.html). Yeah I know this change is documented at least. > We have a series of diagnostics that are important or required by the > standard (or both). Those are called pedwarns. It is an unfortunate > name for two reasons: 1) Not all pedwarns are enabled by -pedantic, > some are enabled by default; and 2) pedwarns can be either warnings or > errors, and what they are depends on command-line options and the > default of each front-end. In fact, pedwarnss are warnings by default > in the C front-end. But they are errors by default in the C++ > front-end unless you use -fpermissive so they are downgraded to > warnings. > > Before GCC 4.3, the C++ preprocessor was ignoring the default of the > C++ front-end. In fact, there was an inconsistence between the > settings of the C++ preprocessor and the settings of the C++ > front-end. It worked for a few things (-pedantic-errors worked fine), > but not for others (the default settings and the effect of > -fpermissive). The inconsistency was evident in the code and if you > played with combinations of -pedantic-errors and -fpermissive. Oh that clears up my confusion. So the right fix would be downgrading this redefinition problem to be pedwarn instead. But I see no point in creating a bug report if its just gonna be closed as invalid, so I hope we can discuss if its feasible to downgrade this error to be a pedwarn. What I see right now this distributions plug -fpermissive in and just go away. But I don't like workarounding gcc this way. I hope we can all agree that downrading this error to be a pedwarn is the correct way to go. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Wednesday 09 January 2008 00:51:32 tarihinde şunları yazmıştınız: > > Oh that clears up my confusion. So the right fix would be downgrading > > this redefinition problem to be pedwarn instead. But I see no point in > > creating a bug report if its just gonna be closed as invalid, so I hope > > we can discuss if its feasible to downgrade this error to be a pedwarn. > > > > What I see right now this distributions plug -fpermissive in and just go > > away. But I don't like workarounding gcc this way. I hope we can all > > agree that downrading this error to be a pedwarn is the correct way to > > go. > > I am sorry you didn't understand my email and didn't read it > completely. I tried my best. Sorry for misunderstanding, Andrew pointed out how I get it all wrong. Reading your mail again, you propose two possible fixes. Like you I am not in the position to see which would be the best solution. So we need C++ FE maintainers to comment if they agree with one of those fixes at least. Though for me the first solution looks more plausible. Thanks again, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Hi again, Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları yazmıştı: > For your particular example, you could open a regression bug against > 4.3 that says: > * '"foo' redefined" is not mandated by the standard or it is not > serious enough, so it should not be a pedwarn just a normal warning; > or Looks like this is actually mandated by standard :-( , thats what I am told on #gcc anyway :) > * "'foo' redefined", although mandated by the standard, is a nuisance > and irrelevant, it should only be active when -pedantic is given and > not by default. I am not sure if this is irrelevant for all cases, so the current behaviour looks correct. The right way would be fixing all those apps not installing their config.h and not pollute global namespace but thats a huge task given that many projects are affected. So for now I guess we'll have to stick to -fpermissive. Thanks for your time and patience. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Sunday 13 January 2008 17:41:03 tarihinde Gabriel Dos Reis şunları yazmıştı: > Ismail Dönmez <[EMAIL PROTECTED]> writes: > | Hi again, > | > | Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları > | > | yazmıştı: > | > For your particular example, you could open a regression bug against > | > 4.3 that says: > | > * '"foo' redefined" is not mandated by the standard or it is not > | > serious enough, so it should not be a pedwarn just a normal warning; > | > or > | > | Looks like this is actually mandated by standard :-( , thats what I am > | told on #gcc anyway :) > > #define foo bar > #define foo baz > > is asking for trouble -- one should look for fixing the source of that > inconsistency. That was just an example, real life testcase shows that problem stems from autoconf and its config.h. Projects end up defining things like HAVE_STDLIB_H twice which is not harmful at all but now causes an error if g++ is used. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı: > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > That was just an example, real life testcase shows that problem stems > > from autoconf and its config.h. Projects end up defining things like > > HAVE_STDLIB_H twice which is not harmful at all but now causes an error > > if g++ is used. > > Redefinitions with the same replacement list are not an error. Ok but that still doesn't cover the general use of #define PACKAGE_NAME foobar etc. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Sunday 13 January 2008 18:10:00 tarihinde Richard Guenther şunları yazmıştı: > On Jan 13, 2008 5:10 PM, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > > Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı: > > > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > > > That was just an example, real life testcase shows that problem stems > > > > from autoconf and its config.h. Projects end up defining things like > > > > HAVE_STDLIB_H twice which is not harmful at all but now causes an > > > > error if g++ is used. > > > > > > Redefinitions with the same replacement list are not an error. > > > > Ok but that still doesn't cover the general use of > > > > #define PACKAGE_NAME foobar > > > > etc. > > But that's just bugs that need to be fixed. I think we already agreed that this is just too many packages to fix and that this warning should only be an error with -pedantic. People already started adding #undef hacks to workaround this, others are building with -fpermissive. So we should should just let Manu finish up his patch and get a review as C++ FE maintainers agreed as well. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Sunday 13 January 2008 18:40:25 tarihinde Gabriel Dos Reis şunları yazmıştı: > | real life testcase shows that problem stems from > | autoconf and its config.h. Projects end up defining things like > | HAVE_STDLIB_H twice which is not harmful at all but now causes an error > | if g++ is used. > > The problem is that any semantics of the above -- that is not an error > or silent ignorance -- is order-dependent, which is worse to debug. True but lots of real world applications are falling apart, is it worth to break them all anyway? Also with -pedantic you will still get an error. I think its a good compromise. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Monday 14 January 2008 12:34:03 tarihinde Paolo Bonzini şunları yazmıştı: > Why not fixing the handful of packages with a /^#define PACKAGE/d, > instead of adding -fpermissive to the 50 users of those broken packages? That simple fix won't work, there might be installed headers which depend on definitions in config.h . This might be broken but there are just too many cases to fix. At least gcc should have warned in gcc 4.3 that this will be an error in next release and do this in 4.4 instead of breaking stuff en masse. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: inclhacks vs. latest autogen?
Hi,
Sunday 27 January 2008 16:37:37 tarihinde Dave Korn şunları yazmıştı:
> I'm using the very latest autogen:
>
> /gnu/gcc/obj $ autogen --version
> autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.9.4
>
> It doesn't seem to like our syntax in inclhacks.def any more:
>
> checking whether to enable maintainer-specific portions of Makefiles... yes
> configure: creating ./config.status
> /bin/sh ./config.status Makefile
> config.status: creating Makefile
> make[3]: Leaving directory
> `/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
> make[3]: Entering directory
> `/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
> cd /gnu/gcc/gcc/fixincludes ; /bin/sh ./genfixes
> AutoGen-ing fixincl.x
> autogen Error: Invalid input char '*' in inclhack.def on line 1088
> Makefile:128: *** [/gnu/gcc/gcc/fixincludes/fixincl.x] Error 1
>
> #0 /gnu/gcc/gcc/fixincludes/fixincl.x at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:128
> #1 fixincl.o at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:116
> #2 full-stamp at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:105
> #3 oneprocess at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:102
> #4 all at ??
> make[3]: Leaving directory
> `/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
> Command-line arguments:
> "all"
> Makefile:2784: *** [all-build-fixincludes] Error 2
>
> It's pointing at some globs in shell syntax:
>
> /gnu/gcc/obj $ cat -n /gnu/gcc/gcc/fixincludes/inclhack.def | grep -C3 1088
> 1085 */
> 1086 fix = {
> 1087 hackname = bsd_stdio_attrs_conflict;
> 1088 mach = *-*-*bsd*;
> 1089 mach = *-*-*darwin*;
> 1090 files = stdio.h;
> 1091 select= "^#define[ \t]*vfscanf[ \t]*__svfscanf[ \t]*$";
> /gnu/gcc/obj $
>
>
> This isn't a recent change, so I'm assuming autogen has changed. What
> versions are other people running?
I use the attached patch successfully, I didn't submit it yet because I
couldn't test it with older autogen. Testing is appreciated.
Regards,
ismail
--
Never learn by your mistakes, if you do you may never dare to try again.
--- fixincludes/inclhack.def 2007-12-29 02:14:35.0 +0200
+++ fixincludes/inclhack.def 2007-12-31 04:21:00.0 +0200
@@ -1085,8 +1085,8 @@
*/
fix = {
hackname = bsd_stdio_attrs_conflict;
-mach = *-*-*bsd*;
-mach = *-*-*darwin*;
+mach = "*-*-*bsd*";
+mach = "*-*-*darwin*";
files = stdio.h;
select= "^#define[ \t]*vfscanf[ \t]*__svfscanf[ \t]*$";
c_fix = format;
@@ -1303,7 +1303,7 @@
*/
fix = {
hackname = freebsd_gcc3_breakage;
-mach = *-*-freebsd*;
+mach = "*-*-freebsd*";
files = sys/cdefs.h;
select= '^#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7$';
bypass= '__GNUC__[ \t]*([>=]=[ \t]*[3-9]|>[ \t]*2)';
@@ -1320,7 +1320,7 @@
*/
fix = {
hackname = freebsd_gcc4_breakage;
-mach = *-*-freebsd*;
+mach = "*-*-freebsd*";
files = sys/cdefs.h;
select= '^#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7 \|\| __GNUC__ == 3$';
c_fix = format;
@@ -1619,7 +1619,7 @@
fix = {
hackname = hppa_hpux_fp_macros;
- mach = hppa*-hp-hpux11*;
+ mach = "hppa*-hp-hpux11*";
files = math.h;
select= "#[ \t]*define[ \t]*FP_NORMAL.*\n"
"#[ \t]*define[ \t]*FP_ZERO.*\n"
@@ -1728,7 +1728,7 @@
*/
fix = {
hackname = hpux11_abs;
-mach = ia64-hp-hpux11*;
+mach = "ia64-hp-hpux11*";
files = stdlib.h;
select= "ifndef _MATH_INCLUDED";
c_fix = format;
@@ -2670,7 +2670,7 @@
*/
fix = {
hackname = netbsd_c99_inline_1;
-mach = *-*-netbsd*;
+mach = "*-*-netbsd*";
files = signal.h;
select= "extern __inline int";
@@ -2683,7 +2683,7 @@
fix = {
hackname = netbsd_c99_inline_2;
-mach = *-*-netbsd*;
+mach = "*-*-netbsd*";
files = signal.h;
select= "#define _SIGINLINE extern __inline";
@@ -2705,7 +2705,7 @@
*/
fix = {
hackname = netbsd_extra_semicolon;
-mach = *-*-netbsd*;
+mach = "*-*-netbsd*";
files = sys/cdefs.h;
select= "#define[ \t]*__END_DECLS[ \t]*};";
Lots of new test failures on trunk due to unrecognizable insn
Hi all, regtesting on i686-apple-darwin9 I see : FAIL: gcc.c-torture/compile/pr33009.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr33009.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr33009.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/pr33009.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/pr33009.c -Os (test for excess errors) Log shows : /Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c: In function 'foo': /Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30: error: unrecognizable insn: (insn 177/Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. This is a new regression introduced under 48 hours. Any ideas? Regards, ismail -- UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. - Dennis Ritchie
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Hi,
On Thu, Mar 6, 2008 at 6:23 PM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> > H.J. Lu wrote:
> > >I agree with it. There is no right or wrong here Let's start from
> > >scratch and figure out
> > >what is the best way to handle this, assuming we are defining a new psABI.
>
> BTW, just tested icc and icc doesn't generate cld either (so it matches the
> new gcc behavior).
> char buf1[32], buf2[32];
> void bar (void);
> void foo (void)
> {
> __builtin_memset (buf1, 0, 32);
> bar ();
> __builtin_memset (buf2, 0, 32);
> }
Also LKML discussion pointed out that Solaris gets this right too.
Regards,
ismail
--
Never learn by your mistakes, if you do you may never dare to try again.
PR31264 on 4.2.0 branch
Hi, Fix for PR31264 doesn't seem to be checked into 4.2.0 branch which breaks MPlayer SVN compilation with : cc -I../libavcodec -I../libavformat -Wdeclaration-after-statement -I. -I.. -I../libavutil -O4 -march=pentium-m -mtune=pentium-m -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/include -I/usr/include/ -I/usr/include/SDL -D_REENTRANT -I/usr/include/freetype2 -I/usr/include -c -o demux_vqf.o demux_vqf.c demux_vqf.c: In function 'demux_open_vqf': demux_vqf.c:24: internal compiler error: in build_int_cst_wide, at tree.c:864 [/packages/mplayer]> cc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/pisi/gcc-4.2.0-23/work/gcc-4.2.0-20070430/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.2.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include --datadir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0 --mandir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/man --infodir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj --disable-libssp --disable-multilib --disable-nls --disable-werror --enable-clocale=gnu --enable-__cxa_atexit --enable-languages=c,c++,objc,fortran --enable-libstdcxx-allocator=new --enable-shared --enable-ssp --enable-threads=posix --enable-version-specific-runtime-libs --without-included-gettext --without-system-libunwind --with-system-zlib Thread model: posix gcc version 4.2.0 20070430 (prerelease) (Pardus Linux) It seems to be a one liner fix which is in mainline for some time, would it be ok to check it into 4.2.0 branch too? Regards, ismail -- Le mieux est l'ennemi du bien.
Re: PR31264 on 4.2.0 branch
On Tuesday 08 May 2007 14:35:26 Richard Guenther wrote: > On 5/8/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Fix for PR31264 doesn't seem to be checked into 4.2.0 branch which breaks > > MPlayer SVN compilation with : > > > > cc -I../libavcodec -I../libavformat -Wdeclaration-after-statement -I. > > -I.. -I../libavutil -O4 -march=pentium-m -mtune=pentium-m -pipe > > -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE > > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/include > > -I/usr/include/ -I/usr/include/SDL -D_REENTRANT > > -I/usr/include/freetype2 -I/usr/include -c -o demux_vqf.o demux_vqf.c > > demux_vqf.c: In function 'demux_open_vqf': > > demux_vqf.c:24: internal compiler error: in build_int_cst_wide, at > > tree.c:864 > > > > [/packages/mplayer]> cc -v > > Using built-in specs. > > Target: i686-pc-linux-gnu > > Configured > > with: /var/pisi/gcc-4.2.0-23/work/gcc-4.2.0-20070430/configure > > --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.2.0 > > --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include > > --datadir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0 > > --mandir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/man > > --infodir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/info > > --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include/g++-v > >3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj > > --disable-libssp --disable-multilib --disable-nls --disable-werror > > --enable-clocale=gnu --enable-__cxa_atexit > > --enable-languages=c,c++,objc,fortran --enable-libstdcxx-allocator=new > > --enable-shared --enable-ssp --enable-threads=posix > > --enable-version-specific-runtime-libs --without-included-gettext > > --without-system-libunwind --with-system-zlib Thread model: posix > > gcc version 4.2.0 20070430 (prerelease) (Pardus Linux) > > > > It seems to be a one liner fix which is in mainline for some time, would > > it be ok to check it into 4.2.0 branch too? > > Did you verify this is actually the same problem? Note that this PR > isn't marked as > broken on 4.2.0 or as a regression, so you should probably file a new > bugreport against 4.2.0 and link to the old one. The file and function is the same but the code looks different. I'll file a PR for 4.2.0 branch. Thanks. Regards, ismail -- Le mieux est l'ennemi du bien. signature.asc Description: This is a digitally signed message part.
Re: PR31264 on 4.2.0 branch
On Tuesday 08 May 2007 14:35:26 Richard Guenther wrote: [...] > Did you verify this is actually the same problem? Note that this PR > isn't marked as > broken on 4.2.0 or as a regression, so you should probably file a new > bugreport against 4.2.0 and link to the old one. Filed as PR31865. -- Le mieux est l'ennemi du bien. signature.asc Description: This is a digitally signed message part.
Re: I'm sorry, but this is unacceptable (union members and ctors)
On Monday 18 June 2007 04:23:35 michael.a wrote: > I'm sorry, but can anyone get through to any of these mirrors ever: > > http://gcc.gnu.org/mirrors.html The first mirror there, ftp://gd.tuwien.ac.at/gnu/gcc/ works fine. But next time please use gcc-help mailing list for such questions. Thanks. /ismail -- Perfect is the enemy of good
Re: Build failure of trunk on i686-pc-gnu-linux
Tuesday 20 November 2007 Tarihinde 03:12:35 yazmıştı: > Does someone provide a Git mirror of the GCC repository? Or a CVS > mirror? (With CVS you at least know what to expect...) Nice people over infradead.org does, http://git.infradead.org/?p=gcc.git;a=summary . To clone git clone git://git.infradead.org/gcc.git Regards, ismail -- Faith is believing what you know isn't so -- Mark Twain
Re: Infinite loop when trying to bootstrap trunk
Saturday 24 November 2007 Tarihinde 03:44:04 yazmıştı: > Hi all, > > I am trying to bootstrap gcc with the following config : [...] Sorry for the noise, looks like my snapshot tarball build from git repo using git-archive has some problems as the gcc-4.3-20071123 snapshot bootstrapped fine. Thanks, ismail -- Faith is believing what you know isn't so -- Mark Twain
Infinite loop when trying to bootstrap trunk
Hi all,
I am trying to bootstrap gcc with the following config :
../configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.3.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include
--datadir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0
--mandir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/man
--infodir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include/g++-v3
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj
--disable-libssp --disable-multilib --disable-nls --disable-werror
--disable-checking
--enable-clocale=gnu --enable-__cxa_atexit
--enable-languages=c,c++,fortran,objc,obj-c++,treelang
--enable-libstdcxx-allocator=new
--enable-shared --enable-ssp --enable-threads=posix
--enable-version-specific-runtime-libs --without-included-gettext
--without-system-libunwind --with-system-zlib
And build freezes at this point (stuck for ~1 hour and going on 2GB RAM Quad
Core Xeon ) :
/var/pisi/gcc-4.3.0_pre20071123-30/work/gcc-4.3.0_20071123/build-default-i686-pc-linux-gnu/./prev-gcc/xgcc
-B/var/pisi/gcc-4.3.0_pre20071123-30/work/gcc-4.3.0_20071123/build-default-i686-pc-linux-gnu/./prev-gcc/
-B/usr/i686-pc-linux-gnu/bin/ -c
-march=i686 -ftree-vectorize -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE
-fprofile-generate -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include
-I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/bid -I../libdecnumberinsn-attrtab.c -o
insn-attrtab.o
I attach gdb to build-default-i686-pc-linux-gnu/./prev-gcc/xgcc and break to
get this backtrace :
#0 0xa7fae410 in __kernel_vsyscall ()
#1 0xa7e5bf93 in waitpid () from /lib/libc.so.6
#2 0x0806608a in pex_wait (obj=0x808aca0, pid=966, status=0x80850d0,
time=0x0) at ../../libiberty/pex-unix.c:100
#3 0x0801 in pex_unix_wait (obj=0x808aca0, pid=966, status=0x80850d0,
time=0x0, done=0, errmsg=0xafc05a54, err=0xafc05a50)
at ../../libiberty/pex-unix.c:486
#4 0x08065d31 in pex_get_status_and_time (obj=0x808aca0, done=0,
errmsg=0xafc05a54, err=0xafc05a50) at ../../libiberty/pex-common.c:531
#5 0x08065d94 in pex_get_status (obj=0x808aca0, count=2, vector=0xafc05a80)
at ../../libiberty/pex-common.c:551
#6 0x0804c6b2 in execute () at ../../gcc/gcc.c:3012
#7 0x08050f44 in do_spec (
spec=0x806828c "%{E|M|MM:
%(trad_capable_cpp) %(cpp_options) %(cpp_debug_options)} %{!E:%{!M:
%{!MM: %{traditional|ftraditional:%eGNU C no longer
supports -traditional without -E} %{!combine:\t %{sa"...)
at ../../gcc/gcc.c:4436
#8 0x0805654e in main (argc=36, argv=0xafc05dc4) at ../../gcc/gcc.c:6684
For information, 2 days old trunk bootstrapped fine. Any idea is appreciated.
Regards,
ismail
--
Faith is believing what you know isn't so -- Mark Twain
Re: Infinite loop when trying to bootstrap trunk
Saturday 24 November 2007 Tarihinde 03:44:04 yazmıştı:
> Hi all,
>
> I am trying to bootstrap gcc with the following config :
>
> ../configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.3.0
> --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include
> --datadir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0
> --mandir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/man
> --infodir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/info
> --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include/g++-v3
> --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj
> --disable-libssp --disable-multilib --disable-nls --disable-werror
> --disable-checking --enable-clocale=gnu --enable-__cxa_atexit
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang
> --enable-libstdcxx-allocator=new --enable-shared --enable-ssp
> --enable-threads=posix --enable-version-specific-runtime-libs
> --without-included-gettext --without-system-libunwind --with-system-zlib
>
> And build freezes at this point (stuck for ~1 hour and going on 2GB RAM
> Quad Core Xeon ) :
>
> /var/pisi/gcc-4.3.0_pre20071123-30/work/gcc-4.3.0_20071123/build-default-i6
>86-pc-linux-gnu/./prev-gcc/xgcc
> -B/var/pisi/gcc-4.3.0_pre20071123-30/work/gcc-4.3.0_20071123/build-default-
>i686-pc-linux-gnu/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -march=i686
> -ftree-vectorize -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE
> -fprofile-generate -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
> -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
> -I../../gcc/../libdecnumber/bid -I../libdecnumberinsn-attrtab.c -o
> insn-attrtab.o
>
>
> I attach gdb to build-default-i686-pc-linux-gnu/./prev-gcc/xgcc and break
> to get this backtrace :
>
> #0 0xa7fae410 in __kernel_vsyscall ()
> #1 0xa7e5bf93 in waitpid () from /lib/libc.so.6
> #2 0x0806608a in pex_wait (obj=0x808aca0, pid=966, status=0x80850d0,
> time=0x0) at ../../libiberty/pex-unix.c:100
> #3 0x0801 in pex_unix_wait (obj=0x808aca0, pid=966, status=0x80850d0,
> time=0x0, done=0, errmsg=0xafc05a54, err=0xafc05a50)
> at ../../libiberty/pex-unix.c:486
> #4 0x08065d31 in pex_get_status_and_time (obj=0x808aca0, done=0,
> errmsg=0xafc05a54, err=0xafc05a50) at ../../libiberty/pex-common.c:531
> #5 0x08065d94 in pex_get_status (obj=0x808aca0, count=2,
> vector=0xafc05a80) at ../../libiberty/pex-common.c:551
> #6 0x0804c6b2 in execute () at ../../gcc/gcc.c:3012
> #7 0x08050f44 in do_spec (
> spec=0x806828c "%{E|M|MM:
> %(trad_capable_cpp) %(cpp_options) %(cpp_debug_options)} %{!E:%{!M:
> %{!MM: %{traditional|ftraditional:%eGNU C no longer
> supports -traditional without -E} %{!combine:\t %{sa"...)
> at ../../gcc/gcc.c:4436
> #8 0x0805654e in main (argc=36, argv=0xafc05dc4) at ../../gcc/gcc.c:6684
Ok looks like this is not a heisenbug, I left the gcc bootstrap going on and
it took 4+ hours to compile insn-attrtab.c on this machine which looks really
bad as it takes 2-3 minutes on my laptop.
Any idea where to look?
Regards,
ismail
--
Faith is believing what you know isn't so -- Mark Twain
Re: svn trunk reaches nearly 1 GiB!!! That massive!!!
Wednesday 28 November 2007 Tarihinde 04:04:18 yazmıştı: > $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc > $ du -s . > 1044451 . > $ > > It's 1'069'517'824 characters made from keyboards and generators!!! > > That massive!!! And slower checkout after several minutes!!! > > Is not there any another solution to reduce this massive quantity > for the most recent part of the trunk of the tree instead of full trunk? git clone --depth 100 git://git.infradead.org/gcc.git should give around ~50mb repository with usable trunk. This is all thanks to Bernardo Innocenti for setting up an up-to-date gcc git repo. P.S: Please cut down on the usage of exclamation mark. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Git and GCC
Wednesday 05 December 2007 21:08:41 Daniel Berlin yazmıştı: > So I tried a full history conversion using git-svn of the gcc > repository (IE every trunk revision from 1-HEAD as of yesterday) > The git-svn import was done using repacks every 1000 revisions. > After it finished, I used git-gc --aggressive --prune. Two hours > later, it finished. > The final size after this is 1.5 gig for all of the history of gcc for > just trunk. > > [EMAIL PROTECTED]:/compilerstuff/gitgcc/gccrepo/.git/objects/pack$ ls -trl > total 1568899 > -r--r--r-- 1 dberlin dberlin 1585972834 2007-12-05 14:01 > pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.pack > -r--r--r-- 1 dberlin dberlin 19008488 2007-12-05 14:01 > pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.idx > > This is 3x bigger than hg *and* hg doesn't require me to waste my life > repacking every so often. > The hg operations run roughly as fast as the git ones I think this (gcc HG repo) is very good but only problem is its not always in sync with SVN, it would really rock if a post svn commit hook would sync hg repo. Thanks for doing this anyhow. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Git and GCC
Thursday 06 December 2007 13:57:06 Johannes Schindelin yazmıştı: [...] > So I fully expect an issue like Daniel's to be resolved in a matter of > minutes on the git list, if the OP gives us a chance. If we are not even > Cc'ed, you are completely right, she or he probably does not want the > issue to be resolved. Lets be fair about this, Ollie Wild already sent a mail about git-svn disk usage and there is no concrete solution yet, though it seems the bottleneck is known. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Git and GCC
Thursday 06 December 2007 21:28:59 Vincent Lefevre yazmıştı: > On 2007-12-06 10:15:17 -0800, Ian Lance Taylor wrote: > > Distributed version systems like git or Mercurial have some advantages > > over Subversion. > > It's surprising that you don't mention svk, which is based on top > of Subversion[*]. Has anyone tried? Is there any problem with it? > > [*] You have currently an obvious advantage here. Last time I tried SVK it was slow and buggy. I wouldn't recommend it. /ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Objective-C 2.0 in GCC
Hi Mike, Tuesday 18 December 2007 20:04:45 tarihinde Mike Stump şunları yazmıştı: > On Dec 17, 2007, at 9:45 PM, Sven Herzberg wrote: > > I was just browsing the gcc-list to see if there are any updates on > > the Objective-C 2.0 extensions. Can you please send and email to the > > gcc-list with the current state? > > I hope to be able to contribute them in the next year, but exactly > when remains uncertain. I hope to know more about timing toward the > front of next year. Sorry I don't have anything more specific to say. Any schedule for fixing Obj-C++ regressions on mainline? Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Objective-C 2.0 in GCC
Tuesday 18 December 2007 20:47:29 tarihinde Mike Stump şunları yazmıştı: > On Dec 18, 2007, at 10:08 AM, Ismail Dönmez wrote: > > Any schedule for fixing Obj-C++ regressions on mainline? > > Same answer. My hope would be that people that introduce regressions > would fix them... We were talking about it the other day and its mentioned some regressions exist since the introduction of Obj-C++ support. Anyway hope you resolve non-technical issues without much sacrifise. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: -Wparentheses lumps too much together
Wednesday 19 December 2007 22:11:22 tarihinde Doug Gregor şunları yazmıştı: > On Dec 19, 2007 3:02 PM, <[EMAIL PROTECTED]> wrote: > > One last point. In looking for the rationale behind this warning, I > > searched for examples of it. I didn't find any discussion on this list. > > What I did find were many examples of people rototilling perfectly fine > > code, "improving" it by adding unneeded parenthesis specifically so that > > it would compile cleanly with -Wall. I think that's a shame: a waste of > > effort at best. > > > > I ask you, please, to consider splitting advice about operator precedence > > from advice about mismatched if/else branches, and to exclude advice > > about making sure && is parenthesized ahead of || from -Wall. -Wall is > > the standard for "good, clean code" in many projects. This warning > > doesn't belong there. > > For what it is worth, I completely agree with everything you have said > here. This warning oversteps the bounds of what -Wall should do, and > forces people to change perfectly good, clean code. Operator > precedence is an important concept that any C or C++ programmer should > know, and we're not helping anyone by pretending that programmer's > won't understand this concept. > > We should certainly remove the warning from -Wall, and perhaps remove > it entirely. Agreed, for example it has lots of useless warnings when compiling ffmpeg. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk
Hi all, I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day and I see 3 tests fail : math/test-float math/test-ildoubl math/test-ifloat The erorrs are all similar : Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i Result: is: 0.e+00 0x0.p+0 should be: 1.57079637050628662109e+00 0x1.921fb600p+0 difference: 1.57079637050628662109e+00 0x1.921fb600p+0 ulp : 13176795. max.ulp : 0. All of the imaginary part checks fail, with the help of GFortran maintainers we identified 2 testcases which fail with glibc 2.7 when compiled with gcc 4.3 trunk [0] . This problem also causes 32 unexpected failures on gfortran regression tests. So I wonder if you guys can help me debug this, I checked out libc sources but its mostly assembly stuff for math functions. Maybe Jakub has an idea, not sure. Any help/comment appreciated. [0] http://sourceware.org/bugzilla/show_bug.cgi?id=5490 Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk
Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları yazmıştı: > Hi all, > > I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day > and I see 3 tests fail : > > math/test-float > math/test-ildoubl > math/test-ifloat > > The erorrs are all similar : > > Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i > Result: > is: 0.e+00 0x0.p+0 > should be: 1.57079637050628662109e+00 0x1.921fb600p+0 > difference: 1.57079637050628662109e+00 0x1.921fb600p+0 > ulp : 13176795. > max.ulp : 0. All these failures are gone when glibc is compiled with -O2 instead of -O3 but there are still 4 regressions : math/test-ildoubl Usual math problem : testing long double (inline functions) Failure: Test: expm1 (1) == M_El - 1.0 Result: is: 1.71828182845904523532e+00 0xd.bf0a8b1457695350p-3 should be: 1.71828182845904523543e+00 0xd.bf0a8b1457695360p-3 difference: 1.08420217248550443401e-19 0x8.p-66 ulp : 1. max.ulp : 0. Maximal error of `expm1' is : 1 ulp accepted: 0 ulp libio/tst-fopenloc2 libio/tst-fopenloc These two seems to be a new gcc regression, they crash when compiled with gcc trunk. elf/check-localplt These seems to be less harmful, shows memalign is missing from expected output. Any ideas appreciated. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk
Friday 28 December 2007 16:20:52 tarihinde Ismail Dönmez şunları yazmıştı: > libio/tst-fopenloc2 > libio/tst-fopenloc > > These two seems to be a new gcc regression, they crash when compiled with > gcc trunk. Ok I identified that commit 130788 [0] broke these testcases , the same commit seems to be the cause for PR34465 . [0] http://gcc.gnu.org/viewcvs?view=rev&revision=130788 Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk
Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları yazmıştı: > Hi all, > > I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day > and I see 3 tests fail : > > math/test-float > math/test-ildoubl > math/test-ifloat > > The erorrs are all similar : > > Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i > Result: > is: 0.e+00 0x0.p+0 > should be: 1.57079637050628662109e+00 0x1.921fb600p+0 > difference: 1.57079637050628662109e+00 0x1.921fb600p+0 > ulp : 13176795. > max.ulp : 0. Replying to myself once again, these failures are due to -fgcse-after-reload flag, -O3 -fno-gcse-after-reload cures this. Any tips on how to debug this? Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk
Saturday 29 December 2007 19:49:13 tarihinde Ian Lance Taylor şunları yazmıştı: > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları yazmıştı: > > > Hi all, > > > > > > I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every > > > day and I see 3 tests fail : > > > > > > math/test-float > > > math/test-ildoubl > > > math/test-ifloat > > > > > > The erorrs are all similar : > > > > > > Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i > > > Result: > > > is: 0.e+00 0x0.p+0 > > > should be: 1.57079637050628662109e+00 0x1.921fb600p+0 > > > difference: 1.57079637050628662109e+00 0x1.921fb600p+0 > > > ulp : 13176795. > > > max.ulp : 0. > > > > Replying to myself once again, these failures are due to > > -fgcse-after-reload flag, -O3 -fno-gcse-after-reload cures this. Any tips > > on how to debug this? > > Generic advice to start: compile with -da to get all the RTL dump > files. Compare the dump files immediately before and after > gcse-after-reload and see what changed. Set breakpoints on > validate_change or make_insn_raw as appropriate for the changes. Walk > up the stack and see what the code is doing. The file in question is > postreload-gcse.c, which is relatively self-contained. > > Of course it is moderately likely that the bug is not in > gcse-after-reload, and is in some other pass generating incorrect > information. Still, finding the problem in gcse-after-reload is a > good start. Thanks I'll try, this is all new to me so its rather likely to be slow progress. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
