https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #25 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #23)
> (In reply to Jürgen Reuter from comment #20)
> > Thanks a lot for reverting, Thomas, shall I further reduce the reproducer,
> > or can you work with it now?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #22 from Jürgen Reuter ---
Ok, I stop shrinking the reproducer further down for the moment, let me know if
you need more help. Thanks for your efforts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #20 from Jürgen Reuter ---
Thanks a lot for reverting, Thomas, shall I further reduce the reproducer, or
can you work with it now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #16 from Jürgen Reuter ---
Created attachment 48388
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48388&action=edit
2nd reproducer, down to 800 kb
Now you can do just ./whizard_check to run the test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #15 from Jürgen Reuter ---
Wow, I have a first version, finally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #14 from Jürgen Reuter ---
Created attachment 48387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48387&action=edit
Reproducer, first try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #13 from Jürgen Reuter ---
I will submit a reproducer, unpack it, do 'make', then execute
./whizard_test --check simulations.
Still trying to get this below 1 MB. :(
In case you cannot fix this, please, Thomas, please, revert this. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #12 from Jürgen Reuter ---
fuck, sdill too big :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #11 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #10)
> (In reply to Richard Biener from comment #3)
> > Can you maybe bisect this to a specific (fortran) commit in GCC?
>
> Richard, when is the last time (presumabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #9 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #8)
> I'd like to understand what went wrong here... I suspect that
> the fix exposed another bug somewhere :-(
>
> Is it possible to isolate a test case like that? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #5 from Jürgen Reuter ---
(In reply to Richard Biener from comment #3)
> Can you maybe bisect this to a specific (fortran) commit in GCC?
This does not necessarily be a Fortran specific commit, it could also be a
change in the middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #4 from Jürgen Reuter ---
It is definitely this routine in our code that triggers this double free error:
call simulation%init ([procname1], .true., .true., global, alt_env=alt_env)
It really looks like that the garbage collector is m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #2 from Jürgen Reuter ---
This is our unit test, we now confirmed that this is the only problem, so the
only failing test: it really looks like that the finalizer for the subroutine
crashes, all routines inside the subroutine get exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #1 from Jürgen Reuter ---
The change must have happened between Sunday, April 16 and Monday, April 27.
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Unfortunately, just a week or so before the release there was a very severe
regression, which leads to a double free corruption in tcache, cf. below.
Unfortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92673
Jürgen Reuter changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from Jürgen Reuter
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
I tested both OCaml 4.02.3 and 4.09.0. For both, linking with gcc 10.0, your
development version r278668 svn://gcc.gnu.org/svn/gcc fails (cf. below). This
problem was observed both on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #21 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #20)
> As of XCode 11.3beta, the contained SDK works OK:
>
> https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
>
> We still have the underlying problems - w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92445
--- Comment #1 from Jürgen Reuter ---
Did anybody look into this one here? At the moment, I cannot build gcc on
MACOSX Catalina.
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Under macOS Catalina (Darwin 19.0.0) bootstrap fails with the following error
message:
libtool: compile: /usr/local/packages/gcc_10.0/_build/./gcc/xgcc
-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91939
--- Comment #3 from Jürgen Reuter ---
Man, Steve, your memory is better than mine, and I even commented on this other
bug ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91939
--- Comment #1 from Jürgen Reuter ---
The discussion on c.l.f. is not clear whether the code is valid:
The Fortran 2018 standard says in 7.5.4.6.8:
A type has default initialization if component-initialization is specified for
any direct componen
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following code gives an ICE as segmentation violation, it was discussed on
c.l.f. on Sep. 30. I believe that the code is not valid though it is compiled
in ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752
--- Comment #4 from Jürgen Reuter ---
(In reply to kargl from comment #3)
> See the documentation. -fallow-invalid-boz reduces the error to a warning.
> The warning can only be silenced by -w. This was done with intent.
Actually not all of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752
--- Comment #2 from Jürgen Reuter ---
Yes, that would work, but the better workaroud is to replace
h = B"11"
by
h = int (B"11")
I convinced the authors of the software we depend upon to do that accordingly.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
nagfor and ifort do not flag this as an error, but only warn as an extension:
program main
implicit none
integer :: h
h = B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #12 from Jürgen Reuter ---
This is still present. Any progress?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #6 from Jürgen Reuter ---
(In reply to kargl from comment #5)
> (In reply to kargl from comment #3)
> > (In reply to Jürgen Reuter from comment #2)
> > > (In reply to kargl from comment #1)
> > > > W(In reply to Jürgen Reuter from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #4 from Jürgen Reuter ---
But where? It works with all former versions of gfortran, and it works with
ifort.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #2 from Jürgen Reuter ---
(In reply to kargl from comment #1)
> W(In reply to Jürgen Reuter from comment #0)
> > Created attachment 46763 [details]
> > Reproducer
> >
> > This is a rather recent regression, failing with r274920, and
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 46763
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46763&action=edit
Reproducer
This is a rather recent regression, failing with r274920, and it h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
--- Comment #30 from Jürgen Reuter ---
Are there any plans on finishing the finalization implementation? To me it
looks that the missing cases are the last open issues (besides some minor known
bug) to claim complete F2003 implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90808
--- Comment #7 from Jürgen Reuter ---
Yes, there two things. The missing library comes from the fact that I didn't
install the system header and libraries under /usr/. I copied the files, now I
get these warnings (but everything works):
ld: warni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90808
--- Comment #2 from Jürgen Reuter ---
So that means this is something that can be solved by editing the gcc code?
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
There is a new bootstrap problem, I don't know whether this is a regression, or
something new due to the new command line tools of Apple.
In file included
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
I don't know whether this already has been reported, it was discussed today
(May 16, 2019) on c.l.f. The following valid code is rejected by gfortran:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379
--- Comment #5 from Jürgen Reuter ---
I am seeing the same issue on Darwin 18.5.0 (macOSX 10.4.4) with XCode 10.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65381
--- Comment #6 from Jürgen Reuter ---
I do not get an ICE with the abridged versions from #5, only for the original
code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120
--- Comment #12 from Jürgen Reuter ---
Paul, getting back to this one? At first glance seems not overly much work left
for the remaining case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60560
--- Comment #2 from Jürgen Reuter ---
This is still present in the 10.0 trunk. How difficult is that to fix?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #11 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #10)
> Interestingly, nagfor rejects this code with the message "Inconsistent
> definitions of COMMON block FOO in program-units $block and BAR". Both ifort
> and pgfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #81 from Jürgen Reuter ---
LLVM worked, so I think there are enough green lights now for committing this
fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #80 from Jürgen Reuter ---
> A little late to the party, but this revised patch worked for me on
> 10.4.4/Xcode10.2 with gcc8.3.0, gcc7.4.0, and gcc6.5.0. fftw3-3.3.8 built
> and passed all tests against the patched gcc8 and gcc7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #75 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #74)
> Thanks, does that include a test suite run and/or building something
> substantial (e.g. LLVM)? .. sorry to pass this on, but right now as noted,
> very limited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #73 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #68)
> Created attachment 46176 [details]
> revised fixincludes patch.
>
> The patch attached include the generated files, and I'd be grateful if folks
> would test it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #72 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #71)
> (In reply to Iain Sandoe from comment #70)
> > (In reply to Jürgen Reuter from comment #69)
> > > (In reply to Iain Sandoe from comment #68)
>
> > Does this mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #69 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #68)
> Created attachment 46176 [details]
> revised fixincludes patch.
>
> The patch attached include the generated files, and I'd be grateful if folks
> would test it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78640
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #65 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #64)
> Why is this a [9 Regression] BTW? If the failure is while compiling
> darwin-driver.c and caused by system headers using _Atomic even in C++, when
> gcc/config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #63 from Jürgen Reuter ---
I confirm that the fix in comment #48 works also with MACOSX 10.14.4, XCode
10.2 on gcc trunk, as of r270245.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #59 from Jürgen Reuter ---
Yes, to me this looks also like an independent problem, and it appears to me
like a sort of race condition. I also just restarted the bootstrap (without a
parallel make). Now I have to do some theoretical ph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #56 from Jürgen Reuter ---
I tried the fix, but now I get another error:
/libstdc++-v3/../libgcc
-I/usr/local/packages/gcc_9.0_fixincl/_build/x86_64-apple-darwin18.5.0/i386/libstdc++-v3/include/x86_64-apple-darwin18.5.0
-I/usr/local/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #54 from Jürgen Reuter ---
Ok, after running genfixes there are still only two modified files in the whole
tree of code, namely fixincludes/inclhack.def and fixincludes/fixincl.x.
Is that as intended?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #53 from Jürgen Reuter ---
(In reply to Erik Schnetter from comment #46)
> The patch does not include the generated files. You need to run "genfixes"
> in the "fixincludes" directory after applying the patch.
This I don't understand:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #50 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #48)
> Perhaps that redefinition of _Atomic should be guarded with
> #if (__STDC_VERSION__ < 201112L) || defined(__cplusplus)
> or so, so that for C -std=c11 you still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #44 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #43)
> Created attachment 46110 [details]
> Proof-of-principle path
>
> Does this work for you?
> - my local testing says it generates the right wrapped include file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #42 from Jürgen Reuter ---
I filed an APPLE bug report:
https://bugreport.apple.com/web/?problemID=49727047
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #40 from Jürgen Reuter ---
Are there any news on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #35 from Jürgen Reuter ---
The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all the
files mentioned before have to be modified, asan_mac.cc, sanitizer_mac.cc,
sanitizer_platform_limits_posix.cc, darwin-driver.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #32 from Jürgen Reuter ---
(In reply to Erik Schnetter from comment #31)
> Here is an updated version of the patch that fixincludes both
> and , and does not need to touch any sources
> files in GCC any more:
>
What about the chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #30 from Jürgen Reuter ---
In addition to Erik's changes I have to do as well:
--- asan_mac.cc 2019-04-04 15:02:48.0 +0200
+++ asan_mac.cc.orig2019-04-04 16:44:32.0 +0200
@@ -32,13 +32,7 @@
#include // for free(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #27 from Jürgen Reuter ---
In order to proceed bootstrapping I had also to fix
libsanitize/sanitizer_common/sanitizer_platform_limits_posix.cc
and
libsanitize/asan/asan_mac.cc
by correspondingly wrapping include statements.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #23 from Jürgen Reuter ---
This patch still doesn't work for me:
libtool: compile: /usr/local/packages/gcc_9.0/_build/./gcc/xgcc -shared-libgcc
-B/usr/local/packages/gcc_9.0/_build/./gcc -nostdinc++
-L/usr/local/packages/gcc_9.0/_bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #18 from Jürgen Reuter ---
Do you think it would be possible to get this fix before the 9.1 release (see
the announcement by Richard B. yesterday/today)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127
--- Comment #5 from Jürgen Reuter ---
Paul, would be cool to get back to this one! ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85686
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #17 from Jürgen Reuter ---
(In reply to Erik Schnetter from comment #16)
> The proper way to fix this via fixinclude is to replace declarations such as
>
> _Atomic u_long
>
> with
>
> _Atomic(u_long)
>
> which is still legal in C.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #15 from Jürgen Reuter ---
Sorry for the spam, now I got it, there was something old (i.e. new) lingering
around still. Now, back to XCode 10.1 and command line tools from October 2018
with a different include/sys. Started compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #14 from Jürgen Reuter ---
Unfortunately, the downgrade to XCode 10.1 didn't work, I still get the
buggy/problematic headers. That is really annoying, because now I am stuck with
my development.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #13 from Jürgen Reuter ---
I see. For the moment, I will be downgrading to XCode 10.1 with its command
line tools, but I really hope that either you or them will be able to fix it.
If you were following the progress from Apple, maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #11 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #10)
> In the short-term, I'd suggest picking up the previous version of Xcode
> command line tools [e.g.10.1] (from developer.apple.com) and using the SDK
> from that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #9 from Jürgen Reuter ---
Trying to continue that fix I get loads and loads of other error in the
libsanitizer :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #8 from Jürgen Reuter ---
Hi Erik,
your patch works beyond the point where the problem occurs first, but then the
sanitizer still fails bootstrapping:
In file included from /usr/include/sys/sysctl.h:83,
from
../../../
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #5 from Jürgen Reuter ---
My hunch is that it takes Apple too long to fix that issue, so a fix inside gcc
would be very much appreciated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #4 from Jürgen Reuter ---
Created attachment 46043
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46043&action=edit
Darwin header file ucred.h
As this seems to be of interest, I posted the Darwin XCode 10.2 header file
ucred.h
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Using the svn revision r269983 under MACOSX 10.14.4/Darwin 18.5.0 with XCode
10.2 bootstrapping gcc 9.0 fails with the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #37 from Jürgen Reuter ---
I'm inclined to advice to close this PR. In principle, it would be good to
follow up on this and see which change around Christmas 2018 triggered this,
but I fear we don't have the personpower atm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695
--- Comment #9 from Jürgen Reuter ---
Sorry if that maybe a stupid question but is it wise that close before the new
release to start such a bigger coding?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89539
--- Comment #6 from Jürgen Reuter ---
Yep, fixed, thanks for the overnight reaction^^. (and next time I think I have
the guts to mark it as 'bootstrap' right from the beginning)
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
gcc fails to compile/bootstrap on MAC OS X Darwin 10.14.3, 64bit,
Darwin Finarfin.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89374
--- Comment #2 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #1)
> Related to/duplicate of pr36383?
Related to most likely yes, could have the same origin. Probably the fortran DT
is cast into an internal C representation
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following example is from the Intel Forum, cf.
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/583935
The NAG compiler and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88438
--- Comment #2 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #1)
> At https://gcc.gnu.org/wiki/Fortran2008Status I see
>
> Unimplemented features -- based on the list in the "Introduction" of the
> F2008 standard
> ...
>
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following issue was discussed on the Intel forum:
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/803316
The assignment is accepted by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41178
--- Comment #3 from Jürgen Reuter ---
Nothing has been done here for a decade, and the functions mentioned below
(gfc_expand_expr and gfc_expand_assign) do not exist any longer in the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41023
--- Comment #7 from Jürgen Reuter ---
Has this patch ever been applied and/or reg-tested?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38113
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37398
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718
--- Comment #6 from Jürgen Reuter ---
Still present in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34663
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34528
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34392
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32986
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
201 - 300 of 701 matches
Mail list logo
