On Thu, Mar 14, 2019 at 1:28 AM Jakub Jelinek wrote:
>
> On Tue, Mar 12, 2019 at 09:36:32AM +0800, H.J. Lu wrote:
> > PR target/89650
> > * config/i386/i386.c (remove_partial_avx_dependency): Handle
> > REG_EH_REGION note.
> >
> > gcc/testsuite/
> >
> > PR target/89650
> >
Ok. Got it. And I will add some cases.
Thanks,
Feng
From: Kyrill Tkachov
Sent: Wednesday, March 13, 2019 5:40:37 PM
To: Feng Xue OS; Richard Biener
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Loop split upon semi-invariant condition (PR
On 3/13/19 6:37 PM, Jakub Jelinek wrote:
Hi!
When a variable template (both static data member of some class or at
namespace level) is accessed without template arguments,
finish_id_expression_1 handles it through:
/* If we didn't find anything, or what we found was a type,
then this
On 3/13/19 6:20 PM, Jakub Jelinek wrote:
On Mon, Mar 11, 2019 at 11:21:00PM +0100, Jakub Jelinek wrote:
The following testcase ICEs since my recent cxx_eval_loop_expr changes.
The problem is that the Forget saved values of SAVE_EXPRs. inside of the
loop can remove SAVE_EXPRs from new_ctx.values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89711
Bug ID: 89711
Summary: ICE in insert_vi_for_tree, at
tree-ssa-structalias.c:2832
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89710
Bug ID: 89710
Summary: ICE in dyn_cast(gimple*) /
should_duplicate_loop_header_p
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84396
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89688
Martin Sebor changed:
What|Removed |Added
Keywords||patch
See Also|
PR 89688 points out a bogus warning about an unterminated
character array argument to strlen. The root cause is
an oversight in the transformation of braced initializer lists
to STRING_CSTs where the solution implemented last summer only
considers one-dimensional arrays and skips more complex
On 3/13/19 10:08 PM, Jason Merrill wrote:
On 3/11/19 6:21 PM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs since my recent cxx_eval_loop_expr changes.
The problem is that the Forget saved values of SAVE_EXPRs. inside of the
loop can remove SAVE_EXPRs from new_ctx.values and if that is
On 3/11/19 6:21 PM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs since my recent cxx_eval_loop_expr changes.
The problem is that the Forget saved values of SAVE_EXPRs. inside of the
loop can remove SAVE_EXPRs from new_ctx.values and if that is the last
iteration, we can also do the loop
On Wed, 13 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> The C FE sadly passes through some really bad prototypes of builtin
> functions as "harmless":
> /* Accept "harmless" mismatches in function types such
> as missing qualifiers or pointer vs same size integer
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80604
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi Kelvin,
On Wed, Mar 13, 2019 at 04:43:35PM -0500, Kelvin Nilsen wrote:
[ snip ]
This looks great, thanks! Okay for trunk. A few more comments, do
with it as you like:
> (altivec_expand_vec_ext_builtin): Use modular arithmetic to
> computer index.
s/computer/compute/
> @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
--- Comment #8 from Jason Merrill ---
Author: jason
Date: Wed Mar 13 23:34:51 2019
New Revision: 269667
URL: https://gcc.gnu.org/viewcvs?rev=269667=gcc=rev
Log:
PR c++/86521 - C++17 copy elision in initialization by constructor.
This
This is an overlooked case in C++17 mandatory copy elision: We want overload
resolution to reflect that initializing an object from a prvalue does not
involve a copy or move constructor even when [over.match.ctor] says that
only constructors are candidates. Here I implement that by looking
On Thu, Mar 14, 2019 at 12:18:08AM +0100, Thomas Koenig wrote:
> Am 13.03.19 um 23:55 schrieb Steve Kargl:
> > On Wed, Mar 13, 2019 at 11:48:12PM +0100, Thomas Koenig wrote:
> >> Hello world,
> >>
> >> this doc patch adds the Q edit descriptor to the non-implemented
> >> extension list. Tested
Am 13.03.19 um 23:55 schrieb Steve Kargl:
On Wed, Mar 13, 2019 at 11:48:12PM +0100, Thomas Koenig wrote:
Hello world,
this doc patch adds the Q edit descriptor to the non-implemented
extension list. Tested with "make dvi", "make pdf" and "make info".
Suggestions? OK for trunk?
How about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #8 from Martin Jambor ---
Created attachment 45964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45964=edit
x86_64 testcase
It took me four or five evenings and is quite fragile, but finally I have an
x86_64-linux testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88588
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
On Wed, Mar 13, 2019 at 11:48:12PM +0100, Thomas Koenig wrote:
> Hello world,
>
> this doc patch adds the Q edit descriptor to the non-implemented
> extension list. Tested with "make dvi", "make pdf" and "make info".
>
> Suggestions? OK for trunk?
How about asttaching the patch? :-)
In all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89709
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89709
--- Comment #1 from Jakub Jelinek ---
Started with r267272.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89709
Volker Reichelt changed:
What|Removed |Added
Target Milestone|--- |9.0
gcc@gcc.gnu.org：
sSQxub电、微 1 3 7 =2 4 3 2= 0 0 7 7 刘NcO
jfiC
06时52分49秒
Hello world,
this doc patch adds the Q edit descriptor to the non-implemented
extension list. Tested with "make dvi", "make pdf" and "make info".
Suggestions? OK for trunk?
Regards
Thomas
Hi!
The C FE sadly passes through some really bad prototypes of builtin
functions as "harmless":
/* Accept "harmless" mismatches in function types such
as missing qualifiers or pointer vs same size integer
mismatches. This is for the ffs and fprintf builtins.
Hi!
When a variable template (both static data member of some class or at
namespace level) is accessed without template arguments,
finish_id_expression_1 handles it through:
/* If we didn't find anything, or what we found was a type,
then this wasn't really an id-expression. */
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89709
Bug ID: 89709
Summary: [9 Regression] ICE with constexpr and "-O"
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> The dump-tree looks funny: it appears that in the last test
>
> print *, "Associated contents?", associated(p1%string, p2%string)
>
> the association is
On Wed, 13 Mar 2019, Richard Biener wrote:
> And that fortran support patch would need yet another iteration.
Fortran never uses the _finite names because it never uses the C header
that can declare the functions to use those asm names.
--
Joseph S. Myers
jos...@codesourcery.com
Hi!
create_dispatcher_calls iterates over ipa_ref *s referring the current node
and wants to remove them all and create new ones. The problem is
that if there are any ipa_ref objects where two or more of them are from the
same cgraph node to the current node (in the testcases there are both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89708
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700
--- Comment #3 from Jonathan Wakely ---
You're mistaken.
struct X
{
std::string str = "not empty";
X() = default;
X(const X&) = default;
};
This type does not have a move constructor. Copying an rvalue will perform a
copy (not a move):
On Mon, Mar 11, 2019 at 11:21:00PM +0100, Jakub Jelinek wrote:
> The following testcase ICEs since my recent cxx_eval_loop_expr changes.
> The problem is that the Forget saved values of SAVE_EXPRs. inside of the
> loop can remove SAVE_EXPRs from new_ctx.values and if that is the last
> iteration,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673
--- Comment #13 from Thomas Koenig ---
Author: tkoenig
Date: Wed Mar 13 22:15:33 2019
New Revision: 269666
URL: https://gcc.gnu.org/viewcvs?rev=269666=gcc=rev
Log:
2019-03-13 Thomas Koenig
PR fortran/87673
Backport from
Am 13.03.19 um 18:50 schrieb Thomas Schwinge:
There are many ways to deal with it without bumping MOD_VERSION in a
backwards but not forwards compatible way, so that a newer compiler will be
able to parse old *.mod files, and newer compiler new ones as long as this
problematic stuff doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673
--- Comment #12 from Thomas Koenig ---
Author: tkoenig
Date: Wed Mar 13 22:05:59 2019
New Revision: 269665
URL: https://gcc.gnu.org/viewcvs?rev=269665=gcc=rev
Log:
2019-03-13 Thomas Koenig
PR fortran/87673
Backport from
An initial draft patch was distributed on 3/8/19. Thanks Segher for careful
review and detailed feedback. This second draft patch differs from the first
in the following regards:
1. Simplified dg directives in the new tests cases:
a) Removed { target { powerpc*-*-* } } from dg-do run
Committed as r269664.
Thanks for the review!
Harald
On 03/13/19 01:41, Steve Kargl wrote:
> On Sun, Mar 10, 2019 at 10:19:03PM +0100, Harald Anlauf wrote:
>> The code in the testcase died due to a run-time bounds-check
>> generated slightly too early, leading to a crash for deferred
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045
--- Comment #4 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Wed Mar 13 21:33:27 2019
New Revision: 269664
URL: https://gcc.gnu.org/viewcvs?rev=269664=gcc=rev
Log:
2019-03-13 Harald Anlauf
PR fortran/87045
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68138
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438
John David Anglin changed:
What|Removed |Added
Last reconfirmed|2018-07-09 00:00:00 |2019-3-13
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88990
--- Comment #1 from Iain Buclaw ---
Doesn't look like invalid code, but 'extern' is propagated erroneously to all
declarations inside the block, even paraneters, which is why the ICE occurs.
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 269662 to trunk and as rev. 269663 to gcc-8-branch.
Index: ChangeLog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705
--- Comment #4 from Marek Polacek ---
Same with int:
struct W { operator const int(); };
int&& i = W();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Mar 13 20:44:50 2019
New Revision: 269663
URL: https://gcc.gnu.org/viewcvs?rev=269663=gcc=rev
Log:
2019-03-13 Vladimir Makarov
PR target/85860
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79651
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
--- Comment #6 from Vladimir Makarov ---
Author: vmakarov
Date: Wed Mar 13 20:35:18 2019
New Revision: 269662
URL: https://gcc.gnu.org/viewcvs?rev=269662=gcc=rev
Log:
2019-03-13 Vladimir Makarov
PR target/85860
*
On Wed, Mar 13, 2019 at 11:39 AM Andrew Burgess
wrote:
> gcc/ChangeLog:
>
> PR target/89627
> * config/riscv/riscv.c (riscv_pass_fpr_single): Add offset
> parameter, and make use of it.
> (riscv_get_arg_info): Pass offset to riscv_pass_fpr_single.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89708
Bug ID: 89708
Summary: printf and std::byte
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Wed Mar 13 20:22:15 2019
New Revision: 269661
URL: https://gcc.gnu.org/viewcvs?rev=269661=gcc=rev
Log:
PR debug/89498
* dwarf2out.c (size_of_die): For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89707
Bug ID: 89707
Summary: [F03] PDT with procedure pointer component
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89660
Marek Polacek changed:
What|Removed |Added
Keywords||rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89660
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Wed Mar 13 20:04:33 2019
New Revision: 269660
URL: https://gcc.gnu.org/viewcvs?rev=269660=gcc=rev
Log:
PR c++/89660 - bogus error with -Wredundant-move.
* typeck.c
On Wed, Mar 13, 2019 at 11:53 AM Andrew Pinski wrote:
> This testcase seems generic, that is it has no ABI dependent values
> attached to it.
> Can it be moved to a more generic location instead? Maybe there are
> other targets which get this incorrect also.
I'm not aware of any other target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89686
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
--- Comment #11 from dave.anglin at bell dot net ---
On 2019-03-13 4:09 a.m., rguenth at gcc dot gnu.org wrote:
> So it's a target issue, not a debug one. Of course we could avoid generating
> wrong-debug by generating none whenever the argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89686
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Wed Mar 13 19:58:20 2019
New Revision: 269659
URL: https://gcc.gnu.org/viewcvs?rev=269659=gcc=rev
Log:
PR c++/89686 - mixing init-capture and simple-capture in lambda.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #11 from Khang H. Nguyen ---
That is cool with me if you think it that way.
But I don't think you would be very happy parsing " 123 4" and still get the
same result as "1234". Or if you were to give it a blank string and get 0 where
On 3/11/19 6:56 PM, Marek Polacek wrote:
My recent patch caused us to call convert_for_initialization for a std:move's
argument to see if it would have succeeded had the returned expression been
just that argument.
That caused a bogus error in this test, because convert_for_initialization
might
I have just committed the updated patch to trunk as r269658. If anyone
thinks this should be backported to 8-branch, please let me know.
Cheers,
Janus
Am Di., 12. März 2019 um 13:00 Uhr schrieb Janus Weil :
>
> Hi Steve,
>
> > > Technically the ICE is a regression, but since it happens on
On 3/12/19 7:51 AM, Jakub Jelinek wrote:
On Mon, Mar 04, 2019 at 11:35:50PM +0100, Jakub Jelinek wrote:
2019-03-04 Jakub Jelinek
PR debug/89498
* dwarf2out.c (size_of_die): For dw_val_class_view_list always use
DWARF_OFFSET_SIZE.
(value_format): For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89706
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
On 3/13/19 3:32 PM, Marek Polacek wrote:
On Wed, Mar 13, 2019 at 02:15:25PM -0400, Jason Merrill wrote:
On 3/12/19 5:42 PM, Marek Polacek wrote:
On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote:
On 3/12/19 3:59 PM, Marek Polacek wrote:
As Barry explained in the PR, lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601
--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Mar 13 19:52:23 2019
New Revision: 269658
URL: https://gcc.gnu.org/viewcvs?rev=269658=gcc=rev
Log:
fix PR 89601
2019-03-13 Janus Weil
PR fortran/89601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #10 from Steve Kargl ---
On Wed, Mar 13, 2019 at 07:36:10PM +, kevin at fai dot host wrote:
>
> --- Comment #9 from Khang H. Nguyen ---
> No, no, you got me wrong, it is not a tutorial. You got it wrong.
> I just see so much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #9 from Khang H. Nguyen ---
No, no, you got me wrong, it is not a tutorial. You got it wrong. I just see so
much insecure with the statement read, of which I think it more like a
procedure. That is why I am trying to report the bug.
On Wed, Mar 13, 2019 at 02:15:25PM -0400, Jason Merrill wrote:
> On 3/12/19 5:42 PM, Marek Polacek wrote:
> > On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote:
> > > On 3/12/19 3:59 PM, Marek Polacek wrote:
> > > > As Barry explained in the PR, lambda capture is one of
> > > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #8 from Steve Kargl ---
On Wed, Mar 13, 2019 at 07:17:42PM +, kevin at fai dot host wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
>
> --- Comment #6 from Khang H. Nguyen ---
> Sorry, if I am wasting your time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705
--- Comment #3 from Jakub Jelinek ---
Started to be rejected in r209521 with:
error: invalid initialization of reference of type ‘E&&’ from expression of
type ‘S’
(before accepted).
Started to ICE with r210436.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #7 from Steve Kargl ---
On Wed, Mar 13, 2019 at 07:09:19PM +, kevin at fai dot host wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
>
> --- Comment #5 from Khang H. Nguyen ---
> > program foo
> > integer i
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #6 from Khang H. Nguyen ---
Sorry, if I am wasting your time.
I just have an addition to add to the above.
If you use formatting. For example, in a case like this below, it will not give
a correct value, as now leading spaces will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #5 from Khang H. Nguyen ---
> program foo
> integer i
> read(*,*) i
> read(*,'(I4)') i
> end program foo
>
> % gfcx -o z a.f90
> % ./z
> % ./z
> 12 b
> 12 b
> At line 4 of file a.f90 (unit = 5, file = 'stdin')
> Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89703
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89706
Bug ID: 89706
Summary: -Wstringop-truncation strncpy message is confusing and
has psuedo-false-positives
Product: gcc
Version: 9.0
Status: UNCONFIRMED
On Wed, Mar 13, 2019 at 11:40 AM Andrew Burgess
wrote:
>
> Jim,
>
> Sorry for the delay in sending this patch.
>
> Thanks,
> Andrew
>
> ---
>
> This fixes PR target/89627.
>
> The RISC-V ABI document[1] says:
>
>For the purposes of this section, "struct" refers to a C struct
>with its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656
--- Comment #12 from John David Anglin ---
Created attachment 45962
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45962=edit
Tree dump
For
FAIL: gcc.dg/ipa/ipa-icf-38.c scan-ltrans-tree-dump-not optimized "Function
bar"
on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69807
--- Comment #2 from John David Anglin ---
Created attachment 45961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45961=edit
.graphite file
gcc-9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Jim,
Sorry for the delay in sending this patch.
Thanks,
Andrew
---
This fixes PR target/89627.
The RISC-V ABI document[1] says:
For the purposes of this section, "struct" refers to a C struct
with its hierarchy flattened, including any array fields. That is,
struct { struct { float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Wed Mar 13 18:38:45 2019
New Revision: 269656
URL: https://gcc.gnu.org/viewcvs?rev=269656=gcc=rev
Log:
PR c++/88979 - further P0634 fix for constructors.
* parser.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
On Wed, Mar 13, 2019 at 02:32:36PM -0400, Jason Merrill wrote:
> On 3/13/19 1:25 PM, Marek Polacek wrote:
> > This PR points out that our P0634 implementation misses constructor
> > parameters
> > and still requires 'typename'. I'm not 100% sure if the standard really
> > says
> > we should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48957
--- Comment #4 from joseph at codesourcery dot com ---
Well, I suppose you could have a new option to say what set of fixed
headers to use, in the case where your sysroot is not based on the one
used when building GCC.
On 3/13/19 1:25 PM, Marek Polacek wrote:
This PR points out that our P0634 implementation misses constructor parameters
and still requires 'typename'. I'm not 100% sure if the standard really says
we should also handle constructors. Does a constructor have a function type?
Not that we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700
Igor Klevanets changed:
What|Removed |Added
CC||cerevra at yandex dot ru
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42689
Joseph S. Myers changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 42689, which changed state.
Bug 42689 Summary: bad formatting of specs diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42689
What|Removed |Added
On 3/12/19 5:42 PM, Marek Polacek wrote:
On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote:
On 3/12/19 3:59 PM, Marek Polacek wrote:
As Barry explained in the PR, lambda capture is one of
simple-capture ...[opt]
...[opt] init-capture
where init-capture requires an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705
--- Comment #2 from Marek Polacek ---
Started with r210436.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89667
--- Comment #2 from joseph at codesourcery dot com ---
Or if for some reason you need an array of pointers to writable strings,
you can use e.g. (char []) { "foo" }, a compound literal, as the
initializer for such a pointer, instead of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89703
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89696
--- Comment #3 from Khang H. Nguyen ---
Sorry, I just have one more quick question.
Bug 1:
Nonetheless, for read(), I was just wondering, if you read from a list input
then it should be like that.
However, if it is just a raw string and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 11 Mar 2019, rguenth at gcc dot gnu.org wrote:
> > I wouldn't expect such a cast to be generated on the result of the
> > multiplication; I'd expect long double to be converted
1 - 100 of 233 matches
Mail list logo
