https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Florian Weimer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108338
Bug ID: 108338
Summary: use mtvsrws for lowpart DI->SF conversion on P9
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743
Jiu Fu Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
--- Comment #15 from Rama Malladi ---
Hi, Can we review this issue and suggest next steps/ action please? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #9 from Gaius Mulley ---
Created attachment 54214
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54214&action=edit
Potential fix for target multilib_dir handling -m and -f (version 3)
version3 work in progress, implemented usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #6 from Gareth Davies ---
(In reply to anlauf from comment #4)
> There is one flaw with the testcase: when OMP_NUM_THREADS > n1,
> array elements threadval(n1+1:OMP_NUM_THREADS) are filled with
> undefined values.
Yes, my bad in try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #54 from John David Anglin ---
Created attachment 54213
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54213&action=edit
Patch to fix test failure on hppa64-hp-hpux11.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #5 from Andrew Pinski ---
Maybe instead of:
!$omp parallel
nt = omp_get_num_threads()
!$omp end parallel
Do:
nt = omp_get_max_threads()
that should improve the situtation of not allocating enough for the array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108337
--- Comment #5 from eric-bugs at omnifarious dot org ---
(In reply to Andrew Pinski from comment #4)
> Yes it affects every function. There might be another way to use attribute
> to specific that only main needs this treatment. Or better yet add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108337
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108337
eric-bugs at omnifarious dot org changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108131
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #4 from anlauf at gcc dot gnu.org ---
There is one flaw with the testcase: when OMP_NUM_THREADS > n1,
array elements threadval(n1+1:OMP_NUM_THREADS) are filled with
undefined values.
When I replace the line
if(omp_get_thread_num(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108131
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:ba5012875bc6f7910be3b5cce03e000aa9322c1f
commit r10-11155-gba5012875bc6f7910be3b5cce03e000aa9322c1f
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108131
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:04310741924e7e6ef1ec637a1a9c3e2972345926
commit r11-10458-g04310741924e7e6ef1ec637a1a9c3e2972345926
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108228
John David Anglin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235
John David Anglin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108337
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108337
--- Comment #1 from Andrew Pinski ---
It might be the case the stack pointer is not inlined when main is called from
the kernel ...
What target is this? X86_64-linux-gnu?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108337
Bug ID: 108337
Summary: Misaligned memory access issues when inline assembly
is used with optimization on x86_64
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #13 from niXman ---
could it be because now as host toolchain used a version which contains the
changes LIU Hao is talked about?
--- Comment #5 from Romain Geissler ---
Hi,
This seems to still happen with current trunk:
#include
std::map _Map;
void f()
{
std::map localMap;
_Map.swap(localMap);
}
compiled with -Wall -Werror -O2:
In file included from
/opt/compiler-explorer/gcc-trunk-20230108/include/c++/13.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #12 from niXman ---
guys, does anyone have an idea why I faced with the error on gcc-12.2.0 ?
```
../../../../src/gcc-12.2.0/libcpp/system.h:404:30: error: expected identifier
before string constant
404 | #define abort() fancy_abo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #13 from Jan Dubiec ---
FYI, Jonathan. This time the target is msp430-elf.
Making all in c++20
make[9]: Entering directory
'/d/Works/xcomp/gcc-build/msp430-elf/large/libstdc++-v3/src/c++20'
/bin/sh ../../libtool --tag CXX --tag disa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108334
--- Comment #3 from Jamaika ---
I add preprocessed source `cdef.o`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #3 from Andrew Pinski ---
Yes the race condition is the following:
the order of calling random_number on which thread first.
init_rand_state definitely takes a lock when reading/writing from/to
master_state.
I see no other race con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108334
--- Comment #2 from Jamaika ---
Created attachment 54212
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54212&action=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108326
--- Comment #4 from Jamaika ---
Here was my mistake.
I tried adding c++config definitions to gcc 11.3.1 with _GLIBCXX_HAS_GTHREADS.
Unfortunately many more features are changed to native Windows.
http://msystem.waw.pl/x265/mingw-gcc1131-20221227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #2 from Gareth Davies ---
(In reply to Andrew Pinski from comment #1)
> Most likely there is only one seed per program so the random # generator is
> using locks. So the order is dependent on which thread calls the function.
>
> Now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328
--- Comment #7 from Sagi Mor ---
Ok, now I understand what you said about the kernel and sysroot.
Yes, it is weird. (non buildroot kernel compiled with 64k pages, buildroot
sysroot with 4k max).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106704
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #1 from Andrew Pinski ---
Most likely there is only one seed per program so the random # generator is
using locks. So the order is dependent on which thread calls the function.
Now having a seed per thread might be a good idea but i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328
--- Comment #6 from Sagi Mor ---
Well, this is only for aarch64 and arc, and they do compile the kernel in
buildroot, so it seems to work? (never checked myself)
By the way, they solve the -Wl,z,relro for kernel/uboot compilation by checking
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
Bug ID: 108336
Summary: Repeatable random_numbers with openmp
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108335
Bug ID: 108335
Summary: New-expression doesn't perform mandatory copy elision
when copy constructor is disabled with `requires`, in
a template
Product: gcc
Versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108334
--- Comment #1 from Andrew Pinski ---
Can you attach the preprocessed source?
GCC thinks you are trying to do a memcpy to a null pointer really:
cc1plus.exe: note: destination object is likely at address zero
Which could mean either the code w
39 matches
Mail list logo
