https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
Dennis Clarke changed:
What|Removed |Added
CC||dclarke at blastwave dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94846
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
Bug ID: 98001
Summary: ext/stdio_filebuf/char/79820.cc is broken
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98002
Bug ID: 98002
Summary: gcc.dg/strncmp-2.c frees mproptected memory
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906
--- Comment #6 from Jakub Jelinek ---
Implemented now for non-AVX512*. Hongtao, do you think you could have a look
at the avx512{bw,vl}/avx512bw splitter(s)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906
--- Comment #7 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #6)
> Implemented now for non-AVX512*. Hongtao, do you think you could have a
> look at the avx512{bw,vl}/avx512bw splitter(s)?
Yes, i'll do it. Thanks for the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
--- Comment #18 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:c0c7270cc4efd896fe99f8ad5409dbef089a407f
commit r11-5430-gc0c7270cc4efd896fe99f8ad5409dbef089a407f
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
--- Comment #19 from CVS Commits ---
The releases/gcc-10 branch has been updated by Thomas Schwinge
:
https://gcc.gnu.org/g:e8e0357d129187b24085ce52172c87dbf6c2ecae
commit r10-9086-ge8e0357d129187b24085ce52172c87dbf6c2ecae
Author: Thomas Schwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98002
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-11-26
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
--- Comment #20 from CVS Commits ---
The releases/gcc-9 branch has been updated by Thomas Schwinge
:
https://gcc.gnu.org/g:25b61f935a8eca56c68c8587fc8915797250bb30
commit r9-9073-g25b61f935a8eca56c68c8587fc8915797250bb30
Author: Thomas Schwinge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
--- Comment #21 from CVS Commits ---
The releases/gcc-8 branch has been updated by Thomas Schwinge
:
https://gcc.gnu.org/g:23ec71d91e3044108a557dace573d3e60ff1c07e
commit r8-10649-g23ec71d91e3044108a557dace573d3e60ff1c07e
Author: Thomas Schwing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98002
--- Comment #1 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5b3a8fad18324cd38c221bdb0ae2b690fc82ede0
commit r11-5431-g5b3a8fad18324cd38c221bdb0ae2b690fc82ede0
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98000
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97979
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:39f5e9aded23e8b7e0e7080fc6020478b9c5b7b5
commit r11-5433-g39f5e9aded23e8b7e0e7080fc6020478b9c5b7b5
Author: Jakub Jelinek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96680
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97993
Martin Liška changed:
What|Removed |Added
Known to fail||11.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97991
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97979
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97987
Richard Biener changed:
What|Removed |Added
Component|inline-asm |testsuite
--- Comment #1 from Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97994
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|[11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97976
--- Comment #11 from Jonathan Wakely ---
The fact that objects cannot live at address zero is not just a GCC quirk. As I
said, it's required by the C and C++ standards. A null pointer cannot be
dereferenced, and cannot point to any object. I'm su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97976
--- Comment #12 from Jonathan Wakely ---
(And for the linux kernel I think it's that the don't want the data flow
analysis done by that option, rather than allowing objects to live at address
zero)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97993
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97994
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97995
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97995
--- Comment #2 from Richard Biener ---
> clang++ t.ii
t.ii:5:16: error: no matching function for call to 'bar'
static_assert (bar (foo);
^~~
t.ii:4:6: note: candidate template ignored: couldn't infer template argument
'b'
void bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97995
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98000
--- Comment #4 from Martin Liška ---
Reduced test-case:
$ cat pr98000.C
struct {
template T *operator()(T);
} hb_addressof;
template static int _hb_cmp_method(Ts...)
{
return 0;
}
template
inline bool hb_bsearch_impl(K key, V, int compar(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98000
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |10.3
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98001
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98003
Bug ID: 98003
Summary: FAIL: 27_io/basic_syncbuf/sync_ops/1.cc (test for
excess errors)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98004
Bug ID: 98004
Summary: FAIL: 30_threads/stop_token/stop_callback/destroy.cc
execution test
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005
Bug ID: 98005
Summary: FAIL: std/ranges/adaptors/sizeof.cc (test for excess
errors)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98006
Bug ID: 98006
Summary: [OpenACC] 'gcc/cp/decl.c:check_goto' should consider
'flag_openacc' in addition to 'flag_openmp'?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
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
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=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=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=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
--- 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=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=98005
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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=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=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=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=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=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=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=98012
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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=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 #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=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=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 #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=97980
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=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 #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=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
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
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=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=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=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=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 #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 #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=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=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=98016
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed||2020-11-26
Ever confirmed|0
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=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
--- 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=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=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=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=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 #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=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=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=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=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
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=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
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=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=98015
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=97997
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 137 matches
Mail list logo
