اطلاعیه وزارت تعاون، کار و رفاه
اجتماعی
اعـزام نیروی کـــار به کشور
آلـمـــان
درباره ما
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919
Eric Gallager changed:
What|Removed |Added
Known to work||10.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 84919, which changed state.
Bug 84919 Summary: [8/9 Regression] error: passing argument 1 to
restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #33 from Rich Felker ---
> An asm clobber just means "may be an output", and no operand will be assigned
> a register mentioned in a clobber. There is no magic.
This, plus the compiler cannot assume the value in any of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #32 from Segher Boessenkool ---
===
#define SYSCALL_CLOBBERLIST \
"$1", "$3", "$11", "$12", "$13", \
"$14", "$15", "$24", "$25", "hi", "lo", "memory"
long syscall6(long n, long a, long b, long c, long d, long e, long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #31 from Segher Boessenkool ---
An asm clobber just means "may be an output", and no operand will be assigned
a register mentioned in a clobber. There is no magic.
Hi!
tree-nested.c didn't handle C array sections in {,task_,in_}reduction clauses.
The following patch implements that, bootstrapped/regtested on x86_64-linux
and i686-linux, committed to trunk so far.
2020-03-14 Jakub Jelinek
PR middle-end/93566
* tree-nested.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93566
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9c3cdb43c2bdaf8a8d2e62db010b04f6086d76b7
commit r10-7179-g9c3cdb43c2bdaf8a8d2e62db010b04f6086d76b7
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #30 from Rich Felker ---
> You need to make $r10 not a clobber but an inout, of course. And not
That's not a correct constraint, because it's clobbered by the kernel between
the first syscall instruction's execution and the second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #29 from Segher Boessenkool ---
(In reply to Rich Felker from comment #27)
> Also just realized:
>
> > Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a
> > reasonable
> solution for you?
>
> It doesn't even
On 3/14/20 4:53 AM, Alexander Monakov wrote:
On Sat, 14 Mar 2020, Alexey Neyman wrote:
Attached is a patch that does it: at -g1, the type attributes are not
generated.
Two small issues I pointed out the last time are still present:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #28 from Rich Felker ---
And it looks like I actually hit this exact bug back in 2012 but misattributed
it:
https://git.musl-libc.org/cgit/musl/commit/?id=4221f154ff29ab0d6be1e7beaa5ea2d1731bc58e
I assumed things went haywire from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #27 from Rich Felker ---
Also just realized:
> Rich, forcing "n" to be in "$r10" seems to do the trick? Is that a reasonable
solution for you?
It doesn't even work, because the syscall clobbers basically all call-clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229
--- Comment #32 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:824722e45f80b22e2f035a61300f494b2a10d6f4
commit r10-7177-g824722e45f80b22e2f035a61300f494b2a10d6f4
Author: H.J. Lu
Date: Sat Mar 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94177
Bug ID: 94177
Summary: TLS global-dynamic model clobbers function parameter
on AIX
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Snapshot gcc-9-20200314 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20200314/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
A mail by Jonathan made me look at that page again after a looong
while, and I noticed two simplifications.
Pushed (though the machinery to update the web site did not appear
to be working then, but I manually re-run it now).
Gerald
patch
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #26 from Rich Felker ---
Indeed, I just confirmed that binding the n input to a particular register
prevents the "i" part of the "ir" alternative from working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162
--- Comment #2 from Cameron ---
(In reply to Jakub Jelinek from comment #1)
> It isn't clear to me what exactly disallows it, perhaps
> http://eel.is/c++draft/class.spaceship#2.2
> ?
> For auto return type
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92068
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:3a285529ee338ef2867ae7add26b6493f004bf0d
commit r10-7176-g3a285529ee338ef2867ae7add26b6493f004bf0d
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93248
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:c393c99d3dc8329dc1a36011e70faa9700185051
commit r10-7174-gc393c99d3dc8329dc1a36011e70faa9700185051
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:b3b0c671cc341fd04afc045a8d42d7a845d7f73c
commit r10-7175-gb3b0c671cc341fd04afc045a8d42d7a845d7f73c
Author: Jason Merrill
Date:
Here the template arguments for the partial specialization are valid
arguments for the template, but not for a partial specialization, because
'd' can never be deduced to anything other than an empty pack.
Tested x86_64-pc-linux-gnu, applying to 8/9/10.
gcc/cp/ChangeLog
2020-03-14 Jason Merrill
find_parameter_packs_r doesn't look through typedefs, which is normally
correct, but that means we need to handle their declarations specially.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-03-14 Jason Merrill
PR c++/92909
* pt.c
When cp_unevaluated_operand is set, tsubst_decl thinks that if it sees a
PARM_DECL that isn't already in local_specializations, we're in a decltype
in a trailing return type or some such, and so we only want a substitution
for a single PARM_DECL. In this case, we want the whole chain, so make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #25 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #23)
> Before RA we have asm inputs
> [
> (reg/v:SI 196 [ n ])
> (reg/v:SI 4 $4 [ r4 ])
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #24 from Rich Felker ---
The reasons I was hesitant to force n to a particular register through an extra
register __asm__ temp var was that I was unsure how it would interact with the
"i" constraint (maybe prevent it from being
Hi,
This patch merges the libphobos implementation with upstream druntime
7915b6a3.
Includes port fixes for Musl on ARM, AArch64, and SystemZ targets.
Bootstrapped and tested on x86_64-linux-gnu, and committed to trunk.
Regards
Iain.
---
diff --git a/libphobos/libdruntime/MERGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #23 from Segher Boessenkool ---
It is harder for us to track it in an older bug with many older patches
for it, including stuff that needed fixups later. And, the "correct"
older bug for it would not be this one, anyway!
Before RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #22 from Rich Felker ---
What should I call the new bug? The description sounds the same as this one,
and it's fixed in gcc 9.x, just not earlier versions, so it seems to be the
same bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #21 from Alexander Monakov ---
> I could guess the compiler might ignore your inputs/outputs that you specify
> if you don't have any % usages for them.
Are you seriously suggesting that examples in the GCC manual are invalid and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #20 from Segher Boessenkool ---
Confirmed with various 7 and 8 (I don't have a mips 6 around).
Don't reopen this bug, it is not necessarily related. Instead, please
open a new PR. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #19 from Rich Felker ---
> This looks like bad inline asm. You seem to be using $2, $8, $9 and $sp
> explicitly and not letting the compiler know you are using them.
$2, $8, and $9 are all explicitly outputs. All changes to $sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #18 from Peter Bergner ---
(In reply to Rich Felker from comment #16)
> long syscall6(long n, long a, long b, long c, long d, long e, long f)
[snip]
> : "ir"(n), "r"(r4), "r"(r5), "r"(r6)
...and "n" is an argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #17 from Peter Bergner ---
(In reply to Rich Felker from comment #16)
> long syscall6(long n, long a, long b, long c, long d, long e, long f)
> {
> register long r4 __asm__("$4") = a;
> register long r5 __asm__("$5") = b;
> The problem here is that compiler thinks that atoi may call back some
> static function in unit that may change value of the variable. There is
> no analysis implemented on how such calls back to unit can affect the
> value. We have leaf attribute that you can annotate atoi (but glibc
> does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #16 from Rich Felker ---
> I didn't say this very well... The only issue is using the same hard
> register for two different operands. You don't need to do this for
> syscalls (and you do not *need* that *ever*, of course).
I hit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #15 from Segher Boessenkool ---
(In reply to Rich Felker from comment #12)
> > You can work around it on older GCC by simply not using a register var
> > for more than one asm operand, I think?
>
> Nope. Making a syscall inherently
Run tests should use vmx_hw, not just powerpc_altivec_ok. Committed.
Segher
gcc/testsuite/
PR target/94176
* gcc.target/powerpc/fold-vec-mule-misc.c: Use vmx_hw selector.
---
gcc/testsuite/ChangeLog | 5 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176
--- Comment #1 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:9a6408bd18fe893a59297d80010fbd3660300347
commit r10-7172-g9a6408bd18fe893a59297d80010fbd3660300347
Author: Segher Boessenkool
> > I think it is because during early opts we do not know if f is not
> > modified by atoi call and at IPA time (where we already know that from
> > resolution info) we do not have jump functions to track global variables.
>
> I confirm that if I remove the calls to atoi, the function is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94176
Bug ID: 94176
Summary: rs6000/test: Fix selector in fold-vec-mule-misc.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218
--- Comment #36 from CVS Commits ---
PR c/93218 - Testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044
--- Comment #9 from Jim Wilson ---
(In reply to Jakub Jelinek from comment #8)
> So perhaps to ease reproduction, tweak the hash function in this case to
> always return 0?
Yes, that works. I just didn't have a chance to look at the hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #14 from Alexander Monakov ---
Just to clarify, the two testcases added in the quoted commit don't try to
catch the issue discussed here: that the operand is passed in a wrong register.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #13 from Peter Bergner ---
(In reply to Rich Felker from comment #12)
> > You can work around it on older GCC by simply not using a register var
> > for more than one asm operand, I think?
>
> Nope. Making a syscall inherently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77595
--- Comment #3 from Andrzej Krzemienski ---
The part of the Standard that requires this:
http://eel.is/c++draft/temp.explicit#11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77595
Andrzej Krzemienski changed:
What|Removed |Added
Version|6.1.0 |10.0
Keywords|
Una duda ¿Usted conoce o tiene cuenta de Netflix, HBO o Amazon Prime?
Ahora usted imagine una plataforma igual, pero con cientos de cursos y
conferencias profesionales impartidas por expertos en todas las áreas. Eso es
exactamente lo que vengo a ofrecerle, una suscripción a nuestra nueva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #12 from Rich Felker ---
> You can work around it on older GCC by simply not using a register var
> for more than one asm operand, I think?
Nope. Making a syscall inherently requires binding specific registers for all
of the
> I think it is because during early opts we do not know if f is not
> modified by atoi call and at IPA time (where we already know that from
> resolution info) we do not have jump functions to track global variables.
I confirm that if I remove the calls to atoi, the function is correctly
> >I was pretty disappointed to see that even if the compiler knows we are
> >calling f_add, it doesn't inline the call (it ends up with "call
> >f_add").
>
> It's probably because we know it's only called once and thus not performance
> relevant. Try put it into a loop.
I think it is because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175
Bug ID: 94175
Summary: [10 Regression] Passing constexpr empty class variable
to function since r10-599
Product: gcc
Version: 10.0
Status: UNCONFIRMED
>It's probably because we know it's only called once and thus not performance
>relevant. Try put it into a loop.
Thanks for the hint, but I'm afraid it is not that. I tried this and it still
calls f_add. I also try with i = 1[...]000.
#include
#include
#include
int main (int argc, char
On Sat, 14 Mar 2020, Alexey Neyman wrote:
> Attached is a patch that does it: at -g1, the type attributes are not
> generated.
Two small issues I pointed out the last time are still present:
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg01646.html
(I did not review the new patch on a more
On March 14, 2020 10:55:09 AM GMT+01:00, "FRÉDÉRIC RECOULES"
wrote:
>Hello the GCC community,
>I just want to share some thoughts on inlining a function even if
>it is called through a function pointer.
>My starting point is the version 9.2 (used at https://godbolt.org/),
>so I am sorry if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044
--- Comment #8 from Jakub Jelinek ---
So perhaps to ease reproduction, tweak the hash function in this case to always
return 0?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94174
--- Comment #2 from Richard Henderson ---
Case 3:
void test3(__int128 a, unsigned long l)
{
if ((__int128_t)a - l <= 1)
doit();
}
currently generates as
subsx0, x0, x2
sbc x1, x1, xzr
cmp x1, 0
Hello the GCC community,
I just want to share some thoughts on inlining a function even if
it is called through a function pointer.
My starting point is the version 9.2 (used at https://godbolt.org/),
so I am sorry if something similar have already been discussed since.
For the context, I got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94174
Richard Henderson changed:
What|Removed |Added
Summary|__builtin_add_overflow vs |Missed ccmp optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94174
Bug ID: 94174
Summary: __builtin_add_overflow vs ccmp
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379
--- Comment #7 from CVS Commits ---
https://gcc.gnu.org/g:50c96067c8ed60f4b3fcbee89fe31c905241b356commit
r10-7169-g50c96067c8ed60f4b3fcbee89fe31c905241b356Author: Aaron Sawdey
Date: Fri Mar 13 18:14:22 2020 -0500Fix UBSAN
error, shifting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94173
Bug ID: 94173
Summary: [RISCV] Superfluous stackpointer manipulation
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #11 from Segher Boessenkool ---
(In reply to Rich Felker from comment #10)
> This is a rather huge bug to have been fixed silently. Could someone who
> knows the commit that fixed it and information on what versions are affected
>
Hi!
The testcase shows some accepts-invalid (the ones without alignas) and
ice-on-invalid-code (the ones with alignas) cases.
If the enum doesn't have an underlying type and is not a definition,
the caller retries to parse it as elaborated type specifier.
E.g. for enum struct S s it will then
On 2/28/20 1:50 PM, Jason Merrill wrote:
On 2/28/20 4:12 PM, Alexey Neyman wrote:
On 2/28/20 12:28 PM, Jason Merrill wrote:
On 2/28/20 2:11 PM, Alexander Monakov wrote:
Hm. So apparently at -g1 we don't emit type information for
functions, and
gdb sees each function as 'void foo()'
Hi!
The following testcase fails with -fcompare-debug. The problem is that
bar is marked as address_taken only with -g and not without.
I've tracked it down to insert_init_stmt calling gimple_regimplify_operands
even on DEBUG_STMTs. That function will just insert normal stmts before
the
Hi!
On the following testcase, if there is ASLR, the compiler generates
different code each time (out of 1000 invocations 994 unique assembler
contents). The problem is that undistribute_bitref_for_vector uses
a hash_map from a tree (SSA_NAME) to a vector and such a hash_map is
by default doing
Hi!
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux
and committed to trunk as obvious.
2020-03-14 Jakub Jelinek
* gimple-fold.c (gimple_fold_builtin_strncpy): Change
"a an" to "an" in a comment.
* hsa-common.h (is_a_helper): Likewise.
*
On Thu, Mar 12, 2020 at 5:11 PM Paul Smith wrote:
>
> On Wed, 2020-03-11 at 17:15 +, Jonathan Wakely wrote:
> > My thinking was to build GCC inside the container, then package up the
> > results and install that on your dev machines (outside a container).
> > But actually that won't work
72 matches
Mail list logo
