https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478
--- Comment #11 from Martin Liška ---
Author: marxin
Date: Fri May 17 07:21:46 2019
New Revision: 271311
URL: https://gcc.gnu.org/viewcvs?rev=271311&root=gcc&view=rev
Log:
Remove a test-case that leads to a huge stack (and file) allocation (PR
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478
Martin Liška changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90495
--- Comment #2 from Martin Liška ---
Author: marxin
Date: Fri May 17 07:22:00 2019
New Revision: 271312
URL: https://gcc.gnu.org/viewcvs?rev=271312&root=gcc&view=rev
Log:
Handle a location with NULL as a file (PR driver/90495)
2019-05-17 Marti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90495
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90496
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90496
--- Comment #7 from Martin Liška ---
Author: marxin
Date: Fri May 17 07:24:28 2019
New Revision: 271313
URL: https://gcc.gnu.org/viewcvs?rev=271313&root=gcc&view=rev
Log:
Handle a location with NULL as a file (PR driver/90496)
2019-05-17 Marti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90514
--- Comment #1 from Andrew Pinski ---
Are you saying the precision should be 1? If so then no, that would be invalid
as in C, enum have the full range of the underlying type and is well defined to
have values of 3 or higher in the enum variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484
--- Comment #6 from Martin Liška ---
(In reply to Jakub Jelinek from comment #5)
> Author: jakub
> Date: Thu May 16 21:45:34 2019
> New Revision: 271299
>
> URL: https://gcc.gnu.org/viewcvs?rev=271299&root=gcc&view=rev
> Log:
> PR c++/9048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #2 from Umesh Kalappa ---
Created attachment 46369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46369&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478
David Binderman changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #3 from Umesh Kalappa ---
options used : -mcpu=e6500 -mno-altivec -mabi=no-altivec -mabi=elfv2
-mcmodel=medium -mhard-float -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478
--- Comment #14 from Martin Liška ---
(In reply to David Binderman from comment #13)
> >The test-case does not makes sense
>
> The test case is accepted fine by previous versions of gcc
> and current version of clang. It looks like good code to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478
Martin Liška changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752
Matthias Kretz changed:
What|Removed |Added
Known to work||7.4.0, 9.1.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90484
Jakub Jelinek changed:
What|Removed |Added
Known to work||10.0
Summary|[9/10 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #39 from Richard Biener ---
Author: rguenth
Date: Fri May 17 08:10:58 2019
New Revision: 271314
URL: https://gcc.gnu.org/viewcvs?rev=271314&root=gcc&view=rev
Log:
2019-05-17 Richard Biener
Backport from mainline
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89576
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #4 from Richard Biener ---
*** Bug 90512 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90512
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #10 from Martin Liška ---
(In reply to Guobing from comment #8)
> Hi, I am the original reporter of this bug. This problem seems not happen on
> GCC8 while do on GCC9. We try to use FMV (target_clone) for some of the
> GlibC libm func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90510
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #9 from Martin Liška ---
So comparison all files in wrf, I've got:
╔═╤╤╤═╗
║ Filename│ Before │ After │ Change ║
╠═
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
Eric Botcazou changed:
What|Removed |Added
Target|powerpc64le-*-* |powerpc64-wrs-vxworks
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90510
--- Comment #2 from Richard Biener ---
So we have
(insn 10 9 11 2 (set (reg:V2DF 92)
(vec_duplicate:V2DF (reg/v:DF 84 [ tem ]))) "t.c":8:42 2984
{vec_dupv2df}
(expr_list:REG_DEAD (reg/v:DF 84 [ tem ])
(nil)))
(insn 11 10 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #10 from Martin Liška ---
> So the only significant offender is module_configure.fppized.f90 file. Let
> me profile it.
Time profile before/after:
╔══╤╤╤═╗
║ PASS │
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #11 from Guobing ---
(In reply to Martin Liška from comment #10)
> (In reply to Guobing from comment #8)
> > Hi, I am the original reporter of this bug. This problem seems not happen on
> > GCC8 while do on GCC9. We try to use FMV (ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #12 from Martin Liška ---
> The background is that, we want to try optimize libm with avx2/avx512, and
> found that not all the libm math functions will have benefit when we
> generally use 'arch=haswell' or 'arch=skylake-avx512' to c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #11 from rguenther at suse dot de ---
On Fri, 17 May 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
>
> --- Comment #10 from Martin Liška ---
> > So the only significant offender is modu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #12 from Martin Liška ---
>
> Can you share -fopt-report-loop differences? From the above I would
> guess we split a lot of loops, meaning the memcpy/memmove/memset
> calls are in the "middle" and we have to split loops (how many
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90514
--- Comment #2 from JunMa ---
(In reply to Andrew Pinski from comment #1)
> Are you saying the precision should be 1? If so then no, that would be
> invalid as in C, enum have the full range of the underlying type and is well
> defined to have v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
--- Comment #3 from Eric Botcazou ---
It's not obvious to me why this would have anything to do with the calling
convention on SPARC 32-bit, which is very reasonable. For example, it's not
like M68k where pointers and integers are passed differe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #11 from junma at gcc dot gnu.org ---
Author: junma
Date: Fri May 17 10:13:29 2019
New Revision: 271319
URL: https://gcc.gnu.org/viewcvs?rev=271319&root=gcc&view=rev
Log:
PR tree-optimization/90106
* gcc.dg/cdce3.c: Ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #5 from Eric Botcazou ---
Created attachment 46370
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46370&action=edit
Fix or workaound
Tested on various PowerPC ports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90516
Bug ID: 90516
Summary: Strange behaviour of code if function no return value
and code embraced by try..catch with opt flags
Product: gcc
Version: 8.3.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256
Nathan Sidwell changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90494
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #13 from rguenther at suse dot de ---
On Fri, 17 May 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
>
> --- Comment #12 from Martin Liška ---
> >
> > Can you share -fopt-report-loop dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90516
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256
--- Comment #10 from Nathan Sidwell ---
digging into the C++ FE's grokdeclarator shows this to be trickier than C. C
has a global variable of the expression component currently being built. it
hooks a COMPOUND_EXPR into there, in its own bindin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #14 from Martin Liška ---
(In reply to rguent...@suse.de from comment #13)
> On Fri, 17 May 2019, marxin at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
> >
> > --- Comment #12 from Martin Liška -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90498
Dominique d'Humieres changed:
What|Removed |Added
Keywords||ice-on-valid-code
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90506
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #15 from rguenther at suse dot de ---
On Fri, 17 May 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
>
> --- Comment #14 from Martin Liška ---
> (In reply to rguent...@suse.de from commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90392
--- Comment #6 from ohaiziejohwahkeezuoz at xff dot cz ---
The ldlang.c:6868 assertion bug was fixed in binutils.
That leaves the -save-temps/gcc driver issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #13 from Guobing ---
(In reply to Martin Liška from comment #12)
> > The background is that, we want to try optimize libm with avx2/avx512, and
> > found that not all the libm math functions will have benefit when we
> > generally use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #14 from Martin Liška ---
(In reply to Guobing Chen from comment #13)
> (In reply to Martin Liška from comment #12)
> > > The background is that, we want to try optimize libm with avx2/avx512, and
> > > found that not all the libm mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #15 from Guobing Chen ---
(In reply to Martin Liška from comment #14)
> (In reply to Guobing Chen from comment #13)
> > (In reply to Martin Liška from comment #12)
> > > > The background is that, we want to try optimize libm with avx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #16 from Martin Liška ---
> I am not quite familiar with libm, will this change the its bevhavior or
> other side effect?
No. You have to tweak the macro definition, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
--- Comment #4 from Ian Lance Taylor ---
What is different about 32-bit SPARC is not that it treats pointers and
integers differently, but that
struct { void *p; }
and
void *p;
are passed as arguments in two different ways. The former is pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90510
Richard Biener changed:
What|Removed |Added
Keywords||patch
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90517
Bug ID: 90517
Summary: [10 regression] test case gcc.dg/cdce1.c fails
starting with r271281
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518
Bug ID: 90518
Summary: ICE: in emit_move_insn, at expr.c:3745 in
gcc.dg/gimplefe-40.c
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965
--- Comment #16 from Jonathan Wakely ---
Author: redi
Date: Fri May 17 14:13:32 2019
New Revision: 271323
URL: https://gcc.gnu.org/viewcvs?rev=271323&root=gcc&view=rev
Log:
PR libstdc++/85965 move is_invocable assertions again
This is another a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90246
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Fri May 17 14:36:37 2019
New Revision: 271326
URL: https://gcc.gnu.org/viewcvs?rev=271326&root=gcc&view=rev
Log:
PR libstdc++/90246 Improve text of std::variant exceptions and assertions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90246
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90497
--- Comment #7 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri May 17 14:48:37 2019
New Revision: 271328
URL: https://gcc.gnu.org/viewcvs?rev=271328&root=gcc&view=rev
Log:
i386: Enable MMX intrinsics without SSE/SSE2/SSSE3
Since MMX intri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89576
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
--- Comment #5 from Eric Botcazou ---
> What is different about 32-bit SPARC is not that it treats pointers and
> integers differently, but that
>
> struct { void *p; }
>
> and
>
> void *p;
>
> are passed as arguments in two different ways.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90517
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90497
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90519
Bug ID: 90519
Summary: ICE (segfault) on derived type which has a recursive
allocatable component of the same type, and a static
component of another type which has a "final"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518
--- Comment #1 from Jeffrey A. Law ---
It looks like BIT_INSERT_EXPR is being expanded as a simple move even though
its got BLKmode operands. That's a no-no. We have go use the mem* routines
rather than a simple move insn.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90520
Bug ID: 90520
Summary: [10 regression] libstdc++-xmethods/unique_ptr.cc
triggers python failure starting with r271158
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90521
Bug ID: 90521
Summary: error: names the constructor, not the type
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90520
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90522
Bug ID: 90522
Summary: unrecognizable insn (V8SF)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523
Bug ID: 90523
Summary: lto1 segfault in arm_parse_cpu_option_name
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90522
--- Comment #1 from Leo Sandoval ---
I just confirmed: without -Ofast, issue is not observed, thus the latter
optimization flag is triggering the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523
--- Comment #1 from krux ---
So this one must be null:
https://github.com/gcc-mirror/gcc/blob/65af043/gcc/config/arm/arm.c#L3148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518
--- Comment #2 from rguenther at suse dot de ---
On May 17, 2019 5:49:21 PM GMT+02:00, law at redhat dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90518
>
>--- Comment #1 from Jeffrey A. Law ---
>It looks like BIT_INSERT_EXPR is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523
--- Comment #2 from Alexander Monakov ---
See also PR 87076, which has a reduced testcase and some root-cause analysis
(likely a duplicate).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
--- Comment #21 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 17:23:30 2019
New Revision: 271334
URL: https://gcc.gnu.org/viewcvs?rev=271334&root=gcc&view=rev
Log:
PR fortran/54613
* gfortran.map (GFORTRAN_9.2): New symbo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
--- Comment #22 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 17:24:27 2019
New Revision: 271335
URL: https://gcc.gnu.org/viewcvs?rev=271335&root=gcc&view=rev
Log:
PR fortran/54613
* gfortran.map (GFORTRAN_9.2): Export _g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523
--- Comment #3 from krux ---
Possible, gcc was built with --disable-multilib --with-arch=armv7e-m
--with-mode=thumb --with-float=soft.
And if I replace -mcpu=cortex-m4 with -march=armv7e-m in my test command
there's no crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
--- Comment #23 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 17:50:55 2019
New Revision: 271336
URL: https://gcc.gnu.org/viewcvs?rev=271336&root=gcc&view=rev
Log:
PR fortran/54613
* gfortran.map (GFORTRAN_9.2): Export _g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90498
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #2 from Janne Blomqvist ---
Author: jb
Date: Fri May 17 18:18:04 2019
New Revision: 271340
URL: https://gcc.gnu.org/viewcvs?rev=271340&root=gcc&view=rev
Log:
libfortran/90038: Use posix_spawn instead of fork
fork() semantics can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90521
--- Comment #1 from Marc Glisse ---
And what do you expect std::string::basic_string means?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #6 from Segher Boessenkool ---
Confirmed. We have for the thunk
.set.LTHUNK0,_ZN12Intermediate1vEv
.align 2
.p2align 4,,15
.globl _ZThn8_N12Intermediate1vEv
.type _ZThn8_N12Intermediat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90521
--- Comment #2 from colton.wernet at linquest dot com ---
(In reply to Marc Glisse from comment #1)
> And what do you expect std::string::basic_string means?
I agree it is redundant because it just means std::string::string. I am not
certain why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433
--- Comment #3 from Thomas Schwinge ---
Author: tschwinge
Date: Fri May 17 19:13:04 2019
New Revision: 271343
URL: https://gcc.gnu.org/viewcvs?rev=271343&root=gcc&view=rev
Log:
[PR89433] Refer to OpenACC 'routine' clauses from "omp declare targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433
--- Comment #4 from Thomas Schwinge ---
Author: tschwinge
Date: Fri May 17 19:13:15 2019
New Revision: 271344
URL: https://gcc.gnu.org/viewcvs?rev=271344&root=gcc&view=rev
Log:
[PR89433] Use 'oacc_verify_routine_clauses' for C/C++ OpenACC 'routi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433
--- Comment #5 from Thomas Schwinge ---
Author: tschwinge
Date: Fri May 17 19:13:26 2019
New Revision: 271345
URL: https://gcc.gnu.org/viewcvs?rev=271345&root=gcc&view=rev
Log:
[PR89433] Repeated use of the C/C++ OpenACC 'routine' directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #3 from Janne Blomqvist ---
Further testing revealed that it leaves zombie processes around as the child is
never wait()'ed for. E.g.
program cmd
implicit none
call execute_command_line("echo hi", wait=.FALSE.)
call sleep(30)
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524
Bug ID: 90524
Summary: attribute name and argument mixed up in an error
message
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90482
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #5 from Janne Blomqvist ---
(In reply to kargl from comment #4)
> What does 'it' refer to? fork() is leaving a zombie?
> posix_spawn() is leaving a zombie?
posix_spawn. Though I guess the old fork() code suffers from the same issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #6 from Steve Kargl ---
On Fri, May 17, 2019 at 07:35:46PM +, jb at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
>
> --- Comment #5 from Janne Blomqvist ---
> (In reply to kargl from comment #4)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 19:47:18 2019
New Revision: 271348
URL: https://gcc.gnu.org/viewcvs?rev=271348&root=gcc&view=rev
Log:
Backported from mainline
2019-04-26 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90303
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 19:48:25 2019
New Revision: 271349
URL: https://gcc.gnu.org/viewcvs?rev=271349&root=gcc&view=rev
Log:
Backported from mainline
2019-05-03 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90326
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 19:49:54 2019
New Revision: 271350
URL: https://gcc.gnu.org/viewcvs?rev=271350&root=gcc&view=rev
Log:
Backported from mainline
2019-05-10 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90383
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 19:50:52 2019
New Revision: 271351
URL: https://gcc.gnu.org/viewcvs?rev=271351&root=gcc&view=rev
Log:
Backported from mainline
2019-05-10 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90385
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 19:51:32 2019
New Revision: 271352
URL: https://gcc.gnu.org/viewcvs?rev=271352&root=gcc&view=rev
Log:
Backported from mainline
2019-05-10 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Fri May 17 19:52:06 2019
New Revision: 271353
URL: https://gcc.gnu.org/viewcvs?rev=271353&root=gcc&view=rev
Log:
Backported from mainline
2019-05-15 Jakub Jelinek
1 - 100 of 126 matches
Mail list logo
