https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70934
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940
Bug ID: 70940
Summary: pmr::resource_adaptor requires optional allocator
requirements and incorrectly aligns returned pointers.
Product: gcc
Version: 6.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
--- Comment #2 from Jakub Jelinek ---
This is tree_unswitch_outer_loop -> hoist_guard not resetting debug stmts that
have some uses of SSA_NAMEs defined in the inner loop.
But the transformation is really weird.
We have:
loop7==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70925
Andreas Schaefer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70906
Markus Trippelsdorf changed:
What|Removed |Added
CC||j.v.dijk at tue dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70933
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70916
Jakub Jelinek changed:
What|Removed |Added
Summary|[6/7 Regression] gcc ICE at |[6 Regression] gcc ICE at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70396
--- Comment #6 from Richard Biener ---
(In reply to Martin Liška from comment #5)
> Hi.
>
> With the updated version of the compiler, I still get the ICE for:
>
> $ cat tc.ii
>
> void fn1() {
> unsigned *a = 0;
> for (int i; i; ++i) {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70396
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
Bug ID: 70941
Summary: [5/6/7 Regression] Test miscompiled with -O2.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #21 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #12)
> I still see:
>
> vcvtss2sd (%ecx,%eax,4), %xmm5, %xmm5
>
> without vxorpd.
You are looking in the cold section. This is by design, the splitter is
condi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70902
Kirill Yukhin changed:
What|Removed |Added
CC||kyukhin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
--- Comment #2 from Jakub Jelinek ---
I'd say this is already wrong in the original dump, the narrowing is done
wrongly:
*.original has:
a = (char) (((unsigned char) -((signed char) (d != 0 && c != 0) ^ -128(OVF))
- (unsigned char) b) + 19);
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085
--- Comment #9 from Jonathan Wakely ---
*** Bug 70898 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70898
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
--- Comment #3 from Richard Biener ---
4.9 has
(void) (a = (char) ((-(unsigned char) b - (unsigned char) ((signed char)
((signed char) d != 0 && (signed char) c != 0) ^ -128)) + 19)) >;
if ((signed char) a != -109)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
--- Comment #4 from Jakub Jelinek ---
That looks fine indeed.
The r217348 to r217349 *.original diff is similar (there is already the (OVF),
but that is probably not it, after all we strip OVF flag away during
gimplification:
- a = (char) ((-(un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70893
--- Comment #7 from Jonathan Wakely ---
(In reply to Кирилл from comment #5)
> It makes no sense, because you can explicitly specify little_endian in the
> template parameters, but not big_endian.
And the standard says that parameter is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70939
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70931
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.4
--- Comment #3 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70929
--- Comment #2 from Richard Biener ---
Looks reasonable if it can get some baking time on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70931
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70902
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #3 from Uroš
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942
Bug ID: 70942
Summary: [c++14] Incorrect deduction of generic lambda `auto&&`
parameter
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: critical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70824
--- Comment #1 from Truls Johnsen ---
Reduced the test case to only include and changed max to a
one-liner that still shows the same behavior. Removing constexpr from max, or
the (unused) template from a() makes the code compile:
#include
con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70824
Truls Johnsen changed:
What|Removed |Added
Attachment #38348|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940
--- Comment #1 from Jonathan Wakely ---
Also:
__null_memory_resource::do_is_equal() is missing a return statement, so returns
garbage off the stack.
__null_memory_resource doesn't need to be a class template.
new_delete_resource() returns some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
--- Comment #6 from Richard Biener ---
The negation issue is a latent fold-const.c issue which when folding
(19 - (unsigned char) b) + (unsigned char) ((signed char) (d != 0 && c != 0) ^
-128(OVF))
runs into the associate: case. We partially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70941
--- Comment #7 from Richard Biener ---
The following fixes this.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 235859)
+++ gcc/fold-const.c(working copy)
@@ -838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70943
Bug ID: 70943
Summary: 'conflicting declaration' error with repeated typedefs
in function templates
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70944
Bug ID: 70944
Summary: [7 Regression] ICE in immed_wide_int_const, at
emit-rtl.c:606 with -O3
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70396
Richard Biener changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70944
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70944
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
Bug ID: 70945
Summary: Offloading: compatibility of target and offloading
toolchains
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openacc, openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70946
Bug ID: 70946
Summary: Bad interaction between IVOpt and loop unrolling
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed May 4 12:08:45 2016
New Revision: 235868
URL: https://gcc.gnu.org/viewcvs?rev=235868&root=gcc&view=rev
Log:
libstdc++/70940 Start fixing polymorphic memory resources
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70946
--- Comment #1 from Wilco ---
PR36712 seems related to this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70947
Bug ID: 70947
Summary: regrename Go breakage on powerpc64
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70947
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
--- Comment #4 from Richard Biener ---
The following patch fixes the testcase (otherwise untested). Maybe the first
fix can be absorbed into this as well. I'll have some time on friday to
continue investigating how the fortran FE works but even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
--- Comment #5 from Richard Biener ---
Ok, ->backend_decl isn't always a decl. Thus sth like the following (I suppose
the check should be done in fortran terms rather than looking at backend_decl)
static void
place_decl_expr (gfc_symbol *sym)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70946
--- Comment #2 from Richard Biener ---
IVO before unrolling is never going to be optimal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70807
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
--- Comment #6 from Dominique d'Humieres ---
Started at r235817.
Which patch should I test?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70948
Bug ID: 70948
Summary: [7 Regression] r235622 caused
gcc.c-torture/execute/va-arg-pack-1.c execution
failure AArch64
Product: gcc
Version: 7.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Wed May 4 13:46:15 2016
New Revision: 235878
URL: https://gcc.gnu.org/viewcvs?rev=235878&root=gcc&view=rev
Log:
PR c/48778
* c-typeck.c (build_binary_op): Don't issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70804
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70371
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027
Ed Catmur changed:
What|Removed |Added
CC||ed at catmur dot co.uk
--- Comment #1 from E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68945
--- Comment #9 from Rainer Orth ---
Created attachment 38413
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38413&action=edit
sparcv9 support patch
This patch (on top of the previous one) fixes the sparcv9 failures reported
before.
As I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70771
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70930
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70775
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70938
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70771
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70051
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70775
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
--- Comment #23 from Gerhard Steinmetz
---
These variants give :
$ cat z1.f90
program p
type ta
integer :: a
end type
type t
type(ta), pointer :: b
end type
type(t) :: z
data z / t(ta(1)) /
end
$ gfortran-6 z1.f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
--- Comment #24 from Gerhard Steinmetz
---
And an exotic case :
$ cat z5.f90
module m
real, target :: a[*]
real, pointer :: z => a
end
$ gfortran-6 -fcoarray=lib -c z5.f90
f951: internal compiler error: in record_reference, at cgraphbuil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70051
--- Comment #2 from Martin Sebor ---
The bug here I believe is in how/where the C++ front end calls the sanitizer to
detect the overflow. With PR69517 resolved by having the C++ front end throw
an exception, this bug will become largely a non-is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70949
--- Comment #1 from Gerhard Steinmetz
---
This variant works :
(as known from several other PRs : change "class" to "type")
$ cat z2.f90
program p
type t1
end type
type t2
type(t1), pointer :: q
end type
type(t1), pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70949
Bug ID: 70949
Summary: ICE in propagate_necessity, at tree-ssa-dce.c:924
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70876
Ilya Enkovich changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70950
Bug ID: 70950
Summary: ICE with -O0 in simplify_subreg, at
simplify-rtx.c:5895
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70877
Ilya Enkovich changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70950
--- Comment #1 from Gerhard Steinmetz
---
Please note : both examples from pr70949 are simplifications of
this PR, thus related. Behaviour differs for -O0 (with/without ICE).
Compiling the example from above with optimization level -Og,
-Os, -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #23 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #22)
> Created attachment 38412 [details]
> Proposed patch
>
> This patch moves all TARGET_SSE_PARTIAL_REG_DEPENDENCY FP conversion
> splitters to a later split pass. Plus, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #24 from H.J. Lu ---
Created attachment 38414
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38414&action=edit
A patch to move special SSE splitters before general SSE float_extend splitter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
--- Comment #3 from Yuri Rumyantsev ---
Jacub,
Here is a simple fix - do not take into consideration edges destination of
which is loop latch block, i.e. loop is endless:
diff --git a/gcc/tree-ssa-loop-unswitch.c b/gcc/tree-ssa-loop-unswitch.c
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
--- Comment #7 from Dominique d'Humieres ---
The ICEs are gone with the patch
--- ../_clean/gcc/fortran/trans-decl.c 2016-03-28 13:03:29.0 +0200
+++ ../p_work/gcc/fortran/trans-decl.c 2016-05-04 16:13:21.0 +0200
@@ -6013,6 +601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70951
Bug ID: 70951
Summary: misleading -Wignored-qualifiers text, incorrect
documentation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
--- Comment #4 from Jakub Jelinek ---
(In reply to Yuri Rumyantsev from comment #3)
> Here is a simple fix - do not take into consideration edges destination of
> which is loop latch block, i.e. loop is endless:
> diff --git a/gcc/tree-ssa-loop-u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62042
--- Comment #10 from Victor Porton ---
Not fixed in GCC 6.1.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235
--- Comment #8 from Victor Porton ---
Note fixed in GCC 6.1.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62236
--- Comment #7 from Victor Porton ---
Not fixed in GCC 6.1.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
Bug ID: 70952
Summary: Missing warning for likely-erroneous octal escapes in
string literals
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #6 from Marek Polacek ---
This should fix it then:
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index d275f8e..d31e915 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -5532,7 +5532,7 @@ c_parser_if_statement (c_parser *pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70953
Bug ID: 70953
Summary: Reallocation on assignment does not work with debug
flags
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70953
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932
--- Comment #2 from Jens Maurer ---
The whole point of flexible array members seems to be to save an allocation for
the array, with the precondition that the array size can be determined at
initialization time and stays fixed for the entire lifet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
--- Comment #1 from Alexander Monakov ---
Octal escapes have no more than three digits by definition, so "\0009" clearly
doesn't fall under this warning.
Upon further testing, there's no diagnostic for
const char c = '\9'; /* same as ... = 9; *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70954
Bug ID: 70954
Summary: -Wmisleading-indentation false positive on GNU "ed"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
--- Comment #2 from Alexander Monakov ---
Bah, please disregard the last point; '\9' is diagnosed similar to "\9".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955
Bug ID: 70955
Summary: regression in code generation for __builtin_ms_va_list
in GCC 6.1
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
1 - 100 of 140 matches
Mail list logo
