On Tue, May 01, 2018 at 09:27:01AM +0200, Jakub Jelinek wrote:
> PR web/85578 complains about broken links in INSTALL/specific.html inside of
> the rc tarballs, I've looked at past releases and at least the releases I've
> checked (4.7.0, 6.1, 7.1, 7.3, 8.1rc2) all have the broken links,
> e.g.
> a
(I am not a reviewer, just commenting)
On Fri, 9 Feb 2018, Roger Sayle wrote:
The following patch implements a number of __builtin_popcount related
optimizations.
(i) popcount(x) == 0 can be simplified to x==0, and popcount(x) != 0 to
x!=0.
(ii) popcount(x&1) can be simplified to x&1, and for u
On Mon, 30 Apr 2018, Jeff Law wrote:
On 02/09/2018 05:42 AM, Roger Sayle wrote:
The following patch implements a number of __builtin_popcount related
optimizations.
(i) popcount(x) == 0 can be simplified to x==0, and popcount(x) != 0 to
x!=0.
(ii) popcount(x&1) can be simplified to x&1, and for
Hi!
The x86_64 RTEMS target doesn't currently have gcc build crti.o and crtn.o. This
surfaces as undefined references to "_fini", which RTEMS references in its
kernel:
https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/newlibc_exit.c#n39
Most other architectures deal with this by adding crt
Hi
The *_resms64*.S files in libgcc don't have section to remove the
executable stack marking. Can this be added to Gcc 8.0 Rc?
gcc/ChangeLog:
2018-05-01 Magnus Granberg
* config/i386/cet.h: Add section to remove executable stack marking.
---
--- a/gcc/config/i386/cet.h 2018-04-20 1
On Tue, May 01, 2018 at 12:24:44PM +0200, Magnus Granberg wrote:
> Hi
>
> The *_resms64*.S files in libgcc don't have section to remove the
> executable stack marking. Can this be added to Gcc 8.0 Rc?
>
> gcc/ChangeLog:
>
> 2018-05-01 Magnus Granberg
>
> * config/i386/cet.h: Add sectio
On 04/30/2018 08:29 PM, David Malcolm wrote:
Following on from the thread on the "gcc" list here:
https://gcc.gnu.org/ml/gcc/2018-04/msg00172.html
here's an updated version of Jonathan's patch, which:
+ {
+ tree valtype = TREE_TYPE (DECL_RESULT (fndecl));
+ if (TREE_
tisdag 1 maj 2018 kl. 12:33:33 CEST skrev Jakub Jelinek:
> On Tue, May 01, 2018 at 12:24:44PM +0200, Magnus Granberg wrote:
> > Hi
> >
> > The *_resms64*.S files in libgcc don't have section to remove the
> > executable stack marking. Can this be added to Gcc 8.0 Rc?
> >
> > gcc/ChangeLog:
> >
On 30 April 2018 at 21:52, Joel Brobecker wrote:
>> +2018-04-30 Francois H. Theron
>> +
>> + * config.sub: Added "nfp" to basic_machine list.
>> + * configure.ac: Added "nfp" target.
>> + * configure: Regenerate.
>
> I am not a maintainer, but I noticed that config.sub is not being
>
It wasn't a problem before that we didn't check for namespace scope,
because we were only looking at functions. Now that we look at
variables as well, we need to consider their scope.
Tested x86_64-pc-linux-gnu, applying to trunk. Jakub, this looks like
a P1, should it go into 8.1 as well?
commi
On Tue, May 01, 2018 at 08:52:42AM -0400, Jason Merrill wrote:
> It wasn't a problem before that we didn't check for namespace scope,
> because we were only looking at functions. Now that we look at
> variables as well, we need to consider their scope.
>
> Tested x86_64-pc-linux-gnu, applying to
On 04/16/2018 08:13 PM, Tom de Vries wrote:
On 04/12/2018 08:58 PM, Jakub Jelinek wrote:
On Thu, Apr 12, 2018 at 11:39:43AM -0700, Cesar Philippidis wrote:
Strange. I didn't observe any regressions when I tested it. But, then
again, I was testing against revision
r259092 | jason | 2018-04-04 0
On 04/30/2018 06:37 AM, Richard Biener wrote:
> On Fri, Apr 27, 2018 at 9:21 AM, graham stott via gcc-patches
> wrote:
>> All
>> Just a heads the trunk has been broken since about Weds most files fail
>> compare during bootstrap at O3 but pass at O2
>> My last succesful boostrap at O3 was Tuesday
On Tue, May 1, 2018 at 9:18 AM, Jakub Jelinek wrote:
> On Tue, May 01, 2018 at 08:52:42AM -0400, Jason Merrill wrote:
>> It wasn't a problem before that we didn't check for namespace scope,
>> because we were only looking at functions. Now that we look at
>> variables as well, we need to consider
There are even more varieties of the Solaris assembler syntax on
different platforms, as discussed on PR 85429. This patch by Rainer
Orth should address them all, I hope. Committed to mainline.
OK for GCC 8 branch?
Ian
Index: gcc/go/gofrontend/MERGE
=
On 12/03/18 16:02 -0300, Tulio Magno Quites Machado Filho wrote:
Changes since v1:
- Completely rewrite of the patch to set ENABLE_FLOAT128 at libstdc++
build time and undef _GLIBCXX_USE_FLOAT128 when building user code.
--- 8< ---
In order to use __float128 in C++ it's necessary to check if
On 05/01/2018 02:48 AM, Marc Glisse wrote:
> On Mon, 30 Apr 2018, Jeff Law wrote:
>
>> On 02/09/2018 05:42 AM, Roger Sayle wrote:
>>> The following patch implements a number of __builtin_popcount related
>>> optimizations.
>>> (i) popcount(x) == 0 can be simplified to x==0, and popcount(x) != 0 to
On Tue, 1 May 2018, Jakub Jelinek wrote:
> On Tue, May 01, 2018 at 09:27:01AM +0200, Jakub Jelinek wrote:
> > PR web/85578 complains about broken links in INSTALL/specific.html inside of
> > the rc tarballs, I've looked at past releases and at least the releases I've
> > checked (4.7.0, 6.1, 7.1,
Hi Francois,
> 2018-05-01 Francois H. Theron
>
> * configure.ac: Added "nfp" target.
> * configure: Regenerate.
I have applied this change patch to both the gcc and binutils mainline sources.
Cheers
Nick
Hi
Thank you. The last thing would be config.sub, do I submit the
accepted patch for it here as well or will it propagate from
config.git?
Francois
On 04/09/2018 06:52 PM, Kugan Vivekanandarajah wrote:
> I would like to queue this patch for stage1 review.
>
> In DSE, while in dse_classify_store, as soon as we see a PHI use
> statement that is part of the loop, we are immediately giving up.
>
> As far as I understand, this can be improved. At
Richard,
I have updated my patch for incremental linking into LTO bytecode, but it now
breaks in
dwarf2out:
lto1: internal compiler error: in dwarf2out_die_ref_for_decl, at
dwarf2out.c:5859
0x5d8a37 dwarf2out_die_ref_for_decl
../../gcc/dwarf2out.c:5858
0xa8c311 lto_write_tree_1
..
On 04/11/2018 04:31 AM, Jakub Jelinek wrote:
> Hi!
>
> As discussed, using --as-needed and --no-as-needed is dangerous, because
> it results in --no-as-needed even for libraries after -lgcc_s, even when the
> default is --as-needed or --as-needed has been specified earlier on the
> command line.
>
On 04/27/2018 05:00 AM, Martin Liška wrote:
> Hi.
>
> I'm sending patch that removes MPX. It preserves all options
> -fcheck-pointer-bounds, -fchkp-* and -mmpx
> target option. These options are now NOP. On the contrary following options
> were removed:
> --static-libmpx -static-libmpxwrappers.
On 04/28/2018 12:25 AM, Alan Modra wrote:
> On Fri, Apr 27, 2018 at 06:24:28PM -0400, Hans-Peter Nilsson wrote:
>> On Fri, 27 Apr 2018, Alan Modra wrote:
>>
>>> This patch adds ATTRIBUTE_NONSTRING, which will be used to curb
>>> -Wstringop-truncation warnings in binutils. OK to apply?
>>>
>>>
On 02/02/2018 06:25 AM, Bernhard Reutner-Fischer wrote:
> On 19 June 2016 at 22:21, Mike Stump wrote:
>> On Jun 18, 2016, at 12:31 PM, Bernhard Reutner-Fischer
>> wrote:
>>>
>>> A branch with a name matching scan-assembler pattern triggers
>>> inappropriate FAIL.
>>
>>> The patch below adds -fno
Now that we're doing normal handling of qualified names in a template,
we need to handle the case of an unresolved enumerator name.
Jakub, should this also go into 8.1?
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f7dae5dc1933f836e47cafeab2ff2bd5d80e4eeb
Author: Jason Merrill
Date: Tu
On Tue, May 01, 2018 at 02:10:51PM -0400, Jason Merrill wrote:
> Now that we're doing normal handling of qualified names in a template,
> we need to handle the case of an unresolved enumerator name.
>
> Jakub, should this also go into 8.1?
It is certainly ok for 8.2, for 8.1 I'll discuss tomorrow
On 01/06/2018 11:58 PM, Prathamesh Kulkarni wrote:
> On 5 January 2018 at 00:20, Jeff Law wrote:
>> On 01/03/2018 12:08 AM, Prathamesh Kulkarni wrote:
>>> On 3 January 2018 at 12:33, Prathamesh Kulkarni
>>> wrote:
On 2 January 2018 at 17:49, Jakub Jelinek wrote:
> On Tue, Jan 02, 2018 a
On 01/11/2018 06:03 AM, Tom de Vries wrote:
> On 01/10/2018 07:03 PM, Bernhard Reutner-Fischer wrote:
>> On 5 January 2018 22:06:10 CET, Tom de Vries wrote:
>>
>>> [ was: Re: [RFC] Add vec::ordered_remove_if ]
>>
>> Tom,
>>
>> s/an an/an/g
>>
>
> Fixed.
>
> Also:
> - added '()' around more macro
On 01/22/2018 06:46 AM, Luis Machado wrote:
> This patch adds a new option to control the minimum stride, for a memory
> reference, after which the loop prefetch pass may issue software prefetch
> hints for. There are two motivations:
>
> * Make the pass less aggressive, only issuing prefetch hint
On 01/22/2018 06:46 AM, Luis Machado wrote:
> The following patch adds an option to control software prefetching of memory
> references with non-constant/unknown strides.
>
> Currently we prefetch these references if the pass thinks there is benefit to
> doing so. But, since this is all based on h
The problem in this PR was that we didn't consider aliases between
writes in the same strided group. After tightening the early exit
we get the expected abs(step) >= 2 versioning check.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK for trunk
and GCC 8?
Thanks,
Richard
2018-05-01 Richa
On 02/07/2018 06:53 PM, David Malcolm wrote:
> PR c/84258 reports that we issue this:
>
> warning: format is a wide character string [-Wformat=]
>
> on this code:
>
> const unsigned char cuc[] = "%i";
> sprintf(buf, (char *)cuc, 1);
>
> despite the absence of wide characters.
>
> This wor
On 02/20/2018 10:35 AM, Sriraman Tallam via binutils wrote:
> Ping. Is this alright to apply now or should I wait for Stage 1?
>
> * plugin-api.h (ld_plugin_get_wrap_symbols): New
> plugin interface.
>
> Thanks
> Sri
>
> On Thu, Feb 15, 2018 at 1:52 PM, Sriraman Tallam wrote:
>> Ping, this
Hi,
atm we run into an assert when compiling the test-case from the patch,
because we encounter a non VAR_DECL (for foo) in this loop in
mark_vars_oacc_gangprivate:
...
if (TREE_CODE (*tp) == BIND_EXPR)
{
tree block = BIND_EXPR_BLOCK (*tp);
for (tree var = BLOCK_VARS (block);
On Tue, May 01, 2018 at 08:40:59PM +0200, Tom de Vries wrote:
> @@ -14210,7 +14210,8 @@ mark_vars_oacc_gangprivate (tree *tp,
>tree block = BIND_EXPR_BLOCK (*tp);
>for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
> {
> - gcc_assert (TREE_CODE (var) == VAR
This is an attempt to solve a packaging problem for linux distros. If the
RISC-V port is built with --disable-multilib, libraries get installed into /lib
which violates the ABI. If it is built with --enable-multilib, 32 versions
of libraries are built which is useful for embedded linux cross comp
Hi
If not told otherwise I'll commit attached patch tomorrow.
Already discussed here:
https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html
François
diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index a4a026e..2b8fd27 100644
--- a/libstdc++-v3/include
Hi,
this patch improves the "offload compiler not found" error message in
nvptx's mkoffload, by suggesting to use '-B' to fix the error.
Committed to trunk.
Thanks,
- Tom
[nvptx] Improve "offload compiler not found" message in mkoffload
2018-05-01 Tom de Vries
PR lto/85451
* config/nvp
Hi,
if lto-wrapper can't find mkoffload for an acceleration target it shows
this error:
...
$ gcc -fopenacc test.c
lto-wrapper: fatal error: problem with building target image for nvptx-none
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit stat
Hi,
the stup^H^H^H^Hhighly benevolent mailing list filter rejected
my patch because it was too large...
Hello world,
now that the release of gcc 8 is really around the corner, it's time
to add some new features :-) I had mostly completed this a few
months ago, but by then we were too deep int
On 11/17/2017 02:18 PM, Tom de Vries wrote:
Hi,
I've factored out 3 new functions to test properties of enum acc_async_t:
...
typedef enum acc_async_t {
/* Keep in sync with include/gomp-constants.h. */
acc_async_noval = -1,
acc_async_sync = -2
} acc_async_t;
...
In order to underst
On 1 May 2018 at 22:56, François Dumont wrote:
> Hi
>
> If not told otherwise I'll commit attached patch tomorrow.
Commit it where? The 8.1 release is not out yet, so we shouldn't be
pushing new stuff onto trunk yet.
Nor should we push such stuff into the release branch.
On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote:
> On 1 May 2018 at 22:56, François Dumont wrote:
> > Hi
> >
> > If not told otherwise I'll commit attached patch tomorrow.
>
>
> Commit it where? The 8.1 release is not out yet, so we shouldn't be
> pushing new stuff onto trunk y
On 03/01/2018 04:53 AM, Martin Liška wrote:
> On 03/01/2018 12:45 PM, Jakub Jelinek wrote:
>> On Thu, Mar 01, 2018 at 12:41:37PM +0100, Martin Liška wrote:
>>> I've been running periodically UBSAN bootstrap and as the runtime errors are
>>> not causing failure of compiler I haven't noticed the erro
On 2 May 2018 at 00:28, Jakub Jelinek wrote:
> On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote:
>> On 1 May 2018 at 22:56, François Dumont wrote:
>> > Hi
>> >
>> > If not told otherwise I'll commit attached patch tomorrow.
>>
>>
>> Commit it where? The 8.1 release is not out yet
On 04/24/2018 07:21 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 24 Apr 2018, Alexander Monakov wrote:
>
>>> Sure but even for that we need to decide if we want to go that or the
>>> opposite way, and that's not easy when a deadline is lurking behind
>>> you.
>>
>> I am surprised there is any ques
On 04/30/2018 05:20 PM, Jim Wilson wrote:
> We have some github repos that use git submodule to include other repos,
> including gcc. When git submodule is used, .git is actually a file not a dir,
> and contains the path to the modules file in the parent repo's .git dir. This
> patch allows contr
On 02/05/18 00:47 +0300, Ville Voutilainen wrote:
On 2 May 2018 at 00:28, Jakub Jelinek wrote:
On Wed, May 02, 2018 at 12:23:27AM +0300, Ville Voutilainen wrote:
On 1 May 2018 at 22:56, François Dumont wrote:
> Hi
>
> If not told otherwise I'll commit attached patch tomorrow.
Commit it wher
Time to come back to this now that the trunk is open again...
Forwarded Message
Subject: [GCC 9][RFC][PATCH] Optimize PHIs with constant arguments better
Date: Thu, 30 Nov 2017 16:24:33 -0700
From: Jeff Law
To: gcc-patches
This addresses some code quality regressions with
Hi Jeff,
Thanks for the review.
On 2 May 2018 at 01:43, Jeff Law wrote:
> On 04/09/2018 06:52 PM, Kugan Vivekanandarajah wrote:
>> I would like to queue this patch for stage1 review.
>>
>> In DSE, while in dse_classify_store, as soon as we see a PHI use
>> statement that is part of the loop, we
On Tue, 1 May 2018, Jakub Jelinek wrote:
> Now in patch form, briefly tested with a hacked gcc_release script (so that
> it works even with uncommitted install.texi2html). Ok for trunk/8.1?
>
> 2018-05-01 Jakub Jelinek
>
> PR web/85578
> * doc/install.texi2html: Replace _002d with
On Wed, 25 Apr 2018, Jonathan Wakely wrote:
Ville is going to prepare something for the new -Wclass-memacess and
-Wcatch-value warnings. Suggestions for other gotchas to document are
welcome.
Committed to CVS.
Great, thank you!
Gerald
Hi
Here is the patch I eventually would like to commit.
Tested under Linux x86_64, ok for trunk ?
François
On 17/04/2018 22:34, François Dumont wrote:
Yes, I also think there is no rush to fix this issue.
I had already written a test for a different purpose using the
input_iterator
Hi
std::rotate already returns the expected iterator so there is no
need for calls to std::advance/std::distance.
Tested under Linux x86_64, ok to commit ?
François
diff --git a/libstdc++-v3/include/bits/stl_algo.h b/libstdc++-v3/include/bits/stl_algo.h
index e10a692..9c1b2d4 100644
---
Hi Segher,
As mentionned in the ticket this was my first thought but this means
making the pattern aware of all the possible way the address could be
access (PIC Vs non-PIC, Arm Vs Thumb-2 Vs Thumb-1) to decide how many
scratch registers are needed. I'd rather reuse the existing pattern as
much as
57 matches
Mail list logo
