Re: Warning annoyances in list_read.c
> > If he added a new option affecting libgfortran, then he should > > fix up libgfortran. > > He didn't add the warning to specifically annoy fortran developers. > It is trivial to add seven gcc_fallthrough() or breaks for someone who > knows the code and the person who added the warning obviously doesn't. The following patch fixes the warnings --- ../_clean/libgfortran/io/list_read.c2017-03-25 20:42:40.0 +0100 +++ libgfortran/io/list_read.c 2017-03-27 12:06:10.0 +0200 @@ -51,7 +51,8 @@ typedef unsigned char uchar; #define CASE_DIGITS case '0': case '1': case '2': case '3': case '4': \ case '5': case '6': case '7': case '8': case '9' -#define CASE_SEPARATORS case ' ': case ',': case '/': case '\n': \ +#define CASE_SEPARATORS /* Fall through. */ \ + case ' ': case ',': case '/': case '\n': \ case '\t': case '\r': case ';' /* This macro assumes that we're operating on a variable. */ Indeed before applying this patch, someone will have to check that the warnings do not occur because of missing breaks. Note that putting /* Fall through. */ before the use of the macro CASE_SEPARATORS does not work. Is it a (known) bug? Dominique
Re: GCC 5.4 Release Candidate available from gcc.gnu.org
Richard,
> … If all goes well I'd like to release GCC 5.4 at the beginning of next
> week.
Would it be possible to apply the following patch
--- ../5.4.0-RC/gcc/testsuite/c-c++-common/asan/sanity-check-pure-c-1.c
2012-12-13 00:04:22.0 +0100
+++ ../5_work/gcc/testsuite/c-c++-common/asan/sanity-check-pure-c-1.c
2015-10-23 09:30:02.0 +0200
@@ -10,7 +10,7 @@ int main() {
}
/* { dg-output "heap-use-after-free.*(\n|\r\n|\r)" } */
-/* { dg-output "#0 \[^\n\r]*(in
_*(interceptor_|)free|\[(\])\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "#0 \[^\n\r]*(in
_*(interceptor_|wrap_)free|\[(\])\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "#1 \[^\n\r]*(in _*main
(\[^\n\r]*sanity-check-pure-c-1.c:8|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r)" } */
-/* { dg-output "#0 \[^\n\r]*(in
_*(interceptor_|)malloc|\[(\])\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "#0 \[^\n\r]*(in
_*(interceptor_|wrap_)malloc|\[(\])\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "#1 \[^\n\r]*(in _*main
(\[^\n\r]*sanity-check-pure-c-1.c:7|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r)" }
*/
in order to fix the failures
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c *
on darwin?
TIA
Dominique
Re: bug report : gfortran E edit descriptor
> I have an trouble in E edit descriptor of gfortran. > This is a example. > (source file: test.f95) >program test >implicit none >real a,b >a=135.0 >b=1737.5 >write(*,*)a,b >write(*,'(e9.3,a,f7.1)')a,' ',b >write(*,'(1pe9.3,a,f7.1)')a,' ',b >end > (compile) > gfortran test.f95 > (execute) > a.exe > (result) >135.00 1737.5 > 0.135E+03 1737.5 > 1.350E+02 17375.0 ( <--- wrong value ) > > I suppose there are some bugs in the E edit descriptor. IIRC (1) the P ‘modifier’ applies to all the subsequent numeric descriptors, (2) when rP is applied to an F descriptor, the value is ‘multiplied’ by 10**r. write(*,'(e9.3,a,1pf7.1)')a,' ‘,b gives 0.135E+03 17375.0 and write(*,'(1pe9.3,a,e9.3)')a,' ‘,b gives 1.350E+02 1.738E+03 So I think gfortran is right. > I like Fortran and I wish gfortran of GCC to be better compiler. > best regards. If you want to contribute, discussion about gfortran should go to fort...@gcc.gnu.org and bug should be filed in bugzilla. Cheers, Dominique
Re: gfortran: enabling specific warnings for a used but not set variable, and a set but not used variable
This is tracked by bugzilla pr61181 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61181). As a general comment post concerning gfortran should go to fort...@gcc.gnu.org. Cheers, Dominique
Re: Action stamps
> For Jakub or anyone else wanting a key to associate a file with a commit, > they can decide for themselves > what date format they want to use and whether to bother with the user id. I > would think that if he is only > interested in commits on the trunk (and so should use log --first-parent), > the timestamp is sufficient. I share Jakub’s concern about having access to an increasing labeling of the revisions. What would be the replacement of « svn update -r »? TIA Dominique
Re: debug-early branch merged into mainline
This caused https://gcc.gnu.org/ml/gcc-bugs/2015-06/msg00602.html. TIA Dominique
Re: Regular darwin builds
Due to pr64625 I have looked more carefully to your logs and I did not see any entry for libgomp. Is it expected? TIA Dominique > Le 15 déc. 2014 à 22:11, FX a écrit : > > Hi all, > > I’ve set up daily builds and regtests on a darwin box. The results should > appear directly on gcc-testresults > (https://gcc.gnu.org/ml/gcc-testresults/current/). > This should, in the future, help track down regressions affecting darwin > (PIC-related, in particular!). > > The hardware is new, the OS is the latest and greatest > (x86_64-apple-darwin14), and will be updated to keep it that way. However, > it’s not very powerful (it’s a Mac Mini). Bootstrap (C, C++, Obj-C, Obj-C++, > Fortran, Java, LTO) takes about 2 hours, regtesting both 32 and 64-bit takes > a bit over 3 hours. > > I plan to schedule it for: > > - daily bootstrap + regtest of trunk > - weekly bootstrap of latest release branch (currently 4.9) > > If you have other ideas, I’m open to suggestions. > > FX
Re: Regular darwin builds
My patch is different and I am attaching it (it is quite old, so it may not apply cleanly). The problem for more evolved form is that *.dSYM are directories and ASAICT there is no command in derange to remove them. At least my patch tracks all the locations giving *.dSYM. Dominique patch-dsym3 Description: Binary data > Le 16 déc. 2014 à 21:55, Mike Stump a écrit : > > On Dec 16, 2014, at 12:46 PM, Iain Sandoe wrote: >> >> On 16 Dec 2014, at 20:40, Dominique d'Humières wrote: >>> >>>> Another testsuite issue on darwin is that testsuite doesn’t clean up the >>>> .dSYM directories it generates. This gets really annoying on my autotester >>>> :( >>> >>> I have a patch for that, but Iain does not like it!-( >> >> Hmm .. I like the patch in principle, >> ... the problem is that it doesn't clean up when one does cross-testing or >> installed testing - so it needed tweaking to use the right approach to >> deleting files on the remote/host - we (erm, probably I, in truth) never got >> around to finding the right recipe. >> >> Might I suggest pulling it out of storage - and getting a review, perhaps >> from Mike who might be able to identify the best place to do the job. > > I won’t be too picky. if is_native cleanup_native isn't unreasonable. > > https://gcc.gnu.org/ml/gcc/2012-03/msg00364.html > > So, I can’t help but think, we don’t need to slow the world down, and we can > just do a find . \*.DSYM -exec rm type of thing at the end. Simple, easy, > works for native and the old cross is native ppc builds on x86. Life goes on.
Re: Regular darwin builds
> Another testsuite issue on darwin is that testsuite doesn’t clean up the > .dSYM directories it generates. This gets really annoying on my autotester :( I have a patch for that, but Iain does not like it!-( Dominique
Re: Regular darwin builds
Is it again the difference between testing before or after install? Dominique > Le 16 déc. 2014 à 20:50, Iain Sandoe a écrit : > > > On 16 Dec 2014, at 19:38, Dominique d'Humières wrote: > >> Looking at your results for gcc 5.0, I see a lot of gcc.dg/ubsan/* failures >> I don’t see in my tests. Any idea why? > > I think that there will be ubsan fails until the library is installed (which > implies that the testing is not setting the right DYLD_LIBRARY_PATH). > > Iain
Re: Regular darwin builds
Hi FX, Thanks for doing that. Looking at your results for gcc 5.0, I see a lot of gcc.dg/ubsan/* failures I don’t see in my tests. Any idea why? Dominique > Le 15 déc. 2014 à 22:11, FX a écrit : > > Hi all, > > I’ve set up daily builds and regtests on a darwin box. The results should > appear directly on gcc-testresults > (https://gcc.gnu.org/ml/gcc-testresults/current/). > This should, in the future, help track down regressions affecting darwin > (PIC-related, in particular!). > > The hardware is new, the OS is the latest and greatest > (x86_64-apple-darwin14), and will be updated to keep it that way. However, > it’s not very powerful (it’s a Mac Mini). Bootstrap (C, C++, Obj-C, Obj-C++, > Fortran, Java, LTO) takes about 2 hours, regtesting both 32 and 64-bit takes > a bit over 3 hours. > > I plan to schedule it for: > > - daily bootstrap + regtest of trunk > - weekly bootstrap of latest release branch (currently 4.9) > > If you have other ideas, I’m open to suggestions. > > FX
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
This was for x86_64-apple-darwin14. The patch also works for x86_64-apple-darwin10. Dominique > Le 6 déc. 2014 à 01:49, Dominique d'Humières a écrit : > > Bootstrap just finished with the patch. > > Thanks, > > Dominique
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
Bootstrap just finished with the patch. Thanks, Dominique > Le 5 déc. 2014 à 23:47, Jakub Jelinek a écrit : > > On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote: >>> As I've tried to explain, that is IMHO wrong though. >>> If what you are after is the -B stuff too, then perhaps: >>> ... >> >> Sorry but it does not work: > > Sorry, make that (just removed 4x ' in each file): > > 2014-12-05 Jakub Jelinek > > PR bootstrap/64023 > * Makefile.tpl (EXTRA_TARGET_FLAGS): Set STAGE1_LDFLAGS > to POSTSTAGE1_LDFLAGS and STAGE1_LIBS to POSTSTAGE1_LIBS. > Add -B to libstdc++-v3/src/.libs and libstdc++-v3/libsupc++/.libs > to CXX. > * Makefile.in: Regenerated. > > --- Makefile.tpl.jj 2014-11-12 09:31:59.0 +0100 > +++ Makefile.tpl 2014-12-05 21:12:21.486031062 +0100 > @@ -641,7 +641,9 @@ EXTRA_TARGET_FLAGS = \ > 'AS=$(COMPILER_AS_FOR_TARGET)' \ > 'CC=$$(CC_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ > 'CFLAGS=$$(CFLAGS_FOR_TARGET)' \ > - 'CXX=$$(CXX_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ > + 'CXX=$$(CXX_FOR_TARGET) -B$$r/$$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ > + -B$$r/$$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \ > + $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ > 'CXXFLAGS=$$(CXXFLAGS_FOR_TARGET)' \ > 'DLLTOOL=$$(DLLTOOL_FOR_TARGET)' \ > 'GCJ=$$(GCJ_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ > @@ -659,6 +661,8 @@ EXTRA_TARGET_FLAGS = \ > 'WINDRES=$$(WINDRES_FOR_TARGET)' \ > 'WINDMC=$$(WINDMC_FOR_TARGET)' \ > 'XGCC_FLAGS_FOR_TARGET=$(XGCC_FLAGS_FOR_TARGET)' \ > + 'STAGE1_LDFLAGS=$$(POSTSTAGE1_LDFLAGS)' \ > + 'STAGE1_LIBS=$$(POSTSTAGE1_LIBS)' \ > "TFLAGS=$$TFLAGS" > > TARGET_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS) $(EXTRA_TARGET_FLAGS) > --- Makefile.in.jj2014-11-28 14:40:52.0 +0100 > +++ Makefile.in 2014-12-05 21:11:48.276616008 +0100 > @@ -835,7 +835,9 @@ EXTRA_TARGET_FLAGS = \ > 'AS=$(COMPILER_AS_FOR_TARGET)' \ > 'CC=$$(CC_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ > 'CFLAGS=$$(CFLAGS_FOR_TARGET)' \ > - 'CXX=$$(CXX_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ > + 'CXX=$$(CXX_FOR_TARGET) -B$$r/$$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \ > + -B$$r/$$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \ > + $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ > 'CXXFLAGS=$$(CXXFLAGS_FOR_TARGET)' \ > 'DLLTOOL=$$(DLLTOOL_FOR_TARGET)' \ > 'GCJ=$$(GCJ_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ > @@ -853,6 +855,8 @@ EXTRA_TARGET_FLAGS = \ > 'WINDRES=$$(WINDRES_FOR_TARGET)' \ > 'WINDMC=$$(WINDMC_FOR_TARGET)' \ > 'XGCC_FLAGS_FOR_TARGET=$(XGCC_FLAGS_FOR_TARGET)' \ > + 'STAGE1_LDFLAGS=$$(POSTSTAGE1_LDFLAGS)' \ > + 'STAGE1_LIBS=$$(POSTSTAGE1_LIBS)' \ > "TFLAGS=$$TFLAGS" > > TARGET_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS) $(EXTRA_TARGET_FLAGS) > > Jakub
