https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
Qirun Zhang changed:
What|Removed |Added
CC||qrzhang at gatech dot edu
--- Comment #8
在 2019/3/21 下午1:06, Bin.Cheng 写道:
On Thu, Mar 21, 2019 at 12:57 PM JunMa wrote:
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)
It tries to avoid folding out of string length although length of a is 5.
This is a bit conservative, it's
On Thu, Mar 21, 2019 at 12:57 PM JunMa wrote:
>
> Hi
> For now, gcc can not fold code like:
>
> const char a[5] = "123"
> __builtin_memchr (a, '7', sizeof a)
>
> It tries to avoid folding out of string length although length of a is 5.
> This is a bit conservative, it's safe to folding
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)
It tries to avoid folding out of string length although length of a is 5.
This is a bit conservative, it's safe to folding memchr/bcmp/memcmp
builtins when constant string stores in array with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #16 from Eric Gallager ---
(In reply to Iain Sandoe from comment #15)
> FWIW I had a quick look the other day if there was an easy fix to this PR,
> and didn't find a '5 minute' one.
>
> (In reply to Eric Gallager from comment #14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243
Eric Gallager changed:
What|Removed |Added
Summary|FSF needs to use xcrun on |FSF GCC needs to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88838
--- Comment #5 from kugan at gcc dot gnu.org ---
Created attachment 46000
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46000=edit
RFC patch
RFC patch fixes this for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89782
Bug ID: 89782
Summary: Can do an internal READ of a character array when it
is a parameter, but not a scalar character parameter
Product: gcc
Version: 7.3.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89783
Bug ID: 89783
Summary: Can do an internal READ of a character array when it
is a parameter, but not a scalar character parameter
Product: gcc
Version: 7.3.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89766
--- Comment #10 from Rimvydas (RJ) ---
Using 9.0.1 20190319 as reference several ICE cases reduce down to the same
snippet (regression on trunk)?
$ cat trunk_accepts_invalid.ii
class a {
constexpr a();
};
template struct b { static constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89781
Bug ID: 89781
Summary: Misleading error messages when initializing a static
data member in-class
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
On 3/20/19 5:25 AM, Paulo Matos wrote:
I am working on trying to get RISC-V 32 emitting sibcalls even in the
present of `-msave-restore`, for a client concerned with generated code
size.
This won't work unless you define a new set of restore functions. The
current ones restore the return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571
--- Comment #11 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Mar 21 01:03:30 2019
New Revision: 269832
URL: https://gcc.gnu.org/viewcvs?rev=269832=gcc=rev
Log:
/cp
2019-03-21 Paolo Carlini
PR c++/89571
*
More pings!
On Fri, Mar 08, 2019 at 09:56:05AM +, co...@sdf.org wrote:
> Ping.
>
> Link for possible convenience :-)
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01899.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89779
--- Comment #2 from Sunil Pandey ---
Reduced test:
$ cat x.i
typedef a;
c(a *d, int b) {
int e, f, g;
for (; e; e++)
for (f = 0; f < 4; f++)
if (d)
for (g = e + 1; g; g++)
h(d[g]);
}
i() {
a *j;
int k, l;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89017
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89017
--- Comment #2 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Mar 20 23:52:48 2019
New Revision: 269828
URL: https://gcc.gnu.org/viewcvs?rev=269828=gcc=rev
Log:
d: Fix ICE force_type_die, at dwarf2out.c using nested types
In
Hi,
This patch adds a new visit method in the decl walker to handle
functions whose return type is instantiated from a nested template (a
voldemort type), as it needs to be ensured that all members of the
instance are emitted before finishing the outer function, otherwise
they will be removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780
Bug ID: 89780
Summary: -Wpessimizing-move is too agressive with templates and
recommends pessimization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89779
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89779
Bug ID: 89779
Summary: [9 Regression] internal compiler error: tree check:
expected class ‘type’, have ‘exceptional’ (error_mark)
in tree_nop_conversion_p, at tree.c:12798
Hi!
As mentioned in the PR, if e.g. build_aligned_type creates some specially
aligned variant of some TYPE_MAIN_VARIANT, that type doesn't appear in the
IL during free_lang_data and later on we call build_aligned_type with the
same arguments as before, we'll get the previously created aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797
--- Comment #5 from Dominique d'Humieres ---
> Revised patch that also addresses PR83515:
The patch fixes the ICE. Compiling the tests z2.f90 or z3.f90 gives the error
2 |c = transfer(a, a)
| 1
Error: Cannot convert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to DIL from comment #14)
> Ok, so you are still looking for a single Fortran source file using this
> feature, namely optional dummy procedure pointers, that would do something
>
The PRs originated in gfc_element_size lacking a treatment of
procedure pointers, which has been added. The testcase is currently
a pure compile test. When a reduced run-time test for PR83515
becomes available, it will be added to the testsuite.
Regtested on x86_64-pc-linux-gnu.
OK for trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #6)
>
> That said, if you can handle it in the RA, it could handle even those
> variable shift cases better (just make sure it doesn't overlap ecx, but
> otherwise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #14 from DIL ---
(In reply to anlauf from comment #13)
> (In reply to Dominique d'Humieres from comment #12)
> > > Sorry, I am confused, I think Comment 1 already has such a reduced test.
> > > At least the what it says there ...
> >
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
> > On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
> > > On Mar 20, 2019, Marek Polacek wrote:
> > >
> > > > This test fails with
> > > >
On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
> On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
> > On Mar 20, 2019, Marek Polacek wrote:
> >
> > > This test fails with
> > > pr88534.C:58:1: sorry, unimplemented: string literal in function template
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676
--- Comment #6 from Jakub Jelinek ---
I wonder if in this case the instruction couldn't replace the current = 0n Ic
constraints e.g. with =r, 0n,0n I,c because if the shift count is constant,
then I don't see the point of early-clobber, if the
On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
> On Mar 20, 2019, Marek Polacek wrote:
>
> > This test fails with
> > pr88534.C:58:1: sorry, unimplemented: string literal in function template
> > signature
>
> Interesting... gcc-8 rejected it with an error message rejecting
On Wed, Mar 20, 2019 at 05:32:16PM -0400, Jason Merrill wrote:
> > Does this look reasonable, or do you have other proposals?
>
> IMO if you need to guard usage with
>
> + if (some_type_hash_table.size () == 0)
> + some_type_hash_table.create ();
>
> this isn't any better than
>
>
On 3/20/19 4:50 PM, Paolo Carlini wrote:
Hi Jason ---
On 17/03/19 21:06, Jason Merrill wrote:
Earlier changes to defer instantiating a defaulted noexcept-specifier
that
depends on yet-unparsed default member initializers broke this testcase,
where instantiation fails for another reason. In
Am Mi., 20. März 2019 um 18:26 Uhr schrieb Thomas Koenig
:
>
> Hi Janus,
>
> > the attached one-line patch fixes an ICE-on-invalid regression with
> > abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for
> > trunk and the release branches (7 and 8)?
>
> OK for all.
Thanks, Thomas.
On 3/20/19 1:12 PM, Jakub Jelinek wrote:
Already in the PR71446 patch I used ugly and slow code to avoid allocating
memory in a hash_set all the time, even when it will be used only rarely and
in PR89767 I've reached it again.
While e.g. a vec is POD that even doesn't have a constructor and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861
--- Comment #10 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Mar 20 21:32:23 2019
New Revision: 269827
URL: https://gcc.gnu.org/viewcvs?rev=269827=gcc=rev
Log:
fix PR 71861
2019-03-20 Janus Weil
PR fortran/71861
20190320-2-pstl-integration.patch.bz2
Description: Revised pstl integration patch
Fixed a failing test.
Thomas Rodgers writes:
> This time with the changelog reflecting the updated files in include/std
>
> Thomas Rodgers writes:
>
>> See attached.
>>
>> Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676
--- Comment #5 from Vladimir Makarov ---
I am working on it. It is a non-trivial problem. We should somehow exclude
creation of conflicts in lra-lives.c for an early clobber matched with an
input.
I hope to fix it this week.
20190320-1-pstl-integration.patch.bz2
Description: Revised pstl integration patch
This time with the changelog reflecting the updated files in include/std
Thomas Rodgers writes:
> See attached.
>
> Jonathan Wakely writes:
>
>> On 11/03/19 21:24 -0700, Thomas Rodgers w
Hi Jason ---
On 17/03/19 21:06, Jason Merrill wrote:
Earlier changes to defer instantiating a defaulted noexcept-specifier that
depends on yet-unparsed default member initializers broke this testcase,
where instantiation fails for another reason. In this case there's no
reason to defer and try
See attached.
20190320-pstl-integration.patch.bz2
Description: revised pstl integration patch
Jonathan Wakely writes:
> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>Let's try this patch -
>>
>
>
> The feature test macro should be 201603L (in and
> ):
Iain Buclaw writes:
> On Fri, 15 Mar 2019 at 16:50, Robin Dapp wrote:
>>
>> Hi,
>>
>> during the last few days I tried to get D running on s390x (apparently
>> the first Big Endian platform to try it?). I did not yet go through the
>> code systematically and add a version(SystemZ) in every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87480
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Wed Mar 20 20:31:40 2019
New Revision: 269826
URL: https://gcc.gnu.org/viewcvs?rev=269826=gcc=rev
Log:
PR c++/87480 - decltype of member access in default template arg
The issue
Ignore
Thomas Rodgers writes:
> Jonathan Wakely writes:
>
>> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>>Let's try this patch -
>>>
>>
>>
>> The feature test macro should be 201603L (in and
>> ):
>>
>> +// Feature test macro for parallel algorithms
>> +# define
The issue here is that declval().d is considered instantiation-dependent
within a template, as the access to 'd' might depend on the particular
specialization. But when we're deducing template arguments for a call, we
know that the call and the arguments are non-dependent, so we can do the
On Wed, 20 Mar 2019 at 22:15, Jakub Jelinek wrote:
>
> On Wed, Mar 20, 2019 at 09:13:42PM +0100, Jakub Jelinek wrote:
> > On Wed, Mar 20, 2019 at 01:05:10PM -0700, Thomas Rodgers wrote:
> > > > We only give that warning for C++11 headers, but for anything newer it
> > > > should be just:
> > > >
On Wed, Mar 20, 2019 at 09:13:42PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 20, 2019 at 01:05:10PM -0700, Thomas Rodgers wrote:
> > > We only give that warning for C++11 headers, but for anything newer it
> > > should be just:
> > >
> > > +#if __cplusplus >= 201703L
> >
> > Did you mean
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89778
--- Comment #2 from myLC at gmx dot net ---
(In reply to Jonathan Wakely from comment #1)
> I think this is a dup
>
> *** This bug has been marked as a duplicate of bug 45896 ***
Thank you, yes indeed. Although, the title
"[C++0x] Facet
On Wed, Mar 20, 2019 at 01:05:10PM -0700, Thomas Rodgers wrote:
> > We only give that warning for C++11 headers, but for anything newer it
> > should be just:
> >
> > +#if __cplusplus >= 201703L
>
> Did you mean
>
> +#if __cplusplus >= 201603L
I guess so:
The fix for 77656 caused us to call convert_nontype_argument even for
value-dependent arguments, to perform the conversion in order to avoid
a bogus warning.
In this case, the argument is Pod{N}. The call to build_converted_constant_expr
in convert_nontype_argument produces Pod::operator
On Wed, 20 Mar 2019 at 22:05, Thomas Rodgers wrote:
> > +#if __cplusplus < 201703L
> > +# include
> > +#else
> >
> > We only give that warning for C++11 headers, but for anything newer it
> > should be just:
> >
> > +#if __cplusplus >= 201703L
>
> Did you mean
>
> +#if __cplusplus >= 201603L
>
>
Jonathan Wakely writes:
> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>Let's try this patch -
>>
>
>
> The feature test macro should be 201603L (in and
> ):
>
> +// Feature test macro for parallel algorithms
> +# define __cpp_lib_parallel_algorithm 201703L
>
> ***
>
> The new files have
On Mar 20, 2019, Marek Polacek wrote:
> This test fails with
> pr88534.C:58:1: sorry, unimplemented: string literal in function template
> signature
Interesting... gcc-8 rejected it with an error message rejecting the
template parameter, but my latest trunk build (dated Mar 13, r269641)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896
Jonathan Wakely changed:
What|Removed |Added
CC||myLC at gmx dot net
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2010-10-05 17:57:04 |2019-3-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89778
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi Thomas,
based on your comments I'll withdraw the patch, but read on...
On 03/20/19 17:14, Thomas Koenig wrote:
> Hi Harald,
>
>> My reading of the standard suggests that this is not allowed:
>>
>>SOURCE shall be a scalar or array of any type.
>>
>>MOLD shall be a scalar or array of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89775
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89692
--- Comment #15 from Jakub Jelinek ---
Created attachment 45999
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45999=edit
gcc9-pr89692.patch
Untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145
--- Comment #7 from Marek Polacek ---
This fixes it. But is it the best fix?
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -8056,7 +8056,14 @@ convert_template_argument (tree parm,
t = canonicalize_type_argument (t, complain);
if
> "Segher" == Segher Boessenkool writes:
>> Section 6.2.5.2 outlines the line number information state machine's
>> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition
>> is:
Segher> How should this work with shrink-wrapping? The whole point of that is
Segher> you do not
On 2/26/19 6:32 PM, Martin Sebor wrote:
> Please disregard the original patch and consider the attached
> version instead.
>
> On 2/26/19 5:03 PM, Martin Sebor wrote:
>> The false positive in PR89350 is due to -Wstringop-overflow
>> trusting that the sizetype offset in POINTER_PLUS_EXPR means
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145
--- Comment #6 from Marek Polacek ---
Slightly different testcase:
struct S {
int val;
constexpr operator int() const {
return static_cast(val);
}
};
template
struct F { };
template
constexpr void foo() {
F f;
}
int
main()
{
> > > > "ggc_collect() discarding/reusing remap_debug_filename() output,
> > > > thus producing invalid objects"
> > >
> > > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd ()
> > > result survives. I vaguely remember GC being happy with heap
> > > strings (due to identifiers?),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #12 from Dominique d'Humieres ---
> Sorry, I am confused, I think Comment 1 already has such a reduced test.
> At least the what it says there ...
It is a reduced test for the ICE (as are further reduced tests in comments 3
and 9),
On Wed, 20 Mar 2019 at 12:27, Iain Buclaw wrote:
>
> On Wed, 20 Mar 2019 at 10:57, Robin Dapp wrote:
> >
> > Hi,
> >
> > the unicode tables in std.internal.unicode_tables are apparently auto
> > generated and loaded at (libphobos) compile time. They are also in
> > little endian format. Is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #11 from DIL ---
(In reply to Dominique d'Humieres from comment #10)
> With the patch in comment 8 all the tests compile and the original test in
> comment 0 gives ta runtime
>
> gfc::bank testing status:0 (PASSED):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89778
Bug ID: 89778
Summary: std::get_time : %d does not work without leading zeros
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Thanks, Pierre-Marie: it'd be a shame if 9.1 couldn't handle IPv4.
--S
> On 20 Mar 2019, at 13:31, Pierre-Marie de Rodat wrote:
>
> Hello Simon,
>
> On 3/19/19 5:02 PM, Simon Wright wrote:
>> Ping?
>
> Sorry for the delay! Thank you for the notice; I’ll try to get our fix ported
> as soon
On Wed, Mar 20, 2019 at 10:13:23AM +, Justin Paston-Cooper wrote:
> Section 6.2.5.2 outlines the line number information state machine's
> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition
> is:
>
> -
> The DW_LNS_set_epilogue_begin opcode takes no operands. It sets the
On 3/20/19 2:08 PM, Moritz Strübe wrote:
>
> Ok, I played around a bit. Interestingly, if I set
> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
> compiler detects that it will always trap, and optimizes the code
> accordingly (the code after the trap is removed).* Which kind of
>
Hi Janus,
the attached one-line patch fixes an ICE-on-invalid regression with
abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for
trunk and the release branches (7 and 8)?
OK for all.
Thanks for the patch!
Regards
Thomas
On 3/20/19 1:15 PM, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 11:10:19AM -0400, Nathan Sidwell wrote:
I was unclear. I was for the lazy creation of the hash. I just think it
can be lazily created at either the first or second explicit capture.
On top of the
On Wed, Mar 20, 2019 at 11:10:19AM -0400, Nathan Sidwell wrote:
> I was unclear. I was for the lazy creation of the hash. I just think it
> can be lazily created at either the first or second explicit capture.
On top of the https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00991.html
patch I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87808
David Malcolm changed:
What|Removed |Added
Summary|gcc_lib_dir is missing from |gcc_lib_dir is missing from
Hi!
Already in the PR71446 patch I used ugly and slow code to avoid allocating
memory in a hash_set all the time, even when it will be used only rarely and
in PR89767 I've reached it again.
While e.g. a vec is POD that even doesn't have a constructor and auto_vec
has quite a cheap ctor,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774
--- Comment #8 from Andrew Pinski ---
(In reply to Marius Messerschmidt from comment #7)
> Looks good, which options did you use?
-O2 -march=native (the last part was done as I wanted to get the fused
multiple-add but it is not needed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774
--- Comment #7 from Marius Messerschmidt ---
Looks good, which options did you use?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Fri, Mar 15, 2019 at 10:53:35AM -0300, Alexandre Oliva wrote:
> On Mar 14, 2019, Jason Merrill wrote:
>
> >> You can use VAR_P for this.
>
> > OK with that change.
>
> Thanks, I went ahead and also added a test before dereferencing it,
> since there was evidence shortly thereafter that it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89777
--- Comment #2 from Nick Savoiu ---
I was afraid that it would be resolved as such.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774
--- Comment #5 from Marius Messerschmidt ---
I did checkt the output without --fsingle-precision-constant
Is this only enabled via -fsingle-precision-constant or at any optimization
level?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774
Marius Messerschmidt changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Hi Harald,
My reading of the standard suggests that this is not allowed:
SOURCE shall be a scalar or array of any type.
MOLD shall be a scalar or array of any type. ...
I read the stanard differently. For comparison, look at UNPACK:
# VECTOR shall be a rank-one array of any type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89621
--- Comment #3 from Jakub Jelinek ---
In particular, what's going on here is that we have a pointer to VLA type,
remap it once on !$omp parallel (that is required, the decls are remapped in
that case) and once again on !$omp do (which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89621
--- Comment #2 from Jakub Jelinek ---
The problem is that tree-inline.c will remap variably_modified_type_p types
unconditionally.
I've tried:
--- gcc/tree-inline.c.jj2019-03-11 22:56:55.888667590 +0100
+++ gcc/tree-inline.c 2019-03-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89777
Andrew Pinski changed:
What|Removed |Added
Keywords|wrong-code |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89777
Bug ID: 89777
Summary: Any optimizaton level over -O0 causes crash in
dynamic_cast
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
On Wed, Mar 20, 2019 at 02:08:09PM +, Moritz Strübe wrote:
> Ok, I played around a bit. Interestingly, if I set -fsanitize=udefined and
> -fsanitize-undefined-trap-on-error the compiler detects that it will always
> trap, and optimizes the code accordingly (the code after the trap is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87808
--- Comment #4 from Matthias Klose ---
Understood, that I need binutils. However if you remove the driver (or rename
it on your system), then the debug output reads:
JIT:entering: virtual void
Hey.
Am 20.03.2019 um 15:26 schrieb Christophe Lyon:
You can -fsanitize-undefined-trap-on-error, which doesn't increase size too
much, it is less user-friendly, but still should catch the UB.
Wouldn't this fail to link? I thought the sanitizers need some runtime
libraries which are only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89774
Marius Messerschmidt changed:
What|Removed |Added
Resolution|WORKSFORME |FIXED
--- Comment #2 from Marius
Even if a global register is being clobbered in a function we usually
do not save and restore it. However, we still have to do this if it is
a special register. Most of the places in the backend handle this
correctly but not the prologue/epilogue optimization.
Bootstrapped and regression tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89775
--- Comment #2 from Andreas Krebbel ---
Author: krebbel
Date: Wed Mar 20 15:28:38 2019
New Revision: 269823
URL: https://gcc.gnu.org/viewcvs?rev=269823=gcc=rev
Log:
S/390: Fix PR89775. Stackpointer save/restore instructions removed
Even if a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89775
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
1 - 100 of 167 matches
Mail list logo
