Re: Bootstrap failure for current gcc trunk on cygwin: in set_curr_insn_source_location, at cfglayout.c:284
I presume that this: -I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber ../../trunk/gcc/gimplify.c -o gimplify.o ../../trunk/gcc/gimplify.c: In function 'create_tmp_var_name': ../../trunk/gcc/gimplify.c:431: internal compiler error: in set_curr_insn_source_location, at cfglayout.c:284 on x86_ia64/fc5 is not a coincidence? Paul -- "Success is the ability to go from one failure to another with no loss of enthusiasm." - Winston Churchill
Re: Bootstrap failure for current gcc trunk on cygwin: in set_curr_insn_source_location, at cfglayout.c:284
It happens! It also meant that I got to bed early:) Thanks Paul On 4/24/07, Jan Hubicka <[EMAIL PROTECTED]> wrote: > On 4/23/07, Paul Richard Thomas <[EMAIL PROTECTED]> wrote: > >on x86_ia64/fc5 is not a coincidence? > > More over, there were a lot of targets by this patch because they > would call insn_locators_initialize when generating the thunks (x86 > did not because it uses text based thunks and not RTL based thunks). I've reverted the patch, so it should be OK now. My apologizes for the breakage. Honza > > -- Pinski -- "Success is the ability to go from one failure to another with no loss of enthusiasm." - Winston Churchill
Re: [RFC] Fortran: How to handle allocatable polymorphic components with OpenMPv5/OpenACCv3
Dear Tobias, I do not see any problem with adding to the vtable; especially with your suggestion of assigning it to a generic function with a function pointer argument. This might be valuable for other future needs, other than OpenMP/OpenACC/coarrays. I would suggest that 'this' and the function pointer are sufficient arguments. With best regards Paul On 13 June 2014 22:57, Tobias Burnus wrote: > This email is probably a bit premature as the OpenMPv4.0 and OpenACC 2.0a > specs do not seem to handle Fortran 2003's polymorphic variables. However, > as I am currently thinking how to handle a similar problem for Fortran's > coarray, I want to raise the issue for OpenMP/OpenACC to see whether > something should be done in gfortran to solve the problem for OpenMP/OpenACC > and coarrays at the same time. For coarrays, see also > https://gcc.gnu.org/ml/fortran/2014-06/msg00132.html > > The issue described below occurs when one needs to copy variables which are > polymorphic or contain components which are polymorphic. That applies both > to copying them to a thread-local variable or with offloading to the memory > of an accelerator. > > In case of Fortran, doing an assignment of a derived type (record type) will > also copy the allocatable components, which in turn might have again > allocatable components. For nonpolymorphic variables, one can simply > recursively walk through all components and do the copying that way. That's > how the Fortran FE does for intrinsic assignments – and what Jakub's > recently committed OpenMPv4.0 patch does. > > However, how to handle it for polymorphic types? In case of the intrinsic > assignment, the variable/component has a pointer to a virtual table, which > contains a function pointer to the type's copy function. > > But how to handle it in case of OpenMP (v4.1?, v5.0?)? One could augment the > vtable by a function pointer to an function which handles this for > OpenMP/OpenACC, probably by calling some libgomp library function. In case > of coarrays, I have (see link above) the same problem: I need to add library > calls to transfer allocatable components forth to and back from a remote > process. Thus, I am also thinking of adding a new entry to the virtual table > > Another issue arises when one mixes code with and without > -fopenmp/-facc/-fcoarray=lib. One either has to generate the vtable entry > and function unconditionally – or only with that option, but then one might > run into corner cases, where the function is not available. > > One option* I see is some kind of generic function, which takes as > additional argument a function pointer; this pointer could point either to > libgomp or to the coarray library (for -fcoarray=lib), depending on the > caller. In addition, it avoids issues with dependencies on the called > library. > > What do you think? Would this be a sensible way for > OpenMPv5/OpenACCv3/coarrays? Or do you see pitfalls with this approach? One > additional issue would be the way the arguments are passed, which one would > have to agree on. > > Comments? Suggestions? Questions? > > Tobias > > * The other option is to generate specific functions, but that is not only > less flexible but also runs into issues like library dependencies. Those can > be solved with weak symbols and stubs, but that's also not very elegant. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [RFC] -Weverything
Hi Thomas, Thanks for initiating this discussion. The responses are very useful. That said, wouldn't a -ffix-everything option be more useful? :-) Cheers Paul On Wed, 23 Jan 2019 at 13:27, Thomas König wrote: > > > > > Am 23.01.2019 um 12:36 schrieb Jonathan Wakely : > > > > When there are new warnings that aren't enabled by -Wall -Wextra, > > there's probably a reason they aren't enabled by default. > > -Wconversion-extra is an example of such a warning. > > It catches a very common error people make in Fortran, see > https://gcc.gnu.org/ml/fortran/2019-01/msg00178.html for a false bug report > which it would have caught early. > > We left it out of -Wextra because people felt it was too noisy. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: GCC 4.5 Status Report (2010-03-15)
Richi, Steven, >> To be fair the people of that company do not expose bugs proportional >> to their headcount either. > > Neither do I, and yet I try to help ;-) Now, now, you two :-) Paul
Re: Errors on your web page
Mikael and Steve, > Do you really think they will change their webpage to one that > explicitly states that their compiler has a competitor with comparable > features, which is at least as fast, supports more platforms and is > available for free? > I would be very surprised if they do. > I think that they might. Their webpage is so lamentably deficient that anybody serious about buying a compiler would wonder why they are being so "economical with the truth". Also, I cannot see why it would be their interest not to be honest. Their compiler works fine, is nicely packaged an has quite a competitive performance, as the latest Polyhedron comparisons show. They even give the impression that an open source plotting package is specific to their compiler. Incidentally, I am so wedded to DISLIN, for which the gfotran version is free, that I have never tried to build plplot; has any body tried it? Cheers Paul
Re: GCC 4.3.3 Status Report (2009-01-17), branch frozen for release
Richard, I would like to revert the cause of the regression reported yesterday in http://gcc.gnu.org/ml/fortran/2009-01/msg00197.html - I'll do it in the next hour, if that is alright? Cheers Paul On Sat, Jan 17, 2009 at 12:03 AM, Richard Guenther wrote: > > It's not my turn to send a status report, but as I plan doing a release > candidate for GCC 4.3.3 soon I thought a status report for that would > be in order. > > Status > == > > The GCC 4.3 branch is now frozen in preparation for a release candidate > for the GCC 4.3.3 release. When the branch is unfrozen again I will > send a message stating so. All checkins to the branch require approval > by a release manager now. > > There is a single regression that shows up as P1, but as it is not > a regression on the branch (but from the tree-ssa merge) it does not > block the GCC 4.3.3 release (but the bug priority is considered the priority > for the newest release the bug is a regression for). > > I am not aware of any issues blocking an immediate release of GCC 4.3.3. > Please make me aware of such issues by replying to this mail and/or > by CCing me on bugzillas that are regressions on the GCC 4.3 branch > but are not marked as such (a regression on the GCC 4.3 branch is a > bug with a testcase that worked in a previous GCC 4.3 based release > but fails on the top of the GCC 4.3 branch). > > > Quality Data > > > Priority # Change from Last Report > --- --- > P11 - 4 > P2 137 + 7 > P32 - 1 > --- --- > Total 140 + 2 > > > The next status report will be sent by me. > > Richard. > -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: GCC 4.3.3 Status Report (2009-01-17), branch frozen for release
> Richard, > > I would like to revert the cause of the regression reported yesterday > in http://gcc.gnu.org/ml/fortran/2009-01/msg00197.html - I'll do it in > the next hour, if that is alright? > > Cheers > > Paul Duly reverted on trunk and 4.3. Paul
Re: Failure building GFortran (Cygwin)
Angelo,
I have seen this too - I thought that it was due to the VERY strange
way in which I was doing the build:-)
Andd 'const' to strsignal.c:408 and the build will go through.
Paul
On Sat, Jun 28, 2008 at 2:09 PM, Angelo Graziosi
<[EMAIL PROTECTED]> wrote:
> Last week I flagged some problems with 4.4-20080620 snapshot [1], now the
> current snapshot fails in a different manner:
>
> [...]
> make[2]: Entering directory `/work/build'
> make[3]: Entering directory `/work/build'
> rm -f stage_current
> make[3]: Leaving directory `/work/build'
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> Comparison successful.
> if false; then \
> rm -rf stage2-*; \
> echo timestamp > stage2-lean; \
>fi
> [...]
> make[4]: Leaving directory `/work/build/i686-pc-cygwin/libgfortran'
> make[3]: Leaving directory `/work/build/i686-pc-cygwin/libgfortran'
> make[2]: Leaving directory `/work/build/i686-pc-cygwin/libgfortran'
> Checking multilib configuration for libiberty...
> mkdir -p -- i686-pc-cygwin/libiberty
> Configuring in i686-pc-cygwin/libiberty
> [...]
> /work/build/./gcc/xgcc -B/work/build/./gcc/
> -B/usr/local/gfortran/i686-pc-cygwin/bin/
> -B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
> /usr/local/gfortran/i686-pc-cygwin/include -isystem
> /usr/local/gfortran/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2
> -I. -I/work/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
> -Wstrict-prototypes -pedantic /work/gcc/libiberty/strerror.c -o strerror.o
> if [ x"" != x ]; then \
> /work/build/./gcc/xgcc -B/work/build/./gcc/
> -B/usr/local/gfortran/i686-pc-cygwin/bin/
> -B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
> /usr/local/gfortran/i686-pc-cygwin/include -isystem
> /usr/local/gfortran/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2
> -I. -I/work/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
> -Wstrict-prototypes -pedantic /work/gcc/libiberty/strsignal.c -o
> pic/strsignal.o; \
>else true; fi
> /work/build/./gcc/xgcc -B/work/build/./gcc/
> -B/usr/local/gfortran/i686-pc-cygwin/bin/
> -B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
> /usr/local/gfortran/i686-pc-cygwin/include -isystem
> /usr/local/gfortran/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2
> -I. -I/work/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
> -Wstrict-prototypes -pedantic /work/gcc/libiberty/strsignal.c -o strsignal.o
> /work/gcc/libiberty/strsignal.c:408: error: conflicting types for
> 'strsignal'
> /usr/include/string.h:78: error: previous declaration of 'strsignal' was
> here
> make[2]: *** [strsignal.o] Error 1
> make[2]: Leaving directory `/work/build/i686-pc-cygwin/libiberty'
> make[1]: *** [all-target-libiberty] Error 2
> make[1]: Leaving directory `/work/build'
> make: *** [all] Error 2
>
> The above happens on Cygwin, using gcc-core, gcc-fortran tarballs and
> configuring
>
> ${gcc_dir}/configure --prefix="${prefix_dir}" \
> --exec-prefix="${eprefix_dir}" \
> --sysconfdir="${sysconf_dir}" \
> --libdir="${lib_dir}" \
> --libexecdir="${libexec_dir}" \
> --mandir="${man_dir}" \
> --infodir="${info_dir}" \
> --enable-languages=c,fortran \
> --enable-bootstrap \
> --enable-decimal-float=bid \
> --enable-libgomp \
> --enable-threads \
> --enable-sjlj-exceptions \
> --enable-version-specific-runtime-libs \
> --enable-nls \
> --enable-checking=release \
> --disable-fixed-point \
> --disable-libmudflap \
> --disable-shared \
> --disable-win32-registry \
> --with-system-zlib \
> --without-included-gettext \
> --without-x
>
>
>
> Cheers,
> Angelo.
>
> ---
> [1] http://gcc.gnu.org/ml/fortran/2008-06/msg00250.html
>
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
Build failure with Cygwin
Dear All, Perhaps this is old news/my fault but I am seeing the following on Cygwin_NT/amd64: /irun/bin/gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -W missing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-for mat-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wn o-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy.exe c-lang.o stu b-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbui ltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o cygwin2.o msformat-c .o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/ libdecnumber.a ../libcpp/libcpp.a -lintl -liconv ../libiberty/libiberty.a ../lib decnumber/libdecnumber.a -lmpfr -lgmp libbackend.a(stringpool.o): In function `ggc_purge_stringpool': ../../trunk/gcc/stringpool.c:192: undefined reference to `_ht_purge' collect2: ld returned 1 exit status make[2]: *** [cc1-dummy.exe] Error 1 make[2]: Leaving directory `/svn/build/gcc' make[1]: *** [install-gcc] Error 2 make[1]: Leaving directory `/svn/build' make: *** [install] Error 2 Other than the obvious, any suggestions? Paul
Regression in gfortran.fortran-torture/execute/st_function.f90
This has appeared in recent days, with any level of optimization other than none at all. [EMAIL PROTECTED] prs]# /svn-4.3/bin/gfortran -static -O1 $test/../gfortran.fortran-torture/execute/st_function.f90 /svn/trunk/gcc/testsuite/gfortran.dg/../gfortran.fortran-torture/execute/st_function.f90: In function 'MAIN__': /svn/trunk/gcc/testsuite/gfortran.dg/../gfortran.fortran-torture/execute/st_function.f90:63: internal compiler error: in expand_expr_real_1, at expr.c:8833 Paul Thomas -- "Success is the ability to go from one failure to another with no loss of enthusiasm." - Winston Churchill
Re: Regression in gfortran.fortran-torture/execute/st_function.f90
See PR31095. Thanks, Daniel. Paul
Large number of fortran testsuite failures
Following my commit of the patch for PR29786, I did a further regtest, which produced a good number of fortran testsuite failures. Being late, I put it out of its misery. I reverted to before my patch (r125628) and find that the failures are still there. For example, $ /irun/bin/gfortran $test/sizeof.f90 /cygdrive/d/svn/trunk/gcc/testsuite/gfortran.dg/sizeof.f90: In function 'check_r eal': /cygdrive/d/svn/trunk/gcc/testsuite/gfortran.dg/sizeof.f90:37: internal compiler error: Segmentation fault f951, run under gdb, runs to completion, so the problem is further towards the backend. I regested earlier last night and all was well (sorry, I did not record the revision #), so the problem has creapt in over a very small number of patches. You will excuse me please if I cannot identify the patch that is responsible - this sort of investigation is just a bit too tedious under Cygwin. I will make one further reversion this morning and will report if I have bracketed the problem. I do not know if there are other gcc regressions. Cheers Paul
Re: Large number of fortran testsuite failures
You will excuse me please if I cannot identify the patch that is responsible - this sort of investigation is just a bit too tedious under Cygwin. I will make one further reversion this morning and will report if I have bracketed the problem. The problem is between r125620 and r125628 but is NOT, as I suspected, r125621. Is nobody else seeing it, or is it a Cygwin specific problem? Paul
