https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107665
--- Comment #1 from Andrew Pinski ---
r13-3387-g79d38dd46e6b07 just made the testcase actually run which it was not
doing previously.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #5 from Xi Ruoyao ---
After r13-3924 this brings PR95115 back. Note that Glibc has added an ugly
hack for RISC-V and old compilers, but other ports may be haunted as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107665
Bug ID: 107665
Summary: [13 regression] g++.dg/cpp23/ext-floating1.C fails
after r13-3387-g79d38dd46e6b07
Product: gcc
Version: 13.0
Status: UNCONFIRMED
On Sat, Nov 12, 2022 at 11:42 AM Jeff Law wrote:
> ISTM that we'd need to strip the unspec and process its argument
> instead.
I tried that first, the result was more ICEs because that pattern
wasn't recognized at later stages. Then I read the change to the
comment over the symbolic_operand
On Linux/x86_64,
2f7f9edd28d75a85a33599978f23811e679e443d is the first bad commit
commit 2f7f9edd28d75a85a33599978f23811e679e443d
Author: Jakub Jelinek
Date: Sat Nov 12 09:33:01 2022 +0100
range-op: Implement floating point multiplication fold_range [PR107569]
caused
FAIL:
On Linux/x86_64,
2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb is the first bad commit
commit 2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb
Author: Jakub Jelinek
Date: Sat Nov 12 09:35:16 2022 +0100
range-op: Implement floating point division fold_range [PR107569]
caused
FAIL: gcc.dg/pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167
--- Comment #1 from Jonathan Wakely ---
Clocks are done in r13-3937-g1736bf5a61c736
Time zones and chrono I/O still missing.
On 11/7/22 15:07, Palmer Dabbelt wrote:
On Thu, 03 Nov 2022 15:23:28 PDT (-0700), j...@ventanamicro.com wrote:
On 11/2/22 18:26, Palmer Dabbelt wrote:
I also tried to remove that restriction but it looks like it can't
work because we can't create
pseudo-registers during shrink wrapping
On 11/9/22 15:12, Jonathan Wakely via Gcc-patches wrote:
Patch rebased on the new doc format. I haven't tested building the docs
this way, but this is just plain text here.
OK for trunk?
-- >8 --
gcc/ChangeLog:
* doc/install/testing.rst: Remove anachronism about separate
On 11/10/22 14:34, Philipp Tomsich wrote:
The strength-reduction implementation in expmed.cc will assess the
profitability of using shift-and-add using a RTL expression that wraps
a MULT (with a power-of-2) in a PLUS. Unless the RISC-V rtx_costs
function recognizes this as expressing a
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
Also add the basic types for timezones, without the non-inline
definitions needed to actually use them.
The get_leap_second_info function currently uses a hardcoded list of
leap seconds, correct as of the end of 2022. That
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
This allows std::format to support __int128 when __STRICT_ANSI__ is
defined, which previously failed because __int128 is not an integral
type in strict mode.
With these changes, std::to_chars still rejects 128-bit integers in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104166
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:1d9454aba615eadd0d85c93713dd848227345f67
commit r13-3936-g1d9454aba615eadd0d85c93713dd848227345f67
Author: Jonathan Wakely
On 11/11/22 09:19, Richard Sandiford via Gcc-patches wrote:
The prologue/epilogue pass allows the prologue sequence
to contain jumps. The sequence is then partitioned into
basic blocks using find_many_sub_basic_blocks.
This patch treats epilogues in the same way. It's needed for
a follow-on
On 11/11/22 10:30, Richard Sandiford via Gcc-patches wrote:
Arm's SME has an array called ZA that for inline asm purposes
is effectively a form of special-purpose memory. It doesn't
have an associated storage type and so can't be passed and
returned in normal C/C++ objects.
We'd therefore
On 2022-11-11 07:11, Aaron Ballman wrote:
Clang doesn't require such a linker (we work with various system linkers).
As long as the system linkers continue to work as they have
traditionally worked, we're fine.
the frontend perspective, we can't tell the difference between
"trust me this
On 2022-11-11 07:11, Aaron Ballman wrote:
We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime, hence a definitive signature mismatch
is something we feel comfortable diagnosing (in some
On 11/8/22 12:54, Philipp Tomsich wrote:
If-conversion is turning '(a >= 0) ? b : 0' into a branchless sequence
not a5,a0
sraia5,a5,63
and a0,a1,a5
missing the opportunity to combine the NOT and AND into an ANDN.
This adds a define_split to help the
On 11/8/22 04:50, Jakub Jelinek via Gcc-patches wrote:
On Mon, Nov 07, 2022 at 12:42:38PM +0100, Aldy Hernandez via Gcc-patches wrote:
* gcc.dg/tree-ssa/pr107541.c: New test.
The test fails when long is 32-bit rather than 64-bit (say x86_64 with
On Sat, Nov 12, 2022 at 3:47 PM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> gcc/ChangeLog:
>
> * value-range.cc (get_bound_with_infinite_markers): New static helper.
> (irange::as_string): New definition.
> * value-range.h: New declaration.
>
> ---
> Provide means
gcc/ChangeLog:
* Makefile.in (OBJS): Add gimple-warn-types.o.
* passes.def: Add pass_warn_type_demotion.
* tree-pass.h (make_pass_warn_type_demotion): New declaration.
* gimple-warn-types.cc: New file.
gcc/c-family/ChangeLog:
* c.opt (Wtype-demotion):
gcc/fortran/ChangeLog:
* arith.cc (compare_complex): Use narrower return type.
(gfc_compare_string): Likewise.
* arith.h (gfc_compare_string): Same.
(gfc_compare_with_Cstring): Ditto.
* array.cc (compare_bounds): Ditto.
(gfc_compare_array_spec):
Hi!
The location of function result declarations was not set.
The first two patches set the location of normal functions in C and C++.
Jason, Nathan, I failed to support C++ template functions, see below.
TL;DR.
Why all this?
PR78798 noted that we should use narrower function return types if
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Joseph Myers
---
gcc/c/ChangeLog:
* c-decl.cc (start_function): Set the result decl source
location to the location of the typespec.
---
gcc/c/c-decl.cc | 6 +-
1 file changed, 5
gcc/ChangeLog:
* value-range.cc (get_bound_with_infinite_markers): New static helper.
(irange::as_string): New definition.
* value-range.h: New declaration.
---
Provide means to print a value range to a newly allocated buffer.
The caller is responsible to free() the
gcc/cp/ChangeLog:
* decl.cc (start_function): Set the result decl source location to
the location of the typespec.
---
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Nathan Sidwell
Cc: Jason Merrill
---
gcc/cp/decl.cc | 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107664
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> It moved
> https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/using-
> vector-instructions-through-built-in-functions.html .
Note it might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107664
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107664
Bug ID: 107664
Summary: Vector Extensions page down
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
--- Comment #4 from Sergei Trofimovich ---
If I read a.cc.254t.optimized correctly I think there are two unrelated places
that are expected to generate `getWaitStatesSince6.constprop`:
- one is through main()
- another is through
Snapshot gcc-12-20221112 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20221112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107663
Bug ID: 107663
Summary: GCC does not catch -Werror=maybe-uninitialized that
looks apparent
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
On Sat, 12 Nov 2022 at 22:47, Andrew Pinski wrote:
>
> On Sat, Nov 12, 2022 at 1:34 PM Philipp Tomsich
> wrote:
> >
> > Some architectures, as it the case on RISC-V with the proposed
> > ZiCondOps and the vendor-defined XVentanaCondOps, define a
> > conditional-zero instruction that is
On Sat, Nov 12, 2022 at 1:34 PM Philipp Tomsich
wrote:
>
> Some architectures, as it the case on RISC-V with the proposed
> ZiCondOps and the vendor-defined XVentanaCondOps, define a
> conditional-zero instruction that is equivalent to:
> - the positive form: rd = (rc != 0) ? rs : 0
> - the
Some architectures, as it the case on RISC-V with the proposed
ZiCondOps and the vendor-defined XVentanaCondOps, define a
conditional-zero instruction that is equivalent to:
- the positive form: rd = (rc != 0) ? rs : 0
- the negated form: rd = (rc == 0) ? rs : 0
While
While the positive case "if ((bits >> SHAMT) & 1)" for SHAMT 0..10 can
trigger conversion into efficient branchless sequences
- with Zbs (bexti + neg + and)
- with XVentanaCondOps (andi + vt.maskc)
the inverted/negated case results in
andi a5,a0,1024
seqz a5,a5
neg a5,a5
and a5,a5,a1
When if-conversion in noce_try_store_flag_mask starts the sequence off
with an order-operator, our patterns for vt.maskc will receive the
result of the order-operator as a register argument; consequently,
they can't know that the result will be either 1 or 0.
To convey this information (and make
Users might use explicit arithmetic operations to create a mask and
then and it, in a sequence like
cond = (bits >> SHIFT) & 1;
mask = ~(cond - 1);
val &= mask;
which will present as a single-bit sign-extract.
Dependening on what combination of XVentanaCondOps and Zbs are
available,
When if-conversion encounters sequences using immediates, the
sequences can't trivially map back onto vt.maskc/vt.maskcn (even if
benefitial) due to vt.maskc and vt.maskcn not having immediate forms.
This adds a splitter to rewrite opportunities for XVentanaCondOps that
operate on an immediate by
Adds a pattern to map the output of noce_try_store_flag_mask
if-conversion in the combiner onto vt.maskc; the input patterns
supported are similar to the following:
(set (reg/v/f:DI 75 [ ])
(and:DI (neg:DI (ne:DI (reg:DI 82)
(const_int 0 [0])))
Both the XVentanaCondOps (a vendor-defined extension from Ventana
Microsystems) and the proposed ZiCondOps extensions define a
conditional-zero(-or-value) instruction, which is similar to the
following C construct:
rd = rc ? rs : 0
This functionality can be tied back into if-convertsion and
This adds the xventanacondops extension to the option parsing and as a
default for the ventana-vt1 core:
gcc/Changelog:
* common/config/riscv/riscv-common.cc: Recognize
"xventanacondops" as part of an architecture string.
* config/riscv/riscv-cores.def (RISCV_CORE):
Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
This function definition was removed years ago, remove it's prototype.
gcc/fortran/ChangeLog:
* gfortran.h (gfc_check_include): Remove declaration.
---
gcc/fortran/gfortran.h | 1 -
1 file changed, 1 deletion(-)
This function definition was removed years ago, remove it's prototype.
gcc/fortran/ChangeLog:
* gfortran.h (gfc_check_include): Remove declaration.
---
gcc/fortran/gfortran.h | 1 -
1 file changed, 1 deletion(-)
---
Regtests cleanly, ok for trunk?
diff --git a/gcc/fortran/gfortran.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107636
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ec6c2029714057b4bca344ee59be977d17361092
commit r13-3932-gec6c2029714057b4bca344ee59be977d17361092
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107444
--- Comment #6 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:59a63247992eb13153b82c4902aadf111460eac2
commit r13-3931-g59a63247992eb13153b82c4902aadf111460eac2
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
--- Comment #3 from Sergei Trofimovich ---
Created attachment 53889
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53889=edit
a_simpler.cc
a_simpler.cc is a bit more trimmed down version of a.cc: does not need pragmas
or argument
On 11/11/22 12:43, Max Filippov wrote:
gcc/
PR target/107645
* config/m68k/predicates.md (symbolic_operand): Return false
when UNSPEC is under the CONST node.
Isn't the underlying object still symbolic though, thus returning false
seems wrong.
insn 342 341 343 35
On Sat, 12 Nov 2022, Gerald Pfeifer wrote:
> I am not aware of who added this, and why, nor actually even why, yet it
> seems if we can get the same in place for /install we'll be good again, so
> I'll ask overseers@.
https://gcc.gnu.org/install/ is up and running fine now/again.
> Next step:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107662
Bug ID: 107662
Summary: [10 concepts] ICE using concept with dependent
template parameter to define variable
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620
--- Comment #2 from vvinayag at arm dot com ---
(In reply to Martin Liška from comment #1)
> Confirmed. Btw. what revision do you build and what command do you use?
Could you please clarify what you are referring to, for the revision and
It irks me that a PR named "we should track ranges for floating-point
hasn't been closed in this release. This is an attempt to do just
that.
As mentioned in the PR, even though we track ranges for floats, it has
been suggested that avoiding recursing through SSA defs in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
--- Comment #2 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #0)
> Reproducing:
>
> $ ./gcc-13-HEAD/bin/gcc -Wall -O0 a.cc -o a
> $ ./gcc-13-HEAD/bin/gcc -Wall -O3 a.cc -o a
> ./bug_HEAD.bash: line 6: 1309437 Illegal
C2x adds __STDC_VERSION_*_H__ macros to individual headers with
interface changes compared to C17. All the new header features in
headers provided by GCC have now been implemented, so define those
macros to the value given in the current working draft.
Bootstrapped with no regressions for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Severity|normal
s: zlib
gcc version 13.0.0 20221112 (experimental) (GCC)
Full a.cc example (somewhat long, also attached):
/// 'function_ref' is taken from llvm-12 as is without any modifications.
/// The rest if severely maimed AMDGCN hasard verifier code.
// How to break:
// $ ./gcc-13-snap/bin/gcc -O3
Hello,
Le 10/11/2022 à 22:56, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the attached patch is a follow-up to the fix for PR107441,
as it finally fixes the treatment of character dummy arguments
that have the value,optional attribute, and allows for checking
of the presence of such
On 11/12/22 18:02, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
No, assigning to a function parameter from within another parameter
declaration wouldn't make sense. They should be readonly. Side effects
should be forbidden, I think.
Such assignments are
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
> > > No, assigning to a function parameter from within another parameter
> > > declaration wouldn't make sense. They should be readonly. Side effects
> > > should be forbidden, I think.
> >
> > Such assignments are already allowed. In a
In this PR, we are crashing because we've encountered a UDL where a
string-literal is expected. This patch makes the parser reject string
and character UDLs in all places where the grammar requires a
string-literal and not a user-defined-string-literal.
Bootstrapped/regtested on
Wookey writes:
> On 2022-11-10 19:08 +0100, Florian Weimer wrote:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more. This
>> means that
> Am 12.11.2022 um 05:56 schrieb Joseph Myers :
>
> [Global / middle-end reviewers, note there is a dfp.cc change here
> that needs review.]
>
> Implement C2x constexpr (a feature based on the C++ one but much more
> minimal, with only constexpr variables, not functions).
>
> I believe this
On 2022-11-10 19:08 +0100, Florian Weimer wrote:
> * Zack Weinberg via Gcc:
>
> > It’s come to my attention (via https://lwn.net/Articles/913505/ and
> > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> > Clang both plan to disable several “legacy” C language features by
>
Am Samstag, den 12.11.2022, 14:54 + schrieb Joseph Myers:
> On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
>
> > Since it's to be used as an rvalue, not as a lvalue, I guess a
> > postfix-expression wouldn't be the right one.
>
> Several forms of postfix-expression are only rvalues.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #3 from Thomas Koenig
Hi Joseph,
On 11/12/22 15:54, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
Since it's to be used as an rvalue, not as a lvalue, I guess a
postfix-expression wouldn't be the right one.
Several forms of postfix-expression are only rvalues.
(with a special rule
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
> Since it's to be used as an rvalue, not as a lvalue, I guess a
> postfix-expression wouldn't be the right one.
Several forms of postfix-expression are only rvalues.
> > (with a special rule about how the identifier is interpreted,
Sam James writes:
>> On 12 Nov 2022, at 03:40, Zack Weinberg wrote:
>> This is definitely more work than I can see myself doing on a volunteer
>> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
>> cherry pick the changes needed to support the newer compilers (and
>>
Paul Eggert writes:
> On 2022-11-10 19:33, Zack Weinberg wrote:
>
>> It would be relatively easy for me to take a couple hours this
>> weekend and put out a 2.72 release with everything that's already in
>> trunk and nothing else. Anyone have reasons I _shouldn't_ do that?
>
> I don't have
On 11/12/22 14:40, Alejandro Colomar wrote:
Hi Joseph,
On 11/12/22 14:03, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);
Is it really ambiguous? Let's show some currently-valid code:
Well,
Hi Joseph,
On 11/12/22 14:03, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);
Is it really ambiguous? Let's show some currently-valid code:
Well, I still don't know what the syntax addition
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
> > struct s { int a; };
> > void f(int a, int b[((struct s) { .a = 1 }).a]);
>
> Is it really ambiguous? Let's show some currently-valid code:
Well, I still don't know what the syntax addition you propose is. Is it
postfix-expression : .
On 11/12/22 13:34, Alejandro Colomar wrote:
struct s {
int a;
};
struct t {
struct s s;
int a;
};
void f(void)
{
struct t x = {
.a = 1,
.s = {
.a = ((struct s) {.a = 1}).a,
},
};
}
From here, a demonstration of what I
Hi Joseph,
On 11/11/22 00:19, Joseph Myers wrote:
On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote:
One problem with WG14 papers is that people put in too much,
because the overhead is so high and the standard is not updated
very often. It would be better to build such feature more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
--- Comment #4 from Jonathan Wakely ---
Yes, that looks right.
Richard Sandiford writes:
> Tamar Christina writes:
>> Hi All,
>>
>> This adds an RTL pattern for when two NARROWB instructions are being combined
>> with a PACK. The second NARROWB is then transformed into a NARROWT.
>>
>> For the example:
>>
>> void draw_bitmap1(uint8_t* restrict pixel,
Tamar Christina writes:
> Hi All,
>
> This adds an RTL pattern for when two NARROWB instructions are being combined
> with a PACK. The second NARROWB is then transformed into a NARROWT.
>
> For the example:
>
> void draw_bitmap1(uint8_t* restrict pixel, uint8_t level, int n)
> {
> for (int i =
Sorry for the slow review, been snowed under with stage1 stuff.
Tamar Christina writes:
> Hi All,
>
> In plenty of image and video processing code it's common to modify pixel
> values
> by a widening operation and then scale them back into range by dividing by
> 255.
>
> This patch adds an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107104
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #3
On Sat, 12 Nov 2022, 08:47 Jakub Jelinek via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Hi!
>
> As reported, I've misplaced __extension__ keywords in these cases
> (wanted not to have them on the whole inlines because _Float128 is
> completely standard now while __float128 is not, but before
Sent from my iPhone
Hi!
The following patch implements CWG2635.
So far tested on
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++
RUNTESTFLAGS="dg.exp=decomp*"
ok for trunk if it passes full bootstrap/regtest and it is voted in?
2022-11-12 Jakub Jelinek
* decl.cc (grokdeclarator): Implement
This patch moves a test that is meant to only work for signed zeros
into range_tests_signed_zeros.
I am not aware of any architectures where this is failing, but it is
annoying to see selftests failing when -fno-signed-zeros is used.
gcc/ChangeLog:
* value-range.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107498
--- Comment #8 from John Paul Adrian Glaubitz ---
(In reply to Eric Botcazou from comment #5)
> Can anyone print the value of mp in the debugger?
glaubitz@gcc202:~/openldap/tests$ gdb --args
/home/glaubitz/openldap/servers/slapd/slapd -Ta -d 0
On Sat, 2022-11-12 at 15:37 +0800, Lulu Cheng wrote:
> Co-Authored-By: xujiahao
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch-def.c: Initial number of parallel
> prefetch.
> * config/loongarch/loongarch-tune.h (struct loongarch_cache):
> Define number of parallel
On Thu, 10 Nov 2022, Martin Liška wrote:
> See that the problematic for some reason uses "content-security-policy:
> default-src 'self' http: https:".
Yep.
On Thu, 10 Nov 2022, Tobias Burnus wrote:
> content-security-policy: default-src 'self' http: https:
>
> There must be some server
Hi Tobias!
On 2022-05-13T19:44:51+0200, Jakub Jelinek via Fortran
wrote:
> On Fri, May 13, 2022 at 07:21:02PM +0200, Tobias Burnus wrote:
>> gcc/fortran/ChangeLog:
>>
>> * trans-openmp.cc (gfc_trans_omp_clauses): When mapping nondescriptor
>> array sections, use
The old stack check was performed before the stack was dropped,
which would cause the detection tool to report a memory leak.
The current stack check scheme is as follows:
'-fstack-clash-protection':
1. When the frame->total_size is smaller than the guard page size,
the stack is dropped
On Sat, Nov 12, 2022 at 9:54 AM Jakub Jelinek wrote:
>
> On Fri, Nov 11, 2022 at 08:25:15PM +0100, Aldy Hernandez wrote:
> > Passes tests for all languages. Passes lapack tests.
> >
> > So ready to be installed unless you have any issues. Oh... I should
> > write some tests..
>
> LGTM.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On Fri, Nov 11, 2022 at 08:25:15PM +0100, Aldy Hernandez wrote:
> Passes tests for all languages. Passes lapack tests.
>
> So ready to be installed unless you have any issues. Oh... I should
> write some tests..
LGTM.
Yeah, for tests we still need to decide whether we make tests in the
Hi!
Pointers should be first casted to intptr_t/uintptr_t before casting
them to another integral type to avoid warnings.
Furthermore, the function has code like
else if (upper <= UINT_MAX)
something;
else
something_else;
so it seems using unsigned type for upper where upper <=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2a193e9df82917eaf440a20f99a3febe91dcb5fe
commit r13-3927-g2a193e9df82917eaf440a20f99a3febe91dcb5fe
Author: Jakub Jelinek
Date:
Hi!
As reported, I've misplaced __extension__ keywords in these cases
(wanted not to have them on the whole inlines because _Float128 is
completely standard now while __float128 is not, but before return
it is a syntax error.
I've verified on a short testcase that both g++ and clang++ accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2f7f9edd28d75a85a33599978f23811e679e443d
commit r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #37 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb
commit r13-3924-g2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #38 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5747470efa8ff0ac82bb5f53d737b29a44f18118
commit r13-3925-g5747470efa8ff0ac82bb5f53d737b29a44f18118
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #36 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2f7f9edd28d75a85a33599978f23811e679e443d
commit r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107469
Lorenzo Salvadore changed:
What|Removed |Added
CC||gerald at pfeifer dot com
---
1 - 100 of 101 matches
Mail list logo
