https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70890
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70810
sd.foolegg at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959
William Clodius changed:
What|Removed |Added
Version|unknown |6.1.0
Summary|Invalid chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959
Bug ID: 70959
Summary: Invalid change of value conversion warning message
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942
--- Comment #2 from TC ---
This only appears to affect captureless generic lambdas with a deduced return
type.
It might have something to do with the conversion function template to function
pointer - I'm guessing that it was somehow instantiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662
--- Comment #15 from Alan Modra ---
Author: amodra
Date: Thu May 5 00:07:27 2016
New Revision: 235914
URL: https://gcc.gnu.org/viewcvs?rev=235914&root=gcc&view=rev
Log:
[RS6000] TARGET_RELOCATABLE
For ABI_V4, -mrelocatable and -fPIC both gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
Carlos Maziero changed:
What|Removed |Added
Severity|minor |trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70951
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 4 May 2016, msebor at gcc dot gnu.org wrote:
> First, as the C example program shows, a type qualifier on a function return
> type does have an effect even in C. The description sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
--- Comment #3 from Andrew Pinski ---
-std=gnu90 or -std=gnu89 (depending on the naming you like :) ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
--- Comment #2 from Carlos Maziero ---
I understand you explanation and agree with it, but I still have some concerns.
For instance, when using the -std=c89 flag, GCC 5.3.1 complains about the '//'
comments, which are not allowed in C89 standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68722
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958
Bug ID: 70958
Summary: Flag -Wreturn-type does not warn about lacking return
statement in main
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #28 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 4 21:13:13 2016
New Revision: 235906
URL: https://gcc.gnu.org/viewcvs?rev=235906&root=gcc&view=rev
Log:
PR target/70873
* config/i386/i386.md
(TA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #16 from Manuel López-Ibáñez ---
(In reply to Eric Gallager from comment #15)
> That has since been closed as fixed. So are the chances of this one being
> fixed next somewhat better now?
Not really. PR23608 fixes the case where the
from Jan van Dijk ---
It appears this has been fixed long time ago already: both
g++ (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
g++ (GCC) 7.0.0 20160504 (experimental)
print the desired error message:
16106.cpp: In constructor ‘A::A(T&) [with T = int]’:
16106.cpp:8:12: e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70906
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70933
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70933
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Wed May 4 20:44:40 2016
New Revision: 235902
URL: https://gcc.gnu.org/viewcvs?rev=235902&root=gcc&view=rev
Log:
PR c++/70906
PR c++/70933
* tree-core.h (enum oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70906
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Wed May 4 20:44:40 2016
New Revision: 235902
URL: https://gcc.gnu.org/viewcvs?rev=235902&root=gcc&view=rev
Log:
PR c++/70906
PR c++/70933
* tree-core.h (enum oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #27 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #26)
> But when this splitter fails, no other splitters will be tried.
Bah. This is clearly an implementation bug in the split pass. I don't think we
have to work around it,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #26 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #25)
> (In reply to H.J. Lu from comment #23)
>
> > We need to move those special SSE SF->DF splitters before
>
> No, this splitter will fail if the transformation doesn't r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #17 from Manuel López-Ibáñez ---
(In reply to Pedro Alves from comment #16)
>
> This could also be sorted out with indentation level tracking -- the if
> binds to the else in the macro, but it is not indented as one would expect
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
--- Comment #8 from rguenther at suse dot de ---
On May 4, 2016 6:20:14 PM GMT+02:00, "dominiq at lps dot ens.fr"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937
>
>--- Comment #7 from Dominique d'Humieres
>---
>The ICEs are gone wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
Bug ID: 70957
Summary: testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on
power7
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70956
Bug ID: 70956
Summary: ICE in build_cross_bb_scalars_def, at
graphite-scop-detection.c:1725
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #16 from Pedro Alves ---
(In reply to Manuel López-Ibáñez from comment #15)
> But I can see that one may wrongly write:
>
> void bar(int x)
> {
> if (x)
> MACRO_WITH_ELSE(x)
> if(!x)
>return;
> }
>
> and no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #15 from Manuel López-Ibáñez ---
Indeed, we also warn for
void bar(int x)
{
if (x)
for (int i = x; i < 5; i++)
if (i != 0)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #14 from Pedro Alves ---
(In reply to Jakub Jelinek from comment #12)
> The warning is about dangling else, which you have in the source.
> if (cond)
> for (...)
> if (cond2)
> ...
> else
> and while the C/C++ grammar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873
--- Comment #25 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #23)
> We need to move those special SSE SF->DF splitters before
No, this splitter will fail if the transformation doesn't result in a constant.
So, we actually want this sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #13 from Pedro Alves ---
Should have been:
if (condition)
ALL_OBJFILE_OSECTIONS (o, osect)
{
/* do something with each o / osect */
}
else
return 0;
So if the ALL_OBJFILE_OSECTIONS macro conta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #12 from Jakub Jelinek ---
The warning is about dangling else, which you have in the source.
if (cond)
for (...)
if (cond2)
...
else
and while the C/C++ grammar say they bind to the inner-most if, many people
actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #10 from Pedro Alves ---
Sure can. But the point is discussing what makes sense for the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #9 from Jakub Jelinek ---
If you want your macro to be immune from this, can't you do something like:
static inline struct obj_section *
whatever (struct obj_section *osect, struct obj_section *sections_end)
{
while (osect < sectio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
--- Comment #8 from Pedro Alves ---
- There's exactly the same number of ifs and elses in the macro.
- The indentation of the else matches that of the if.
- There's actually no "else" at all at the macro call site, making the warning
look odd.
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
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
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=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 #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=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=70953
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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=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=62236
--- Comment #7 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=62042
--- Comment #10 from Victor Porton ---
Not fixed in GCC 6.1.1.
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=38470
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=66773
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
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=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=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=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=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=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=70876
Ilya Enkovich changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=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=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=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=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=70932
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=70051
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
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=70938
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=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=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=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=70371
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |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=48778
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=70873
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
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=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=70937
--- Comment #6 from Dominique d'Humieres ---
Started at r235817.
Which patch should I test?
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=70946
--- Comment #2 from Richard Biener ---
IVO before unrolling is never going to be optimal.
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=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=70947
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=70946
--- Comment #1 from Wilco ---
PR36712 seems related to this
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=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=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=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=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=70944
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
1 - 100 of 140 matches
Mail list logo
