https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #14 from rguenther at suse dot de ---
On Fri, 8 Apr 2022, guihaoc at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
>
> --- Comment #13 from HaoChen Gui ---
> Could we use the original alias set if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #13 from HaoChen Gui ---
Could we use the original alias set if the tree code of 'atemp' is var_decl? Is
it safe? In which situation we shall use alias-set zero? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #12 from Richard Biener ---
(In reply to HaoChen Gui from comment #11)
> I tested C source code with Ofast. The Ofast enables data store race. It
> should do store motion but it fails. The problem is on cselim pass. It does
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #11 from HaoChen Gui ---
I tested C source code with Ofast. The Ofast enables data store race. It should
do store motion but it fails. The problem is on cselim pass. It does
conditional store replacement. The 'atemp' is converted to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #10 from rguenther at suse dot de ---
On Mon, 28 Mar 2022, guihaoc at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
>
> --- Comment #9 from HaoChen Gui ---
> Escaped for 'atemp' doesn't be set with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #9 from HaoChen Gui ---
Escaped for 'atemp' doesn't be set with Fortran source code, while it's set
with C source code. 'auto_var_in_fn_p + pt_solution_includes' works for Fortran
code. But if the function is a head of the loop in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #8 from rguenther at suse dot de ---
On Fri, 25 Mar 2022, guihaoc at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
>
> --- Comment #7 from HaoChen Gui ---
> The original case comes from a Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #7 from HaoChen Gui ---
The original case comes from a Fortran program. I rewrote it with C. As the
arguments are passed by reference in Fortran (by default), the problem is
common. But I am not sure if it has a large performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #6 from rguenther at suse dot de ---
On Fri, 25 Mar 2022, guihaoc at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
>
> --- Comment #5 from HaoChen Gui ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #5 from HaoChen Gui ---
(In reply to Richard Biener from comment #4)
> something like
>
> void *bar (void *x)
> {
> *(double *)x = 1.;
> }
>
> void foo(int n)
> {
>double atemp;
>pthread_create (..., bar, );
>for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #4 from Richard Biener ---
something like
void *bar (void *x)
{
*(double *)x = 1.;
}
void foo(int n)
{
double atemp;
pthread_create (..., bar, );
for (int i = 0; i < n; i++)
if (a[i] < atemp)
atemp = a[i];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #3 from HaoChen Gui ---
(In reply to Richard Biener from comment #2)
> That occured to me as well - I think the answer is maybe. In principle
> foo() could launch a thread and make the 'atemp' available to it. As long
> as foo()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
HaoChen Gui changed:
What|Removed |Added
Host||powerpc-*-linux-gnu
--- Comment #1 from
14 matches
Mail list logo
