Hi!
Some of the builtin folding sets TREE_NO_WARNING flags, which triggers as
--enable-checking=fold errors. I think we should allow setting of
TREE_NO_WARNING flag when folding, so this patch arranges that.
Tested on:
../configure --enable-languages=c,c++,fortran --enable-checking=fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394
--- Comment #3 from spinpx ---
CVE-2019-9071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89395
--- Comment #3 from spinpx ---
CVE-2019-9070
Hi,
This patch fixes PR89487 by following comments in PR. It simply avoid checking
runtime
alias by versioning in loop distribution if address of register variable may
need to be taken.
One thing I am not sure is if we should avoid generating data reference in the
first place:
Creating dr for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #27 from Xi Ruoyao ---
I confirm it is back in 8.3.0.
See https://gcc.godbolt.org/z/QoSa3W.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482
--- Comment #9 from David ---
(In reply to Ciro Santilli from comment #8)
- I haven't posted a patch file since I wasn't sure that I was all that close
to being done. But I'm certainly not opposed to the idea. Were you
volunteering to move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
In PR 89406 the cmd/go tests are timing out after 10 minutes. Double
the timeout to give them a better chance of completing. Bootstrapped
and ran gotools tests on x86_64-pc-linux-gnu. Committed to mainline.
Ian
2019-02-28 Ian Lance Taylor
PR go/89406
* Makefile.am (GOTOOLS_TEST_TIMEOUT):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542
--- Comment #2 from puffydaemon at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
> Are you sure this is not an binutils bug at reporting the wrong line numbers
> based on the preprocessed output?
No, I am not sure. Even I dont
* opts.c: Ignore -Wno-error=.
---
gcc/opts.c | 5 -
gcc/testsuite/c-c++-common/pr89524.c | 7 +++
2 files changed, 11 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/c-c++-common/pr89524.c
diff --git a/gcc/opts.c b/gcc/opts.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542
--- Comment #1 from Andrew Pinski ---
Are you sure this is not an binutils bug at reporting the wrong line numbers
based on the preprocessed output?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542
Bug ID: 89542
Summary: Error reported on incorrect line number when using GCC
to compile .S files using #include
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89531
--- Comment #3 from Arseny Solokha ---
In my case the target is 32-bit BE powerpc.
Additionally, the testcase fails w/ -fno-PIC and/or ( -fstack-protector-all or
-fno-stack-protector ); it does not fail w/ -fPIC and/or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89541
Bug ID: 89541
Summary: [9 Regression] ICE in VN_INFO(tree_node*)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88100
Li Jia He changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
This libgo patch changes the go tool to default to invoking gccgo with
-O2. That seems like the right default for people who choose to use
this toolchain. It can be overridden with the go tool's -gccgoflags
option. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
On Thu, Feb 28, 2019 at 1:59 AM Rainer Orth
wrote:
>
> > On Thu, Feb 21, 2019 at 1:47 AM Andreas Schwab wrote:
> >>
> >> On Feb 20 2019, Ian Lance Taylor wrote:
> >>
> >> > if test x$hasoutput = xtrue; then
> >> > - echo ' {"'$n'", '$j', "'"$output"'",
> >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540
--- Comment #2 from Andres Takach ---
You are right. I did use LD_LIBRARY_PATH, but the issue I had is that I used
the "lib" instead of the "lib64" version (I did not build 32-bit compatability)
so I was picking up the wrong version since "lib"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89526
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459
--- Comment #4 from joseph at codesourcery dot com ---
In fact, having tested it, and used static linking to make sure the new
libquadmath was used rather than an older distribution version, this bug
was fixed in GCC 8, presumably by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540
--- Comment #1 from joseph at codesourcery dot com ---
Are you sure you're using (at runtime) the libquadmath from the GCC
version you're using (via -rpath / LD_LIBRARY_PATH, or linking with static
rather than shared libquadmath), rather than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #9 from H. Peter Anvin ---
I can confirm this bug is still present as of gcc 8.2.1.
I have attached a test case which clearly shows __udivdi3 called with the
regparm convention, but libgcc definitely does not expect it:
objdump -dr
build_m_component_ref can't handle type-dependent operands, so let's use the
default case; tsubst_copy_and_build also uses build_x_binary_op for
substituting a DOTSTAR_EXPR.
Tested x86_64-pc-linux-gnu, applying to trunk.
* pt.c (fold_expression) [DOTSTAR_EXPR]: Remove special handling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88183
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Fri Mar 1 00:08:58 2019
New Revision: 269293
URL: https://gcc.gnu.org/viewcvs?rev=269293=gcc=rev
Log:
PR c++/88183 - ICE with .* fold-expression.
build_m_component_ref can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86969
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Fri Mar 1 00:08:21 2019
New Revision: 269292
URL: https://gcc.gnu.org/viewcvs?rev=269292=gcc=rev
Log:
PR c++/86969 - ICE with constexpr if and recursive generic lambdas.
I wanted this when messing with binding levels for 86969. This function is
only used interactively from the debugger, so it's safe to go in now.
---
gcc/cp/name-lookup.c | 2 ++
gcc/cp/ChangeLog | 4
2 files changed, 6 insertions(+)
diff --git a/gcc/cp/name-lookup.c
On Wed, Feb 27, 2019 at 4:54 PM Jason Merrill wrote:
>
> Immediately capturing a VLA means we need to create a dependent VLA capture
> type, and not in the context of the lambda op(), since trying to look up the
> instantiation of the op() while we're substituting into the capture list
> would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #8 from H. Peter Anvin ---
Created attachment 45862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45862=edit
Test code (object output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #7 from H. Peter Anvin ---
Created attachment 45861
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45861=edit
Test case (assembly output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #6 from H. Peter Anvin ---
Created attachment 45860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45860=edit
Test case (preprocessed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
H. Peter Anvin changed:
What|Removed |Added
CC||hpa at zytor dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540
Bug ID: 89540
Summary: roundq(x) returning value with non-zero fractional
part
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89534
--- Comment #1 from jon_y <10walls at gmail dot com> ---
Weak symbols aren't quite supported with PE, I'm not sure if making the symbol
weak is the right approach.
Do you have a test case to show this will lead to the correct behavior with
On Fri, Mar 01, 2019 at 12:19:36AM +0100, Eric Botcazou wrote:
> > I know Eric has committed a tweak here, but I view this magic handling as
> > something meant for boolean types only (if it is correct at all and the
> > right fix wouldn't be avoid the BIT_NOT_EXPR for the prec > 1 booleans, I
> >
> I know Eric has committed a tweak here, but I view this magic handling as
> something meant for boolean types only (if it is correct at all and the
> right fix wouldn't be avoid the BIT_NOT_EXPR for the prec > 1 booleans, I
> believe the expansion of BIT_NOT_EXPR doesn't have any special case
On Mon, Feb 25, 2019 at 10:07:10AM +0100, Eric Botcazou wrote:
> 2019-02-25 Eric Botcazou
>
> * tree-ssa-dom.c (edge_info::derive_equivalences) : Fix
> and move around comment.
> : Likewise.
> : Add specific handling for boolean types.
This broke the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89539
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
the value is 0 instead of the entire value.
* gcc.c-torture/execute/20190228-1.c: New test.
--
Eric Botcazou/* PR tree-optimization/89536 */
/* Testcase by Zhendong Su */
int a = 1;
int main (void)
{
a = ~(a && 1);
if (a < -1)
a = ~a;
if (!a)
__b
::derive_equivalences) : Test
only whether bit #0 of the value is 0 instead of the entire value.
Added:
branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/execute/20190228-1.c
- copied unchanged from r269289,
trunk/gcc/testsuite/gcc.c-torture/execute/20190228-1.c
Modified:
branches/gcc
On Wed, Feb 27, 2019 at 06:48:13PM -0500, Jason Merrill wrote:
> > Or would you prefer to have P1002R1 implemented and thus make this perhaps a
> > pedwarn before cxx2a, similarly for the error on try block in the body and
> > tweak build_constexpr_constructor_member_initializers? I think
::derive_equivalences) : Test
only whether bit #0 of the value is 0 instead of the entire value.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20190228-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89539
Bug ID: 89539
Summary: [9.0 regression] gcc fails to build/bootstrap on
MACOSX
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77604
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #5 from Dominique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #19 from Eric Botcazou ---
> We do take the range as granted in both cases. If for BIT_NOT_EXPR on say
> int the result is -2 or -1, then your TREE_INT_CST_LOW fix would DTRT, sure.
> If the result is any other value, then we run
Snapshot gcc-7-20190228 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190228/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87068
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87068
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Thu Feb 28 22:29:42 2019
New Revision: 269288
URL: https://gcc.gnu.org/viewcvs?rev=269288=gcc=rev
Log:
PR c++/87068 - missing diagnostic with fallthrough statement.
*
On Thu, Feb 28, 2019 at 05:16:14PM -0500, Marek Polacek wrote:
> 2019-02-28 Marek Polacek
>
> PR c++/87068 - missing diagnostic with fallthrough statement.
> * gimplify.c (expand_FALLTHROUGH_r): If IFN_FALLTHROUGH was found
> at the end of a seq, save its location to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576
--- Comment #29 from Dominique d'Humieres ---
> Is this still an issue?
I still get the stack-buffer-overflow reported in comment 26 with 8.2 and trunk
(9.0) but not with 7.4.
On Thu, Aug 30, 2018 at 11:24:50PM +0200, Jakub Jelinek wrote:
> On Thu, Aug 30, 2018 at 05:17:03PM -0400, Marek Polacek wrote:
> > > 2018-08-23 Marek Polacek
> > >
> > > PR c++/87068
> > > * gimplify.c (expand_FALLTHROUGH_r): If IFN_FALLTHROUGH was found
> > > at the end of a seq, save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
One more.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.48
diff -u -r1.48 changes.html
--- changes.html28 Feb 2019 20:51:28 - 1.48
+++ changes.html28 Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
Hi!
The following testcase ICEs on ARM, because the backend creates CONST_INTs
that aren't valid for SImode, in which they are used (0x8000 rather than
the canonical -0x8000). This is fixed by the 3 gen_int_mode calls
instead of just GEN_INT.
Once that is fixed, we ICE because if both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576
--- Comment #28 from anlauf at gcc dot gnu.org ---
Is this still an issue?
On x86_64-pc-linux-gnu and with current trunk, I do only get a memory
leak with -fsanitize=address (both -m32 and -m64), which disappears
if I deallocate the arrays at
On Thu, Feb 28, 2019 at 10:12:00PM +0100, Thomas Schwinge wrote:
> On Wed, 15 Jun 2016 20:12:15 -0700, Cesar Philippidis
> wrote:
> The code changes now are actually very simple. The "problem" is that
> we're incrementing the Fortran module version, 'MOD_VERSION', which
> breaks binary
Hi!
On Wed, 15 Jun 2016 20:12:15 -0700, Cesar Philippidis
wrote:
> [...], this patch updates the way that
> the fortran FE handles the 'acc routine' attribute in modules. Before,
> it only recorded that a function was marked as an acc routine.
(By means of 'OMP_DECLARE_TARGET', that is.)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87751
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77604
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #6 from Jonathan Wakely ---
(In reply to Marek Polacek from comment #5)
> 89537.C:9:18: error: invalid use of non-static member function ‘void B<
> , ,
> , >::keys() [with _Tp =
> int; = int; = A;
> = A]’
> 9 | :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544
--- Comment #9 from Harald Anlauf ---
(In reply to kargl from comment #8)
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c (revision 266281)
> +++
Applied.
Index: gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.47
diff -u -r1.47 changes.html
--- gcc-9/changes.html 28 Feb 2019 10:31:50 - 1.47
+++ gcc-9/changes.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538
Bug ID: 89538
Summary: [7.3.0] GCC miscompiling LLVM because of wrong
vectorization
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538
--- Comment #1 from Taewook Oh ---
And I confirmed that this bug doesn't reproduce with GCC5.
Hi!
On Mon, 15 Aug 2016 18:54:49 -0700, Cesar Philippidis
wrote:
> [...]
>
> Note that besides for checking for multiple acc routine directives, this
> patch also handles the case where the optional name argument in 'acc
> routine (NAME)' is the name of the current procedure. This was a TODO
>
Hi!
On Thu, 28 Jul 2016 21:21:29 -0700, Cesar Philippidis
wrote:
> Thomas found a bug in the fortran routine parser where errors involving
> invalid combinations of gang, worker, vector and seq clauses were
> getting suppressed. [...]
> This bug is also present in trunk, but [...]
Re-worked a
Hi!
On Fri, 12 Aug 2016 18:13:43 +0200, I wrote:
> Let me actually break this out of the other pending patches; this should
> be uncontroversial. Originally by Cesar, extended by me. OK for trunk?
>
> commit a0fee96c0f204814e87ddf6635f9cbec2afc6887
> Author: Thomas Schwinge
> Date: Fri Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433
--- Comment #2 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:36 2019
New Revision: 269287
URL: https://gcc.gnu.org/viewcvs?rev=269287=gcc=rev
Log:
[PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
--- Comment #10 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:23 2019
New Revision: 269286
URL: https://gcc.gnu.org/viewcvs?rev=269286=gcc=rev
Log:
[PR72741] For all Fortran OpenACC 'routine' directive variants check for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
--- Comment #11 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:36 2019
New Revision: 269287
URL: https://gcc.gnu.org/viewcvs?rev=269287=gcc=rev
Log:
[PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433
--- Comment #1 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:01 2019
New Revision: 269285
URL: https://gcc.gnu.org/viewcvs?rev=269285=gcc=rev
Log:
[PR72741, PR89433] Accept intrinsic symbols in Fortran OpenACC 'routine'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
--- Comment #9 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:01 2019
New Revision: 269285
URL: https://gcc.gnu.org/viewcvs?rev=269285=gcc=rev
Log:
[PR72741, PR89433] Accept intrinsic symbols in Fortran OpenACC 'routine'
Hello world,
the attached patch fixes a wrong-code bug for gfortran where pointers
were not marked as escaping. A C_PTR can be stashed away and reused
later (at least as long as the variable it points to remains active).
This is not a regression, but IMHO a bad wrong-code bug. The chances
of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
--- Comment #13 from Thomas Koenig ---
This looks like it does the trick (test case passes):
Index: trans-types.c
===
--- trans-types.c (Revision 269260)
+++ trans-types.c
If get_target_expr_sfinae gets an expression whose type is incomplete, it's
upset. digest_init returns error_mark_node if it gets an expression with
incomplete type, so we need to respect that, and not call
get_target_expr_sfinae on ORIG_CL in that case.
Bootstrapped/regtested on x86_64-linux,
On 2/28/19 10:05 AM, Qing Zhao wrote:
> Hi,
>
> I have been debugging a runtime error caused by value range propagation. and
> finally located to the following gcc routine:
>
> vrp_meet_1 in gcc/tree-vrp.c
>
>
> /* Meet operation for value ranges. Given two value ranges VR0 and
>VR1,
On 2/28/19 10:05 AM, Qing Zhao wrote:
> Hi,
>
> I have been debugging a runtime error caused by value range propagation. and
> finally located to the following gcc routine:
>
> vrp_meet_1 in gcc/tree-vrp.c
>
>
> /* Meet operation for value ranges. Given two value ranges VR0 and
>VR1,
On Thu, Feb 28, 2019 at 02:33:37PM -0500, Jason Merrill wrote:
> On 2/28/19 2:00 PM, Marek Polacek wrote:
> > Here we issued the "invalid use of non-static member function" error with
> > UNKNOWN_LOCATION, which merely shows "cc1plus" and no file/line. We can
> > greatly improve this situation
On 2/28/19 2:00 PM, Marek Polacek wrote:
Here we issued the "invalid use of non-static member function" error with
UNKNOWN_LOCATION, which merely shows "cc1plus" and no file/line. We can
greatly improve this situation with the below.
The patch is IMHO trivial (though it's user-provided) to go
Hi!
While looking for something else -- isn't that always how it happens ;-)
-- I noticed one thing here:
On Wed, 25 Jun 2014 01:41:02 +0200, FX wrote:
> I’ll wait a few more days to commit, so others can comment/review and I am
> sure to be around if there is fallout.
(This got committed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #18 from Jakub Jelinek ---
We do take the range as granted in both cases. If for BIT_NOT_EXPR on say int
the result is -2 or -1, then your TREE_INT_CST_LOW fix would DTRT, sure. If
the result is any other value, then we run into
> So it looks to me that the assert has to allow this. I've bootstrapped the
> following (not that it matters much as it simply relaxes the assert) and
> verified it fixes the testcase.
Yes, fallthrough edges to the exit block exist in RTL, see could_fall_through.
> OK for trunk?
>
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #17 from Eric Botcazou ---
> How is BIT_NOT_EXPR expanded for the prec > 1 BOOLEAN_TYPEs btw? If it is
> normal QImode or SImode etc. one's complement, then I'd say it is a bug if
> match.pd generates such BIT_NOT_EXPRs.
No idea
32-bit indices in VSIB address are sign-extended to 64 bits. In x32,
when 32-bit indices are used as addresses, like in
vgatherdps %ymm7, 0(,%ymm9,1), %ymm6
32-bit indices, 0xf7fa3010, is sign-extended to 0xf7fa3010 which
is invalid address. Add addr32 prefix to UNSPEC_VSIBADDR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #16 from Eric Botcazou ---
> So, for BIT_AND_EXPR we only handle the case where the result of
> BIT_AND_EXPR is known to be non-zero. That means both operands have to be
> non-zero (and have at least one common bit). Now, if say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #15 from Jakub Jelinek ---
How is BIT_NOT_EXPR expanded for the prec > 1 BOOLEAN_TYPEs btw? If it is
normal QImode or SImode etc. one's complement, then I'd say it is a bug if
match.pd generates such BIT_NOT_EXPRs.
Here we issued the "invalid use of non-static member function" error with
UNKNOWN_LOCATION, which merely shows "cc1plus" and no file/line. We can
greatly improve this situation with the below.
The patch is IMHO trivial (though it's user-provided) to go in even at
this point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #14 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #12)
> > Adding integer_onep wouldn't be
> > correct IMHO, if you have some non-boolean non-prec==1 integral type, even
> > if you know rhs has range [0, 1], if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #13 from Eric Botcazou ---
> On the testcase, value is -2 and before your change it would derive
> correctly that if BIT_NOT_EXPR is -2, then rhs must be ~-2, i.e. 1, but
> after the patch it says rhs must be 0.
The oversight is
__attribute__ ((target("arch=broadwell"))) should enable AVX with -mavx
at command-line. When we apply target attribute, we need to clear
x_ix86_isa_flags_explicit and x_ix86_isa_flags2_explicit, which are
turned on at command-line, so that target features will be enabled.
mv17.C has a version
On Thu, 28 Feb 2019, Alexander Monakov wrote:
> Hi,
>
> in PR 85899 an assert is failing in find_fallthru_edge_from because the code
> tries to verify the invariant e->dest == e->src->next_bb for a fallthru edge
> and does not anticipate that it will fail if e->dest is the exit block (bb 1):
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #12 from Eric Botcazou ---
> On the testcase, value is -2 and before your change it would derive
> correctly that if BIT_NOT_EXPR is -2, then rhs must be ~-2, i.e. 1, but
> after the patch it says rhs must be 0.
Right, an annoying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #11 from Jakub Jelinek ---
The [0, 1] range in that case (if not boolean or prec==1) is not the property
of the type, but just that optimizations figured out the SSA_NAME will not have
other values. In tree-ssa-dom.c it goes in the
From: Claudiu Zissulescu
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc-c.def (__ARC_UNALIGNED__): Set it on
unaligned_access variable.
* config/arc/arc.c (arc_override_options): Set unaligned access
default on for HS CPUs.
* config/arc/arc.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #10 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #9)
> > Then I don't understand the problem in the BIT_NOT_EXPR case: we have int
> > type and [0, 1] range for rhs; if we know that BIT_NOT_EXPR is zero, we can
> >
Hi,
in PR 85899 an assert is failing in find_fallthru_edge_from because the code
tries to verify the invariant e->dest == e->src->next_bb for a fallthru edge
and does not anticipate that it will fail if e->dest is the exit block (bb 1):
in this case next_bb is fairly arbitrary (it's just the next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #9 from Eric Botcazou ---
> Then I don't understand the problem in the BIT_NOT_EXPR case: we have int
> type and [0, 1] range for rhs; if we know that BIT_NOT_EXPR is zero, we can
> deduce that it must be 1 too.
So the problem is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #8 from Eric Botcazou ---
> Isn't that different though? I mean, even if we have int type and have [0,
> 1] range and have a check that the value isn't 0, then it must be 1.
Then I don't understand the problem in the BIT_NOT_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
Jakub Jelinek changed:
What|Removed |Added
Attachment #45856|0 |1
is obsolete|
1 - 100 of 195 matches
Mail list logo
