[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668 --- Comment #2 from Chung-Lin Tang --- Note that what I'm working on at the moment does not include the Fortran parts, and this particular feature appears to be more suitable to be implemented within the Fortran FE, I think.
[Bug target/46934] gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934 Chung-Lin Tang changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #2 from Chung-Lin Tang 2010-12-23 10:09:29 UTC --- I think this can be solved by changing the predicate of operand[2] in *thumb1_addsi3 to "reg_or_int_operand". This allows later passes like reload to do its job. However, after the above change, I see another ICE during reload: h.c:16:1: error: unrecognizable insn: (insn 88 3 6 2 (set (reg:SI 3 r3) (const_int 2147483648 [0x8000])) h.c:5 -1 (nil)) h.c:16:1: internal compiler error: in extract_insn, at recog.c:2127 This turns out to be because, the generic 'general_operand' predicate used in thumb1_movsi_insn does a "trunc_int_for_mode (INTVAL(op), mode) == INTVAL(op)" test, and 0x8000 (2147483648) gets negated due to the sign-extension in trunc_int_for_mode(), failing the equality test: trunc_int_for_mode(2147483648, SImode) == -2147483648 (0x8000) We can probably fix this by using another ARM predicate in this case, though this boundary case of trunc_int_for_mode() is troubling, as the above truncate-and-test-for-equality idiom seems quite common in the compiler.
[Bug target/37440] [4.4/4.5/4.6 Regression] GNAT Bug Box a-ngcefu.adb:397
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440 Chung-Lin Tang changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #12 from Chung-Lin Tang 2011-02-07 16:38:50 UTC --- This looks suspiciously like PR47540, which has a submitted (by still uncommitted?) upstream patch.
[Bug target/47719] ICE compiling libavcodec/adxdec.c (FFmpeg) for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47719 Chung-Lin Tang changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #1 from Chung-Lin Tang 2011-02-17 08:29:38 UTC --- This should be fixed by this patch, I encountered it when building ffmpeg too. http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00381.html
[Bug rtl-optimization/46178] gcc.target/i386/(u)divmod-[58].c FAIL: ICE: in dec_register_pressure, at ira-lives.c:215 with -fira-algorithm=priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46178 --- Comment #1 from Chung-Lin Tang 2011-02-18 17:26:37 UTC --- Author: cltang Date: Fri Feb 18 17:26:31 2011 New Revision: 170277 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170277 Log: 2011-02-18 Chung-Lin Tang PR rtl-optimization/46178 * ira.c (setup_hard_regno_class): Use ira_class_translate[] to compute ira_hard_regno_cover_class[]. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug rtl-optimization/46002] ICE: in update_copy_costs, at ira-color.c:319 with -fira-algorithm=priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46002 --- Comment #4 from Chung-Lin Tang 2011-02-22 03:23:24 UTC --- Author: cltang Date: Tue Feb 22 03:23:21 2011 New Revision: 170388 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170388 Log: 2011-02-21 Chung-Lin Tang PR rtl-optimization/46002 * ira-color.c (update_copy_costs): Change class intersection test to reg_class_contents[] test of 'hard_regno'. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-color.c
[Bug rtl-optimization/49720] Infinite recursion compiling gold binary_test.cc testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49720 --- Comment #2 from Chung-Lin Tang 2011-10-28 06:35:37 UTC --- Author: cltang Date: Fri Oct 28 06:35:31 2011 New Revision: 180604 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180604 Log: 2011-10-28 Chung-Lin Tang PR rtl-optimization/49720 * simplify-rtx.c (simplify_relational_operation_1): Detect infinite recursion condition in "(eq/ne (plus x cst1) cst2) simplifies to (eq/ne x (cst2 - cst1))" case. testsuite/ * g++.dg/torture/pr49720.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr49720.C Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/52528] New: combine bug (powerpc testcase)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52528
Bug #: 52528
Summary: combine bug (powerpc testcase)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: clt...@gcc.gnu.org
Target: powerc-linux
The below testcase:
struct S {
unsigned a : 30;
unsigned b : 2;
};
int foo (int b)
{
struct S s = {0};
s.b = b;
return bar (0x000b0010, 0x00040100ULL, *(unsigned long *)&s);
}
currently on trunk (target powerpc) compiles to:
foo:
lis 6,0x4
li 5,0
ori 6,6,256
li 7,0
crxor 6,6,6
b bar
Notice the incorrect code generated: no construction of the 1st arg (reg 3),
and
wrong code for the 3rd arg (reg 7)
I have diagnosed this as a problem in combine, and have a patch in testing.
Opening this issue for status tracking.
[Bug rtl-optimization/52528] combine bug (powerpc testcase)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52528 --- Comment #1 from Chung-Lin Tang 2012-03-10 14:57:34 UTC --- Author: cltang Date: Sat Mar 10 14:57:30 2012 New Revision: 185175 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185175 Log: 2012-03-10 Chung-Lin Tang PR rtl-optimization/52528 * combine.c (can_combine_p): Add setting of subst_low_luid before call to expand_field_assignment(). Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug rtl-optimization/52528] combine bug (powerpc testcase)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52528 --- Comment #3 from Chung-Lin Tang 2012-03-15 10:04:18 UTC --- Author: cltang Date: Thu Mar 15 10:04:12 2012 New Revision: 185425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185425 Log: 2012-03-15 Chung-Lin Tang Backport from mainline 2012-03-10 Chung-Lin Tang PR rtl-optimization/52528 * combine.c (can_combine_p): Add setting of subst_low_luid before call to expand_field_assignment(). Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/combine.c
[Bug target/52667] New: sh_reorg segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52667 Bug #: 52667 Summary: sh_reorg segfault Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: clt...@gcc.gnu.org Target: sh-linux Attached testcase from glibc causes segfault ICE. Patch in testing, submitting issue for tracking.
[Bug target/52667] sh_reorg segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52667 --- Comment #1 from Chung-Lin Tang 2012-03-22 13:51:44 UTC --- Created attachment 26956 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26956 glibc testcase
[Bug target/52667] sh_reorg segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52667 --- Comment #2 from Chung-Lin Tang 2012-03-27 13:05:06 UTC --- Author: cltang Date: Tue Mar 27 13:05:01 2012 New Revision: 185867 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185867 Log: 2012-03-27 Chung-Lin Tang PR target/52667 * config/sh/sh.c (find_barrier): Add equality check of last_got to avoid going above orig insn. Update comments. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug target/52836] internal compiler error: in push_minipool_fix, at config/arm/arm.c:13084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52836 Chung-Lin Tang changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #2 from Chung-Lin Tang 2012-04-03 04:33:44 UTC --- Also note that, for the above testcase from Meador, the ICE is hidden after the changes in rev.185913, although a similar fail may still be triggered for gcc.c-torture/compile/920928-2.c
[Bug rtl-optimization/50496] [4.7 regression] ICE in redirect_jump, at jump.c:1497
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50496 --- Comment #9 from Chung-Lin Tang 2011-11-23 13:22:34 UTC --- Author: cltang Date: Wed Nov 23 13:22:30 2011 New Revision: 181664 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181664 Log: 2011-11-23 Chung-Lin Tang PR rtl-optimization/50496 * jump.c (redirect_jump): Assert fail on nlabel == NULL_RTX only after epilogue is created. Add comments. Modified: trunk/gcc/ChangeLog trunk/gcc/jump.c
[Bug rtl-optimization/51623] New: PowerPC section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51623 Bug #: 51623 Summary: PowerPC section type conflict Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: clt...@gcc.gnu.org Target: powerpc-linux Created attachment 26144 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26144 Uboot nand_dump testcase gcc-patches discussion thread: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01240.html During final output of objects, existence of a .text.unlikely section triggers a section flag mismatch when looking up in the section htab. More information in mailing list thread, attached are testcases, a larger one from U-boot, and a very minimal one trying to demonstrate the fail. (for the minimal testcase, use -Os/-O2 -mrelocatable to trigger, for the Uboot one add -ffreestanding)
[Bug rtl-optimization/51623] PowerPC section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51623 --- Comment #1 from Chung-Lin Tang 2011-12-19 15:44:10 UTC --- Created attachment 26145 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26145 Minimal testcase
[Bug other/79543] Inappropriate "ld --version" checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79543 --- Comment #5 from Chung-Lin Tang --- Author: cltang Date: Tue Sep 3 14:10:26 2019 New Revision: 275341 URL: https://gcc.gnu.org/viewcvs?rev=275341&root=gcc&view=rev Log: 2019-09-03 Chung-Lin Tang libatomic/ PR other/79543 * acinclude.m4 (LIBAT_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. libffi/ PR other/79543 * acinclude.m4 (LIBAT_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. libgomp/ PR other/79543 * acinclude.m4 (LIBGOMP_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. libitm/ PR other/79543 * acinclude.m4 (LIBITM_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. libstdc++-v3/ PR other/79543 * acinclude.m4 (GLIBCXX_CHECK_LINKER_FEATURES): Fix GNU ld --version scanning to conform to the GNU Coding Standards. * configure: Regenerate. Modified: trunk/libatomic/ChangeLog trunk/libatomic/acinclude.m4 trunk/libatomic/configure trunk/libffi/ChangeLog trunk/libffi/acinclude.m4 trunk/libffi/configure trunk/libgomp/ChangeLog trunk/libgomp/acinclude.m4 trunk/libgomp/configure trunk/libitm/ChangeLog trunk/libitm/acinclude.m4 trunk/libitm/configure trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug c/87924] OpenACC wait clauses without async-arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87924 --- Comment #2 from Chung-Lin Tang --- Author: cltang Date: Tue Feb 19 14:10:15 2019 New Revision: 269016 URL: https://gcc.gnu.org/viewcvs?rev=269016&root=gcc&view=rev Log: 2019-02-19 Chung-Lin Tang PR c/87924 gcc/c/ * c-parser.c (c_parser_oacc_clause_wait): Add representation of wait clause without argument as 'wait (GOMP_ASYNC_NOVAL)', adjust comments. gcc/cp/ * parser.c (cp_parser_oacc_clause_wait): Add representation of wait clause without argument as 'wait (GOMP_ASYNC_NOVAL)', adjust comments. gcc/fortran/ * openmp.c (gfc_match_omp_clauses): Add representation of wait clause without argument as 'wait (GOMP_ASYNC_NOVAL)'. libgomp/ * oacc-parallel.c (GOACC_parallel_keyed): Remove condition on call to goacc_wait(). (goacc_wait): Handle ACC_ASYNC_NOVAL case, remove goacc_thread() call and related adjustment. Reviewed-by: Thomas Schwinge Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/libgomp/ChangeLog trunk/libgomp/oacc-parallel.c
[Bug c/87924] OpenACC wait clauses without async-arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87924 --- Comment #4 from Chung-Lin Tang --- Author: cltang Date: Wed Feb 20 10:09:53 2019 New Revision: 269036 URL: https://gcc.gnu.org/viewcvs?rev=269036&root=gcc&view=rev Log: Correction of ChangeLog entry, Thomas provided the code for this change. 2019-02-19 Thomas Schwinge PR c/87924 * openmp.c (gfc_match_omp_clauses): Add representation of wait clause without argument as 'wait (GOMP_ASYNC_NOVAL)'. Modified: trunk/gcc/fortran/ChangeLog
[Bug target/90009] New: [nvptx] ICE when OpenACC region has num_workers>1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90009 Bug ID: 90009 Summary: [nvptx] ICE when OpenACC region has num_workers>1 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: cltang at gcc dot gnu.org Target Milestone: --- Target: nvptx Created attachment 46098 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46098&action=edit testcase ./mainline/bin/gcc -w -fopenacc -O2 nvptx-worker2-ice.c during RTL pass: mach nvptx-worker2-ice.c: In function ‘foo._omp_fn.0’: nvptx-worker2-ice.c:6:11: internal compiler error: Segmentation fault 6 | #pragma acc parallel num_workers(2) | ^ 0xe9b265 crash_signal /scratch/cltang/openacc/trunk/gcc/toplev.c:326 0x132ed7e nvptx_skip_par /scratch/cltang/openacc/trunk/gcc/config/nvptx/nvptx.c:4585 0x132f53a nvptx_neuter_pars /scratch/cltang/openacc/trunk/gcc/config/nvptx/nvptx.c:4791 0x132f325 nvptx_neuter_pars /scratch/cltang/openacc/trunk/gcc/config/nvptx/nvptx.c:4733 0x132fd9a nvptx_reorg /scratch/cltang/openacc/trunk/gcc/config/nvptx/nvptx.c:5025 0xe38c94 execute /scratch/cltang/openacc/trunk/gcc/reorg.c:3992 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. mkoffload: fatal error: ./mainline/bin/x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status compilation terminated.
[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72743 --- Comment #8 from Chung-Lin Tang --- Author: cltang Date: Thu Sep 15 09:46:36 2016 New Revision: 240155 URL: https://gcc.gnu.org/viewcvs?rev=240155&root=gcc&view=rev Log: 2016-09-15 Chung-Lin Tang PR fortran/72743 * ipa-icf.c (set_alias_uids): New function. (sem_variable::merge): Use set_alias_uids to set DECL_PT_UID of all the merged variable's referring aliases. testsuite/ * gfortran.dg/goacc/pr72743.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/goacc/pr72743.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72743 --- Comment #9 from Chung-Lin Tang --- Author: cltang Date: Thu Sep 15 10:00:14 2016 New Revision: 240156 URL: https://gcc.gnu.org/viewcvs?rev=240156&root=gcc&view=rev Log: 2016-09-15 Chung-Lin Tang Backport from mainline 2016-09-15 Chung-Lin Tang PR fortran/72743 * ipa-icf.c (set_alias_uids): New function. (sem_variable::merge): Use set_alias_uids to set DECL_PT_UID of all the merged variable's referring aliases. testsuite/ * gfortran.dg/goacc/pr72743.f90: New test. Added: branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/pr72743.f90 Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/ipa-icf.c branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
[Bug fortran/77371] [6/7 Regression] ICE in force_constant_size, at gimplify.c:671 (... and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77371 --- Comment #4 from Chung-Lin Tang --- Author: cltang Date: Sun Oct 2 10:13:04 2016 New Revision: 240700 URL: https://gcc.gnu.org/viewcvs?rev=240700&root=gcc&view=rev Log: 2016-10-02 Chung-Lin Tang PR fortran/77371 * omp-low.c (lower_omp_target): Avoid reference-type processing on pointers for firstprivate clause. * gimplify.c (gimplify_adjust_omp_clauses): Add 'remove = true' when emitting error on private/firstprivate reductions. testsuite/ * gfortran.dg/goacc/pr77371-1.f90: New test. * gfortran.dg/goacc/pr77371-2.f90: New test. Added: branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/pr77371-1.f90 branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/pr77371-2.f90 Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/gimplify.c branches/gomp-4_0-branch/gcc/omp-low.c branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 Chung-Lin Tang changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #1 from Chung-Lin Tang --- Sebastian, I'm not sure what your problem is. The atomics in nios2 are implemented by __sync_* functions placed in libgcc. The built-in function expansion inside GCC is aware of this, and __atomic_* functions get mapped to those. Is there anything affecting your use? libatomic is usually supported by those targets with more "rich" atomic instructions, and nios2 in its current form is obviously not one of them.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #3 from Chung-Lin Tang --- (In reply to Sebastian Huber from comment #2) > (In reply to Chung-Lin Tang from comment #1) > > Sebastian, I'm not sure what your problem is. The atomics in nios2 are > > implemented by __sync_* functions placed in libgcc. The built-in function > > expansion inside GCC is aware of this, and __atomic_* functions get mapped > > to those. Is there anything affecting your use? > > I think this mapping of __atomic_* functions to __sync_* functions is > wrong/outdated. Is this a speciality of the Nios II support? I am not > aware of a second target support in GCC which does this. The __sync_* > builtins are a legacy API: > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins. > html#g_t_005f_005fsync-Builtins Nios II is not the only target which implements __sync_*, see the libgcc source code for details. In the current GCC code expansion paths, the __atomic_* functions are meant to expand to hardware instruction sequences. In cases where we need to generate library calls for atomics, GCC only generates __sync_* calls. > > > > libatomic is usually supported by those targets with more "rich" atomic > > instructions, and nios2 in its current form is obviously not one of them. > > The libatomic is for architectures which lack atomic instructions. To clarify/correct my above statement, we do build libatomic like other targets, but the basic __atomic_* functions used inside it is also generated as __sync_* calls. libatomic does NOT directly "implement" the basic __atomic_* operations, that's supposed to be done inside the compiler. Can you more specifically describe what you're trying to do? Or is this just a general query?
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #5 from Chung-Lin Tang --- > I checked the code generation on some targets for the test case above. The > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets > generated all __atomic_* functions. > Only on Nios II it seems, the other targets emit __atomic_* calls. Many of those target archs use __sync_* by default on Linux, although you might generate __atomic_* on bare metal. That's the case on nios2; we should be generating __atomic_* calls if you're using nios2 ELF (bare metal), for Linux the compiler will generate __sync_* calls, unless the architecture has hardware instructions. > > > > > > > > libatomic is usually supported by those targets with more "rich" atomic > > > > instructions, and nios2 in its current form is obviously not one of > > > > them. > > > > > > The libatomic is for architectures which lack atomic instructions. > > > > To clarify/correct my above statement, we do build libatomic like other > > targets, but the basic __atomic_* functions used inside it is also generated > > as __sync_* calls. > > > > libatomic does NOT directly "implement" the basic __atomic_* operations, > > that's supposed to be done inside the compiler. > > > > Can you more specifically describe what you're trying to do? Or is this just > > a general query? > > I don't find any Nios II specific parts in libatomic. > > Implementing __atomic_* functions via __sync_* in libatomic makes no sense > to me. The host specific implementation should provide (libatomic_i.h): Most architectures don't have library implementations of __atomic_* operations, especially if we already have __sync_*. The major difference is the consistency model arguments in __atomic_* APIs, which is useless for simpler architectures like nios2.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #7 from Chung-Lin Tang --- (In reply to Sebastian Huber from comment #6) > (In reply to Chung-Lin Tang from comment #5) > > > I checked the code generation on some targets for the test case above. The > > > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets > > > generated all __atomic_* functions. > > > > > Only on Nios II it seems, the other targets emit __atomic_* calls. > > > > Many of those target archs use __sync_* by default on Linux, although you > > might generate __atomic_* on bare metal. > > That's the case on nios2; we should be generating __atomic_* calls if you're > > using nios2 ELF (bare metal), for Linux the compiler will generate __sync_* > > calls, unless the architecture has hardware instructions. > > This sounds reasonable. Which magic switch in GCC leads to the generation > of __sync_* functions instead of __atomic_* functions? You can use -fno-sync-libcalls to force OFF __sync_* and generate __atomic_* calls, if that's really what you want (although we have not implemented that kind of runtime support). > > > Implementing __atomic_* functions via __sync_* in libatomic makes no sense > > > to me. The host specific implementation should provide (libatomic_i.h): > > > > Most architectures don't have library implementations of __atomic_* > > operations, especially if we already have __sync_*. The major difference is > > the consistency model arguments in __atomic_* APIs, which is useless for > > simpler architectures like nios2. > > The __sync_* stuff is deprecated. A user can always use the __atomic_* API, the compiler will take care of the rest.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #9 from Chung-Lin Tang ---
(In reply to Sebastian Huber from comment #8)
> (In reply to Chung-Lin Tang from comment #7)
> > (In reply to Sebastian Huber from comment #6)
> > > (In reply to Chung-Lin Tang from comment #5)
> > > > > I checked the code generation on some targets for the test case
> > > > > above. The
> > > > > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets
> > > > > generated all __atomic_* functions.
> > > >
> > > > > Only on Nios II it seems, the other targets emit __atomic_* calls.
> > > >
> > > > Many of those target archs use __sync_* by default on Linux, although
> > > > you
> > > > might generate __atomic_* on bare metal.
> > > > That's the case on nios2; we should be generating __atomic_* calls if
> > > > you're
> > > > using nios2 ELF (bare metal), for Linux the compiler will generate
> > > > __sync_*
> > > > calls, unless the architecture has hardware instructions.
> > >
> > > This sounds reasonable. Which magic switch in GCC leads to the generation
> > > of __sync_* functions instead of __atomic_* functions?
> >
> > You can use -fno-sync-libcalls to force OFF __sync_* and generate __atomic_*
> > calls,
> > if that's really what you want (although we have not implemented that kind
> > of runtime support).
>
> Ok, thanks for the hint. Now I know where the problem is really. In
> "gcc/config/rtems.h" we define TARGET_LINUX_ABI to enable the TLS support
> for RTEMS. This is due to (nios2.c):
>
> #undef TARGET_HAVE_TLS
> #define TARGET_HAVE_TLS TARGET_LINUX_ABI
>
> We also have:
>
> /* Implement TARGET_INIT_LIBFUNCS. */
> static void
> nios2_init_libfuncs (void)
> {
> /* For Linux, we have access to kernel support for atomic operations. */
> if (TARGET_LINUX_ABI)
> init_sync_libfuncs (UNITS_PER_WORD);
> }
>
> Would it be possible to add an alternative way to enable TLS support for
> RTEMS? For example:
>
> #ifndef TARGET_HAVE_TLS
> #define TARGET_HAVE_TLS TARGET_LINUX_ABI
> #endif
>
> Then use in rtems.h:
>
> #define TARGET_HAVE_TLS 1
I think I know what you need, I submit a patch later.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #10 from Chung-Lin Tang --- Author: cltang Date: Thu Nov 17 06:26:56 2016 New Revision: 242534 URL: https://gcc.gnu.org/viewcvs?rev=242534&root=gcc&view=rev Log: 2016-11-17 Chung-Lin Tang PR target/78357 * config/nios2/nios2.c (nios2_init_libfuncs): Remove TARGET_LINUX_ABI condition. (TARGET_INIT_LIBFUNCS): Delete definition and... * config/nios2/linux.h (TARGET_INIT_LIBFUNCS): ...move to here, add comments. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nios2/linux.h trunk/gcc/config/nios2/nios2.c
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557 --- Comment #10 from Chung-Lin Tang --- The ICE still happens under -mno-lra (and using reload).
[Bug middle-end/61430] [4.10 regression] ICE in lra_create_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61430 --- Comment #6 from Chung-Lin Tang --- Author: cltang Date: Mon Jun 16 09:58:34 2014 New Revision: 211701 URL: https://gcc.gnu.org/viewcvs?rev=211701&root=gcc&view=rev Log: 2014-06-16 Chung-Lin Tang PR middle-end/61430 * lra-lives.c (process_bb_lives): Skip creating copy during insn scan when src/dest has constrained to same regno. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-lives.c
[Bug tree-optimization/61554] [4.10 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61554 --- Comment #4 from Chung-Lin Tang --- Author: cltang Date: Tue Jun 24 06:33:58 2014 New Revision: 211928 URL: https://gcc.gnu.org/viewcvs?rev=211928&root=gcc&view=rev Log: 2014-06-24 Chung-Lin Tang PR tree-optimization/61554 * tree-ssa-propagate.c: Include "bitmap.h". (substitute_and_fold_dom_walker): Add 'bitmap need_eh_cleanup' member, properly update constructor/destructor. (substitute_and_fold_dom_walker::before_dom_children): Remove call to gimple_purge_dead_eh_edges, add bb->index to need_eh_cleaup instead. (substitute_and_fold): Call gimple_purge_all_dead_eh_edges on need_eh_cleanup. testsuite/ 2014-06-24 Markus Trippelsdorf PR tree-optimization/61554 * g++.dg/torture/pr61554.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr61554.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-propagate.c
[Bug target/59784] Nios2: Wrong code generation for fextsd custom instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59784 --- Comment #1 from Chung-Lin Tang --- Author: cltang Date: Thu Jan 30 05:51:30 2014 New Revision: 207297 URL: http://gcc.gnu.org/viewcvs?rev=207297&root=gcc&view=rev Log: 2014-01-30 Savin Zlobec PR target/59784 * config/nios2/nios2.c (nios2_fpu_insn_asm): Fix asm output of SFmode to DFmode case. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nios2/nios2.c
[Bug libgomp/67141] wrong libgomp mutex initialisation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 --- Comment #6 from Chung-Lin Tang --- Author: cltang Date: Tue Sep 22 06:45:22 2015 New Revision: 227994 URL: https://gcc.gnu.org/viewcvs?rev=227994&root=gcc&view=rev Log: 2015-09-22 Chung-Lin Tang PR libgomp/67141 * oacc-int.h (goacc_host_init): Add declaration. * oacc-host.c (goacc_host_init): Remove static and constructor attribute. * oacc-init.c (goacc_runtime_initialize): Call goacc_host_init() at end. Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-host.c trunk/libgomp/oacc-init.c trunk/libgomp/oacc-int.h
[Bug libgomp/67141] wrong libgomp mutex initialisation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 --- Comment #7 from Chung-Lin Tang --- Author: cltang Date: Tue Sep 22 11:18:23 2015 New Revision: 228011 URL: https://gcc.gnu.org/viewcvs?rev=228011&root=gcc&view=rev Log: 2015-09-22 Chung-Lin Tang Backport from mainline: 2015-09-22 Chung-Lin Tang PR libgomp/67141 * oacc-int.h (goacc_host_init): Add declaration. * oacc-host.c (goacc_host_init): Remove static and constructor attribute. * oacc-init.c (goacc_runtime_initialize): Call goacc_host_init() at end. Modified: branches/gcc-5-branch/libgomp/ChangeLog branches/gcc-5-branch/libgomp/oacc-host.c branches/gcc-5-branch/libgomp/oacc-init.c branches/gcc-5-branch/libgomp/oacc-int.h
[Bug libgomp/67141] wrong libgomp mutex initialisation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 --- Comment #8 from Chung-Lin Tang --- Can the MinGW folks confirm if the reported problem was fixed? Thanks.
[Bug target/43872] VLAs are not aligned correctly on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43872 --- Comment #4 from Chung-Lin Tang 2011-03-17 14:02:15 UTC --- Author: cltang Date: Thu Mar 17 14:02:12 2011 New Revision: 171096 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171096 Log: 2011-03-17 Chung-Lin Tang PR target/43872 * config/arm/arm.c (arm_get_frame_offsets): Adjust early return condition with !cfun->calls_alloca. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug target/46934] gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934 --- Comment #3 from Chung-Lin Tang 2011-03-23 14:48:38 UTC --- Please disregard the above comments, I think this is an ARM backend problem after all.
[Bug target/46934] gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934 --- Comment #4 from Chung-Lin Tang 2011-03-24 02:47:58 UTC --- Author: cltang Date: Thu Mar 24 02:47:55 2011 New Revision: 171379 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171379 Log: 2011-03-23 Chung-Lin Tang PR target/46934 * config/arm/arm.md (casesi): Use the gen_int_mode() function to subtract lower bound instead of GEN_INT(). testsuite/ * gcc.target/arm/pr46934.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/pr46934.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
[Bug target/48250] ICE in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48250 --- Comment #2 from Chung-Lin Tang 2011-04-12 04:43:01 UTC --- Author: cltang Date: Tue Apr 12 04:42:55 2011 New Revision: 172297 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172297 Log: 2011-04-11 Chung-Lin Tang Richard Earnshaw PR target/48250 * config/arm/arm.c (arm_legitimize_reload_address): Update cases to use sign-magnitude offsets. Reject unsupported unaligned cases. Add detailed description in comments. * config/arm/arm.md (reload_outdf): Disable for ARM mode; change condition from TARGET_32BIT to TARGET_ARM. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md
[Bug target/43872] VLAs are not aligned correctly on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43872 Chung-Lin Tang changed: What|Removed |Added Status|NEW |RESOLVED CC||cltang at gcc dot gnu.org Resolution||FIXED Known to fail|| --- Comment #5 from Chung-Lin Tang 2011-04-23 08:36:28 UTC --- This should be fixed now.
[Bug target/46934] gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934 Chung-Lin Tang changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Chung-Lin Tang 2011-05-16 08:09:48 UTC --- This is fixed now.
[Bug c++/46298] New: constexpr ICE on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46298 Summary: constexpr ICE on ARM Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: clt...@gcc.gnu.org Target: arm Current mainline trunk ARM build fails with this (seems a BIND_EXPR appears in an assertion expecting a CALL_EXPR): make[4]: Entering directory `/home/cltang/nexus/build/gcc-arm-4_6/arm-nthu-linux-gnueabi/libstdc++-v3/include' mkdir -p ./arm-nthu-linux-gnueabi/bits/stdc++.h.gch /home/cltang/nexus/build/gcc-arm-4_6/./gcc/xgcc -shared-libgcc -B/home/cltang/nexus/build/gcc-arm-4_6/./gcc -nostdinc++ -L/home/cltang/nexus/build/gcc-arm-4_6/arm-nthu-linux-gnueabi/libstdc++-v3/src -L/home/cltang/nexus/build/gcc-arm-4_6/arm-nthu-linux-gnueabi/libstdc++-v3/src/.libs -B/home/cltang/nexus/arm-4_6/arm-nthu-linux-gnueabi/bin/ -B/home/cltang/nexus/arm-4_6/arm-nthu-linux-gnueabi/lib/ -isystem /home/cltang/nexus/arm-4_6/arm-nthu-linux-gnueabi/include -isystem /home/cltang/nexus/arm-4_6/arm-nthu-linux-gnueabi/sys-include-x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE -I/home/cltang/nexus/build/gcc-arm-4_6/arm-nthu-linux-gnueabi/libstdc++-v3/include/arm-nthu-linux-gnueabi -I/home/cltang/nexus/build/gcc-arm-4_6/arm-nthu-linux-gnueabi/libstdc++-v3/include -I/home/cltang/nexus/trunk/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/cltang/nexus/trunk/libstdc++-v3/include/precompiled/stdc++.h \ -o arm-nthu-linux-gnueabi/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /home/cltang/nexus/build/gcc-arm-4_6/arm-nthu-linux-gnueabi/libstdc++-v3/include/ccomplex:42:0, from /home/cltang/nexus/trunk/libstdc++-v3/include/precompiled/stdc++.h:53: /home/cltang/nexus/build/gcc-arm-4_6/arm-nthu-linux-gnueabi/libstdc++-v3/include/complex: In constructor 'constexpr std::complex::complex(std::complex::_ComplexT)': /home/cltang/nexus/build/gcc-arm-4_6/arm-nthu-linux-gnueabi/libstdc++-v3/include/complex:1044:67: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5475
[Bug c++/46298] constexpr ICE on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46298 --- Comment #2 from Chung-Lin Tang 2010-11-04 18:03:21 UTC --- Created attachment 22286 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22286 Testcase -std=gnu++0x is enough to trigger, but seems to only manifest on ARM.
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557 Chung-Lin Tang changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #8 from Chung-Lin Tang 2010-12-13 06:46:26 UTC --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00732.html
[Bug target/46883] GCC ICE with error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46883 Chung-Lin Tang changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #4 from Chung-Lin Tang 2010-12-14 14:12:40 UTC --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01096.html
[Bug target/46883] GCC ICE with error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46883 --- Comment #5 from Chung-Lin Tang 2010-12-16 05:10:23 UTC --- Author: cltang Date: Thu Dec 16 05:10:18 2010 New Revision: 167900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167900 Log: 2010-12-16 Chung-Lin Tang PR target/46883 * config/arm/arm.md (zero_extendhisi2 for register input splitter): Change "register_operand" to "s_register_operand". (zero_extendqisi2 for register input splitter): Same. testsuite/ * gcc.target/arm/pr46883.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/arm/pr46883.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
[Bug target/48250] ICE in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48250 Chung-Lin Tang changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #5 from Chung-Lin Tang 2011-06-05 14:12:03 UTC --- I was not able to reproduce these ICEs, tried backporting to both mainline gcc-4_6-branch and a latest Linaro 4.6 pull.
[Bug fortran/70598] Fortran OpenACC host_data construct ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70598 --- Comment #4 from Chung-Lin Tang --- Author: cltang Date: Sun Aug 14 18:19:10 2016 New Revision: 239457 URL: https://gcc.gnu.org/viewcvs?rev=239457&root=gcc&view=rev Log: 2016-08-14 Chung-Lin Tang PR fortran/70598 gcc/fortran/ * openmp.c (resolve_omp_clauses): Adjust use_device clause handling to only allow pointers and arrays. gcc/testsuite/ * gfortran.dg/goacc/host_data-tree.f95: Adjust to use pointers in use_device clause. * gfortran.dg/goacc/uninit-use-device-clause.f95: Likewise. * gfortran.dg/goacc/list.f95: Adjust to catch "neither a POINTER nor an array" error messages. libgomp/ * testsuite/libgomp.oacc-fortran/host_data-1.f90: New test. Added: trunk/libgomp/testsuite/libgomp.oacc-fortran/host_data-1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/goacc/host_data-tree.f95 trunk/gcc/testsuite/gfortran.dg/goacc/list.f95 trunk/gcc/testsuite/gfortran.dg/goacc/uninit-use-device-clause.f95 trunk/libgomp/ChangeLog
[Bug other/76739] New: Add support dynamically allocated multi-dimensional arrays in OpenACC data clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76739 Bug ID: 76739 Summary: Add support dynamically allocated multi-dimensional arrays in OpenACC data clauses Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: cltang at gcc dot gnu.org Target Milestone: --- According to the OpenACC specification, dynamically allocated multi-dimensional arrays are to be supported in C/C++, for example: typedef float row[200]; row* BB; float* CC[200]; float** DD; We will be using this PR to track this development.
[Bug other/76739] Add support dynamically allocated multi-dimensional arrays in OpenACC data clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76739 Chung-Lin Tang changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-08-15 Assignee|unassigned at gcc dot gnu.org |cltang at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/70895] OpenACC: loop reduction does not work. Output is zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70895 --- Comment #6 from Chung-Lin Tang --- Author: cltang Date: Thu Aug 18 14:46:19 2016 New Revision: 239576 URL: https://gcc.gnu.org/viewcvs?rev=239576&root=gcc&view=rev Log: 2016-08-18 Chung-Lin Tang PR middle-end/70895 gcc/ * gimplify.c (omp_add_variable): Adjust/add variable mapping on enclosing parallel construct for reduction variables on OpenACC loop directives. gcc/testsuite/ * gfortran.dg/goacc/loop-tree-1.f90: Add gimple scan-tree-dump test. * c-c++-common/goacc/reduction-1.c: Likewise. * c-c++-common/goacc/reduction-2.c: Likewise. * c-c++-common/goacc/reduction-3.c: Likewise. * c-c++-common/goacc/reduction-4.c: Likewise. libgomp/ * testsuite/libgomp.oacc-fortran/reduction-7.f90: Add explicit firstprivate clauses. * testsuite/libgomp.oacc-fortran/reduction-6.f90: Remove explicit copy clauses. * testsuite/libgomp.oacc-c-c++-common/reduction-7.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-flt.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-wv-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/collapse-4.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-w-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-dbl.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/reduction-1.c trunk/gcc/testsuite/c-c++-common/goacc/reduction-2.c trunk/gcc/testsuite/c-c++-common/goacc/reduction-3.c trunk/gcc/testsuite/c-c++-common/goacc/reduction-4.c trunk/gcc/testsuite/gfortran.dg/goacc/loop-tree-1.f90 trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/collapse-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/collapse-4.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-w-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-wv-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-7.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-dbl.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-flt.c trunk/libgomp/testsuite/libgomp.oacc-fortran/reduction-6.f90 trunk/libgomp/testsuite/libgomp.oacc-fortran/reduction-7.f90
[Bug middle-end/70895] OpenACC: loop reduction does not work. Output is zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70895 --- Comment #7 from Chung-Lin Tang --- Author: cltang Date: Thu Aug 18 14:56:11 2016 New Revision: 239577 URL: https://gcc.gnu.org/viewcvs?rev=239577&root=gcc&view=rev Log: Backport from mainline: 2016-08-18 Chung-Lin Tang PR middle-end/70895 gcc/ * gimplify.c (omp_add_variable): Adjust/add variable mapping on enclosing parallel construct for reduction variables on OpenACC loop directives. gcc/testsuite/ * gfortran.dg/goacc/loop-tree-1.f90: Add gimple scan-tree-dump test. * c-c++-common/goacc/reduction-1.c: Likewise. * c-c++-common/goacc/reduction-2.c: Likewise. * c-c++-common/goacc/reduction-3.c: Likewise. * c-c++-common/goacc/reduction-4.c: Likewise. libgomp/ * testsuite/libgomp.oacc-fortran/reduction-7.f90: Add explicit firstprivate clauses. * testsuite/libgomp.oacc-fortran/reduction-6.f90: Remove explicit copy clauses. * testsuite/libgomp.oacc-c-c++-common/reduction-7.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-flt.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-wv-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/collapse-4.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-w-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-dbl.c: Likewise. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/gimplify.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/reduction-1.c branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/reduction-2.c branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/reduction-3.c branches/gcc-6-branch/gcc/testsuite/c-c++-common/goacc/reduction-4.c branches/gcc-6-branch/gcc/testsuite/gfortran.dg/goacc/loop-tree-1.f90 branches/gcc-6-branch/libgomp/ChangeLog branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/collapse-2.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/collapse-4.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-w-1.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-wv-1.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-7.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-dbl.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-flt.c branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/reduction-6.f90 branches/gcc-6-branch/libgomp/testsuite/libgomp.oacc-fortran/reduction-7.f90
[Bug middle-end/70895] OpenACC: loop reduction does not work. Output is zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70895 --- Comment #8 from Chung-Lin Tang --- Author: cltang Date: Thu Aug 18 15:01:50 2016 New Revision: 239579 URL: https://gcc.gnu.org/viewcvs?rev=239579&root=gcc&view=rev Log: Backport from mainline: 2016-08-18 Chung-Lin Tang PR middle-end/70895 gcc/ * gimplify.c (omp_add_variable): Adjust/add variable mapping on enclosing parallel construct for reduction variables on OpenACC loop directives. gcc/testsuite/ * gfortran.dg/goacc/loop-tree-1.f90: Add gimple scan-tree-dump test. * c-c++-common/goacc/reduction-1.c: Likewise. * c-c++-common/goacc/reduction-2.c: Likewise. * c-c++-common/goacc/reduction-3.c: Likewise. * c-c++-common/goacc/reduction-4.c: Likewise. libgomp/ * testsuite/libgomp.oacc-fortran/reduction-7.f90: Add explicit firstprivate clauses. * testsuite/libgomp.oacc-fortran/reduction-6.f90: Remove explicit copy clauses. * testsuite/libgomp.oacc-c-c++-common/reduction-7.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-flt.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-wv-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/collapse-4.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/loop-red-w-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/reduction-dbl.c: Likewise. Modified: branches/gomp-4_0-branch/gcc/gimplify.c branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/reduction-1.c branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/reduction-2.c branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/reduction-3.c branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/reduction-4.c branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/loop-tree-1.f90 branches/gomp-4_0-branch/libgomp/ChangeLog.gomp branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/collapse-2.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/collapse-4.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-w-1.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-wv-1.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-7.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-dbl.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-flt.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/reduction-6.f90 branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/reduction-7.f90
[Bug c++/103705] [12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'array_ref' in finish_omp_clauses, at cp/semantics.c:7928 since r12-5838-g6c0399378e77d029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103705 Chung-Lin Tang changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Chung-Lin Tang --- I don't see more to fix ATM. Closing for now.
[Bug fortran/104696] [OpenMP] Implicit mapping breaks struct mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104696 --- Comment #3 from Chung-Lin Tang --- The problem, at a low-level, is that the Fortran FE is using always_pointer, while C/C++ front-ends generate attach_detach (and turns in attach after gimplify). attach and always_pointer both modify the GPU-side field into the correct GPU pointer, but only attach will "clean-up" at the end, restoring the host-side pointer contents, before the full implicit struct mapping copies back to the host (due to tofrom map-kind). Since Fortran array descriptors are like little structs, I think quickest fix is to make the Fortran FE use 'attach_detach' for the array data pointer field. That should immediately make things work. A more elaborate way is to try to turn off the creation of the implicit mapping for the whole array descriptor, which should be a killer of performance. (not sure when this started, although prior changes did put implicit mappings to the very front of the sequence)
[Bug middle-end/103416] [12 Regression][OpenMP] Bogus firstprivate(n) map(to:n [len: 4][implicit])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103416 --- Comment #1 from Chung-Lin Tang --- Can you see if adding this patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583279.html fixes this problem? If so, then it should be another occurrence of PR90030
[Bug c++/105861] New: OpenMP target construct not properly privatizing C++ member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105861
Bug ID: 105861
Summary: OpenMP target construct not properly privatizing C++
member variables
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cltang at gcc dot gnu.org
Target Milestone: ---
struct C {
omp_allocator_handle_t a;
void foo (void) {
#pragma omp target private (a)
a = (omp_allocator_handle_t) 0;
}
};
int main (void)
{
C c;
c.foo ();
return 0;
}
After C++ front-end processing we get:
{
omp_allocator_handle_t D.2823 [value-expr: ((struct C *) this)->a];
#pragma omp target private(D.2823)
{
{
<>>>>;
}
}
}
The OMP field privatization seems to be doing something here.
However gimplify turns this into:
void C::foo (struct C * const this)
{
omp_allocator_handle_t a [value-expr: ((struct C *) this)->a];
#pragma omp target num_teams(1) thread_limit(0) private(a) \
map(alloc:MEM[(char *)this] [len: 0]) map(firstprivate:this [pointer
assign, bias: 0])
{
this->a = 0;
}
}
Which is incorrect. Proper privatization should look something like this (which
works for omp parallel/task):
void C::foo (struct C * const this)
{
omp_allocator_handle_t a [value-expr: ((struct C *) this)->a];
#pragma omp parallel private(a)
{
a = 0;
}
}
Suspect that some where in gimplify, there's some insufficient handling of the
omp_disregard_value_expr langhook
under OMP_TARGET case. Creating issue here to track this.
