Am 20.01.24 um 23:42 schrieb Alexander Westbrooks:
Based on what I am reading here, I can either do the DCO path or the copy
right form path? Or is it both, where I send in the copy right forms and
then on every commit I put the DCO?
I thought the text is pretty clear. As already mentioned,
Based on what I am reading here, I can either do the DCO path or the copy
right form path? Or is it both, where I send in the copy right forms and
then on every commit I put the DCO?
On Sat, Jan 20, 2024 at 3:40 PM Harald Anlauf wrote:
> Am 20.01.24 um 21:37 schrieb Jerry D:
> > On 1/20/24 12:08
Am 20.01.24 um 21:37 schrieb Jerry D:
On 1/20/24 12:08 PM, Harald Anlauf wrote:
Am 20.01.24 um 20:08 schrieb Jerry D:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance
On 1/20/24 12:08 PM, Harald Anlauf wrote:
Am 20.01.24 um 20:08 schrieb Jerry D:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander Westb
Am 20.01.24 um 20:08 schrieb Jerry D:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander Westbrooks
Inserting myself in here just a li
On 1/20/24 11:08 AM, Jerry D wrote:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander Westbrooks
Inserting myself in here just a li
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander Westbrooks
Inserting myself in here just a little bit. I will apply and test toda
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for GFortran.
Has anyone had a chance to review it?
Thanks,
Alexander Westbrooks
On Thu, Jun 29, 2023 at 10:38 PM Alexander Westbrooks
wrote:
> Hello,
>
> I have finished my testing, and updated my patch a
Hello,
I wanted to follow up on this, and ask what the next steps would be to
incorporate this patch?
Thanks,
Alexander Westbrooks
On Thu, Jun 29, 2023 at 10:38 PM Alexander Westbrooks
wrote:
> Hello,
>
> I have finished my testing, and updated my patch and relevant Changelogs.
> I added 4 n
Hi All,
I have gone through the PDT problem reports and made sure that they
block PR82173.
To my utter astonishment (i) There might be only one duplicate; and
(ii) Only 82649, 84119, 90218, 95541, 99079, 102901 & 105380 (out of
50 PRs) depend on the representation.
Regards
Paul
Hi Alexander,
I suggest that you take a look at PR82649 before going too far down
the road of fixing PDT bugs. This PR underlines just how wrong the PDT
representation is - mea culpa!
The mechanics for constructing PDTs are in
decl.cc(gfc_get_pdt_instance). They need to be turned inside out to
cr
On Thu, Jun 29, 2023 at 10:38:42PM -0500, Alexander Westbrooks via Fortran
wrote:
> I have finished my testing, and updated my patch and relevant Changelogs. I
> added 4 new tests and all the existing tests in the current testsuite
> for gfortran passed or failed as expected. Do I need to attach t
Hello,
I have finished my testing, and updated my patch and relevant Changelogs. I
added 4 new tests and all the existing tests in the current testsuite
for gfortran passed or failed as expected. Do I need to attach the test
results here?
The platform I tested on was a Docker container running in
Hi Alex,
welcome to the gfortran community. It is great that you are trying
to get actively involved.
You already did quite a few things right: patches shall be sent to
the gcc-patches ML, but Fortran reviewers usually notice them only
where they are copied to the fortran ML.
There are some ge
Hello,
I am new to the GFortran community. Over the past two weeks I created a
patch that should fix PR82943 for GFortran. I have attached it to this
email. The patch allows the code below to compile successfully. I am
working on creating test cases next, but I am new to the process so it may
take
Ping
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613640.html
Richard Sandiford writes:
> This series of patches fixes PR106594, an aarch64 regression in which
> we fail to combine an extension into an address. The first patch just
> refactors code. The second patch contains the actual
This series of patches fixes PR106594, an aarch64 regression in which
we fail to combine an extension into an address. The first patch just
refactors code. The second patch contains the actual fix.
The cover note for the second patch describes the problem and the fix.
Tested on aarch64-linux-gn
On 2/11/23 22:14, Gerald Pfeifer wrote:
On Sat, 11 Feb 2023, NightStrike wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
I would have expected the PR to have been automatically updated based on
the commit email. Any idea why that didn't happen? Not to change the state
to closed, but
On Sat, 11 Feb 2023, NightStrike wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
> I would have expected the PR to have been automatically updated based on
> the commit email. Any idea why that didn't happen? Not to change the state
> to closed, but to add the commit information as
On Sat, Feb 11, 2023 at 3:52 AM Gerald Pfeifer wrote:
>
> On Sat, 11 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> >> could you please close the corresponding BR too?:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
> > I can't close it, but I put a note that it has been committed.
>
>
On 2/11/23 08:52, Gerald Pfeifer wrote:
On Sat, 11 Feb 2023, Jonathan Yong via Gcc-patches wrote:
could you please close the corresponding BR too?:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
I can't close it, but I put a note that it has been committed.
I closed the report.
Gerald
On Sat, 11 Feb 2023, Jonathan Yong via Gcc-patches wrote:
>> could you please close the corresponding BR too?:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
> I can't close it, but I put a note that it has been committed.
I closed the report.
Gerald
On 2/11/23 07:28, i.nix...@autistici.org wrote:
Thank you Jonathan!
could you please close the corresponding BR too?:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
best!
I can't close it, but I put a note that it has been committed.
On 2023-02-11 06:32, Jonathan Yong wrote:
On 2/6/23 06:40, Jonathan Yong wrote:
On 1/18/23 10:44, i.nixman--- via Gcc-patches wrote:
hello again!
the final version of the path for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
successfully bootstraped for x86_64-mingw32 and x86_64-linu
On 2/6/23 06:40, Jonathan Yong wrote:
On 1/18/23 10:44, i.nixman--- via Gcc-patches wrote:
hello again!
the final version of the path for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
successfully bootstraped for x86_64-mingw32 and x86_64-linux.
could anyone apply it please?
best!
On 1/18/23 10:44, i.nixman--- via Gcc-patches wrote:
hello again!
the final version of the path for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
successfully bootstraped for x86_64-mingw32 and x86_64-linux.
could anyone apply it please?
best!
Looks good to me, please supply the a
hello,
could someone look at patch attached please?
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610147.html
hello again!
the final version of the path for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
successfully bootstraped for x86_64-mingw32 and x86_64-linux.
could anyone apply it please?
best!
diff --git a/libiberty/lrealpath.c b/libiberty/lrealpath.c
index 3c7053b0b70..a1ad074d00e 100
updated patch in attachments.
diff --git a/libiberty/lrealpath.c b/libiberty/lrealpath.c
index 3c7053b0b70..8858619e854 100644
--- a/libiberty/lrealpath.c
+++ b/libiberty/lrealpath.c
@@ -68,8 +68,138 @@ extern char *canonicalize_file_name (const char *);
/* cygwin has realpath, so it won't get
hello,
I just finished with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
could anyone review and apply the attached patch please?
GCC master was succesfully bootstrapped as x86_64-w64-mingw32.
best!
diff --git a/libiberty/lrealpath.c b/libiberty/lrealpath.c
index 3c7053b0b70..885861
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
[PR97847] IRA: Skip abnormal critical edge splitting
PPC64 can generate jumps with clobbered pseudo-regs and a BB with
such jump can have abno
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
The patch was successfully bootstrapped on x86-64.
[PR97969] LRA: Transform pattern `plus (plus (hard reg, const), pseudo)` after elimination
LRA can loop infinitely on targets without `reg + imm` insns. Register e
On 2021-01-07 6:01 a.m., Richard Sandiford wrote:
Vladimir Makarov via Gcc-patches writes:
The following fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978
The patch was successfully bootstrapped on x86-64.
Can you explain this a bit more? The assert fires if the register
allocation
Vladimir Makarov via Gcc-patches writes:
> The following fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978
>
> The patch was successfully bootstrapped on x86-64.
Can you explain this a bit more? The assert fires if the register
allocation is inconsistent with the conflict information.
The following fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978
The patch was successfully bootstrapped on x86-64.
commit fbf9b2b634e376516cd21d7aa92ef3fd5778aa10 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Wed Jan 6 14:48:53 2021 -0500
[PR97978] LRA: Permit temporary all
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
The patch was successfully bootstrapped on x86-64 and s390x.
commit fb352136db34a7adbc7be6a1e4e90b56bc632ebd (HEAD -> master)
Author: Vladimir N. Makarov
Date: Tue Nov 24 11:25:16 2020 -0500
[PR97933] LRA: f
After submitting the patch dealing with insn scratches in IRA, a report
came that sync-3.c started to fail with x86_64-aarch64 cross-compiler.
The following patch fixes this problem. The patch was successfully
bootstrapped on x86-64.
commit 885cbb4a0a677299de34d9e413818df5bb8272b1
Author: Vl
The following patch has been committed into the main line. The patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97313
The patch was successfully bootstrapped and tested on x86-64.
gcc/ChangeLog:
2020-10-09 Vladimir Makarov
PR rtl-optimization/97313
* lra-constraints.c (match_re
On 2020-02-24 4:54 a.m., Christophe Lyon wrote:
Hi,
On Sun, 23 Feb 2020 at 22:26, Vladimir Makarov wrote:
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
The patch was successfully bootstrapped on x86-64 and benchmarked on
SPEC2000.
It seems this patch caus
On 2020-02-27 7:33 a.m., Andrew Stubbs wrote:
On 26/02/2020 15:16, Andrew Stubbs wrote:
The problem appears to be that the high-part of a register pair is
not marked as "ever live". I'm trying to figure out whether this is
some kind of target-specific issue that has merely been exposed, but
On 26/02/2020 15:16, Andrew Stubbs wrote:
The problem appears to be that the high-part of a register pair is not
marked as "ever live". I'm trying to figure out whether this is some
kind of target-specific issue that has merely been exposed, but it's
difficult to see what's going on. I'm prett
On 23/02/2020 21:25, Vladimir Makarov wrote:
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
The patch was successfully bootstrapped on x86-64 and benchmarked on
SPEC2000.
Since this patch I get an ICE with checking enabled, for amdgcn-amdhsa:
during RTL pa
On 1/28/20 9:52 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
>
> The patch was successfully tested and bootstrapped on x86_64.
>
> Unfortunately it is hard to create a test case for the patch. So there is no
> test for this PR.
Hi,
On Sun, 23 Feb 2020 at 22:26, Vladimir Makarov wrote:
>
> The following patch is for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
>
> The patch was successfully bootstrapped on x86-64 and benchmarked on
> SPEC2000.
>
It seems this patch causes regression on some arm cores (seen on
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
The patch was successfully bootstrapped on x86-64 and benchmarked on
SPEC2000.
commit 3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d
Author: Vladimir N. Makarov
Date: Sun Feb 23 16:20:05 2020 -0500
Changing cost
Hi!
On Thu, Feb 06, 2020 at 05:16:14PM -0500, Vladimir Makarov wrote:
> --- a/gcc/lra-assigns.c
> +++ b/gcc/lra-assigns.c
> @@ -964,6 +964,8 @@ spill_for (int regno, bitmap spilled_pseudo_bitmap, bool
> first_p)
>bitmap_clear (&spill_pseudos_bitmap);
>for (j = hard_regno_nregs (ha
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93561
The patch was successfully bootstrapped on x86-64.
commit d26f37a16e3ed3d75a93ffb1da10c44c36a8a36d (HEAD -> master)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1754aa76399..aec58a06529 100644
--- a/gcc/ChangeLog
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333
The patch was successfully bootstrapped and tested on x86-64.
The patch changes order of putting colorable allocnos on the stack and
consequently changes order of assigning hard registers to the allocnos
(they all
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
The patch was successfully tested and bootstrapped on x86_64.
Unfortunately it is hard to create a test case for the patch. So there
is no test for this PR.
commit 5c8a1211b9873a1b69ef7b2fddae181535bc3b0a (HEAD ->
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027
The patch was successfully tested bootstrapped on x86-64.
Committed as r280133
Index: ChangeLog
===
--- ChangeLog (revision 280132)
+++ ChangeLog (workin
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796
The patch was successfully bootstrapped and tested on x86-64.
Committed as r279204
Index: ChangeLog
===
--- ChangeLog (revision 279200)
+++ ChangeLog (w
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
The patch was tested on i686, x86-64, and ppc64.
Committed as r279061.
Index: ChangeLog
===
--- ChangeLog (revision 279060)
+++ ChangeLog (working copy)
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
The patch has no test because it is very hard to reproduce PR and check
the patch even on a specific GCC revision.
The patch was successfully bootstrapped and tested on x86-64.
Committed as r278865
Index: Chang
On 2019-11-27 3:31 a.m., Richard Biener wrote:
On Tue, Nov 26, 2019 at 3:57 PM Vladimir Makarov wrote:
This is the patch removing discrepancy between recog and LRA insn
recognition:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01842.html
OK.
Thank you, Richard. Committed as r278770.
On Tue, Nov 26, 2019 at 3:57 PM Vladimir Makarov wrote:
>
> This is the patch removing discrepancy between recog and LRA insn
> recognition:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01842.html
OK.
This is the patch removing discrepancy between recog and LRA insn
recognition:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01842.html
Index: ChangeLog
===
--- ChangeLog (revision 278451)
+++ ChangeLog (working copy)
@@ -1,3 +1,9
On Wed, 20 Nov 2019, Alexander Monakov wrote:
> On Wed, 20 Nov 2019, Richard Biener wrote:
>
> > On Tue, Nov 19, 2019 at 5:07 PM Vladimir Makarov
> > wrote:
> > >
> > > The following patch fixes
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
> > >
> > > Sometime ago a code which
On 2019-11-20 5:06 a.m., Richard Biener wrote:
On Tue, Nov 19, 2019 at 5:07 PM Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
Sometime ago a code which permits LRA to reload hard register into
memory as it did for pseudo were added. But
On Wed, 20 Nov 2019, Richard Biener wrote:
> On Tue, Nov 19, 2019 at 5:07 PM Vladimir Makarov wrote:
> >
> > The following patch fixes
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
> >
> > Sometime ago a code which permits LRA to reload hard register into
> > memory as it did for pse
On Tue, Nov 19, 2019 at 5:07 PM Vladimir Makarov wrote:
>
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
>
> Sometime ago a code which permits LRA to reload hard register into
> memory as it did for pseudo were added. But this LRA possibility was
> not reflecte
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
Sometime ago a code which permits LRA to reload hard register into
memory as it did for pseudo were added. But this LRA possibility was
not reflected in recog.c. The following patch fixes this discrepancy
and as a
Applying as obvious:
A +initlist-array1.C
> moved from initlist-arrray1.C
D initlist-arrray1.C
> moved to initlist-array1.C
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91223
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 273810.
Index: ChangeLog
===
--- ChangeLog (revision 273809)
+++ ChangeLo
On 7/4/19 2:18 AM, Oliver Browne wrote:
> See below for modified patch, indentation and newline for curly braces
> style applied, and commented out chunk removed. Apologies, indentation
> and newline for scope are not they way I normally write things, habits
> got the better of me, and I forgot to
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
The patch was bootstrapped and tested on x86-64
Committed as rev. 273357
Index: ChangeLog
===
--- ChangeLog (revision 273356)
+++ ChangeLog (working
See below for modified patch, indentation and newline for curly braces
style applied, and commented out chunk removed. Apologies, indentation
and newline for scope are not they way I normally write things, habits
got the better of me, and I forgot to remove the commented out chunk
before submission
On 6/12/19 12:25 PM, Oliver Browne wrote:
> Patch fixes following PRs:
> c++/90816 - -finstrument-functions-exclude-function-list improperly
> handles namespace/class definitions
> c++/90809 - -finstrument-functions-exclude-function-list mishandles
> comma escaping
>
> Fixes as follows:
> At flag_
Patch fixes following PRs:
c++/90816 - -finstrument-functions-exclude-function-list improperly
handles namespace/class definitions
c++/90809 - -finstrument-functions-exclude-function-list mishandles
comma escaping
Fixes as follows:
At flag_instrument_functions_exclude_p [gimplify.c]
Using lang_hoo
On Mon, Jun 3, 2019 at 6:46 PM Qing Zhao wrote:
>
> Hi,
>
> this is the 3rd version of the patch, which fixed the issues Paolo raised in
> the previous email.
>
> Okay for trunk?
OK.
Thanks,
Richard.
> thanks.
>
> gcc/ChangeLog:
>
> 2019-06-03 qing zhao
>
>* doc/cppopts.texi: Add do
Hi,
this is the 3rd version of the patch, which fixed the issues Paolo raised in
the previous email.
Okay for trunk?
thanks.
gcc/ChangeLog:
2019-06-03 qing zhao
* doc/cppopts.texi: Add document for -fmax-include-depth.
* doc/invoke.texi (Preprocessor Options): List -fmax-inc
Hi, Paolo,
thanks for the comment.
I will fix these issues.
Qing
> On Jun 3, 2019, at 10:03 AM, Paolo Carlini wrote:
>
> Hi,
>
> a few minor comments.
>
> On 03/06/19 16:49, Qing Zhao wrote:
>> +fmax-include-depth=
>> +C ObjC C++ ObjC++ Joined RejectNegative UInteger
>> +fmax-include-depth
Hi,
a few minor comments.
On 03/06/19 16:49, Qing Zhao wrote:
+fmax-include-depth=
+C ObjC C++ ObjC++ Joined RejectNegative UInteger
+fmax-include-depth= Set the maximum number of depth of nested #include.
I think you want something like "Set the maximum depth of nested #include".
+@item -f
Hi, this is the 2nd version of the patch.
the main changes are:
1. some typo.
2. enhance the error message to provide user idea on how to increase the
limit.
bootstrap and regression tested on X86, no issue.
Okay for trunk?
thanks.
Qing
gcc/ChangeLog:
2019-06-03 qing zhao
On Thu, May 30, 2019 at 10:46 PM David Malcolm wrote:
>
> On Thu, 2019-05-30 at 11:23 -0500, Qing Zhao wrote:
> > Hi,
> >
> > PR 90581 (provide an option to adjust the maximum depth of nested
> > #include)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
> >
> > is to add a new cpp option -f
> On May 30, 2019, at 3:46 PM, David Malcolm wrote:
>
> On Thu, 2019-05-30 at 11:23 -0500, Qing Zhao wrote:
>> Hi,
>>
>> PR 90581 (provide an option to adjust the maximum depth of nested
>> #include)
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
>>
>> is to add a new cpp option -fmax-
On Thu, 2019-05-30 at 11:23 -0500, Qing Zhao wrote:
> Hi,
>
> PR 90581 (provide an option to adjust the maximum depth of nested
> #include)
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
>
> is to add a new cpp option -fmax-inlcude-depth to set the maximum
> depth of nested #include.
>
> '
> On May 30, 2019, at 3:38 PM, David Malcolm wrote:
>
> On Thu, 2019-05-30 at 15:17 -0500, Qing Zhao wrote:
>>> On May 30, 2019, at 2:13 PM, Bernhard Reutner-Fischer >> gmail.com> wrote:
>>>
>>> On 30 May 2019 18:23:43 CEST, Qing Zhao
>>> wrote:
Hi,
PR 90581 (provide an option
On Thu, 2019-05-30 at 15:17 -0500, Qing Zhao wrote:
> > On May 30, 2019, at 2:13 PM, Bernhard Reutner-Fischer > gmail.com> wrote:
> >
> > On 30 May 2019 18:23:43 CEST, Qing Zhao
> > wrote:
> > > Hi,
> > >
> > > PR 90581 (provide an option to adjust the maximum depth of nested
> > > #include)
>
> On May 30, 2019, at 2:13 PM, Bernhard Reutner-Fischer
> wrote:
>
> On 30 May 2019 18:23:43 CEST, Qing Zhao wrote:
>> Hi,
>>
>> PR 90581 (provide an option to adjust the maximum depth of nested
>> #include)
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
>>
>> is to add a new cpp opt
On 30 May 2019 18:23:43 CEST, Qing Zhao wrote:
>Hi,
>
>PR 90581 (provide an option to adjust the maximum depth of nested
>#include)
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
>
>is to add a new cpp option -fmax-inlcude-depth
Typo inl vs inc.
Why isn't this a param?
Wouldn't a param ease
Noticed this is -> if typo. Applying to trunk as obvious.
2019-05-30 Marek Polacek
* cp-tree.h (TYPE_HAS_NONTRIVIAL_DESTRUCTOR): Fix a typo.
diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index 7a74fd4fac5..edd59d5f000 100644
--- gcc/cp/cp-tree.h
+++ gcc/cp/cp-tree.h
@@ -4295,7 +4295,7
Hi,
PR 90581 (provide an option to adjust the maximum depth of nested #include)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
is to add a new cpp option -fmax-inlcude-depth to set the maximum depth of
nested #include.
'-fmax-include-depth=DEPTH'
Set the maximum depth of the nested inc
On Mon, May 20, 2019 at 01:44:47PM -0400, Jason Merrill wrote:
> On 5/20/19 11:56 AM, Marek Polacek wrote:
> > This patch fixes a naked inform call that can be seen with -w.
> >
> > While at it, I added missing quotes; I'm surprisesd this wasn't fixed by the
> > recent patch Martin submitted.
> >
On 5/20/19 11:56 AM, Marek Polacek wrote:
This patch fixes a naked inform call that can be seen with -w.
While at it, I added missing quotes; I'm surprisesd this wasn't fixed by the
recent patch Martin submitted.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK. We might also change
On 5/20/19 12:23 PM, Marek Polacek wrote:
On Mon, May 20, 2019 at 12:18:18PM -0400, Marek Polacek wrote:
This test fails in C++2a since r271338, because the types in the "aka" differ:
in C++17 and below we print:
{aka 'const char [3]'}
while in C++2a:
{aka 'const char8_t [3]'}
We can make
On Mon, May 20, 2019 at 12:18:18PM -0400, Marek Polacek wrote:
> This test fails in C++2a since r271338, because the types in the "aka" differ:
> in C++17 and below we print:
> {aka 'const char [3]'}
> while in C++2a:
> {aka 'const char8_t [3]'}
>
> We can make the regexp accept both.
...beca
This test fails in C++2a since r271338, because the types in the "aka" differ:
in C++17 and below we print:
{aka 'const char [3]'}
while in C++2a:
{aka 'const char8_t [3]'}
We can make the regexp accept both.
Tested on x86_64-linux, ok for trunk?
2019-05-20 Marek Polacek
* g++.dg
This patch fixes a naked inform call that can be seen with -w.
While at it, I added missing quotes; I'm surprisesd this wasn't fixed by the
recent patch Martin submitted.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-05-20 Marek Polacek
* name-lookup.c (finish_using_dir
On 3/21/19 6:04 AM, Nick Clifton wrote:
> Hi Ian,
>
> Attached is a proposed patch to fix PR 89394, which contains an
> artificial mangled name that triggers excessive recursion in
> d_count_templates_scopes. The patch uses the same recursion limit
> that is al
Not sure if this is a correct fix to this bug found here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but
comments are welcome. If a backtrace is required please
let me know.
Signed-off-by: Nicholas Krause
---
gcc/cp/constraint.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 269878.
Index: ChangeLog
===
--- ChangeLog (revision 269876)
+++ Ch
Hi Ian,
Attached is a proposed patch to fix PR 89394, which contains an
artificial mangled name that triggers excessive recursion in
d_count_templates_scopes. The patch uses the same recursion limit
that is already in place for d_print_comp, which I hope will be
acceptable.
There is
Hello!
> 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: testsuite/gcc.target/i386/pr85860.c
===
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
=
On 2/17/19 11:54 AM, Marek Polacek wrote:
On Sat, Feb 16, 2019 at 03:54:21PM -0500, Marek Polacek wrote:
I noticed this test fails in c++2a since the implementation of P0846
landed in r265734. Since it's in g++.old-deja/, I never noticted the
fail (but I don't see any others). This patch tweak
On Sat, Feb 16, 2019 at 03:54:21PM -0500, Marek Polacek wrote:
> I noticed this test fails in c++2a since the implementation of P0846
> landed in r265734. Since it's in g++.old-deja/, I never noticted the
> fail (but I don't see any others). This patch tweaks a dg-error in
> order to make it pass
I noticed this test fails in c++2a since the implementation of P0846
landed in r265734. Since it's in g++.old-deja/, I never noticted the
fail (but I don't see any others). This patch tweaks a dg-error in
order to make it pass in c++2a also.
Tested on x86_64-linux, ok for trunk?
2019-02-16 Mar
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
The patch was bootstrapped and tested on x86-64 and ppc64. It was
also tested on ARM by Tamar Christina. The patch changes expected
generated code for one test on ppc64 but in a better way. I'll send a
patch f
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225
The patch was bootstrapped and tested on x86-64.
Committed as rev. 268597.
Index: ChangeLog
===
--- ChangeLog (revision 268596)
+++ ChangeLog (work
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 268404
Index: ChangeLog
===
--- ChangeLog (revision 26840
1 - 100 of 1269 matches
Mail list logo
