https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82338
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66249
--- Comment #2 from Eric Gallager ---
(In reply to Marek Polacek from comment #1)
> -Wformat-signedness has many issues (which was the reason it's been pulled
> out of -Wformat=2).
Maybe it's time for a -Wformat=3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82648
Eric Gallager changed:
What|Removed |Added
CC||dj at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54582
Eric Gallager changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176
Eric Gallager changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81669
Eric Gallager changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71175
--- Comment #2 from Eric Gallager ---
svn blame says many people were involved in this code; not sure which of them
to cc...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50355
--- Comment #1 from Eric Gallager ---
I can't seem to find the code in question in the source file any longer...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52124
Eric Gallager changed:
What|Removed |Added
CC||jayants at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59205
Eric Gallager changed:
What|Removed |Added
CC||nickc at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69285
Eric Gallager changed:
What|Removed |Added
CC||paolo at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80672
Eric Gallager changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91676
Alan Modra changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77936
Eric Gallager changed:
What|Removed |Added
CC||singler at gcc dot gnu.org
Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71327
--- Comment #1 from Eric Gallager ---
(In reply to David Binderman from comment #0)
> libiberty/cplus-dem.c:2702]: (style) Redundant condition: If 'EXPR == '_'',
> the comparison 'EXPR' is always true.
>
> Source code is
>
> while (*scan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71324
Eric Gallager changed:
What|Removed |Added
CC||kyukhin at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69286
Eric Gallager changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66469
--- Comment #1 from Eric Gallager ---
I can't seem to find the mentioned code in the source file any longer...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70800
--- Comment #5 from Eric Gallager ---
(In reply to David Binderman from comment #0)
> trunk/libgcc/config/libbid/bid_binarydecimal.c:143934]: (style) Expression
> '(X & 0x) > 0xf423f' is always false.
>
> Source code is
>
> nan(s,((
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85978
Eric Gallager changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
--- Comment #4 from Guillaume ---
Thanks :)
Le sam. 28 sept. 2019 à 02:13, pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> a écrit :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
>
> Andrew Pinski changed:
>
>What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
--- Comment #2 from Guillaume ---
Thanks for your quick reply.
Yes, I actually managed to write a minimal test case showing the problem
(attached source file).
Compiling it with:
aarch64-elf-gcc -mcpu=cortex-a72 -march=armv8-a+crc -O3 -mstrict-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
--- Comment #1 from Andrew Pinski ---
Do you have a full testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925
--- Comment #4 from Marek Polacek ---
Also ICEs without the template:
struct A {};
int fn(A);
struct B {
A a;
decltype(fn(a)) p;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925
--- Comment #3 from Marek Polacek ---
struct A {};
template T fn(T);
class B {
A a;
decltype(fn(a)) p;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jason at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504
--- Comment #8 from Jason Merrill ---
Created attachment 46968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46968&action=edit
partial fix
This fixes handling of references to the first object, but not later ones, so
several of the testca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
Bug ID: 91927
Summary: -mstrict-align doesn't prevent unaligned accesses at
-O2 and -O3 on AARCH64 targets
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88203
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Fri Sep 27 20:14:24 2019
New Revision: 276212
URL: https://gcc.gnu.org/viewcvs?rev=276212&root=gcc&view=rev
Log:
PR c++/88203
c-family/
* c-common.h (c_omp_predefined_vari
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #14 from Jakub Jelinek ---
Author: jakub
Date: Fri Sep 27 20:13:00 2019
New Revision: 276211
URL: https://gcc.gnu.org/viewcvs?rev=276211&root=gcc&view=rev
Log:
PR middle-end/91920
* gimplify.c (omp_default_clause): Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924
--- Comment #9 from Eyal Rozenberg ---
(In reply to Jason Merrill from comment #8)
> I think if the object were not an actual Aint, performing the standard
> conversion to A* should be undefined, allowing the devirtualization. But
> I'm not find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
Jakub Jelinek changed:
What|Removed |Added
Attachment #46956|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80936
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #7 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173
--- Comment #5 from Marc Glisse ---
A similar example was reported on https://stackoverflow.com/q/57964217/1918193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #26 from Segher Boessenkool ---
Yeah, and it probably should be a param (that different targets can default
differently, per CPU probably). On most Power CPUs all loops take a minimum
number of cycles per iteration (say, three), but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91926
--- Comment #1 from José Rui Faustino de Sousa ---
Created attachment 46966
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46966&action=edit
Fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91926
Bug ID: 91926
Summary: assumed rank optional
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80936
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91910
--- Comment #7 from Jonathan Wakely ---
Fixed on trunk only for now but I might backport it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91910
--- Comment #6 from Jonathan Wakely ---
Author: redi
Date: Fri Sep 27 16:20:40 2019
New Revision: 276184
URL: https://gcc.gnu.org/viewcvs?rev=276184&root=gcc&view=rev
Log:
PR libstdc++/91910 fix data race in Debug Mode destructors
Fix data race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68686
Joseph S. Myers changed:
What|Removed |Added
CC||tydeman at tybor dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91924
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91919
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Sep 27 15:48:51 2019
New Revision: 276183
URL: https://gcc.gnu.org/viewcvs?rev=276183&root=gcc&view=rev
Log:
PR target/91919
* config/arm/arm.md (mlal): Remove SE wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88203
--- Comment #7 from Jakub Jelinek ---
Created attachment 46964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46964&action=edit
gcc10-pr88203.patch
Untested implementation of that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88203
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from Jakub Jelin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79328
Arnaud Desitter changed:
What|Removed |Added
CC||arnaud02 at users dot
sourceforge.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91923
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504
Jason Merrill changed:
What|Removed |Added
CC||n.eugene536 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89239
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70929
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925
--- Comment #2 from Marek Polacek ---
Started with r268075.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #25 from Richard Earnshaw ---
Well very small loops should be unrolled more than slightly larger ones. So
perhaps if the loop body is only 3 or 4 instructions it should be unrolled four
times but above that perhaps only twice.
Some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #19 from Manfred Schwarb ---
Created attachment 46963
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46963&action=edit
extended patch from comment #4 to also cover gfc_simplify_dble and
gfc_simplify_sngl
Note, I do not have nei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #13 from robert at robbieab dot com ---
The patch appears to fix both my test-case, and the original problem in
Darktable.
Darktable is using a 3 member array which does get modified, initialized to
-FLT_MAX and than used to store the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924
--- Comment #7 from Kamlesh Kumar ---
After this patch
diff --git a/gcc/ipa-polymorphic-call.c b/gcc/ipa-polymorphic-call.c
index 705af03..b76793f 100644
--- a/gcc/ipa-polymorphic-call.c
+++ b/gcc/ipa-polymorphic-call.c
@@ -1118,6 +1118,10 @@
ip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #12 from robert at robbieab dot com ---
Ah, thank you for the explanation.
I will try and test this today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #11 from Jakub Jelinek ---
BTW, dunno what darktable uses, but if it has possibly large automatic local
variable in the body with possibly large initializer and that variable isn't
really modified, you might as well make it static con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #10 from Jakub Jelinek ---
(In reply to robert from comment #9)
> Does the patch mean k[] gets marked as shared?
No, k is a local automatic variable in the scope of the worksharing loop body
and as such it is really private.
The patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91885
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Fri Sep 27 10:28:48 2019
New Revision: 276178
URL: https://gcc.gnu.org/viewcvs?rev=276178&root=gcc&view=rev
Log:
PR tree-optimization/91885
* gcc.dg/pr91885.c (__int64_t):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #9 from robert at robbieab dot com ---
Does the patch mean k[] gets marked as shared?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #33 from Andrew Pinski ---
See https://mails.dpdk.org/archives/dev/2019-September/144749.html also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #32 from Andrew Pinski ---
>I'm sure -flto-parition=none is needed for workaround, now.
This does not always work. I think if the symver was done in an archive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #7 from robert at robbieab dot com ---
Yeah, what Daniel said.
The test case here was just "something simple that triggers the problem".
The revised test cases also exhibit the problem for me, and shouldn't be racy,
or anything else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
robert at robbieab dot com changed:
What|Removed |Added
Attachment #46955|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
robert at robbieab dot com changed:
What|Removed |Added
Attachment #46954|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925
Bug ID: 91925
Summary: -fpack-struct causes a decltype with template to ICE
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #4 from Daniel Kolesa ---
Yeah, the testcase doesn't really matter, AFAIK the purpose here was just to
provide something that fails in the same way as darktable (which is the project
where this bug shows up).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #3 from Jakub Jelinek ---
Will fix, just note that the testcase is invalid (racy).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91909
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91909
--- Comment #6 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Fri Sep 27 08:21:37 2019
New Revision: 276175
URL: https://gcc.gnu.org/viewcvs?rev=276175&root=gcc&view=rev
Log:
Fix reduc_index==1 handling for COND_REDUCTION (PR91909)
75 matches
Mail list logo
