https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |12.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a53781c8fd258608780821168a7f5faf7be63690
commit r12-3538-ga53781c8fd258608780821168a7f5faf7be63690
Author: Jason Merrill
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329
--- Comment #2 from Hugo van der Sanden ---
I guess this is justified by the second paragraph of the -Wmaybe-uninitialized
docs: "In addition, passing a pointer (or in C++, a reference) to an
uninitialized object to a const-qualified function ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102336
--- Comment #1 from CVS Commits ---
The master branch has been updated by Max Filippov :
https://gcc.gnu.org/g:4633d623d7c112a8e239b84b2d85caaef02d316c
commit r12-3535-g4633d623d7c112a8e239b84b2d85caaef02d316c
Author: Max Filippov
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80629
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-debug
--- Comment #2 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327
--- Comment #2 from Hongtao.liu ---
Yes, it's redundant, Also vector init for v8hf is not optimal
, refer to https://godbolt.org/z/M6a4aav48.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102337
Bug ID: 102337
Summary: possibly wrong warning about truncation
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45256
--- Comment #4 from Andrew Pinski ---
With IVOPTs we get:
# ivtmp.13_97 = PHI
_34 = MEM[(const __be32 *)_28 + -4B + ivtmp.13_97 * 4];
_36 = MEM[(const __be32 *)_27 + -4B + ivtmp.13_97 * 4];
if (_34 != _36)
goto ; [5.50%]
else
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324
Andrew Pinski changed:
What|Removed |Added
Target Milestone|10.4|---
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306
--- Comment #9 from Eric Botcazou ---
> The patch in c#5 looks good. Since you test added_sets_0 and added_sets_1
> as well, does this mean it could happen before this patch as well?
No idea, but it seems strange to disallow the copy for i2 an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102336
Bug ID: 102336
Summary: plugins for xtensa-elf gcc cannot be built because
xtensa-config.h is missing
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244
--- Comment #6 from Andrew Pinski ---
Here are some better testcases as the power of 2 case can be handled on the rtl
level as it is just a shift.
extern struct s{
int a, b, c, d, e, f, g, h;
} data[];
int find(int i, int j)
{
struct s *a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559
Andrew Pinski changed:
What|Removed |Added
CC||mikulas at artax dot
karlin.mff.cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63264
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93903
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-14
Component|inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84187
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396
--- Comment #4 from Jason Merrill ---
Created attachment 51462
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51462&action=edit
patch to allow redeclaration in module
This isn't a proper fix, but may let you make progress with modularizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306
--- Comment #8 from Segher Boessenkool ---
The patch in c#5 looks good. Since you test added_sets_0 and added_sets_1
as well, does this mean it could happen before this patch as well?
We already did have some things that did combine 2->2 (via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396
--- Comment #3 from Jonathan Wakely ---
cp/rtti.c defines:
/* Declare language defined type_info type and a pointer to const
type_info. This is incomplete here, and will be completed when
the user #includes . There are language defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2021-03-05 00:00:00 |2021-9-14
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #6 from Andreas Krebbel ---
(insn 9 8 10 2 (set (strict_low_part (reg:SI 66))
(mem/c:SI (plus:SI (reg/f:SI 64)
(const_int 4 [0x4])) [1 read_inode_val+0 S4 A32]))
With -mesa this should be a simple move. Howev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Andreas Krebbel changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
--- Comment #8 from Andrew Pinski ---
I thought there was another bug which was asking for something similar that I
did not link here yet. It had a reference to a syntax something like {"r1"}.
But I can't find it right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
Andrew Pinski changed:
What|Removed |Added
Component|inline-asm |c
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102333
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71246
--- Comment #1 from Andrew Pinski ---
So I think there needs to be some better documentation here with respect to the
constraints that allow memory and the + modifier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94180
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
--- Comment #12 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #11)
> as mentioned in another bug, this is more of a documentation issue and the
> internal details on how inline-asm works.
Yup. I suggest we advice to always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311
--- Comment #5 from anlauf at gcc dot gnu.org ---
For the sake of completeness: considered as "obvious"
https://gcc.gnu.org/pipermail/fortran/2021-September/056521.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #10 from Jakub Jelinek ---
The optimize attribute is how different options are represented in LTO
compilation, so it grew over years from perhaps initial debugging use to
something that is used everywhere. And we definitely aren't g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.3
Summary|gcc-11 -Warray-b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102050
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #9 from Kees Cook ---
(In reply to Jakub Jelinek from comment #8)
> So, instead (when building the kernel with sanitization) build with
> -fsanitize=signed-integer-overflow and no -fno-strict-overflow, and
> the routines where you wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.5
Summary|Volatile pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98774
--- Comment #5 from Andrew Pinski ---
For the trunk (without -ffast-math), the perms are done too early:
vect__5.32_53 = VEC_PERM_EXPR ;
vect__5.33_54 = VEC_PERM_EXPR ;
vect__5.34_55 = VEC_PERM_EXPR ;
_3 = *mag_9(D);
_58 = {_3, _3};
v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:b305ec979d9dfc8153859a62a8ab9dd43c3bfc73
commit r12-3533-gb305ec979d9dfc8153859a62a8ab9dd43c3bfc73
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98774
--- Comment #4 from Ivan Sorokin ---
I retested the sample on GCC 11.2.
https://godbolt.org/z/xrarP3zbY
Compared to Clang 12.0.1 GCC still generates 6 more instructions in total and
does 6 mulpd against Clang's 4 mulpd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102335
--- Comment #1 from Andrew Pinski ---
Internal GCC details:
Most likely because there is a TARGET_EXPR in the IR which causes it to be
considered a side effect:
<) >;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102335
Andrew Pinski changed:
What|Removed |Added
Severity|normal |minor
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102335
Bug ID: 102335
Summary: gcc misses -Wunused-value
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78963
--- Comment #1 from Eyal Rozenberg ---
... and perhaps I should add that, under certain circumstances, perhaps it
should be possible to just mov four bytes from memory and ignore one of the
bytes. On platforms where access must be aligned that wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102334
Bug ID: 102334
Summary: [12 Regression] ICE in trans_associate_var, at
fortran/trans-stmt.c:1794
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102333
--- Comment #1 from G. Steinmetz ---
Compiles with "allocatable" instead :
$ cat z2.f90
function f(x) result(y)
class(*), allocatable :: y
contains
function g() result(z)
procedure(f), allocatable :: z
end
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102333
Bug ID: 102333
Summary: [9/10/11/12 Regression] ICE in
gfc_generate_function_code, at
fortran/trans-decl.c:6941
Product: gcc
Version: 12.0
Status: UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332
Bug ID: 102332
Summary: ICE in select_type_set_tmp, at fortran/match.c:6366
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331
Bug ID: 102331
Summary: ICE in attr_decl1, at fortran/decl.c:8691
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102330
Bug ID: 102330
Summary: [12 Regression] ICE in expand_gimple_stmt_1, at
cfgexpand.c:3932
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329
Bug ID: 102329
Summary: pointer "maybe uninitialized" right after assignment
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324
--- Comment #2 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #1)
> So likely we're seeing a POLY_INT here which could eventually be handled the
> same as an INTEGER_CST but the question is what to do else (well,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102328
Bug ID: 102328
Summary: ICE when compare std::list iterator
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #8 from Jakub Jelinek ---
So, instead (when building the kernel with sanitization) build with
-fsanitize=signed-integer-overflow and no -fno-strict-overflow, and
the routines where you want wrapv behavior and not runtime traps build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #7 from Kees Cook ---
The problem the kernel needs to solve is basically having our cake and eating
it too. :)
In _most_ situations, we want signed overflows to trap (i.e. get caught by
"-fsanitize=signed-integer-overflow").
In som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102163
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:de07cff96abd43f6f65dcf333958899c2ec42598
commit r12-3527-gde07cff96abd43f6f65dcf333958899c2ec42598
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305
--- Comment #6 from Jonathan Wakely ---
It should be backported IMHO.
I don't see how anybody can be relying on is_default_constructible being wrong,
that doesn't make much sense. You check that trait in SFINAE contexts to see if
you can constr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305
--- Comment #5 from Jakub Jelinek ---
On one side, some code could be relying on bug compatibility and so it would be
undesirable to change it on release branches, on the other side the current
behavior there is just weird,
#include
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327
David Binderman changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327
Bug ID: 102327
Summary: gcc/config/i386/i386-expand.c:14678: Suspicious coding
?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295
--- Comment #6 from Jakub Jelinek ---
Fixed for 12+ so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305
--- Comment #4 from Jakub Jelinek ---
Fixed for 12.0 so far.
Do we want to backport it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:818c505188ff5cd8eb048eb0e614c4ef732225bd
commit r12-3526-g818c505188ff5cd8eb048eb0e614c4ef732225bd
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f008fd3a480e3718436156697ebe7eeb47841457
commit r12-3525-gf008fd3a480e3718436156697ebe7eeb47841457
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #22 from Chip Kerchner ---
(In reply to Chip Kerchner from comment #21) - Forgot one line of code
> --
> #pragma GCC target "cpu=power10"
> int main() {
> float *b;
> __vector_quad c;
> __builtin_mma_disasse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
--- Comment #21 from Chip Kerchner ---
I'm also seeing MMA problems with LTO. With this simple program (main.ii)
--
int main() {
float *b;
__vector_quad c;
__builtin_mma_disassemble_acc(b, &c);
return 0;
}
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306
--- Comment #5 from Eric Botcazou ---
Created attachment 51460
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51460&action=edit
Tentative fix
To be tested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306
--- Comment #4 from Eric Botcazou ---
There is substantial checking for volatile references in can_combine_p but it
implicitly assumes that the combination reduces the number of instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101981
--- Comment #9 from Martin Liška ---
So GCC 7 emits:
$ nm --print-size pr101981-2.o
0034 T big_switch
and GCC master emits:
nm --print-size pr101981-2.o
0030 T big_switch
So the code is smaller with the current mast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102326
Bug ID: 102326
Summary: ICE in tree_to_uhwi, at tree.c:4520
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101981
--- Comment #8 from Martin Liška ---
>
> Not a big difference in term of instructions is this case but as much as the
> switch increases, the difference becomes huge (in my case it switched from
> 75 to 94 lines)
> Code size increases of about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
--- Comment #7 from zhuguanghong ---
I get it, thank you for your answer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102242
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102313
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
--- Comment #5 from zhuguanghong ---
But what I want is that 0-7cpu can run this thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102313
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:33fdbbe4ce6055eb858096d01720ccf94aa854ec
commit r12-3524-g33fdbbe4ce6055eb858096d01720ccf94aa854ec
Author: Tobias Burnus
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
--- Comment #4 from zhuguanghong ---
This leads to when I set the environment variable "GOMP_CPU_AFFINITY=0-7" and
call the initialize_env function, the thread will be automatically bound to one
cpu and cannot be scheduled to other cpu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
--- Comment #3 from zhuguanghong ---
hi ，thanks for your reply
initialize_env (void)
1 {
0
1 if (parse_affinity (ignore))
2 {
3 if (gomp_global_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
--- Comment #2 from Jakub Jelinek ---
I'm sorry but from the above it is impossible to decipher what do you think is
a bug and why.
Can you write a few sentences about what env var or cpu configuration do you
think misbehaves and why?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102320
--- Comment #1 from zhuguanghong ---
fix？ like this ?
while(gomp_places_list_len-- ){
*(gomp_places_list[0]) | = *(gomp_places_list[gomp_places_list_len])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-09-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325
Bug ID: 102325
Summary: gm2 testsuite drivers should be unique
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |10.4
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102324
Bug ID: 102324
Summary: ICE in initialize_matrix_A, at tree-data-ref.c:3959
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102323
Bug ID: 102323
Summary: gm2 testsuite needs to be parallelized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102322
Bug ID: 102322
Summary: libgm2 Makefiles should be self-contained
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101389
--- Comment #2 from Rainer Orth ---
(In reply to Gaius Mulley from comment #1)
> Thanks for the report - I've pushed some fixes to various Makefiles. I've
> tested it using make -j48 and believe it is fixed.
A -j48 build on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392
Rainer Orth changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101388
Rainer Orth changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101388
--- Comment #3 from Rainer Orth ---
Created attachment 51458
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51458&action=edit
Missed part of patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101391
--- Comment #4 from Rainer Orth ---
Created attachment 51457
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51457&action=edit
Additonal patch providing cgetopt_*
1 - 100 of 138 matches
Mail list logo
