On Mon, Dec 5, 2022 at 7:07 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote:
> > Changed target code to select .rodata section for 'const volatile'
> > defined variables.
> > This change is in the context of the bugzilla #170181.
> >
> >
On Sun, Jan 1, 2023 at 3:54 PM Nikita Zlobin via Gcc wrote:
>
> Vector extension is great, because allowes to use controllable
> vectorization without dealing with each SIMD ISA separately. When
> properly used, it allowes to get better performance, than with
> auto-vectorization. However,
On Wed, Dec 28, 2022 at 1:47 PM Alexandre Oliva via Gcc-patches
wrote:
>
> On Dec 28, 2022, Martin Liška wrote:
>
> > I really like the verification code you added. It's quite similar to what
> > I added to hash-table.h:
>
> *nod*
>
> Prompted by your encouragement, I've combined the element
On Wed, Dec 28, 2022 at 9:17 AM Martin Liška wrote:
>
> Hi.
>
> The patch checks all attribute arguments if they are string. If not,
> an error message is emitted.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
>
On Tue, Dec 27, 2022 at 9:46 PM Jeff Law wrote:
>
>
>
> On 12/19/22 00:44, Richard Biener wrote:
> > On Sat, Dec 17, 2022 at 2:54 AM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 12/16/22 18:44, 钟居哲 wrote:
> >>> Yes, VNx4DF only has 4 bit in mask mode in case of load and store.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Florian Weimer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Fri, Dec 23, 2022 at 12:10 AM Roger Sayle wrote:
>
>
> With many thanks to H.J. for doing all the hard work, this patch resolves
> two P1 regressions; PR target/106933 and PR target/106959.
>
> Although superficially similar, the i386 backend's two scalar-to-vector
> (STV) passes perform their
On Thu, 22 Dec 2022, Qing Zhao wrote:
>
>
> > On Dec 22, 2022, at 2:09 AM, Richard Biener wrote:
> >
> > On Wed, 21 Dec 2022, Qing Zhao wrote:
> >
> >> Hi, Richard,
> >>
> >> Thanks a lot for your comments.
> >>
> >>> On Dec 21, 2022, at 2:12 AM, Richard Biener wrote:
> >>>
> >>> On Tue,
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.
Jeff Law via Gcc-patches writes:
> I've been getting sporatic errors like this since the introduction of
> the modula-2 front-end:
>
>> In file included from ../../..//gcc/gcc/m2/mc-boot/GSFIO.c:29:
>> ../../..//gcc/gcc/system.h:556:20: error: conflicting declaration of C
>> function 'const
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=edit
Potential fix for target multilib_dir handling -m and -f (version 3)
version3 work in progress, implemented using
I've been getting sporatic errors like this since the introduction of
the modula-2 front-end:
In file included from ../../..//gcc/gcc/m2/mc-boot/GSFIO.c:29:
../../..//gcc/gcc/system.h:556:20: error: conflicting declaration of C function
'const char* strsignal(int)'
556 | extern const
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
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=edit
Patch to fix test failure on hppa64-hp-hpux11.11
Snapshot gcc-13-20230108 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20230108/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
On Sat, Jan 7, 2023 at 9:04 PM Takayuki 'January June' Suwa
wrote:
>
> This patch optimizes the operation of cutting and splicing two register
> values at a specified bit position, in other words, combining (bitwise
> ORing) bits 0 through (C-1) of the register with bits C through 31
> of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108337
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Andrew
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
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
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|---
Everyone knows the state-of-art old-fashioned file cabinet for the library. Its
"analytical" boxes and dividers, like the cards themselves, have faithfully
served more than one generation of librarians. Paper cards have been a very
flexible medium, allowing librarians to expand datasets and
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?
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Esperanto team of translators. The file is available at:
https://translationproject.org/latest/cpplib/eo.po
(This file,
cpplib-12.1-b20220213.eo.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
Hi Richard,
Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran
:
Hi Thomas,
Following your off-line explanation that the seemingly empty looking
assembly line forces an effective reload from memory, all is now clear.
It’s not a full fix (for register vars) and it’s ‚superior‘
> Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran
> :
>
> Hi Thomas,
>
> Following your off-line explanation that the seemingly empty looking
> assembly line forces an effective reload from memory, all is now clear.
It’s not a full fix (for register vars) and it’s ‚superior‘
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()
Hi Thomas,
Following your off-line explanation that the seemingly empty looking
assembly line forces an effective reload from memory, all is now clear.
OK for mainline and for backporting as you see fit.
Thanks for the patch.
Paul
On Sat, 7 Jan 2023 at 15:46, Thomas Koenig via Fortran
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
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
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=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.
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.
>
>
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
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
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
56 matches
Mail list logo
