https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51765
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Arseny Solokha changed:
What|Removed |Added
Component|c |middle-end
--- Comment #2 from Arseny S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
--- Comment #3 from Jakub Jelinek ---
The problem is that for these packed structs the DECL_BIT_FIELD_REPRESENTATIVE
is not integral FIELD_DECL that the c-omp.c code assumes. BIT_FIELD_REF seems
to work with non-integral base types from which th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88974
Bug ID: 88974
Summary: [9 Regression] ICE: Segmentation fault (in
linemap_resolve_location)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: error-recove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88975
Bug ID: 88975
Summary: ICE: Segmentation fault (in verify_ssa or gimple_code)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88976
Bug ID: 88976
Summary: ICE in fold_convert_loc, at fold-const.c:2552
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936
--- Comment #9 from Richard Biener ---
(In reply to Jan Hubicka from comment #7)
> Hi,
> there is ipa_reduced_postorder that will compute SCCs and store scc
> index.
OK, from looking at examples it seems that I can access node->aux
as ipa_dfs_in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #5 from Marat Stanichenko ---
(In reply to Richard Biener from comment #1)
> This is because it still needs to generate the std::string objects at the
> caller
Thank you very much for the comment! That is probably why I had to add a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88977
Bug ID: 88977
Summary: __builtin_is_constant_evaluated() as function template
argument causes substitution failure
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #11 from Thomas De Schampheleire ---
Any feedback? With the reduced testcase qemu is out of the picture.
Do you agree that this is a bug in gcc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88948
--- Comment #3 from Uroš Bizjak ---
Created attachment 45494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45494&action=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044
--- Comment #17 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #16)
> Fixed.
I confirm the problem I mentioned in #c3 is now fixed. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #5 from Anton Blanchard ---
Martin: "gcc -c x.c" was enough to hit it on a build of trunk on my POWER9
ppc64le box.
Jakub: Thanks, that fixes it for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #6 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Jan 22 14:03:22 2019
New Revision: 268151
URL: https://gcc.gnu.org/viewcvs?rev=268151&root=gcc&view=rev
Log:
[arm] PR target/88469 fix incorrect argument passing with 64-bit bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #21 from ktkachov at gcc dot gnu.org ---
So the actual hot loop in xz_r does:
typedef unsigned char __uint8_t;
typedef unsigned int __uint32_t;
typedef unsigned long long __uint64_t;
int
foo (const __uint64_t len_limit, const __uint8_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936
--- Comment #10 from Richard Biener ---
So the idea for the fix is to make locals that escape through recursive edges
behave as if they were really *ptr with ptr pointing to &local, &localp
where localp would be "the other locals". This could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #6 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, maratrus at mail dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
>
> --- Comment #5 from Marat Stanichenko ---
>
> (In reply to Richard Biener from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
Richard Earnshaw changed:
What|Removed |Added
Summary|[7/8/9 regression] AAPCS - |[7/8 regression] AAPCS -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #22 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, ktkachov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
>
> --- Comment #21 from ktkachov at gcc dot gnu.org ---
> So the actual hot loop in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919
--- Comment #4 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, clyon at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919
>
> Christophe Lyon changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88978
Bug ID: 88978
Summary: Failed outer loop vectorization with grouped accesses
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88978
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979
Bug ID: 88979
Summary: [C++20] P0634R3 not working for constructor parameter
types
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
--- Comment #3 from Alexander Monakov ---
Note, without the attribute gcc passes the union on an SSE register, so it
doesn't look like TImode on the union matters (otherwise it would be passed via
rdx:rax register pair):
typedef unsigned long u6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
--- Comment #22 from Jonathan Wakely ---
Pedro, I'm seeing this again with GDB 8.2 (specifically gdb-8.2-6.fc29.x86_64).
Is it likely to be something different, or a GDB regression?
(I still want a libstdc++ fix that works for older GDB anyway)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #7 from Marat Stanichenko ---
(In reply to rguent...@suse.de from comment #6)
> > Do you believe that compiler can do better in such situations? Or the
> > current
> > behaviour is perfectly valid and no improvements are really neede
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #6 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Jan 22 14:53:41 2019
New Revision: 268152
URL: https://gcc.gnu.org/viewcvs?rev=268152&root=gcc&view=rev
Log:
i386: Load external function address via GOT slot
With noplt attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #4 from Tomalak Geret'kal ---
To be honest I'd expect this in less trivial circumstances too. If, at a given
stage of processing, the only possible paths towards a match all require a
prefix that's already been ruled out, that should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
--- Comment #23 from Jonathan Wakely ---
Actually, I wonder if it's caused by r264958 because 'std::string' is no longer
unambiguous in libstdc++.so
In some translation units it is a typedef for std::basic_string and in
other translation units i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #18 from Segher Boessenkool ---
(In reply to Alan Modra from comment #17)
> > Is anything broken though?
>
> Yes, as demonstrated by the testcase.
I couldn't get the testcase to link, I don't think I have an __floatunsidf
anywhere,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88980
Bug ID: 88980
Summary: [9 regression] segfault on allocatable string member
assignment
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #8 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, maratrus at mail dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
>
> --- Comment #7 from Marat Stanichenko ---
> (In reply to rguent...@suse.de from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86756
--- Comment #7 from Jonathan Wakely ---
There are more changes needed to the library code, to stop using chdir, mkdir
etc. when not supported. This was first brought up in
https://gcc.gnu.org/ml/libstdc++/2019-01/msg00039.html
I'm not sure how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88981
Bug ID: 88981
Summary: [nvptx, openacc, libgomp] How to handle async regions
without corresponding wait
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88981
Tom de Vries changed:
What|Removed |Added
Keywords||openacc
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88740
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Tue Jan 22 16:08:18 2019
New Revision: 268154
URL: https://gcc.gnu.org/viewcvs?rev=268154&root=gcc&view=rev
Log:
PR libstdc++/88740 Print assertion messages to stderr
PR libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88740
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #20 from Bill Schmidt ---
Oh, sorry, I missed that in all the commentary. I had looked at the code and
seen the "obvious" problem in the expansion, and noted you had suggested that
also. Should have read further.
I think that's rig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #21 from Bill Schmidt ---
We should probably disable the _v4sf_scalar one for LE also, as this seems to
be doing a similar trick for V4SF.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #22 from Bill Schmidt ---
(I'll test with both disabled for LE and report results.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88909
--- Comment #1 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Jan 22 16:20:25 2019
New Revision: 268155
URL: https://gcc.gnu.org/viewcvs?rev=268155&root=gcc&view=rev
Log:
i386: Add mask2 to builtin_description
There are
struct builtin_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #5 from Tim Shen ---
(In reply to Tomalak Geret'kal from comment #4)
> To be honest I'd expect this in less trivial circumstances too. If, at a
> given stage of processing, the only possible paths towards a match all
> require a prefi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88982
Bug ID: 88982
Summary: ICE in tsubst_pack_expansion, at cp/pt.c:12221
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983
Bug ID: 88983
Summary: ICE in label_matches, at cp/constexpr.c:4035
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88984
Bug ID: 88984
Summary: [9 Regression] ICE in genericize_switch_stmt, at
cp/cp-gimplify.c:377
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-vali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #23 from Jakub Jelinek ---
Created attachment 45496
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45496&action=edit
gcc9-pr87064.patch
Patch I've so far tested on powerpc64le-linux only, where it fixed
FAIL: libgomp.oacc-fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88938
--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jan 22 16:32:47 2019
New Revision: 268156
URL: https://gcc.gnu.org/viewcvs?rev=268156&root=gcc&view=rev
Log:
PR target/88938
* config/i386/i386.c (ix86_expand_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #6 from Segher Boessenkool ---
That patch looks good, and is pre-approved. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88938
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jan 22 16:35:53 2019
New Revision: 268157
URL: https://gcc.gnu.org/viewcvs?rev=268157&root=gcc&view=rev
Log:
PR target/88938
* config/i386/i386.c (ix86_expand_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #6 from Tim Shen ---
(In reply to Tomalak Geret'kal from comment #4)
> To be honest I'd expect this in less trivial circumstances too. If, at a
> given stage of processing, the only possible paths towards a match all
> require a prefi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88984
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88938
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #7 from Tomalak Geret'kal ---
(In reply to Tim Shen from comment #5)
> For the original test case, have you tried regex_match() with "what.*"?
That behaves as I'd expect
(http://quick-bench.com/AKdMnnhA03T1vwfN9sf53xlbD6s).
> Do you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #5 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #1)
> I've asked the ifort/clang maintainers about why they keep violating the
> standard, but haven't heard back from them. And I must say I was trying
> hard to read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Martin Sebor changed:
What|Removed |Added
Blocks||84774
--- Comment #2 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88909
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
--- Comment #3 from Martin Sebor ---
Created attachment 45497
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45497&action=edit
canonicalize_pathname function extracted from the translation unit.
Attached is the canonicalize_pathname functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #6 from Jakub Jelinek ---
No, gcc always implements just one OpenMP version, the latest one that has
support written.
Defaulting to almost 8 years old OpenMP version is weird.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #21 from Steve Ellcey ---
If I look at this specific example:
int f2 (int x, int y)
{
return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
}
Before the combine change, I see in x.c.260r.combine:
Trying 8, 9 -> 15:
8: r98:SI=x1:SI<<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88911
--- Comment #3 from David Malcolm ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01311.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88294
--- Comment #5 from Marek Polacek ---
I can try. Unfortunately, the patch for 86476 doesn't fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #7 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #6)
> No, gcc always implements just one OpenMP version, the latest one that has
> support written.
E.g. because of this everyone affected will need to either just comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #8 from Jakub Jelinek ---
Well, in your case firstprivate is really what you want, unless the compiler
figures that out for you magically you want to firstprivatize these variables.
A different thing is of course if you have a large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #9 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #8)
> Well, in your case firstprivate is really what you want, unless the compiler
> figures that out for you magically you want to firstprivatize these
> variables.
H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 88973, which changed state.
Bug 88973 Summary: [8/9 Regression] New -Wrestrict warning since r268048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88988
Bug ID: 88988
Summary: [8/9 Regression] ICE: Segmentation fault (in
lookup_name_real_1)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88986
Bug ID: 88986
Summary: [9 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'error_mark'
in member_vec_binary_search, at cp/name-lookup.c:1136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88985
Bug ID: 88985
Summary: [9 Regression] ICE in estimate_edge_devirt_benefit, at
ipa-fnsummary.c:2585
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88987
Bug ID: 88987
Summary: [9 Regression] ICE: unexpected expression '(bool)sm'
of kind implicit_conv_expr
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83754
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #22 from Wilco ---
(In reply to Steve Ellcey from comment #21)
> If I look at this specific example:
>
> int f2 (int x, int y)
> {
> return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
> }
>
> Is this because of x0 (a hard register) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989
Bug ID: 88989
Summary: ICE in resolvePropertiesX, at d/dmd/expression.c:251
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88990
Bug ID: 88990
Summary: ICE in get_symbol_decl, at d/decl.cc:1097
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88981
--- Comment #2 from Tom de Vries ---
A good thing to note here, when adding #pragma acc wait, the program (compiled
with -O0) takes ~10 seconds to finish on my quadro 1200m.
Without the pragma acc wait, it still takes 10 seconds.
When inspectin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #23 from Wilco ---
Author: wilco
Date: Tue Jan 22 17:49:46 2019
New Revision: 268159
URL: https://gcc.gnu.org/viewcvs?rev=268159&root=gcc&view=rev
Log:
Fix vect-nop-move.c test
Fix a failing test - changes in Combine mean the test n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80257
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39795
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
gcc-bugs@gcc.gnu.org
+
氏瑚优 惠 办 理 正 规 税 票，认 证 后 付 款。
详 电：李 生，136—6075— 4190，
业 q：157— 533— 2698
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #8 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Jan 22 17:56:02 2019
New Revision: 268160
URL: https://gcc.gnu.org/viewcvs?rev=268160&root=gcc&view=rev
Log:
[arm] Further fixes for PR88469
A bitfield that is exactly the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #10 from Jakub Jelinek ---
firstprivate is that each thread will have its own copy of the variable,
initialized from the original.
shared means there is just one copy.
E.g. if you take the address of the variable within the region, fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88991
Bug ID: 88991
Summary: missing warning on a strcpy and strlen from a
zero-length array
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88991
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979
--- Comment #2 from 19Sebastian95 at gmx dot de ---
I'm sorry if I'm misinterpreting this, but the program I wrote does compile
with gcc 9.0, as the "error" part is commented out, so I'll just write what to
do to get the descriped error:
If my c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88992
Bug ID: 88992
Summary: missing -Warray-bounds indexing into a zero-length
array
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88991
Martin Sebor changed:
What|Removed |Added
Blocks||88443
--- Comment #2 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88423
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347
--- Comment #2 from David Malcolm ---
*** Bug 88423 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88984
--- Comment #2 from Jakub Jelinek ---
Created attachment 45498
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45498&action=edit
gcc9-pr88984.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #10 from Devin Hussey ---
I also want to add that aarch64 shouldn't even be spilling; it has 32 NEON
registers and with 128 byte vectors it should only use 24.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
101 - 200 of 256 matches
Mail list logo
