On Tue, Nov 07, 2006 at 06:16:50AM -0500, Jakub Jelinek wrote:
> If you want to add over time new fields, if there is space in
> common.flags, you just define a new bit there and add the new field
> to the end of u.p structure if there is space for it. That's the
> easy part.
We're having a flag
Hello world,
just a heads-up that libgfortran build is currently blocked at
least on i686-pc-linux-gnu with a newer glibc by PR 30678.
I won't be able to do any work on gfortran development until this
is fixed :-(
Thomas
Hello world
it seems I hosed my developer's bugzilla account by changing
my E-Mail address there from [EMAIL PROTECTED] to
[EMAIL PROTECTED]:
- I can no longer change the e-mail address back
- I no longer have maintainer's rights on bugzilla.
Could somebody change it back, please?
Thanks a lot
[adjusting Subject and also forwarding to [EMAIL PROTECTED]
On Wed, 2007-04-18 at 12:12 -0700, Vivek Rao wrote:
> Here is a feature of g95 that I would like to see in
> gfortran. G95 assigns numbers to warnings and allows
> selected warnings to be treated as errors.
[...]
> g95 -Wall -Wextra -W
Hi,
any reason why the message
http://gcc.gnu.org/ml/fortran/2005-03/msg00282.html
was rejected as spam from gcc-patches, yet accepted on the fortran
list?
Toon Moene wrote:
> I'm still thinking about the text to warn gfortran users for the fact
> that this compiler at present doesn't cover all of Fortran 77 - and that
> we assume distributors to provide access to g77 as long as that's useful.
What about
"This compiler at present doesn't cover al
With the current 4.0 snapshot:
../../gcc-4.0/gcc/config/i386/i386.md:17581: warning: operand 1 missing mode?
Is this cause for concern? Should I open a PR for this?
I'm getting the following error messages when trying to run
a diff from mainline:
$ cvs diff Makefile.am libgfortran.h runtime/in_pack_generic.c
runtime/in_unpack_generic.c m4/in_pack.m4 m4/in_unpack.m4 >
~/Krempel/In-pack/in_pack.patch
cvs diff: [13:47:28] waiting for hubicka's lock in /cvs/g
Compilation of two Fortran test cases now fails with -O3:
real_const_1.f and real_const_2.f90.
I have submitted this as PR 22619.
Apparently, running the Fortran testsuite is something not
everybody does before committing patches :-|
Thomas
On Fri, Jul 22, 2005 at 10:01:43PM -0700, Steve Kargl wrote:
> This is caused by
>
> 2005-07-21 Richard Henderson <[EMAIL PROTECTED]>
Really?
I have that in my tree (gcc version 4.1.0 20050722 (experimental)), but
don't experience that failure.
See my comments on PR 22623.
On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote:
> Dude, I hope fortran will, after branching of 4.1, follow the usual rules
> of regression fixes only.
Currently, gfortran is in a half-usable state. It is not yet
ready as a replacement for g77 (see PR 19292) and there are quite
On Mon, Oct 31, 2005 at 01:20:48PM +0100, FX Coudert wrote:
> New version of the patch attached, to answer Joseph's remark.
Actually, no :-)
> What should "gfortran -fdollar-ok a.f b.c" do, if -fdollar-ok if a
> fortran-only option?
It shouldn't pass -fdollar-ok to cc1, IMHO.
Hi,
having just lost a few hours on a space in lang.opt where
there was supposed to be none, leading to a new option
being silently ignored, a request:
Would it be possible to improve the syntax checking for lang.opt?
It's a file that people touch only rarely, so it is likely that
they will have
Hi Martin,
Sure, I can improve sanity checking.
Thanks!
What exactly have you screwed up?
I had, in lang.opt
EnumValue
Enum (gfc_fcoarray) String (native) Value (GFC_FCOARRAY_NATIVE)
It was a bit non-obvious to me that this led to the whole sub-option
being ignored due to
*drum roll*
th
Hi Martin,
I was able to write a sanity check for these kind of issues, but it does
not resolve all similar issues for other keywords. It's not easy to do it.
Having looked at the origina awk code, I agree. Maybe, in the long
term, a lex/yacc grammar with a monolithic C program to write out
t
Hi Yusuke,
I'd like to participate in Google Summer of Code 2020 at GCC.
In particular, I'm interested in the idea: "Fortran – run-time argument
checking.".
It seems that there are still many projects written in Fortran, thus improving
Fortran itself
is worthwhile for those who do high perform
same as @var{X}.
If @var{X} is @code{COMPLEX}, the imaginary part @math{\omega} is in
the range
-@math{-\pi \leq \omega \leq \pi}.
+@math{-\pi < \omega \leq \pi}.
@item @emph{Example}:
@smallexample
2015-06-14 Thomas Koenig
* intrinsic.texi: Change \leq to < in descrition of imaginary
part in argument to log.
Hi Steve,
subroutine foo(n)
integer n
integer i, j
i = 2
j = 4
n = i**j ! <-- This should evaluate to 16 without a function call.
end subroutine foo
To do this in the Fortran front end would require constant propagation,
which we currently do not do.
We do not
See
http://arstechnica.com/information-technology/2015/11/llvm-to-get-fortran-compiler-that-targets-parallel-gpus-in-clusters/
It is not entirely clear on what they plan to do.
Use gfortran via dragonegg?
Regards
Thomas
Hello world,
the attached patch fixes the regression of PR 60526 by checking for
the presence of a type with the same name as the variable. Types
effectively have their separate namespace because the names of their
symtrees start with an uppercase letter. So far, so good.
However, the error me
What would it take to use an LTO-enabled version of gfortran?
It could turn out to be quite useful for speeding up programs,
especially where I/O or array intrinsics are used.
I also expect many issues to surface where libgfortran is
playing with types in a way that could break LTO, so I
would n
Am 16.08.2016 um 20:57 schrieb Richard Biener:
On August 16, 2016 7:11:26 PM GMT+02:00, Thomas Koenig
wrote:
What would it take to use an LTO-enabled version of gfortran?
It could turn out to be quite useful for speeding up programs,
especially where I/O or array intrinsics are used.
I also
Hi,
I ran some testing on the soon-to-be-committed matmul patch.
Specifically, I tried out what putting -march=native into
libgfortran's Makefile.
Here is the performance data with the new code without -march.
The interesting numbers are the ones for Matml fixed explicit,
for size>=32.
===
I ran some testing on the soon-to-be-committed matmul patch.
Specifically, I tried out what putting -march=native into
libgfortran's Makefile.
I should have added that this was for a system with AVX
(namely an i7-2600).
I want to add a test case to the gfortran testsuite for PR 65563.
If all goes right, running the test case will
a) terminate the program with an error message (to be checked for)
b) create a file, which needs to be cleaned up after the test case
is run.
a) is clear, but how do I do b)? I hav
Hi Janne,
> ! { dg-final { remote_file build delete "pr64770test.dat" } }
did the trick. It is not mentioned in the docs, though.
Thanks!
Thomas
Hello world,
Assume I want to calculate a dot product,
s = sum(a[i]*b[i], i=1..n)
The order of summation in this case should be arbitrary.
Currently, the way to do this is to write out an explicit loop
(either by by the user or by the compliler, such as a DOT_PRODUCT)
and specify the options (f
Hi,
a gentle reminder: Patches which touch gcc/fortran or libgfortran need
to be discussed on the fortran mailing list and approved by a reviewer.
There have been a couple of commits recently where this wasn't followed,
please remember to do so in the future.
Regards
Thomasa
Hi,
I recently had occastion to use --enable-maintainer-mode after the
change to autoconf 2.69 / automake 1.15.1.
This led to two changes in libgfortran/configure. First, an option
"runstatedir" was removed (whatever this does, or is). Second, the
definition of a macro LARGE_OFF_T was changed.
Hi,
What would people think about a -Weverything option which turns on
every warning there is?
I think that could be quite useful in some circumstances, especially
to find potential bugs with warnings that people, for some reason
or other, found too noisy for -Wextra.
The name could be somethin
Hello world,
Fortran allows pointers to contained procedures (other languages
might call this nested functions), and also allows them to be
called using procedure pointers (function pointers in C). This is
permitted as long as the host instance is still active (the parent
function is still runni
Hi,
There is a large increase in rodata size for derived types in gfortran
starting with gcc 8 due to the presence of large initializers for
derived types. Among other things, this affects SPEC tonto (PR 84487),
but there are also other bug reports which mention this behavior.
The large default
Hi Andreas,
The large default initializers are all filled with zeros which end up in
the rodata section, like this:
... and so on. To reduce the size of the executable, it would make more
sense to put this into the BSS section.
Note that .bss is writable. There is no read-only bss section.
Hi Andreas,
Well, nothing is going to write to it (this is not accessible by
user code), so that should not be a problem.
Then don't make it read-only.
I tried this, and while it solves the executable size problem, it
causes an OpenMP regression (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?
Am 05.04.19 um 12:15 schrieb Richard Biener:
Putting readonly data into .rodata isn't required by the C standard I think
so we could freely choose .bss for data exceeding a reasonable
size limit.
That would be the best solution, I think.
IIRC GCC behaved one or another way in the past alread
Hi Richard,
I don't know without looking, but I'd start at assemble_variable in varasm.c.
Thanks. I've done that, and this is what a patch could look like.
However, I will not have time to formally submit this until next
weekend.
In the meantime, comments are still welcome :-)
Regards
Hi!
Is there a way to mark a TREE statement (or a variable) so that
a warning is issued at a later stage if the statement has not been
removed in the meantime?
I am thinking, for example, of Fortran's -Warray-temporaries, which
issues a warning in the front end even though the whole temporary
ar
Hi,
consider this: There is a bug, confirmed by several people. This occurs
in closed-source, proprietary software, and appears to be due to one
of my commits.
Despite considerable help from somebody who has access to the source,
and putting in quite a few (volunteer) hours myself, there is no
t
Am 25.05.19 um 15:16 schrieb Toon Moene:
On 5/25/19 2:52 PM, Thomas Koenig wrote:
Hi,
consider this: There is a bug, confirmed by several people. This occurs
in closed-source, proprietary software, and appears to be due to one
of my commits.
Despite considerable help from somebody who has
Hi Gilles,
Several SPEC benchmarks are available at no cost for non commercial
usage.
See https://www.spec.org/order.html, you may qualify.
I checked, and I do not qualify - I am just a simple volunteer with
a day job which has nothing to do with maintaining gfortran, and
I do draw the line a
Hi Toon,
On 5/25/19 7:01 PM, Steve Kargl wrote:
For WRF, I suppose you or Martin could be a good citizen and
contact the project to report a bug.
I have thought about this. As a person with experience building and
running weather forecasting codes, I would be first in line to try this.
But
Hi Toon,
However, there *is* a Segmentation Fault when running one of its tests:
cat nf_test/tst_f90.log
Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.
Thanks! Now I finally have (open) source to work with...
I think I have an idea what's wrong now.
Regar
Am 20.06.19 um 11:07 schrieb Martin Liška:
On the contrary, decompression
of zstd with zlib will end with:
lto1: internal compiler error: compressed stream: data error
Sogenerating object files on one system and trying to read them
on another system which does not happen to have a particular
li
Hi Martin,
LTO bytecode is not supposed to be a distributable format.
One of my dreams is to make libgfortran LTO-clean. There is
a lot of performance to be gained both in I/O (where a huge
number of special cases could be shortcut by LTO, because
hardly any program uses them all) and in arra
Am 20.06.19 um 15:00 schrieb david.tay...@dell.com:
Dell Customer Communication - Confidential
Can't expect me to read this, then? :-)
I wrote:
Committed as r274551.
Well, this revision appears to have woken quite a few bugs from their
slumber. While argument mismatch was always illegal, it seems to have
been a common idiom at one time. And, like almost all bad habits of
the past, SPEC also has this (see PR 91473, where you
Hi,
I am using gcc version 10.0.0 20190825 (experimental) . During the
Lapack compilation I got the following errors:
sbdsvdx.f:777:39:
777 | CALL SCOPY( N*2, Z( 1,I ), 1, WORK, 1 )
|
Am 04.10.19 um 22:58 schrieb Bill Schmidt:
Have you tried -fno-strict-aliasing? There is a known issue with
spec_qsort() that affects both of these benchmarks. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201.
Reading that bug report (another refusal to correct a glaring
standards v
Am 05.10.19 um 15:12 schrieb Toon Moene:
On 10/3/19 10:01 PM, Thomas Koenig wrote:
If you use a slightly newer version, the error message will become
clearer:
sbdsvdx.f:777:39:
420 | CALL SCOPY( N, D, 1, WORK( IETGK ), 2 )
| 2
..
777
Am 06.10.19 um 16:25 schrieb Tamar Christina:
As discussed during the Cauldron I have created a wiki page
https://gcc.gnu.org/wiki/GCCSpec2017
For us to discuss and exchange ideas to improve GCC's spec score.
A few of them are written in Fortran. As SPEC is closed source and
costs are quite
Hi Tamar,
In general our approach is to identify areas for improvement in a benchmark and
provide a testcase that's independent of the benchmark when reporting it in a
PR upstream.
Sounds like a good approach, in principle.
If the people who are doing the identfying know Fortran well, that
Hi, I just saw this:
FAIL: gfortran.dg/goacc/finalize-1.f -O scan-tree-dump-times gimple
"(?n)#pragma omp target oacc_enter_exit_data
map\\(delete:MEM\\[\\(c_char \\*\\)[^\\]]+\\] \\[len: [^\\]]+\\]\\)
map\\(to:del_f_p \\[pointer set, len: [0-9]+\\]\\)
map\\(alloc:del_f_p\\.data \\[pointe
Am 29.12.19 um 14:26 schrieb Segher Boessenkool:
We cannot waste a year on a social experiment. We can slowly and carefully
adopt new procedures, certainly. But anything drastic isn't advisable imo.
Also, many GCC developers aren't familiar with Git at all. It takes time
to learn it, and to l
Am 11.01.20 um 15:39 schrieb Joseph Myers:
This conversion is now in place, read-only for checking purposes. I've
done all the usual validation, including in particular checking branch
tips and tags against SVN.
Is checkout via git+ssh supposed to work for this? It does not for me
(something
Hi Martin,
It does not for me
(something about public key rejected), but then I am a complete novice
at using git, so I am more or less doing vodoo git here.
Please paste the error message you face?
Currently, gcc.gnu.org is totally under water, even accessing the
wiki leads to a timeout, s
Am 27.03.2017 um 19:41 schrieb Marek Polacek:
Of course "the person" had bootstrapped and tested all the languages before
adding the warning. If only any of you bothered to check the fortran/
ChangeLogs:
The problem is with libfortran, which apparently was not tested
(or the problem would hav
Hi,
is the gcc-prs mailing list active? The archives show no
bugs entered for example for https://gcc.gnu.org/ml/gcc-prs/2017-04/ .
Regards
Thomas
Hello world,
I am wondering how best to implement an AMD-specific version
of MATMUL for libfortran.
What we currently have in there is restricted to Intel chips,
with a run-time selection of versions depending on availability
of AVX, AVX2+FMA and AVX512F.
The specific function is then declared
Hi,
I am getting
$ LANG=C svn up
Updating '.':
svn: E170013: Unable to connect to a repository at URL
'svn+ssh://tkoe...@gcc.gnu.org/svn/gcc/trunk'
svn: E210002: To better debug SSH connection problems, remove the -q
option from 'ssh' in the [tunnels] section of your Subversion
configuration
Hi,
this is just a heads-up that I am currently unable to work on the
library side of Paul's recent rank 15 patch for gfortran.
My ssh keys no longer work on gcc.gnu.org. I have contacted
overse...@gcc.gnu.org, but have gotten no reply so far.
If there is anybody else I should be contacting, pl
Am 28.01.2018 um 11:58 schrieb Andreas Schwab:
On Jan 27 2018, Thomas Koenig wrote:
svn: E210002: To better debug SSH connection problems, remove the -q
option from 'ssh' in the [tunnels] section of your Subversion
configuration file.
And what does it say?
Andreas.
Nothing, but
Am 28.01.2018 um 13:43 schrieb Jonathan Wakely:
i.e. does this work?
SVN_SSH="ssh -o PubkeyAcceptedKeyTypes=ssh-dss" svn up
Yes, it did. Thanks a lot!
I used this to add my new key via
ssh -o PubkeyAcceptedKeyTypes=ssh-dss tkoe...@gcc.gnu.org appendkey <
id_rsa.pub
and now everything is
Hello world,
whenever I look at the list of serious bugs, I find myself chaning the
columns to add the priority field.
What do you think about adding the priority field when clicking on that
link? A patch is attached.
Regards
Thomas
Index: index.html
==
Hi Matt,
[timings]
Intel AVX2:
C_SW 1.4931
D_SW 5.4254
PG_D 1.0878
TRACER_2D 24.7418
REMAPPING 27.2644
Now I looked at GNU Fortran (7.3.0). Here my "stock" flags are quite
boring (and all flags, not just the optimization ones):
[Various options elided,
Hi Richard,
First and foremost we need a syntax that actually works for the
Fortran frontend and a way to automatically include this special
header / module.
I can imagine parsing the relevant headers while compiling gfortran
and generating C code from it, which could then be #included in the
Hi,
this is a heads-up that configuring with --enable-maintainer-mode
currently breaks bootstrap; see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
for details.
Running configure with --enable-maintainer-mode --disable-werror
allows bootstrap to proceed until the underlying issue is fixed
Hello world,
I just noticed that C++ now appears to be built by default, even when
only the C and fortran are specified. The configure line
../trunk/configure --prefix=$HOME --enable-languages=c,fortran
--with-mpc=/usr/local --with-mpfr=/usr/local
leads to the message
checking for versi
Hello,
I have set up a semi-automatic lapack tester on
powerpc64-unknown-linux-gnu (gcc110 on the gcc compile farm).
It downloads the current trunk, compiles it, then uses that
compiler to compile the reference BLAS and Lapack and run the LAPACK
test suite, cycling through the Lapack build with d
Hi Steve,
PR 51751 seems to concern only complex*16 failures. Have
you had a chance to look at the real and double precision
errors?
That PR is in a different category, because input values to a BLAS
routine are wrong. I suspect an error in the testing (relying
on uninitialized memory), but
Does this ring any bells? This is with a recent trunk.
$ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran
--enable-maintainer-mode && make && make install
make[3]: Leaving directory `/var/work/gcc-bin/trunk/libdecnumber'
make[3]: Entering directory `/var/work/gcc-bin/trunk/g
On Sat, 2009-08-15 at 17:56 +0200, Ralf Wildenhues wrote:
> Which aclocal version do you have in PATH? Looks like 1.10 or newer,
> rather than 1.9.6.
Yes, that was probably it. Seems like Debian changed that behind my
back during a recent update...
Thanks!
Thomas
Hello world,
http://www.heise.de/newsticker/GCC-4-4-0-erschienen--/meldung/136529
reports the release of gcc 4.4.0 and also claims that 453.povray from
SPEC CPU 2006 caused an ICE in g++. The tone of the report is fairly
negative.
Can somebody with access to SPEC sources confirm / deny and file
Hello world,
bootstrap appears to be broken totally on i686-pc-linux-gnu (see PR 27763).
Can somebody have a look?
Thomas
Is anything wrong with SVN, or did my authorization to commit somehow
fall through the cracks?
Thomas
$ svn commit fortran/ChangeLog fortran/trans-array.c testsuite/ChangeLog
testsuite/gfortran.dg/multiple_allocation_2.f90
Waiting for Emacs...Done
svn: Commit failed (details follow):
svn
On Sun, May 28, 2006 at 02:43:20PM -0400, Daniel Jacobowitz wrote:
> On Sun, May 28, 2006 at 08:38:34PM +0200, Thomas Koenig wrote:
> > Is anything wrong with SVN, or did my authorization to commit somehow
> > fall through the cracks?
>
> Is it maybe an anonymous checkout?
I just tried to commit the fix for PR 27470, a gfortran 4.1 regression,
and I got the error message:
$ svn commit fortran/ChangeLog fortran/trans-array.c testsuite/ChangeLog
testsuite/gfortran.dg/multiple_allocation_2.f90
Waiting for Emacs...Done
svn: Commit failed (details follow):
svn: Authoriz
Hello world,
are there any platforms where gcc doesn't support 8-byte ints?
Can a front end depend on this?
This would make life easier for Fortran, for example, because we
could use INTEGER(KIND=8) for a lot of interfaces without having
to bother with checks for the presence of KIND=8 integers.
On Wed, Feb 16, 2005 at 10:59:00PM -0500, Jason Merrill wrote:
> I suspect that the problem is that the transformations fold_indirect_ref_1
> is doing on arrays don't mix well with how fortran handles arrays.
I have been trying to look at the problem in the BLAS sources,
and I find it hard to deb
> Your analysis is correct, see http://gcc.gnu.org/PR20030 :-) A fix has already
> been committed.
Thanks, I should have searched the PRs more carefully before starting
work on this :-)
Hello world,
-floop-flatten breaks Lapack, which uses quite a common technique; see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52307
This is not a regression as far as I can determine, but the bug is
severe enough that I would consider removing the option for the 4.7
release.
Opinions?
Hello world,
I just got a bootstrap error on trunk, with configuration
../trunk/configure --prefix=$HOME --enable-languages=c,fortran
--disable-build-poststage1-with-cxx
The error was:
../../trunk/gcc/fortran/decl.c: In function 'match_attr_spec':
../../trunk/gcc/fortran/decl.c:3276:3: error
Am 04.03.2013 21:34, schrieb N.M. Maclaren:
(quoting documentation about DEC UNIONs for Fortran)
"However, if you overlay one variable with another smaller variable,
that portion of the initial variable is retained that is not overlaid.
Depending on the application, the retained portion of an o
On Tue, 2008-08-12 at 10:46 +0200, VandeVondele Joost wrote:
> A nightly tester has been set up to track the performance of the
> gcc/gfortran compiler (trunk) for typical CP2K runs. Results and code can
> be found at:
>
> http://cp2k.berlios.de/gfortran/
>
> I'll consider your suggestions for
On Thu, 2008-08-14 at 14:41 -0700, H.J. Lu wrote:
> It should be fixed now.
Thanks a lot for the quick fix.
My problem is that I don't have access to a machine with GFC_REAL_16 and
working autoconf2.59, so possible problems in cut&paste code tend to be
hidden from me.
I'll make special mention
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
?
IMHO, these bugs are especially nasty and should get high visibility
(and maybe even special privileges for fixing on a release branch).
Thomas
On Fri, 2007-05-25 at 22:12 +0100, Paul Brook wrote:
> On Friday 25 May 2007, Thomas Koenig wrote:
> > What about a keyword for bugs that
> >
> > - generate wrong code
> > - affect a standard-conforming program
> > - are silent (no error message)
>
> We alre
On Tue, 2007-07-24 at 11:23 +0200, Thomas Veith wrote:
> Hi *,
>
> bootstrap is broken on trunk rev. 126866 during Stage3:
Thanks. This has been fixed by Tobias Burnus with
http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00736.html
.
This is on i686-pc-linux-gnu:
$ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran
--enable-maintainer-mode && make bootstrap
...
build/genmodes -h > tmp-modes.h
/bin/sh: build/genmodes: No such file or directory
make[3]: *** [s-modes-h] Error 127
make[3]: Leaving directory `/
Hi,
since the change to the new list management, there has been
an uptick of spam getting through. Spam is bounced by my ISP,
and this just resulted in a warning that there were too many
bounces and that I would get removed from the list unless I
confirmed it (which I then did).
So, a request: C
Hi,
since the change to the new list management, there has been
an uptick of spam getting through. Spam is bounced by my ISP,
and this just resulted in a warning that there were too many
bounces and that I would get removed from the list unless I
confirmed it (which I then did).
This has now ha
Am 21.03.20 um 21:29 schrieb Frank Ch. Eigler via Gcc:
Hi -
since the change to the new list management, there has been
an uptick of spam getting through. Spam is bounced by my ISP,
and this just resulted in a warning that there were too many
bounces and that I would get removed from the list u
Of course, better would be to remove ChangeLogs entirely (including not
putting anything like them into a commit message), because they are
largely not useful and are just make-work.
I disagree. I find them quite useful.
Hi,
I have a test case which does a double free on a pointer,
at runtime. I have to narrow it down a bit before
comitting, but it indicates a regression.
Assuming I put this into the testsuite, how can I make sure
that this actually fails if the problem ever re-occurs?
Is there a combination of
Hi Martin,
Thanks to Jakub, we finally set up an experimental environment:
gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
How does one go about testing this? It would be helpful if you
could explain this assuming that the Fortran people have at best
an extremely shallow knowledge of git and
Hm, one question: I find the r11-1234 type commit to be much more
readable, in ChangeLog files and everywhere else.
Would it be possible to have that format instead of
"cherry picked from commit $HEX_SOUP" ?
/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -54,15 +54,6 @@
* expr.c (gfc_check_pointer_assign): Revert patch for PR 93956.
* interface.c: Likewise.
-2020-04-24 Thomas Koenig
-
- Backport from trunk
- PR fortran/93956
- * expr.c (gfc_check_pointer_assign): Also
Am 21.05.20 um 11:45 schrieb Andreas Schwab:
On Mai 21 2020, Thomas Koenig via Gcc wrote:
$ git revert r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
on origin/releases/gcc-9, and now only the ChangeLog entries reversed
(which is not wanted), but the code is unchanged (which is even
less
Am 21.05.20 um 13:05 schrieb Andreas Schwab:
On Mai 21 2020, Thomas Koenig wrote:
An error message or warning from git might have been nice, though.
How can it know?
Obviously, reverting the already applied patch was a no-op.
I would assume that git noticed that, and could issue a message
Hi Andreas,
git is not doing a plain patch, it is doing a merge. It is not unusual
for a merge to have changes that are already present on both sides.
... which just goes to show that it is very easy to make a fool of
yourself with git if you have no mental model of what it does.
That's not n
Hi,
what's currently in trunk (as of a few hours ago) fails for me with
File "contrib/mklog.py", line 36, in
from unidiff import PatchSet
ModuleNotFoundError: No module named 'unidiff'
I think this is an error which would have to be taken into account
one way or another - maybe include i
1 - 100 of 218 matches
Mail list logo
