https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89469
Sunil Kumar changed:
What|Removed |Added
CC||sunil.kumar3 at ltts dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #5 from Dennis Clarke ---
Not sure how useful this is but all of the following toss the same ICE :
long f(long arg){return arg + 4096;}
long f(long arg){return arg - 4096;}
long f(long arg){return 4096 + arg;}
lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018
--- Comment #4 from Richard Biener ---
Note always_inline inlining cannot be disabled. Should it disable function
splitting and IPA transforms that require thunks? Thus any transform that
might add or remove a frame? Even if the thunk might us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-* i?86-*-*
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #15 from rguenther at suse dot de ---
On Fri, 27 Nov 2020, luoxhu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
>
> --- Comment #14 from luoxhu at gcc dot gnu.org ---
> (In reply to luoxhu from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #14 from luoxhu at gcc dot gnu.org ---
(In reply to luoxhu from comment #13)
>
> 2) mad2.c
>
> float foo (double x, float y, float z)
> {
>return ( y * fabs (x) + z );
> }
>
>
> mad2.c.098t.cunrolli:
>
> foo (double x, float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #13 from luoxhu at gcc dot gnu.org ---
Tried implementation with backprop, found that this model seems not suitable
for double promotion remove with BACK propagation. i.e:
1) mad1.c
float foo (float x, float y, float z)
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85163
Yibiao Yang changed:
What|Removed |Added
CC||cs.yang.yibiao at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85163
Sunil Kumar changed:
What|Removed |Added
CC||sunil.kumar3 at ltts dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98023
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98023
Bug ID: 98023
Summary: ICE: free_expr0(): Bad expr type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
Bug ID: 98022
Summary: ICE in gfc_assign_data_value, at fortran/data.c:468
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #2 from eggert at cs dot ucla.edu ---
(In reply to Andrew Pinski from comment #1)
> so you are asking not to show the source file for #warning ?
That's the possibility I suggested, yes. Another possibility would be to not
show the dia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #1 from Andrew Pinski ---
so you are asking not to show the source file for #warning ?
I don't see why this warning should be treated as any different from any other
warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
Bug ID: 98021
Summary: #warning issues redundant diagnostic lines
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: prepr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #22 from Thomas Koenig ---
Hi Toon,
it took some time, but we finally figured out that it is actually
a bug in your program that is causing problems.
It has (shortened)
nxglobal = 72;
This sets the coarray nxglobal to 72 on every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300
--- Comment #6 from anlauf at gcc dot gnu.org ---
Currently the only generated STAT code is 5014 for LIBERROR_ALLOCATION.
This is ambiguous.
Shall we add another enum value to libgfortran_error_codes, such as
LIBERROR_VIRTUAL_MEMORY, LIBERROR_MEM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #10 from eggert at cs dot ucla.edu ---
The generic workaround that Bruno describes ran into problems in Gnulib, as
it's enabled only when compiled with -DGCC_LINT, and some users don't compile
it that way. So we now have a more elabora
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98020
Bug ID: 98020
Summary: PPC: mfvsrwz+extsw not merge to mtvsrwa
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #18 from Jakub Jelinek ---
Created attachment 49633
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49633&action=edit
gcc11-pr97459-wip.patch
Completely untested patch, so far only for double-word unsigned modulo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #22 from Chris Clayton ---
I've applied Richard's patch to the 20201122 snapshot and can happily report
that the build now completes successfully. My thanks to Martin and Richard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016
--- Comment #5 from kargl at gcc dot gnu.org ---
Index: gcc/gcc/fortran/expr.c
===
--- gcc/gcc/fortran/expr.c (revision 280157)
+++ gcc/gcc/fortran/expr.c (working copy)
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019
--- Comment #1 from Egor Suvorov ---
Also, I would expect a warning in this case:
requires {
foo(); // Looks like a statement.
};
but not this:
requires {
static_cast(foo());
};
or this:
requires {
{ foo() }; // expression chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019
Bug ID: 98019
Summary: Concepts: compound requirement expression from
'requires' expression is considered discarded-value
expression for [[nodiscard]], false positive warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:10522ed1089277e2aa6cd708205aa5c730179cf0
commit r11-5447-g10522ed1089277e2aa6cd708205aa5c730179cf0
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018
--- Comment #3 from H.J. Lu ---
-fforce-frame-pointer should disable
1. Tail call.
2. Inlining. Should inlining be totally disabled? Which inlining should be
disabled? What do do with static inline and extern inline?
3. Frame pointer optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018
--- Comment #2 from Uroš Bizjak ---
I vote for -fforce-frame-pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018
--- Comment #1 from H.J. Lu ---
Something like, -fneed-frame-pointer, -fforce-frame-pointer or
-fgenerate-frame-pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
--- Comment #9 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:294e72e9acbd0ff15ef5b18895de62cc173464ca
commit r11-5445-g294e72e9acbd0ff15ef5b18895de62cc173464ca
Author: Eric Botcazou
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902
--- Comment #15 from Jan Smets ---
Thanks. See 98018.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98018
Bug ID: 98018
Summary: Option to force frame pointer
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97997
--- Comment #5 from Matthijs Kooijman ---
Awesome, thanks for the quick response and fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902
H.J. Lu changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902
--- Comment #13 from Jan Smets ---
H.J, There are still some very basic backtrace implementations that rely on
frame pointers. (No DWARF based things or any other forms of 'assistance'). A
missing stack frame means the "previous" function is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97997
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97997
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a3ebc13492ff238873f2c6a7a3e51abefec1d052
commit r11-5444-ga3ebc13492ff238873f2c6a7a3e51abefec1d052
Author: Jakub Jelinek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
Richard Biener changed:
What|Removed |Added
Known to work||11.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98015
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #20 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:c76b3f9e83353a4cd437ca137c1fb835c9b5c21f
commit r11-5443-gc76b3f9e83353a4cd437ca137c1fb835c9b5c21f
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016
--- Comment #4 from Dominique d'Humieres ---
I confirm that the test in comment O compiles without any error.
However if I replace
real y(n)
with
dimension y(n)
I get the error
Error: Variable 'n' cannot appear in the expression at (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016
--- Comment #3 from Jürgen Reuter ---
Ah wait, the version I committed works, the original version from c.l.f. still
fails, because it uses implicit typing, so not real :: y(3)
and real :: y(n), but
dimension y(3)
$ cat clf_20201126.f90
program
reuter/local --disable-multilib
--enable-languages=c,c++,fortran,lto
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201126 (experimental) (GCC)
Still present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #23 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #22)
> -S -fpreprocessed test.i will not work
It doesn't seem to support -fpreprocessed though.
Thanks for explanations and sorry about
naively attributing that effec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902
--- Comment #12 from Martin Liška ---
Thanks for the feedback. So do you tend to close it again as invalid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902
--- Comment #11 from H.J. Lu ---
(In reply to Richard Biener from comment #10)
> (In reply to Martin Liška from comment #9)
> > (In reply to H.J. Lu from comment #8)
> > > (In reply to Martin Liška from comment #7)
> > > > Can you please H.J. tak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98000
--- Comment #6 from Martin Liška ---
(In reply to ishikawa,chiaki from comment #5)
> (In reply to Martin Liška from comment #3)
> > Thank you for the report, it's very likely a different issue.
> > I'm reducing that right now..
>
> You are very
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #22 from Jakub Jelinek ---
(In reply to Stas Sergeev from comment #21)
> (In reply to Jakub Jelinek from comment #19)
> > It is just that clang doesn't support -g3 at all, as can be seen by clang
> > not producing any .debug_macinfo n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #21 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #19)
> It is just that clang doesn't support -g3 at all, as can be seen by clang
> not producing any .debug_macinfo nor .debug_macro sections.
So with -fdebug-macro it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #20 from Stas Sergeev ---
Ah, makes sense, thank you.
I was always wondering why under clang I
need to do "-fdebug-macro" for that (which
makes problems for gcc as being an unknown option).
But "clang -g3 -fdebug-macro -E -Wp,-P -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98000
--- Comment #5 from ishikawa,chiaki ---
(In reply to Martin Liška from comment #3)
> Thank you for the report, it's very likely a different issue.
> I'm reducing that right now..
You are very welcome and
thank you for the reduction to simpler ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902
--- Comment #10 from Richard Biener ---
(In reply to Martin Liška from comment #9)
> (In reply to H.J. Lu from comment #8)
> > (In reply to Martin Liška from comment #7)
> > > Can you please H.J. take a look?
> > > Maybe we can add a param that w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98015
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed||2020-11-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
Bug ID: 98017
Summary: Suspected regression (relative to 7.5) using PACK in
iolist
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #19 from Martin Liška ---
What a nice reduced test-case.
Btw. started to fail with r8-4962-g4aa458f2ac11aef0 with -O2 -fno-tree-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #19 from Jakub Jelinek ---
Note, clang like gcc documents -P to only disable line markers, and it is also
what that option does in clang.
Just try clang -dD -E -P, it will show the #define lines all over too.
It is just that clang doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #18 from Richard Biener ---
int __attribute__((noipa))
foo (int flag, int *p)
{
int val = *p;
if (flag)
{
if (val != 1)
__builtin_unreachable ();
return 0;
}
int val2 = *p;
return val2 == 2;
}
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #18 from Stas Sergeev ---
IMHO the only thing that makes sense,
is whether or not this is useful in practice.
If there are no practical cases for current
"-g3 -P" behaviour, then to me the fact that
its documented that way, is more or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016
Bug ID: 98016
Summary: Host association problem
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98015
Bug ID: 98015
Summary: [11 regression] ICE in gimple_expand_vec_cond_expr
since g:fddc7f0080f1f056c4d145451608ebd3e807422a
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #17 from Jakub Jelinek ---
Looks like a bad idea to me. And, I think gcc had this behavior for -g3 and -P
years before clang implemented those, so arguing here about clang-compatibility
is strange. clang simply decided not to implem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
--- Comment #9 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:c6145860aac6acfeed2a98fe7532dd2cd0ffab2b
commit r8-10650-gc6145860aac6acfeed2a98fe7532dd2cd0ffab2b
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
--- Comment #8 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:e45e65016754cf4bfc6c00cbbdca700f01f7c324
commit r9-9074-ge45e65016754cf4bfc6c00cbbdca700f01f7c324
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
--- Comment #17 from Richard Biener ---
The issue is a bogus jump threading done in VRP2 caused by bogus range info on
the hoisted gimple_code (use->stmt).
tree-ssa-loop-ivopts.c.137t.pre- # PT = nonlocal escaped null
tree-ssa-loop-ivopts.c.13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:4cdc67405842946e08e7ddf375e850331530abb7
commit r10-9087-g4cdc67405842946e08e7ddf375e850331530abb7
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #16 from Stas Sergeev ---
What do you think about, in addition
to your current patch, to also change
-P to disable debug?
Looks more user-friendly and clang-compatible?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #38 from Martin Jambor ---
*** Bug 97980 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97980
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98011
--- Comment #2 from Tobias Burnus ---
Regarding OpenACC: There is something going wrong here (-fopenacc):
../testsuite/gfortran.dg/goacc/sentinel-free-form.f95:13:6:
13 | !$ acc parallel ! { dg-error "Unclassifiable statement" }
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005
--- Comment #4 from Andreas Schwab ---
Except that those are not the failing assertions.
sizeof(ranges::take_while_view) and
sizeof(ranges::transform_view) are both 10, probably
because sizeof(pred_l) and sizeof(func_l) are 1, and padding is dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98011
--- Comment #1 from Tobias Burnus ---
The OpenMP version is a bit crude, but OpenMP has besides
!$omp
also
!$
as "conditional compilation sentinel".
In free-form source code: "Initial lines must have a space after the sentinel".
Still, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
--- Comment #6 from Jonathan Wakely ---
I added b.close() before the fclose anyway. I'll backport this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2762cb1df686fc1ebcee23c7c4f0f6e8bf5a6abc
commit r11-5437-g2762cb1df686fc1ebcee23c7c4f0f6e8bf5a6abc
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
--- Comment #4 from Jonathan Wakely ---
Yes, when the filebuf is given a FILE* it doesn't own it, and so the destructor
doesn't touch it:
__basic_file*
__basic_file::close()
{
__basic_file* __ret = static_cast<__basic_file*>(NULL);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98014
Bug ID: 98014
Summary: [Fortran OpenACC] Empty '!$acc' continuation line
rejected
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: openacc
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005
--- Comment #3 from Andreas Schwab ---
Objects of type ranges::take_while_view or
ranges::transform_view do have the correct size, though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98009
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98012
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98009
--- Comment #1 from Tobias Burnus ---
I am not aware of any OpenACC construct which contains a typespec like
'INTEGER' or 'TYPE(t)'
In OpenACC it is used for gfc_match_omp_declare_reduction like is:
!$omp declare reduction (baz : integer :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98013
Bug ID: 98013
Summary: [OpenACC]
'gcc/fortran/trans-decl.c:gfc_generate_function_code'
should consider 'flag_openacc' in addition to
'flag_openmp'?
Produ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98012
Bug ID: 98012
Summary: [OpenACC] 'gcc/fortran/scanner.c:include_line' should
consider 'flag_openacc' in addition to 'flag_openmp'?
Product: gcc
Version: 11.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98010
--- Comment #1 from Tobias Burnus ---
Those flags are about implicitly regarding variables as 'SAVE' (i.e. resisting
in static memory); this feature clashes with calling procedures recursively or
concurrent; the latter affects OpenMP and OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98011
Bug ID: 98011
Summary: [OpenACC] 'gcc/fortran/scanner.c:load_line' should
consider 'flag_openacc' in addition to 'flag_openmp'
(and vice versa?)?
Product: gcc
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
--- Comment #3 from rguenther at suse dot de ---
On Thu, 26 Nov 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
>
> Jonathan Wakely changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98010
Bug ID: 98010
Summary: [OpenACC] 'gcc/fortran/options.c:gfc_post_options'
should consider 'flag_openacc' in addition to
'flag_openmp'?
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98009
Bug ID: 98009
Summary: [OpenACC] 'gcc/fortran/match.c:gfc_match_type_spec'
should consider 'flag_openacc' in addition to
'flag_openmp'?
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98008
--- Comment #1 from Jonathan Wakely ---
If the following C program works, but 54185.cc deadlocks, it suggests there
might be a bug in the libstdc++ code or test instead (this C program fails on
AIX, due to a bug in pthread_cond_wait). This works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005
--- Comment #1 from Andreas Schwab ---
/daten/aranym/gcc/gcc-20201125/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc:45:
error: static assertion failed
/daten/aranym/gcc/gcc-20201125/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc:47:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98008
Bug ID: 98008
Summary: WARNING: 30_threads/condition_variable/54185.cc
execution test program timed out.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98007
Bug ID: 98007
Summary: [OpenACC] 'gcc/cp/semantics.c:finish_return_stmt'
should consider 'flag_openacc' in addition to
'flag_openmp' for 'gcc/cp/decl.c:check_omp_return'?
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944
--- Comment #8 from Jonathan Wakely ---
(In reply to Christophe Lyon from comment #0)
> Since this new test was introduced, it fails randomly on arm, aarch64 and
> other targets (apparently powerpc, ia64, m68k according to gcc-testresults).
And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98004
--- Comment #1 from Andreas Schwab ---
Output: terminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1
1 - 100 of 137 matches
Mail list logo
