http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605
--- Comment #5 from Dan Nagle 2011-12-18 13:13:48 UTC
---
Citations from 10-007r1.pdf
[185:17-18] says the polymorphic symbol_ptr takes the type of the type guard
within the type guard.
[171:7-8] says the associating entity loses the pointer at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51607
--- Comment #3 from David 2011-12-18 14:15:15 UTC ---
any ideas of how to solve this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605
--- Comment #11 from Dan Nagle 2011-12-19 15:51:40
UTC ---
Hi,
I can confirm that changing the label of the select type to
integer_or_logical_or_error
removes the ICE.
I did so at lines 9325 and 13536 in the original source.
The new label is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40963
--- Comment #5 from Andrew Baldwin 2012-01-31
04:53:40 UTC ---
(In reply to comment #4)
> I encountered the same bug in gfortran 4.7.0 20110329 and 4.5.2.
>
> Are there any updates on this bug?
I did not encounted this bug with g++ 4.7.0 20
: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: moussu.robin at pm dot me
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hello,
I filled first a bug on gcovr bug-tracker, and they eventually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994
--- Comment #2 from Robin ---
Nice :)
Feel free to ask me any additionnal things if it may help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994
--- Comment #4 from Robin ---
Perfect! How do I test your patch. If I update my git clone of gcc (gcov is in
gcc repo, isn't it?), it should already be in it, or do I need to wait a few
days?
I guess I can also apply the patch itself on my repo t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994
--- Comment #6 from Robin ---
Ok, thx
Envoyé depuis ProtonMail mobile
Message d'origine
On 23 janv. 2019 à 12:33, marxin at gcc dot gnu.org a écrit :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994
>
> --- Comment #5 fro
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: me at zv dot io
Target Milestone: ---
Code generated by gcc targeting `sh2eb-linux-musl` occasionally
contains duplicate symbols with optimization level `O2` or above
and produces the following errors during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89012
--- Comment #3 from Zach van Rijn ---
Created attachment 45545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45545&action=edit
Tarball containing intermediate asm (with -dp) for each of 5 cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89012
--- Comment #4 from Zach van Rijn ---
The error can be reproduced at `O1` optimization level with both
(strictly both) of the following options:
./cc -c mintest.c -O1 -freorder-blocks-algorithm=stc -ftree-pre
Changing to `-freorder-blocks-algor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89012
--- Comment #5 from Zach van Rijn ---
Created attachment 45546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45546&action=edit
All files produced by -O2 -da
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to the formula for 'common_type', as an abominable function type does
not have a valid retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029
--- Comment #2 from Alisdair Meredith ---
Having just discovered -ftime-report due to recent blog posts, I thought I
would repeat the experiment, and can confirm it is still an issue in the latest
development gcc available to me through MacPorts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029
--- Comment #3 from Alisdair Meredith ---
And for reference, -ftime-report on the same file without -Wall:
time g++ -std=c++2a main.cpp -ftime-report
Time variable usr sys wall
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at adhokshajmishraonline dot in
Target Milestone: ---
Proof of concept:
=
template
auto make_value(){
return T{};
}
template
auto call(F func
Assignee: unassigned at gcc dot gnu.org
Reporter: angus at agibson dot me
Target Milestone: ---
Created attachment 44132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44132&action=edit
Segfaulting example
I've run into a bit of a heisenbug regarding the associat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786
--- Comment #2 from Angus Gibson ---
Changing the declaration of e to also be 'target', and associating the pointer:
CS%v(2)%p => e
if (query_ptr(e, CS)) then
...
still causes the segfault. Perhaps I disconnected this from the orig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85786
--- Comment #11 from Angus Gibson ---
Apologies if this is unrelated to the issue at hand (I don't quite understand
how everything is inter-related yet), but maybe it helps. First up, here's what
valgrind says about the segfault:
...
loc(cs%v(2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152
Tomasz Konojacki changed:
What|Removed |Added
CC||me at xenu dot pl
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69616
Tomasz Konojacki changed:
What|Removed |Added
CC||me at xenu dot pl
--- Comment #4
: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: bonjour at matteodelabre dot me
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 44315
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86291
--- Comment #7 from Mattéo Delabre ---
Can confirm the fix works for my use case. Thanks!
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: beachboy44 at me dot com
Target Milestone: ---
https://godbolt.org/z/8O-ItF
The following code fails to compile:
template
struct S {};
template
++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Per several existing bug reports (e.g.,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433) in phase one of
translation, when mapping source character set to basic character set, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87438
--- Comment #1 from Zach van Rijn ---
Created attachment 46699
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46699&action=edit
Test case. Triggers bug on 8.x to at least 10-20190721.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87438
--- Comment #2 from Zach van Rijn ---
Using GCC 8-20180706 snapshot,
gcc -c -O2 -fPIC grapes.c
during RTL pass: reload
grapes.c: In function 'smaxval_r8':
grapes.c:57:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1155
}
^
0x408422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91309
--- Comment #1 from beachboy44 at me dot com ---
Possibly related cases that also fail to compile:
template
using F = decltype([]{ return T{0}; });
auto g = [](auto x) {
using G = F;
return G{}();
};
https://godbolt.org/z/tSwWUF
auto
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alistair at alistair23 dot me
Target Milestone: ---
Target: riscv32
Build: x86_64
Created attachment 46845
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91691
--- Comment #1 from Alistair ---
The full command line is:
gcc clnt_udp.c -c -std=gnu11 -fgnu89-inline -O2 -Wall -Wwrite-strings -Wundef
-Werror -fmerge-all-constants -frounding-math -fno-stack-protector
-Wstrict-prototypes -Wold-style-definiti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91691
--- Comment #2 from Alistair ---
I can also reproduce this with the 9.2 release.
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: beachboy44 at me dot com
Target Milestone: ---
https://godbolt.org/z/OQHx2M
The following code fails to
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: forkenmasterforce at keemail dot me
Target Milestone: ---
Instruction ignored causing the error seems to be emitted at m68k.md:7370
return "lea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91829
Jon Daniel changed:
What|Removed |Added
URL||https://cygwin.com/ml/cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91829
--- Comment #2 from Jon Daniel ---
Enabling only the COLDFIRE section in load_got seems to fix the compilation
problem even without a coldfire cpu target.
I'll try to figure out which lea move.l combo to use for a specific motorola
target cpu.
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
The following program should compile and run without error when built as C++17
or later. However, current versions of g++ will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91958
Alisdair Meredith changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83534
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to [temp.explicit] p15, final sentence (after the note), 'extern
template' declarations cannot have intern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92034
--- Comment #1 from Alisdair Meredith ---
Sorry, link to Compiler Explorer showing the right compiler test (Clang 9):
https://godbolt.org/z/9QIIrE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92034
--- Comment #4 from Alisdair Meredith ---
(In reply to Jonathan Wakely from comment #3)
> I'm not sure if a diagnostic is required. The standard doesn't specifically
> say it's ill-formed to do this. By my reading it's undefined, and so
> silentl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91691
--- Comment #4 from Alistair ---
Thanks for looking into this Jim. We have worked around it in glibc master, so
that's fine that it can't be back ported. I'm glad it has been fixed in the
latest version.
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: angus at agibson dot me
Target Milestone: ---
Created attachment 47036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47036&action=edit
Reproducing example
I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #2 from Angus Gibson ---
Created attachment 47037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47037&action=edit
Reproducing example (gz)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #5 from Angus Gibson ---
I agree that it's not ideal... Unfortunately an awkward file format, and
fortran is usually the wrong language for this kind of IO anyway. I guess the
note that "A processor may prohibit some control character
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ethan at ethanhs dot me
Target Milestone: ---
As I have read the filesystem TS, I believe concat on path items should have an
overload following:
path& operator+=(value_type x);
However, on trying to use 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Jens-S. Vöckler changed:
What|Removed |Added
CC||jens4303 at me dot com
--- Comment
mal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: 7aitsev at pm dot me
Target Milestone: ---
Since GCC version 8.0 at least these two options were replaced:
-fdump-class-hierarchy ---> -fdump-lang-class
-fdump-translation-unit ---> -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89712
--- Comment #6 from Maxim Zaitsev <7aitsev at pm dot me> ---
(In reply to Martin Liška from comment #2)
> @Maxim: I see -fdump-class-hierarchy[-n] mentioned in PDF manual. Where do
> you see -fdump-translation-unit mentione
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
Target Milestone: ---
Using built-in specs.
COLLECT_GCC=/home/jojo/work/csky/cskytoolchain/csky-toolchain-build-riscv/riscv-install/bin/riscv64-unknown-linux-gnu-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #3 from jojo ---
Haha..., get_address_cost() will cost down some address which is not my
expected, you
can get that code from my the 1st comment, i can not understand why adding that
code
in new version :(
(In reply to Andrew Pinski
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rjiejie at me dot com
Target Milestone: ---
with the following code, it's compiled error with gcc-newlib*:
error: ‘mutex’ is not a member of ‘std’
and it's ok in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90371
--- Comment #2 from jojo ---
Thanks for your reply:)
(In reply to Andrew Pinski from comment #1)
> For your target, needs to fully support pthreads and a few other things.
> You can look at what is needed via libstdc++/configure.ac and related f
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: moussu.robin at pm dot me
Target Milestone: ---
Test it directly on https://godbolt.org/z/IsXG2E
Version of the compiler: 9.0.1 (contracts branch
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: moussu.robin at pm dot me
Target Milestone: ---
Reproduce error with https://godbolt.org/z/cjlS79
gcc version: 9.0.1 (concept branch)
The following code, when compiled with
-std=c++2a -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #13 from jojo ---
Hi, guys,
Any solution for this issue ?
My be the following patch is choice :) ?
Are there issue with applied this patch ?
--- tree-ssa-loop-ivopts-orig.c 2019-05-17 09:32:58.05200 +0800
+++ tree-ssa-loop-iv
iority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
This is a tale of woe in the standard, but boils down to the following simple
test program, which compiles and passes with the current Microsoft
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to the current standard, is_default_constructible_v is true if
is_constructible_v is true. The current libstdc++ disagrees
gcc 8 within, and it did build
fine. This tells me that the symptoms described in this bug are still present
in recent sources.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Note that this bug is a real corner case unlikely to occur in production code,
but bit us in experimental coding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90960
--- Comment #2 from Alisdair Meredith ---
I agree the second problem looks like a dupe.
It has since been pointed out to me that the first error is indeed correct, and
simply the error message is less than helpful:
[temp.spec]p8 of C++17 says
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #82 from Jens-S. Vöckler ---
I had some prior issues with w.r.t 32bits. Tinkering, this script does build a
gcc 9.1 on macOS 10.14.5 on APFS. I didn't create it for beauty, and it's
specific to my setup. The resulting compiler is unab
++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at adhokshajmishraonline dot in
Target Milestone: ---
Test code
-
class A {};
class B {
using C = A;
enum D {
A,
};
};
When the above code is compiled using g++ (g++ -c test.cpp -o test.o), the
compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91119
--- Comment #2 from Adhokshaj Mishra ---
(In reply to Andrew Pinski from comment #1)
> No GCC is correct. There is another section which you missed made this code
> invalid but no diagnostic is required.
Can you please point to the section whic
: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: me at nvartolomei dot com
Target Milestone: ---
Hello,
Here is a test program that behaves different on Linux vs macOS.
main.c:
```
#include "lib.h"
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: me at zv dot io
Target Milestone: ---
Created attachment 44752
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44752&action=edit
Build log with -j1 for clarity.
Attempting to build GCC 8.2.0 with the followin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #55 from Jens-S. Vöckler ---
Would it be worthwhile to limit it to "darwin" *and* "apfs" on objdir? I am
thinking of something along the lines of
diskutil info $(stat -f '%Sd' /path/to/objdir) | \
perl -lane 'print $F[$#F] if /^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #57 from Jens-S. Vöckler ---
(In reply to Francois-Xavier Coudert from comment #56)
> I would advise to keep it simple.
Agreed: Simple is better.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at swarmer dot me
Target Milestone: ---
Created attachment 44866
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44866&action=edit
Source code to reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671
--- Comment #2 from Anton Barkovsky ---
No, without sanitizers also, although I'm getting a different value (1433833072
in my latest run) in the debugger instead of 16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87671
--- Comment #7 from Anton Barkovsky ---
(In reply to Jonathan Wakely from comment #6)
> That does seem to explain the difference. With GCC 8 GDB thinks that 'ptr'
> is passed in the register %rsi so the value in the register is the value of
> the
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stypox at pm dot me
Target Milestone: ---
Created attachment 44911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44911&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14557
--- Comment #22 from postmas...@flash-gordon-me-uk.bounceio.net ---
Your email was bounced...
-
... because something went wrong between you and your recipient. Oh
no!
What to do next
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Created attachment 38456
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38456&action=edit
file is very slow compiled with Wall
The attached file uses a simp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #27 from Thorsten Kurth ---
Hello Jakub,
I wanted to follow up on this. Is there any progress on this issue?
Best Regards
Thorsten Kurth
++
Assignee: unassigned at gcc dot gnu.org
Reporter: thorstenkurth at me dot com
Target Milestone: ---
Created attachment 41990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41990&action=edit
Test case
Dear Sir/Madam,
g++ 7.1.1 cannot compile correct OpenMP 4.5
++
Assignee: unassigned at gcc dot gnu.org
Reporter: thorstenkurth at me dot com
Target Milestone: ---
Created attachment 42005
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42005&action=edit
small test case
Dear Sir/Madam,
I am not sure if my report got posted the fir
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
The following simple program complains about duplicate definitions for two
different template instantiations:
template void fn() {}
int main() {
fn();
fn
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: me at hussam dot eu.org
CC: cmang at google dot com
Target Milestone: ---
The following commit causes a build error in gcc-7-branch here
https://gcc.gnu.org/git/?p=gcc.git;a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80814
--- Comment #2 from Hussam Al-Tayeb ---
(In reply to Ian Lance Taylor from comment #1)
> Are you doing a from-scratch build or an incremental build? Try removing
> the x86_64-pc-linux-gnu/libgo directory to force it to be rebuilt.
I was doing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80814
--- Comment #4 from Hussam Al-Tayeb ---
(In reply to Ian Lance Taylor from comment #3)
> I can't recreate the problem. It looks like the compilation step in the
> failing command is reading old versions of the .gox files, versions that use
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80814
--- Comment #5 from Hussam Al-Tayeb ---
(In reply to Ian Lance Taylor from comment #3)
> Have you run `make install` to install an earlier version of the build?
> Perhaps the compilation command is incorrectly looking at the installed .gox
> fi
: unassigned at gcc dot gnu.org
Reporter: mail at kitsu dot me
Target Milestone: ---
Greetings!
I want to use static const std::map with aggregate initialization. The simpler
example of my case is:
#include
int main() {
static const std::map a {{1,2}};
return 0;
}
Besides I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80839
mail at kitsu dot me changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
++
Assignee: unassigned at gcc dot gnu.org
Reporter: thorstenkurth at me dot com
Target Milestone: ---
Dear Sir/Madam,
I am working on the Cori HPC system, a Cray XC-40 with intel Xeon Phi 7250. I
probably found a performance "bug" when using the OpenMP 4.5 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #3 from Thorsten Kurth ---
Created attachment 41414
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41414&action=edit
OpenMP 4.5 Testcase
This is the source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #4 from Thorsten Kurth ---
Created attachment 41415
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41415&action=edit
Testcase
This is the test case. The files ending on .as contain the assembly code with
and without target regi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #5 from Thorsten Kurth ---
To clarify the problem:
I think that the additional movq, pushq and other instructions generated when
using the target directive can cause a big hit on the performance. I understand
that these instructions a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #7 from Thorsten Kurth ---
Hello Jakub,
thanks for your comment but I think the parallel for is not racey. Every thread
is working a block of i-indices so that is fine. The dotprod kernel is actually
a kernel from the OpenMP standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #8 from Thorsten Kurth ---
Here is the output of the get_num_threads section:
[tkurth@cori02 omp_3_vs_45_test]$ export OMP_NUM_THREADS=32
[tkurth@cori02 omp_3_vs_45_test]$ ./nested_test_omp_4dot5.x
We got 1 teams and 32 threads.
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #9 from Thorsten Kurth ---
Sorry, in the second run I set the number of threads to 12. I think the code
works as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #11 from Thorsten Kurth ---
Hello Jakub,
yes, you are right. I thought that map(tofrom:) is the default mapping but
I might be wrong. In any case, teams is always 1. So this code is basically
just data streaming so there is no n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #13 from Thorsten Kurth ---
Hello Jakub,
the compiler options are just -fopenmp. I am sure it does not have to do
anything with vectorization as I compare the code runtime with and without the
target directives and thus vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #15 from Thorsten Kurth ---
The code I care about definitely has optimization enabled. For the fortran
stuff it does (for example):
ftn -g -O3 -ffree-line-length-none -fno-range-check -fno-second-underscore
-Jo/3d.gnu.MPI.OMP.EXE -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #16 from Thorsten Kurth ---
FYI, the code is:
https://github.com/zronaghi/BoxLib.git
in branch
cpp_kernels_openmp4dot5
and then in Src/LinearSolvers/C_CellMG
the file ABecLaplacian.cpp. For example, lines 542 and 543 can be comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #17 from Thorsten Kurth ---
the result though is correct, I verified that both codes generate the correct
output.
the fortran kernels (they are scattered
across multiple files) but the fortran kernels and our C++ ports give the same
performance with the original OpenMP parallelization. In any case, I wonder why
the compiler honors the target region even if -march=knl is specified. However,
please let me know
you if you compiled with MPI, OpenMP, etc. There is an inputs
file you just pass to it:
./main3d.. inputs
That's it. Tell me if you need more info.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #22 from Thorsten Kurth ---
Hello Jakub,
that is stuff for Intel vTune. I have commented it out and added the NUM_TEAMS
defines in the GNUmakefile. Please pull the latest changes.
Best and thanks
Thorsten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #24 from Thorsten Kurth ---
Hello Jakub,
I know that the section you mean is racey and gets the wrong number of threads
is not right but I put this in in order to see if I get the correct numbers on
a CPU (I am not working on a GPU y
101 - 200 of 753 matches
Mail list logo
