On Mon, Mar 06, 2023 at 11:01:18AM +, Richard Biener wrote:
> + auto_mpfr &operator=(const auto_mpfr &) = delete;
> + auto_mpz &operator=(const auto_mpz &) = delete;
Just formatting nit, space before (.
Looks like nice improvement and thanks Jonathan for the suggestions ;)
Jakub
On Mon, Mar 06, 2023 at 03:08:00PM +, Richard Sandiford via Gcc-patches
wrote:
> Segher Boessenkool writes:
> > On Mon, Mar 06, 2023 at 12:47:06PM +, Richard Sandiford wrote:
> >> How about the patch below?
> >
> > What about it? What would make it any better than the previous?
>
> It d
On Mon, Mar 06, 2023 at 11:27:16AM +0100, Robin Dapp wrote:
> > This broke the tests, I'm seeing syntax errors:
> > ERROR: gcc.dg/vect/slp-3.c -flto -ffat-lto-objects: error executing
> > dg-final: syntax error in target selector "target ! vect_partial_vectors
> > || vect32 || s390_vx"
> > ERRO
Hi!
In my recent rtti.cc change I assumed when emitting the support tinfos
that the tinfos for the fundamental types haven't been created yet.
Normally (in libsupc++.a (fundamental_type_info.o)) that is the case,
but as can be seen on the testcase, one can violate it by using typeid
etc. in the sa
On Tue, Mar 07, 2023 at 07:51:03PM +0100, Bernhard Reutner-Fischer wrote:
> While it's a nice idea, there have been resentments towards (visible)
> C++ in the fortran frontend and especially the library, i think.
I thought libgfortran is written in C and Fortran and doesn't use gmp/mpfr,
so this d
On Wed, Mar 08, 2023 at 02:31:38PM +0800, Hongyu Wang wrote:
> Hi,
>
> When OMP_WAIT_POLICY is not specified, current implementation will cause
> icv flag GOMP_ICV_WAIT_POLICY unset, so global variable wait_policy
> will remain its uninitialized value. Set it to -1 when the flag is not
> specified
On Wed, Mar 08, 2023 at 04:21:46PM +0800, Hongyu Wang wrote:
> Hongyu Wang 于2023年3月8日周三 16:07写道：
> >
> > > I think the right spot to fix this would be instead in initialize_icvs,
> > > change the
> > > icvs->wait_policy = 0;
> > > in there to
> > > icvs->wait_policy = -1;
> > > That way it wil
On Wed, Mar 08, 2023 at 04:54:20PM +0800, Hongyu Wang wrote:
> > Seems for many ICVs the default values are done through
> > gomp_default_icv_values, but that doesn't cover wait_policy.
> > For other vars, the defaults are provided through just initializers of
> > those vars on the var definitions,
On Wed, Mar 08, 2023 at 10:13:39AM +, Jonathan Wakely wrote:
> On Wed, 8 Mar 2023 at 07:25, Richard Biener wrote:
> >
> > On Wed, 8 Mar 2023, Alexander Monakov wrote:
> >
> > >
> > > On Tue, 7 Mar 2023, Jonathan Wakely wrote:
> > >
> > > > > Shouldn't this use the idiom suggested in ansidecl.h,
On Thu, Mar 09, 2023 at 08:09:02AM +0100, Gerald Pfeifer wrote:
> I struggled a bit understanding this and so have come up with what I
> hope is simpler (without changing the meaning).
>
> What do you think of the change below?
LGTM, thanks.
>
> diff --git a/htdocs/gcc-13/porting_to.html b/htdo
Hi!
The following testcase is reduced from miscompilation of scipy package.
If we have say lhs = [1., 1.] - [1., 1.] and want to compute the range
of lhs from it, we correctly determine it is [0., 0.] (if computations
are exact, we generally don't try to round them further in
frange_arithmetic).
On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote:
> I think this is a reasonable way to address the regression, so OK.
It is true that both C and C++ (including c++14_down and c++17 and later
where the latter have different ordering rules) evaluate the lhs of
MODIFY_EXPR after rhs, s
On Wed, Mar 08, 2023 at 09:38:43AM +, Richard Biener via Gcc-patches wrote:
> The following plugs one place in extract_muldiv where it should avoid
> folding when sanitizing overflow.
>
> I'm unsure about the testcase, I didn't find any that tests for
> a runtime sanitizer error ...
>
> Boots
On Thu, Mar 09, 2023 at 10:03:20AM -0800, Andrew Pinski via Gcc-patches wrote:
> The problem here is after r13-4748-g2a27ae32fabf85, in some
> cases we were calling inform without a corresponding warning.
> This changes the logic such that we only cause that to happen
> if there was a warning happe
Hi!
The following testcase FAILs, because starting with r12-6028
the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one 8-bit
bitfield and one 8-bit char field.
The reason is that when end_of_class attempts to compute dsize, it simply
adds byte_position of the field and DECL_SIZ
Hi!
The following patch does two things (both related to range extension
around the boundaries).
The first part (in the 2 real_isfinite blocks) is to make the ranges
narrower when the old boundaries are minimum and/or maximum representable
finite number. In that case frange_nextafter gives -Inf
Hi!
This patch, incremental to the just posted one, improves the reverse
operation ranges significantly by widening just by 0.5ulp in each
direction rather than 1ulp. Again, REAL_VALUE_TYPE has both wider
exponent range and wider mantissa precision (160 bits) than any
supported type, this patch u
On Thu, Mar 09, 2023 at 05:14:11PM +, Richard Sandiford wrote:
> We decided to keep the current mangling of __bf16 and use it for
> std::bfloat16_t too. __bf16 will become a non-standard arithmetic type.
> This will be an explicit diversion from the Itanium ABI.
>
> I think that's equivalent
refix-map: Fix up -f*-prefix-map= (3 variants)
Thanks
Jakub
On Fri, Jan 20, 2023 at 04:05:55PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Nov 01, 2022 at 01:46:20PM -0600, Jeff Law via Gcc-patches wrote:
> > > This does cause a change of behaviour if users were p
Hi!
On Wed, Mar 01, 2023 at 01:32:43PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Thoug
Hi!
I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
- PR107558 - P2 - c++: Don't clear TREE_READONLY for -fmerge-all-constants
for non-aggregates
Thanks
Jakub
On Thu, Nov 24, 2022 at 10:13:55AM +0100, Jakub Jelinek via G
n Thu, Feb 02, 2023 at 03:30:29PM +0100, Jakub Jelinek via Gcc-patches wrote:
> The recent change to undo the tree_code_type/tree_code_length
> excessive duplication apparently broke building the Linux kernel
> plugin. While it is certainly desirable that GCC plugins are built
> with the
Hi!
I'd like to ping this patch (as I wrote a week ago, NightStrike has tested
it):
On Fri, Mar 03, 2023 at 07:44:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > > 2023-02-22 Jakub Jelinek
> > >
> > > PR target/107998
> > > * config.gcc (x
On Fri, Mar 10, 2023 at 08:53:37AM +, Richard Biener wrote:
> Meh - I wonder if we can avoid all this by making float_widen_lhs_range
> friend of frange and simply access m_min/m_max directly and use the
> copy-CTOR to copy bounds and nan state ... after all verify_range
> will likely fail afte
On Fri, Mar 10, 2023 at 08:43:02AM +, Richard Sandiford wrote:
> > So, either __bf16 should be also extended floating-point type
> > like decltype (0.0bf16) and std::bfloat16_t and in that case
> > it is fine if it mangles u6__bf16, or __bf16 will be a distinct
> > type from the latter two,
>
On Fri, Mar 10, 2023 at 11:50:39AM +, Richard Sandiford wrote:
> > Will test it momentarily (including the patch it depends on):
Note, testing still pending, I'm testing in a Fedora scratch build
and that is quite slow (lto bootstrap and the like).
> A naive question:
>
> > --- libgcc/config
Hi!
This is on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html
and
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613724.html
patches (to be precise, the latter isn't essential for it), I've
realized that for the PR107703 bugfix in the first patch I haven't
add
On Fri, Mar 10, 2023 at 06:54:10PM +0100, Thomas Koenig via Gcc-patches wrote:
> Hello world, here's the patch that was discussed.
>
> Regression-tested. OK for trunk?
>
> Since this appeared only in gcc13, I see no need for a backport.
> I will also document this in the changes file.
>
> Best r
On Thu, Mar 09, 2023 at 07:44:53PM -0500, Marek Polacek wrote:
> On Thu, Mar 09, 2023 at 09:44:49AM +0100, Jakub Jelinek wrote:
> > On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote:
> > > I think this is a reasonable way to address the regression, so OK.
> >
> > It is true that both
On Mon, Mar 13, 2023 at 08:59:15AM +0100, Aldy Hernandez wrote:
> > Yes, sure - I just noticed that we're forced to use high-level API for
> > something that's quite low-level and should be internal (a range
> > "breaking" internal consistency checks).
>
> Yeah, let's fix the API. No sense hackin
Hi!
On Tue, Mar 07, 2023 at 05:50:39PM +, Jonathan Wakely via Gcc-patches wrote:
> I guess you want to regenerate the powerpc64 ones now. The others are
> all OK for trunk.
So the following patch updates powerpc64 which has been excluded from
the last patch (the difference between the older a
On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> gdbhooks, which expects tree_code_type to always be available. I considered
> trying to make gdbhooks more robust, but it seemed simpler to define
> tree_
On Mon, Mar 13, 2023 at 10:02:41PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> > The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> > gdbhooks, which expects tree_code_type to always be available. I considered
> > tryin
On Thu, Mar 09, 2023 at 07:36:21PM +, Tamar Christina via Gcc-patches wrote:
> PR target/108583
> * gcc.dg/mla_1.c: New test.
The testcase FAILs on all targets but AArch64 (maybe ARM is fine too).
While f1/g1 are compilable on all targets and f3/g3 with -Wno-psabi in
dg-options, f2
Hi!
On Fri, Mar 10, 2023 at 01:49:38PM -0500, Jason Merrill via Gcc-patches wrote:
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp2a/concepts-lambda3.C: Run at lower std levels,
> but expect errors.
I'm seeing
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C -std=c++11 compilation failed to
Hi!
As reported in the PR, for __has_unique_object_representations we
were treating unnamed bitfields as named ones, which is wrong, they
are actually padding.
THe following patch fixes that. Ok for trunk (and what about release
branches later?)?
2023-03-14 Jakub Jelinek
PR c++/1090
Hi!
As mentioned in the PR, range_of_expr returns false if the type
of the expression isn't suitable for corresponding range type,
but doesn't if the range is undefined for other reasons. Still,
lower/upper_bound is defined only for ranges which actually have
at least one pair of subranges, VR_UN
On Tue, Mar 14, 2023 at 10:12:58AM +, Richard Biener via Gcc-patches wrote:
> In PR109087 it was noticed that we rely on DSE to remove .DEFERRED_INIT
> when it is the only remaining use of a variable. Since DSE is imperfect
> and even if it were not would be limited by the amount of statements
Hi!
On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> gdbhooks, which expects tree_code_type to always be available. I considered
> trying to make gdbhooks more robust, but it seemed simpler to define
>
Hi!
In my PR107627 change I've missed one important case, which causes
miscompilation of f4 and f6 in the following tests.
Combine matches there *concatsidi3_3 define_insn_and_split (as with all
other f* functions in those tests), and RA ends up with:
(insn 11 10 17 2 (set (reg:DI 0 ax [89])
On Wed, Mar 15, 2023 at 10:48:32AM +, Richard Biener wrote:
> use_after_inval_p uses stmt UIDs to speed up repeated dominance
> checks within a basic-block but it fails to assign UIDs to PHIs
> which means compares with PHIs in the same block get a random
> result.
>
> The following factors re
On Wed, Mar 15, 2023 at 10:49:19AM +, Richard Biener via Gcc-patches wrote:
> The following switches the -Wuse-after-free diagnostics from emitted
> during the late access warning passes to the early access warning
> passes to make sure we run before passes performing code motion run
> which ar
On Wed, Mar 15, 2023 at 01:07:56PM +, Richard Biener wrote:
> The following patch was bootstrapped and tested on
> x86_64-unknown-linux-gnu. It now doesn't regress anything in the
> testsuite but on its own it has the chance to (by luck maybe
> avoided previosuly due to the PHI compare bug) i
On Wed, Mar 15, 2023 at 03:24:04PM +0100, Tobias Burnus wrote:
> When adding a new OpenMP routine, also omp_runtime_api_call needs
> to be adapted - to get proper error like:
>
> error: OpenMP runtime API call ‘omp_in_explicit_task’ in a region with
> ‘order(concurrent)’ clause
>
> OK for mainli
On Wed, Mar 15, 2023 at 02:39:43PM +, Richard Biener via Gcc-patches wrote:
> I've tested and most of the -Wuse-after-free testcases work with -Og
> before and after the change (unfortunately adding -Og via RUNTESTFLAGS
> doesn't work since explicit -O2 in the testcases overrides that).
>
> We
Hi!
I've noticed I forgot to update copyright years when updating from
Unicode 15.0.0 (and makeucnid.cc had it hopelessly obsolete).
Committed as obvious to trunk.
2023-03-16 Jakub Jelinek
* makeucnid.cc (write_copyright): Update Unicode copyright years
up to 2022.
*
Hi!
I've noticed we have instructions on how to update from newer Unicode
standard, but it didn't mention uname2c.h regeneration.
The following patch mentions that, also mentions that the Copyright years
of Unicode should be updated and adds a copy of NameAliases.txt which
is used for uname2c.h g
On Wed, May 10, 2023 at 03:17:58PM +0800, Pan Li via Gcc-patches wrote:
> gcc/ChangeLog:
>
> * var-tracking.cc (DECL_OR_VALUE_OR_DEFAULT): New macro for
> clean code.
ChangeLog formatting shouldn't have spaces after the initial tab.
Furthermore, the entry doesn't describe what chang
Hi!
The PR contains a testcase where the Fortran FE creates FUNCTION_TYPE
which doesn't really match the passed in arguments (FUNCTION_TYPE has
5 arguments, call has 6). Now, I think that is a Fortran FE bug that
should be fixed there, but I think with function pointers one can
create something s
On Wed, May 10, 2023 at 07:57:05PM +0800, pan2...@intel.com wrote:
> --- a/gcc/var-tracking.cc
> +++ b/gcc/var-tracking.cc
> @@ -116,9 +116,14 @@
> #include "fibonacci_heap.h"
> #include "print-rtl.h"
> #include "function-abi.h"
> +#include "mux-utils.h"
>
> typedef fibonacci_heap bb_heap_t;
On Fri, Mar 24, 2023 at 04:30:38PM +0100, Frederik Harwath wrote:
> this patch series implements the OpenMP 5.1 "unroll" and "tile"
> constructs. It includes changes to the C,C++, and Fortran front end
> for parsing the new constructs and a new middle-end
> "omp_transform_loops" pass which impleme
On Mon, May 15, 2023 at 12:35:23PM +0200, Aldy Hernandez wrote:
> gcc/ChangeLog:
>
> PR tree-optimization/109695
> * value-range.cc (irange::operator=): Resize range.
> (irange::union_): Same.
> (irange::intersect): Same.
> (irange::invert): Same.
> (int_range_m
On Mon, May 15, 2023 at 12:19:00PM +0200, Jakub Jelinek via Gcc-patches wrote:
> For C++ in templates we obviously need to defer that until instantiations,
> the constants in the clauses etc. could be template parameters etc.
Even in C++ the how many canonical loop nest form loops doe
On Mon, May 15, 2023 at 01:08:51PM +0200, Richard Biener wrote:
> Btw, why's there a trailing underscore for union but not intersect?
Because union is a C++ keyword, while intersect is not.
Jakub
On Mon, May 15, 2023 at 11:41:46AM -0400, Jason Merrill via Gcc-patches wrote:
> On 5/15/23 11:24, Patrick Palka wrote:
> > This adds the feature-test macro for PR0849R8, as per
> > https://github.com/cplusplus/CWG/issues/281.
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
On Tue, May 16, 2023 at 11:45:16AM +0200, Frederik Harwath wrote:
> The place where different compilers implement the loop transformations
> was discussed in an OpenMP loop transformation meeting last year. Two
> compilers (another one and GCC with this patch series) transformed the loops
> in the
Hi!
My GCC 12 change to avoid removing zero-sized bitfields as they are
important for ABI and are needed for layout compatibility traits
apparently causes zero sized bitfields to be initialized in the IL,
which at least in 13+ results in ICEs in the ranger which is upset
about zero precision types
Hi!
When looking into _BitInt support, I've noticed unterminated parens in
a function comment.
Fixing thusly.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2023-05-17 Jakub Jelinek
* wide-int.cc (wi::from_array): Add missing closing paren in fu
Hi!
When _Float128 support has been added to C++ for 13.1, float128t_type_node
tree has been added - in C float128_type_node and float128t_type_node is
the same and represents both _Float128 and __float128, but in C++ they
are distinct types which have different handling in the FEs.
When doing th
Hi!
As can be seen on the following testcase, for
std::{atan2,fmod,pow,copysign,fdim,fmax,fmin,hypot,nextafter,remainder,remquo,fma}
if one operand type is std::float{16,32,64,128}_t or std::bfloat16_t and
another one some integral type or some other floating point type which
promotes to the other
On Thu, May 18, 2023 at 01:56:46PM +0100, Jonathan Wakely via Gcc-patches wrote:
> --- a/gcc/testsuite/gcc.test-framework/gen_directive_tests
> +++ b/gcc/testsuite/gcc.test-framework/gen_directive_tests
> @@ -322,8 +322,8 @@ two() {
> echo "${GOOD_PROG}" >> $FILE1
> echo "${GOOD_PROG}" >
On Thu, May 18, 2023 at 01:56:45PM +0100, Jonathan Wakely via Gcc-patches wrote:
> From: Michael B??uerle
>
> POSIX sh does not support the == for string comparisons, use = instead.
>
> gcc/ChangeLog:
>
> PR bootstrap/105831
> * config/nvptx/gen-opt.sh: Use = operator instead of ==.
On Thu, May 18, 2023 at 01:56:47PM +0100, Jonathan Wakely via Gcc-patches wrote:
> POSIX sh does not support the == for string comparisons, use = instead.
>
> These contrib scripts all use a bash shebang so == does work, but
> there's no reason they can't just use the more portable form anyway.
>
On Thu, May 18, 2023 at 02:03:58PM +0100, Jonathan Wakely via Gcc-patches wrote:
> Fixes a fat finger error in the v1 patch, spotted by Jakub.
>
> -- >8 --
>
> POSIX sh does not support the == for string comparisons, use = instead.
>
> The gen_directive_tests script uses a bash shebang so == doe
Hi!
As can be seen on the following testcase, we pattern recognize it on
i?86/x86_64 as return __builtin_mul_overflow_p (x, y, 0UL) and avoid
that way the extra division, but don't do it e.g. on aarch64 or ppc64le,
even when return __builtin_mul_overflow_p (x, y, 0UL); actually produces
there bett
Hi!
In the pattern recognition of signed __builtin_mul_overflow{,_p} we
check for result of unsigned division (which follows unsigned
multiplication) being equality compared against one of the multiplication's
argument (the one not used in the division) and check for the comparison
to be done agai
On Fri, May 19, 2023 at 10:08:28AM +0200, Gerald Pfeifer wrote:
> This is how I actually noticed the situation in gcc-13/buildstat.html
> (and then I mixed the two up).
>
> Jakub, do you have some old templates somewhere maybe?
Usually I git diff last year's changes and apply that after adjusting
Hi!
When an OpenMP program with target regions is linked statically,
it fails to link on various arches (doesn't when using recent glibc
because it has libdl stuff in libc), because libgomp.a(target.o) uses
dlopen/dlsym/dlclose, but we aren't linking against -ldl (unless
user asked for that). We
Hi!
On the following testcase we hang, because POLY_INT_CST is CONSTANT_CLASS_P,
but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the
(x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2)
simplification actually relies on the (CST1 & CST2) simplification,
otherwise it is a deoptimization, t
On Wed, May 17, 2023 at 01:55:00PM +0200, Frederik Harwath wrote:
> Thanks for the explanation. But actually doing this would require a
> complete rewrite which would almost certainly imply that mainline GCC
> would not support the loop transformations for a long time.
I don't think it needs compl
On Fri, Apr 28, 2023 at 05:22:52PM -0600, Sandra Loosemore wrote:
> OpenMP 5.0 removed the restriction that multiple collapsed loops must
> be perfectly nested, allowing "intervening code" (including nested
> BLOCKs) before or after each nested loop. In GCC this code is moved
> into the inner loop
On Fri, Apr 28, 2023 at 05:22:53PM -0600, Sandra Loosemore wrote:
> OpenMP 5.0 removed the restriction that multiple collapsed loops must
> be perfectly nested, allowing "intervening code" (including nested
> BLOCKs) before or after each nested loop. In GCC this code is moved
> into the inner loop
On Wed, Jan 06, 2021 at 11:34:32AM +0800, Hongtao Liu via Gcc-patches wrote:
> > >>
> > >> Note there's a data dependency between them. insn 7 feeds insn 9. When
> > >> there's a data dependency, combiner patterns are usually the better
> > >> choice than peepholes. I think you'd be looking to m
On Thu, Jan 21, 2021 at 06:30:06PM -0300, Alexandre Oliva wrote:
>
> GNAT may create temporaries to hold return values of function calls.
> If such a temporary is created as part of a dynamic initializer of a
> variable in a unit other than the one being compiled, the initializer
> is dropped, inc
Hi!
Alex' 2 years old change to build_zero_init_1 to return NULL pointer with
reference type for references breaks the sanitizers, the assignment of NULL
to a reference typed member is then instrumented before it is overwritten
with a non-NULL address later on.
That change has been done to fix err
Hi!
As discussed in the PR, the problem here is that the routines changed in
this patch sign extend the difference of index and low_bound from the
precision of the index, so e.g. when index is unsigned int and contains
value -2U, we treat it as index -2 rather than 0xfffeU on 64-bit
ar
Hi!
In the PR Andrew said he has implemented a simplification that has been
added to LLVM, but that actually is not true, what is in there are
X * (X cmp 0.0 ? +-1.0 : -+1.0) simplifications into +-abs(X)
but what has been added into GCC are (X cmp 0.0 ? +-1.0 : -+1.0)
simplifications into copysig
On Thu, Jan 21, 2021 at 07:42:43PM -0300, Alexandre Oliva wrote:
> On Jan 21, 2021, Alexandre Oliva wrote:
>
> > But I was wrong. The bootstrap with the added assert has just failed,
> > as early as stage2 libiberty. Looking into it...
>
> Uhh, I take that back. I just goofed in the assert, i
On Thu, Jan 21, 2021 at 06:35:48PM -0300, Alexandre Oliva wrote:
>
> Ada makes extensive use of nested functions, which turn all automatic
> variables of the enclosing function that are used in nested ones into
> members of an artificial FRAME record type.
>
> The address of a local variable is u
Hi!
When GCC is emitting .debug_line or .gnu.debuglto_.debug_line section by
itself (happens either with too old or non-GNU assembler, with
-gno-as-loc-support or with -flto) on empty translation units, it violates
the DWARF 5 requirements.
The standard says:
"The first entry is the current direct
Hi!
The x86 __m64 type is defined as:
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
and so matches the comment above it in that reads and stores th
On Mon, Sep 21, 2020 at 10:12:20AM +0200, Richard Biener wrote:
> On Mon, 21 Sep 2020, Jan Hubicka wrote:
> > these testcases now fails because they contains an invalid type puning
> > that happens via const VALUE_TYPE *v pointer. Since the check function
> > is noinline, modref is needed to trigge
Hi!
As mentioned in the PR, the compiler behaves differently during strncmp
and strncasecmp folding between 32-bit and 64-bit hosts targeting 64-bit
target. I think that is highly undesirable.
The culprit is the host_size_t_cst_p predicate that is used by
fold_const_call, which punts if the targ
Hi!
Spotted while fixing the rs6000 aliasing issue.
Regtested on x86_64-linux and i686-linux, committed to trunk as obvious.
2021-01-22 Jakub Jelinek
* gcc.target/i386/m128-check.h (CHECK_EXP, CHECK_FP_EXP): Fix a typo,
UINON_TYPE to UNION_TYPE.
* gcc.target/i386/m256-
Hi!
And ditto for powerpc. Written as separate patch because it was dependent
on the no-strict-aliasing patch.
Committed to trunk as obvious.
2021-01-22 Jakub Jelinek
* gcc.target/powerpc/m128-check.h (CHECK_EXP, CHECK_FP_EXP): Fix a
typo, UINON_TYPE to UNION_TYPE.
--- gcc/t
On Fri, Jan 22, 2021 at 05:45:54PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 22, 2021 at 07:02:04PM +0100, Jakub Jelinek wrote:
> > The x86 __m64 type is defined as:
> > /* The Intel API is flexible enough that we must allow aliasing with other
> >vector types, and their scalar components.
On Sat, Jan 23, 2021 at 01:03:31AM +0100, Jakub Jelinek via Gcc-patches wrote:
> The problem is that the testcase uses the
> _mm_loadl_pi
> API, and per the Intel intrinsic rules it is ok when that intrinsic
> loads from wide range of types, e.g. including pairs of integers or
>
Hi!
The testcase in the patch doesn't assemble, because the instruction requires
that the penultimate operand (lsb) range is [0, 32] (or [0, 64]) and the last
operand's range is [1, 32 - lsb] (or [1, 64 - lsb]).
The INTVAL (shft_amnt) < GET_MODE_BITSIZE (mode) will accept the lsb operand
to be in
On Fri, Jan 22, 2021 at 06:56:37PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 22, 2021 at 08:02:28PM +0100, Jakub Jelinek wrote:
> > On Mon, Sep 21, 2020 at 10:12:20AM +0200, Richard Biener wrote:
> > > On Mon, 21 Sep 2020, Jan Hubicka wrote:
> > > > these testcases now fails because they conta
Hi!
I'd like to ping 3 patches:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563710.html
expand: Expand x / y * y as x - x % y if the latter is cheaper [PR96696]
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563711.html
match.pd: Add some __builtin_ctz (x) cmp cst simplifi
Hi!
binutils since https://sourceware.org/bugzilla/show_bug.cgi?id=25612
changes from March last year until the
https://sourceware.org/pipermail/binutils/2020-August/112684.html
fix in early August emits incorrect .debug_info when assembling files
with --gdwarf-5. Instead of emitting proper DWARF
On Mon, Jan 25, 2021 at 03:21:45PM +, Kwok Cheung Yeung wrote:
> I forgot to update the libgomp documentation to document the new
> omp_fulfill_event runtime routine introduced by task detach support. Is this
> patch okay for trunk?
>
> Thanks
>
> Kwok
> From efeaac839879bc30e0e7e129ca433811
Hi!
On Mon, Jan 25, 2021 at 01:18:05PM +0100, Richard Biener wrote:
> This simplifies vector_element_bits further, avoiding any mode
> dependence and instead relying on boolean vector construction
> to populate element precision accordingly.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu
Hi!
In 4.8 and earlier we used to fold the following to 0 during GENERIC folding,
but we don't do that anymore because ctor_for_folding etc. has been turned into
a
GIMPLE centric API, but as the testcase shows, it is invoked even during
GENERIC folding and there the automatic vars still should ha
On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > folding,
> > but we don't do that anymore because ctor_for_folding etc. has been turned
> > into a
> > GIMPLE centric API, but as the testcase shows, it is
On Tue, Jan 26, 2021 at 10:55:35AM +0100, Jan Hubicka wrote:
> > On Tue, Jan 26, 2021 at 10:03:16AM +0100, Richard Biener wrote:
> > > > In 4.8 and earlier we used to fold the following to 0 during GENERIC
> > > > folding,
> > > > but we don't do that anymore because ctor_for_folding etc. has been
On Tue, Jan 26, 2021 at 11:37:42AM +0100, Jan Hubicka wrote:
> I think it would make more sense.
> We could also simply clean it up next stage1.
I'll rebootstrap/retest the following version then (adding PROP_rtl
just in case it would be called during expand or later).
2021-01-26 Jakub Jelinek
On Tue, Jan 26, 2021 at 12:16:14PM +0100, Richard Biener wrote:
> > + /* Unless this is called during FE folding. */
> > + if (cfun
> > + && (cfun->curr_properties & (PROP_trees | PROP_rtl)) == 0
>
> don't you want && (cfun->curr_properties & PROP_trees) != 0?
No, PROP_trees is mis
On Tue, Jan 26, 2021 at 12:25:16PM +0100, Richard Biener wrote:
> On Tue, 26 Jan 2021, Jakub Jelinek wrote:
>
> > On Tue, Jan 26, 2021 at 12:16:14PM +0100, Richard Biener wrote:
> > > > + /* Unless this is called during FE folding. */
> > > > + if (cfun
> > > > + && (cfun->curr_
Hi!
My recent dwarf2asm.c patch broke powerpc*-*-* bootstrap, while most target
define POINTER_SIZE to (cond ? cst1 : cst2) or constant, rs6000 defines
it to a variable, and the arbitrarily chosen type of that variable determines
whether we get warnings on comparison of that against signed or unsi
301 - 400 of 4686 matches
Mail list logo
