https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #6 from Aldy Hernandez ---
Can this be re-checked now that the forward threader has been dropped post-VRP?
BTW, please CC me on any compile-time hogs related to the threader, especially
if it's not SPEC related, as I've yet to hunt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93811
--- Comment #4 from Andrew Pinski ---
Mono's implementation seems like the best so far:
https://github.com/mono/mono/blob/main/mono/mini/mini-ppc.c#L759-L795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #21 from Andrew Cooper ---
Another possibly-bug, but possibly mis-expectations on my behalf.
I've found some code in the depths of Xen which is causing a failure on final
link due to a missing `__x86_indirect_thunk_nt_rax` symbol.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000
--- Comment #3 from Andrew Pinski ---
(In reply to Tamar Christina from comment #2)
> From a quick look at the failures on -m32 it looks like SLP vectorization
> fails completely but these targets declare vect_float so that's not enough
> to sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000
--- Comment #2 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> Looks like these are missing { target { vect_complex_add_float } } in there.
>
No, that's not right, `vect_complex_add_float` is for when the target supports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #20 from Andrew Cooper ---
(In reply to H.J. Lu from comment #19)
> (In reply to Andrew Cooper from comment #17)
> > I think I've found a bug in the -fcf-check-attribute implementation.
>
> Please try the v5 patch.
Thanks. That do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #19 from H.J. Lu ---
(In reply to Andrew Cooper from comment #17)
> I think I've found a bug in the -fcf-check-attribute implementation.
>
Please try the v5 patch. BTW, do you have a testcase to show how
-fcf-check-attribute=yes i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
H.J. Lu changed:
What|Removed |Added
Attachment #51696|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400
--- Comment #6 from Tobias Burnus ---
Created attachment 51700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51700&action=edit
Draft patch for the 'gcc -E' / 'gcc -save-temps' issue
This solves the -E / -save-temps preprocessing issue.
F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102953
--- Comment #17 from Andrew Cooper ---
I think I've found a bug in the -fcf-check-attribute implementation.
$ cat fnptr-array-arg.c
static int __attribute__((cf_check)) foo(char a[], int b)
{
return 0;
}
int (*ptr)(char[], int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400
--- Comment #5 from Tobias Burnus ---
The problem is that the pragma is not known/registered. In that case, when
calling
libcpp/directives.c's do_pragma, the result is p == NULL
and thus:
if (p)
...
else if (pfile->cb.def_pragma)
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102409
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:0078a058a569387153419876acca080142873b65
commit r12-4797-g0078a058a569387153419876acca080142873b65
Author: Tobias Burnus
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102547
Patrick Palka changed:
What|Removed |Added
CC||cantonios at google dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102999
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Resol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103002
Bug ID: 103002
Summary: Missed loop unrolling opportunity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Bernhard Reutner-Fischer changed:
What|Removed |Added
CC||aldot at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103001
Bug ID: 103001
Summary: missing simplify of (CAF) get_team
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103000
Bug ID: 103000
Summary: Some updated test cases from r12-4786 fail
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993
--- Comment #7 from Luke Dashjr ---
It's the standard Ubuntu focal g++-mingw-w64-i686 package.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91669
--- Comment #3 from Tobias Burnus ---
Comparing the two inside handle_pragma_visibility:
* the no-save-temps version has as 'loc' the line pointing to
_Pragma(#__VA_ARGS__)
* with -save-temps, 'loc' == 'input_location'.
But: control_warning_opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102980
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99250
--- Comment #2 from sandra at gcc dot gnu.org ---
Hmmm. I've been going through the list at
https://gcc.gnu.org/wiki/Fortran2018Status
and there really are a large number of unimplemented F2018 features, not just
this one. :-( Anyway, I added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102999
Bug ID: 102999
Summary: g++-11 regression: sorry, unimplemented: unexpected
AST of kind nontype_argument_pack
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91669
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #10 from Jürgen Reuter ---
Reassuringly, the gfortran 11.2 from Macports has the same problem as the
gfortran 12.0.0 installed by hand: no redirecting into files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102996
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102983
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102983
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:cb596fd43667f92c4cb037a4ee8b2061c393ba60
commit r12-4788-gcb596fd43667f92c4cb037a4ee8b2061c393ba60
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #9 from Jürgen Reuter ---
I also tried that for a Fortran program ./a.out | less (pipe to less) works.
It's just the redirection that does not work. I'm waiting for the compilation
to check whether gfortran 11.2 from Macports shares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
--- Comment #16 from hubicka at kam dot mff.cuni.cz ---
> It will only help for V2DF I think, so no, not really. But an IPA idea of
> whether there's cross-call STLF issues might be nice.
>
> Generally doing wider stores is fine but of course i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71065
--- Comment #4 from Tobias Burnus ---
>From IRC: "testcases where nothing should be diagnosed would include e.g.
lambdas in expressions inside of teams clauses and similar nastiness"
Simple examples:
#pragma omp target map(tofrom: b[0:100])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71065
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
Iain Sandoe changed:
What|Removed |Added
Summary|Piping in a file does no|fortran: redirecting
|l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102058
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #7 from Iain Sandoe ---
(although , the output is fine when not redirected, so perhaps that's
irrelevant)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #6 from Iain Sandoe ---
I had a brief look at some new fails on macOS12 / Darwin21 for gcov.
It seems that .mod_term_funcs entries are not being run - so if libgfortran
relies on something defined as __attribute__((destructor)) [e.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102977
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102977
--- Comment #10 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:4045d5fa42f2ee7b284977c8f2f0edc300a63e43
commit r12-4786-g4045d5fa42f2ee7b284977c8f2f0edc300a63e43
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102977
--- Comment #9 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:ed3de62ac949c92ad41ef6de7cc926fbb2a510ce
commit r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #5 from hubicka at kam dot mff.cuni.cz ---
> Not seen on Haswell (but w/o PGO). Is this PGO specific? There's another
> large jump visible end of 2019.
It is between 2019-11-15 and 18 but the revisions does not exist at git
- perhap
> Not seen on Haswell (but w/o PGO). Is this PGO specific? There's another
> large jump visible end of 2019.
It is between 2019-11-15 and 18 but the revisions does not exist at git
- perhaps they reffer to the old git mirror. Martin will know better.
In that range there are many of Richard's vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #4 from hubicka at kam dot mff.cuni.cz ---
> Not seen on Haswell (but w/o PGO). Is this PGO specific? There's another
> large jump visible end of 2019.
This is kabylake LTO+PGO+march=native
https://lnt.opensuse.org/db_default/v4/SP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998
--- Comment #1 from Roland Illig ---
> for the following redeclarations
That's wrong. There is only 1 redeclaration in the code that follows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #3 from Richard Biener ---
train data:
Samples: 6K of event 'cycles', Event count (approx.): 7715838425
Overhead Samples Command Shared Object Symbol
5.68% 382 calculi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102998
Bug ID: 102998
Summary: Wrong documentation for -Warray-parameter
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #2 from Richard Biener ---
Btw, IIRC calculix train data and ref data do not match up wrt the hottest
loops, so not sure whether any regression here is considered important. Maybe
the profile is now preserved better.
I can't reprod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102996
--- Comment #2 from Eyal Rozenberg ---
(In reply to Richard Biener from comment #1)
> The foo form is handled by the early uninit pass
Since _none_ of `as` is initialized, one could argue that an early uninit pass
could catch that as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
Bug ID: 102997
Summary: 45% calculix regression with LTO+PGO -march=native
-Ofast between
ce4d1f632ff3f680550d3b186b60176022f41190 and
6fca1761a16c68740f875fc487b9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986
--- Comment #3 from Jakub Jelinek ---
Or tree-vect-generic.c would need to check the predicates of the vector shift
and try to figure out if they accept REGs or not. But no idea how to do that
cleanly, the predicate could be very well some targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #5 from Jürgen Reuter ---
I checked that the assembler code on macOS Big Sur and Monterey is identical
(up to the date in the .ident line). So either the assembler works differently,
or one of the routines from the libgfortran (_gfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102986
Jakub Jelinek changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102996
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-10-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102966
--- Comment #8 from Jakub Jelinek ---
What checks are emitted evolves over time...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102966
--- Comment #7 from Bastiaan Braams ---
Pleased to see that the run-time error is properly diagnosed in version 11.2.1
and later, and agreed that the matter is outside the fortran language standard.
Just one comment on the discussion in view of
PASS: gcc.dg/vect/vect-simd-17.c -flto -ffat-lto-objects execution test
=== gcc Summary ===
# of expected passes4
/home/luoxhu/workspace/build/gcc/xgcc version 12.0.0 20211029 (experimental)
(GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102880
--- Comment #5 from Richard Biener ---
Created attachment 51699
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51699&action=edit
hack to make forwarders
This is an overly simple attempt to make forwarders which works to restore the
DCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102985
--- Comment #2 from Jakub Jelinek ---
Actually, I think 5.2 got this right and thus the testcase is not valid in 5.2.
This is because of the introduction of work-distribution constructs term.
For lastprivate the restriction now says:
"A list it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102984
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |WORKSFORME
--- Comment #9 from Jonath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993
--- Comment #6 from Eric Botcazou ---
> I think we still default to those for 32bit unless you configure with
> --disable-sjlj-exceptions.
Yes, everybody should configure with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102714
--- Comment #8 from Bo Duan ---
(In reply to Richard Biener from comment #7)
> (In reply to Bo Duan from comment #6)
> > Hello, should we backport this patch to gcc-10?
>
> It's scheduled for a backport to GCC 11, I'm not aware that GCC 10 is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993
--- Comment #5 from Richard Biener ---
I think we still default to those for 32bit unless you configure with
--disable-sjlj-exceptions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102984
Milian Wolff changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102996
Bug ID: 102996
Summary: No warning on use dereferencing of uninitialized point
in an array
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102995
Bug ID: 102995
Summary: Template friend class declaration of same class with
different template parameters fails to allow private
methods access
Product: gcc
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 102820, which changed state.
Bug 102820 Summary: [DR2351] Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:eca767aa51d1f69614222ceb130ca6bb07713232
commit r12-4782-geca767aa51d1f69614222ceb130ca6bb07713232
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
Carlos Galvez changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102714
Richard Biener changed:
What|Removed |Added
Summary|[11 Regression] A |[10/11 Regression] A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102949
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Richard Biener ---
> Fixed (by inspecting assembly).
Indeed: the execution tests PASS again. Thanks.
77 matches
Mail list logo
