https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82338
Eric Gallager changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #5 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52154
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
Greetings,
Did you received my message?let me know.
Best Regards,
Mr.Abdelkader Alsamman.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72783
Eric Gallager changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79346
--- Comment #3 from Eric Gallager ---
(In reply to Eric Gallager from comment #2)
> Confirmed, although it's pretty easy to work around, just write:
>
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ < 199901L
> #endif
>
> instead.
Ah,
On 2019/6/27 11:48 PM, Jeff Law wrote:
On 6/27/19 12:11 AM, Li Jia He wrote:
Hi,
According to the optimizable case described by Qi Feng on
issue 88784, we can combine the cases into the following:
1. x > y && x != XXX_MIN --> x > y
2. x > y && x == XXX_MIN --> false
3. x <= y
Hi.
This patch includes implementation of new function roundeven along
with two utility functions. The patch bootstraps on x86_64-linux-gnu
and passes regression tests.
Thanks,
Tejas
gcc/ChangeLog:
2019-06-12 Tejas Joshi
* builtins.c (mathfn_built_in_2): Added CASE_MATHFN for ROUNDEVEN.
On Jun 27, 2019, Richard Biener wrote:
> On Thu, Jun 27, 2019 at 10:18 AM Alexandre Oliva wrote:
>> @@ -909,6 +909,13 @@ DEFTREECODE (TRY_CATCH_EXPR, "try_catch_expr",
>> tcc_statement, 2)
>> The second operand is a cleanup expression which is evaluated
>> on any exit (normal, exception, or
Hi Segher,
Thanks a lot for the comments.
on 2019/6/28 上午9:32, wrote:
> Hi Kewen,
>
> On Thu, Jun 27, 2019 at 10:32:18AM +0800, Kewen.Lin wrote:
>> 6: NOTE_INSN_BASIC_BLOCK 2
>>
>>12: r135:CC=cmp(r122:DI,0)
>>13: pc={(r135:CC!=0)?L52:pc}
>> REG_DEAD r135:CC
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91026
Bug ID: 91026
Summary: switch expansion produces a jump table with trivial
entries
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
On Thu, Jun 27, 2019 at 5:38 PM Rainer Orth
wrote:
>
> Hi Hongtao,
>
> > On Thu, Jun 27, 2019 at 5:02 PM Rainer Orth
> > wrote:
> >>
> >> Hi Hongtao,
> >>
> >> >> as usual, the new effective-target keyword needs documenting in
> >> >> sourcebuild.texi.
> >> > Like this?
> >>
> >> a couple of
On 6/27/19 10:12 AM, Jakub Jelinek wrote:
> On Thu, Jun 27, 2019 at 09:15:41AM -0600, Jeff Law wrote:
>> Actually it was trivial to create with store merging.
>>
>> char x[20];
>> foo()
>> {
>> x[0] = 0x41;
>> x[1] = 0x42;
>> }
>>
>> MEM [(char *)] = 16961;
>>
>> So clearly we can get this
This patch updates the predicates for prefixed addressing.
This patch deletes a predicate that I had originally added, but the code no
longer uses.
This patch changes how local symbols for pc-relative addressing are marked.
Previously, we had used a machine dependent bit in the SYMBOL_REF node.
To keep things organized, I'm going to start submitting the patches for for a
possible future PowerPC machine's prefixed addressing (including pc-relative
suport) as threads under this message.
There are two patches that I've already submitted that are needed for the rest
of the patches:
Patch
On Thu, Jun 20, 2019 at 12:50 PM Jim Wilson wrote:
> This looks OK to me. It is worth pointing out that ARM already ships
> compilers built this way, but they didn't bother adding a configure
> option. They just override Makefile variables in their build scripts.
> I think this is much cleaner
On 27/06/19 19:07 -0400, Ed Smith-Rowland wrote:
On 6/27/19 1:06 PM, Ville Voutilainen wrote:
On Thu, 27 Jun 2019 at 19:55, Ed Smith-Rowland via libstdc++
wrote:
I don't think this will work in a constant expression:
?? /// Assign @p __new_val to @p __obj and return its previous value.
??
On 6/27/19 1:06 PM, Ville Voutilainen wrote:
On Thu, 27 Jun 2019 at 19:55, Ed Smith-Rowland via libstdc++
wrote:
I don't think this will work in a constant expression:
?? /// Assign @p __new_val to @p __obj and return its previous value.
?? template
+?? _GLIBCXX20_CONSTEXPR
?? inline
Snapshot gcc-7-20190627 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190627/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On 6/27/19 12:40 PM, Richard Biener wrote:
> On June 27, 2019 7:04:32 PM GMT+02:00, Jakub Jelinek wrote:
>> On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
>>> The LHS is unsigned short so handle_char_store would not be called
>>> because of the check in the caller. You would need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55442
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Thu Jun 27 21:29:19 2019
New Revision: 272765
URL: https://gcc.gnu.org/viewcvs?rev=272765=gcc=rev
Log:
PR c++/55442 - memory-hog with highly recursive constexpr.
This testcase
Hi!
The likely/unlikely C++11 attributes on case labels result in GIMPLE_PREDICT
statements inserted after the label; we should just ignore such statements,
they aren't something executable in between the labels.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
queued
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91024
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Thu Jun 27 21:25:56 2019
New Revision: 272764
URL: https://gcc.gnu.org/viewcvs?rev=272764=gcc=rev
Log:
PR c++/91024
* gimplify.c (collect_fallthrough_labels): Ignore
Hi!
As the testcase shows, offset{1,2} can be NULL and operand_equal_p doesn't
like NULL arguments. If both are NULL, we should return true, if just one,
we should return false.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2019-06-27 Jakub Jelinek
PR
On 6/23/19 5:51 PM, Martin Sebor wrote:
On 6/22/19 9:37 PM, Jason Merrill wrote:
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91010
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Thu Jun 27 21:23:09 2019
New Revision: 272763
URL: https://gcc.gnu.org/viewcvs?rev=272763=gcc=rev
Log:
PR tree-optimization/91010
* tree-vect-stmts.c
On 6/24/19 4:52 AM, Paolo Carlini wrote:
Hi,
On 23/06/19 19:45, Jason Merrill wrote:
On 6/23/19 7:53 AM, Paolo Carlini wrote:
... hi again ;)
The other day I was having a look at using declarations for this
issue and noticed that only a few lines below the de-virtualization
check we have
This testcase in the PR is extremely recursive, and therefore uses a huge
amount of memory on caching the results of individual calls. We no longer
need to track all calls to catch infinite recursion, as we have other limits
on maximum depth and operations count. So let's only cache a few calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70462
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Hi,
The parameter names here were in the wrong order (which doesn't matter
to the interpreter, but confuses the humans reading the calling code).
I am going to install the following patch soon.
gcc/ChangeLog:
* gdbhooks.py (GdbPrettyPrinters.add_printer_for_types): Reorder
A future PowerPC machine may have prefixed instructions. This patch changes
the RTL "length" attribute of all of the "mov*", and "*extend*" insns from an
explicit "4" to "*". This change prepares for the length attribute to be set
appropriately for single instruction loads, stores, and add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91025
--- Comment #1 from Jonathan Wakely ---
(In reply to Stephen Kell from comment #0)
> I'm happy in principle to produce a patch... but haven't quite got my head
> around how the man pages are generated (from the texinfo?).
Yes, via .pod files.
I am testing the latest GCC with not-yet-submitted GLIBC changes that
implement libmvec on Aarch64.
While trying to run SPEC 2017 (specifically 521.wrf_r) I ran into a
case where GCC was generating a call to _ZGVnN2vv_powf, that is a
vectorized powf call for 2 (not 4) elements. This was a
On Thu, Jun 27, 2019 at 11:16 AM Martin Sebor wrote:
>
> On 6/27/19 8:03 AM, Martin Liška wrote:
> > Hi.
> >
> > This reduces 2 warnings reported by clang.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
> > Thanks,
> > Martin
> >
> >
On Thu, Jun 27, 2019 at 11:32 AM charfi asma via gcc wrote:
>
> Thank you for your help.
> Yes, It seems that gcj6 is not well installaed.
> Could you please help me to install it ? which installation instruction
> should I follow ?
>
> I can not installed with apt-get
> should I checkout the
On 6/27/19 11:04 AM, Jakub Jelinek wrote:
On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
The LHS is unsigned short so handle_char_store would not be called
because of the check in the caller. You would need something like:
MEM [(char *)] = { 'a', 'b' };
This is invalid,
The default for the kernel is soft-float, however a user writing a kernel
extension might want to make use of hard float. This change makes
" -mkernel -mhard-float " work as expected.
tested on powerpc-darwin9
applied to mainline
thanks
Iain
2019-06-27 Iain Sandoe
*
A recent merge dropped whitespace in the endfile specs, which affects
transactional memory cases.
applied to mainline
thanks
Iain
2019-06-27 Iain Sandoe
* config/rs6000/darwin.h (ENDFILE_SPEC): Correct whitespace in the
spec.
--- a/gcc/config/rs6000/darwin.h
+++
The linker [ld64] that supports 64Bit does not need the JBSR longcall
optimisation, and will not work with the most generic case (where the
symbol is undefined external, but there is no symbl stub). So switch
the longcall option off. ld64 will generate branch islands as needed.
tested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91011
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
>
> > On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
> >
> >>
> >> It's useful on targets without COMDAT support. Are there any such
> >> that we care about at this point?
> >>
> >> If the problem is the combination with LTO, why not just prohibit that?
> >
> > The problem is that at the
>
> > On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
> >
> >>
> >> It's useful on targets without COMDAT support. Are there any such
> >> that we care about at this point?
> >>
> >> If the problem is the combination with LTO, why not just prohibit that?
> >
> > The problem is that at the
On June 27, 2019 7:04:32 PM GMT+02:00, Jakub Jelinek wrote:
>On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
>> The LHS is unsigned short so handle_char_store would not be called
>> because of the check in the caller. You would need something like:
>>
>> MEM [(char *)] = { 'a',
On 6/25/19 4:43 PM, Jeff Law wrote:
> On 6/25/19 2:22 PM, acsaw...@linux.ibm.com wrote:
>> From: Aaron Sawdey
>>
>> * builtins.c (get_memory_rtx): Fix comment.
>> * optabs.def (movmem_optab): Change to cpymem_optab.
>> * expr.c (emit_block_move_via_cpymem): Change movmem to cpymem.
> On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
>
>>
>> It's useful on targets without COMDAT support. Are there any such
>> that we care about at this point?
>>
>> If the problem is the combination with LTO, why not just prohibit that?
>
> The problem is that at the collect2 time we want
> On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
>
>>
>> It's useful on targets without COMDAT support. Are there any such
>> that we care about at this point?
>>
>> If the problem is the combination with LTO, why not just prohibit that?
>
> The problem is that at the collect2 time we want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91024
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |9.2
>
> It's useful on targets without COMDAT support. Are there any such
> that we care about at this point?
>
> If the problem is the combination with LTO, why not just prohibit that?
The problem is that at the collect2 time we want to decide whether to
hold stderr/stdout of the linker. The
>
> It's useful on targets without COMDAT support. Are there any such
> that we care about at this point?
>
> If the problem is the combination with LTO, why not just prohibit that?
The problem is that at the collect2 time we want to decide whether to
hold stderr/stdout of the linker. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91024
--- Comment #2 from Jakub Jelinek ---
Created attachment 46530
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46530=edit
gcc10-pr91024.patch
Untested fix.
On Mon, Jun 24, 2019 at 1:46 PM Jan Hubicka wrote:
> >
> > I thought I remembered someone's recent-ish work to treat specially
> > types containing a char array, but I'm not finding it now.
> >
> > > For dynamically allocated memory as well as for stack space after stack
> > > slot sharing done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90987
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91024
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
I've committed the attached patch after successful
regression tests on x86_64-*-freebsd. The patch
returns MATCH_NO when matching is done for a COMMON
statement, but the statement in fact is not COMMON.
See testcases.
While here I corrected the recording of the wrong
revision number in the
On Thu, Jun 27, 2019 at 10:23 AM Martin Liška wrote:
>
> On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> > On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
> >>
> >> On 6/21/19 4:28 PM, Richard Biener wrote:
> >>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>
> On Fri, Jun 21,
On Thu, Jun 27, 2019 at 10:23 AM Martin Liška wrote:
>
> On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> > On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
> >>
> >> On 6/21/19 4:28 PM, Richard Biener wrote:
> >>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>
> On Fri, Jun 21,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90987
--- Comment #1 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jun 27 17:52:00 2019
New Revision: 272756
URL: https://gcc.gnu.org/viewcvs?rev=272756=gcc=rev
Log:
2019-06-27 Steven G. Kargl
PR fortran/90987
* match.c
Martin Liška writes:
> diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
> index d50b811d863..1bd251ea8e2 100644
> --- a/gcc/config/i386/i386-expand.c
> +++ b/gcc/config/i386/i386-expand.c
> @@ -19780,8 +19780,7 @@ ix86_expand_sse2_mulvxdi3 (rtx op0, rtx op1, rtx op2)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
--- Comment #3 from David Binderman ---
--language=c++ seems to be required for C++ code.
--force helps cppcheck to avoid a too-early finish.
I use the current development cppcheck code, although it's fair to say that
new features rarely work
On Thu, 27 Jun 2019 at 19:55, Ed Smith-Rowland via libstdc++
wrote:
> > I don't think this will work in a constant expression:
> >
> > ?? /// Assign @p __new_val to @p __obj and return its previous value.
> > ?? template
> > +?? _GLIBCXX20_CONSTEXPR
> > ?? inline _Tp
> > ??
On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
> The LHS is unsigned short so handle_char_store would not be called
> because of the check in the caller. You would need something like:
>
> MEM [(char *)] = { 'a', 'b' };
This is invalid, because the rhs is non-empty CONSTRUCTOR
On Thu, Jun 27, 2019 at 5:26 AM Uros Bizjak wrote:
>
> On Thu, Jun 27, 2019 at 2:23 PM Jan Beulich wrote:
> >
> > >>> On 27.06.19 at 14:00, wrote:
> > > On Thu, Jun 27, 2019 at 1:46 PM Jan Beulich wrote:
> > >>
> > >> >>> On 27.06.19 at 13:09, wrote:
> > >> > On Thu, Jun 27, 2019 at 12:11 PM
On 6/27/19 9:15 AM, Jeff Law wrote:
On 6/27/19 9:00 AM, Jeff Law wrote:
On 6/26/19 8:40 PM, Martin Sebor wrote:
On 6/26/19 4:31 PM, Jeff Law wrote:
On 6/25/19 5:03 PM, Martin Sebor wrote:
The caller ensures that handle_char_store is only called for stores
to arrays (MEM_REF) or single
On 6/27/19 11:41 AM, Jonathan Wakely wrote:
On 26/06/19 19:13 -0400, Ed Smith-Rowland via libstdc++ wrote:
Here is the first of three patches for C++20 constexpr library.
?? Implement C++20 p0202 - Add constexpr Modifiers to Functions
in and Headers.
??Implement C++20 p1023 -
As I detail in PR 91009, I had some testsuite failures with my patches for a
future machine. In the future patches, I added new RTL attributes to support
the new prefixed load/store instructions (which will include pc-relative
support). This new attribute needs to look at the 'type' RTL
On Thu, Jun 27, 2019 at 09:15:41AM -0600, Jeff Law wrote:
> Actually it was trivial to create with store merging.
>
> char x[20];
> foo()
> {
> x[0] = 0x41;
> x[1] = 0x42;
> }
>
> MEM [(char *)] = 16961;
>
> So clearly we can get this in gimple. So we need a check of some kind,
> either
On 6/27/19 12:11 AM, Li Jia He wrote:
> Hi,
>
> According to the optimizable case described by Qi Feng on
> issue 88784, we can combine the cases into the following:
>
> 1. x > y && x != XXX_MIN --> x > y
> 2. x > y && x == XXX_MIN --> false
> 3. x <= y && x == XXX_MIN --> x ==
On 26/06/19 19:13 -0400, Ed Smith-Rowland via libstdc++ wrote:
Here is the first of three patches for C++20 constexpr library.
?? Implement C++20 p0202 - Add constexpr Modifiers to Functions in
and Headers.
??Implement C++20 p1023 - constexpr comparison operators for std::array.
I
On 6/27/19 9:34 AM, Jakub Jelinek wrote:
> On Thu, Jun 27, 2019 at 09:24:58AM -0600, Jeff Law wrote:
>> On 6/27/19 12:05 AM, Jakub Jelinek wrote:
>>> On Wed, Jun 26, 2019 at 12:19:28PM +0200, Uros Bizjak wrote:
Yes, the patch works OK. I'll regression test it and push it later today.
>>>
>>>
On Thu, Jun 27, 2019 at 09:24:58AM -0600, Jeff Law wrote:
> On 6/27/19 12:05 AM, Jakub Jelinek wrote:
> > On Wed, Jun 26, 2019 at 12:19:28PM +0200, Uros Bizjak wrote:
> >> Yes, the patch works OK. I'll regression test it and push it later today.
> >
> > I think it caused
> > +FAIL:
Thank you for your help.
Yes, It seems that gcj6 is not well installaed.
Could you please help me to install it ? which installation instruction should
I follow ?
I can not installed with apt-get
should I checkout the gcj 6 from git and setup it manually ?
If yes, can you please give me the
On 6/27/19 12:05 AM, Jakub Jelinek wrote:
> On Wed, Jun 26, 2019 at 12:19:28PM +0200, Uros Bizjak wrote:
>> Yes, the patch works OK. I'll regression test it and push it later today.
>
> I think it caused
> +FAIL: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;"
> which admittedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91025
Bug ID: 91025
Summary: cpp man page incorrectly describes -MD option
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On 6/27/19 8:03 AM, Martin Liška wrote:
Hi.
This reduces 2 warnings reported by clang.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-06-27 Martin Liska
* edit-context.c
On 6/27/19 9:00 AM, Jeff Law wrote:
> On 6/26/19 8:40 PM, Martin Sebor wrote:
>> On 6/26/19 4:31 PM, Jeff Law wrote:
>>> On 6/25/19 5:03 PM, Martin Sebor wrote:
>>>
The caller ensures that handle_char_store is only called for stores
to arrays (MEM_REF) or single elements as wide as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86564
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On 6/26/19 8:40 PM, Martin Sebor wrote:
> On 6/26/19 4:31 PM, Jeff Law wrote:
>> On 6/25/19 5:03 PM, Martin Sebor wrote:
>>
>>>
>>> The caller ensures that handle_char_store is only called for stores
>>> to arrays (MEM_REF) or single elements as wide as char.
>> Where? I don't see it, even after
On 6/27/19 8:21 AM, Martin Liška wrote:
On 6/27/19 4:11 PM, Jakub Jelinek wrote:
On Thu, Jun 27, 2019 at 04:03:06PM +0200, Martin Liška wrote:
* ggc-page.c (free_page): Use (char *) for %p printf format
argument.
--- a/gcc/ggc-page.c
+++ b/gcc/ggc-page.c
@@ -977,7 +977,7 @@
Hi people!
This is a call for proposals for the Toolchain micro-conference at this
years' Linux Plumbers Conference (LPC) 2019 which will be held in
Lisbon, Portugal for September 9-11.
The Linux kernel is particularly demanding in terms of tooling, and the
main purpose of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91024
Bug ID: 91024
Summary: -Wimplicit-fallthrough is confused by likely/unlikely
attributes
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Keywords: diagnostic
On Thu, Jun 27, 2019 at 04:21:10PM +0200, Martin Liška wrote:
> 2019-06-27 Martin Liska
>
> * edit-context.c (test_applying_fixits_unreadable_file): Do not
> use () for a constructor call.
> (test_applying_fixits_line_out_of_range): Likewise.
> * ggc-page.c
On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>>
>> On 6/21/19 4:28 PM, Richard Biener wrote:
>>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> On 6/21/19 1:58
On 6/27/19 2:58 PM, Jonathan Wakely wrote:
> On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>>
>> On 6/21/19 4:28 PM, Richard Biener wrote:
>>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> On 6/21/19 1:58
On 6/27/19 4:11 PM, Jakub Jelinek wrote:
> On Thu, Jun 27, 2019 at 04:03:06PM +0200, Martin Liška wrote:
>> * ggc-page.c (free_page): Use (char *) for %p printf format
>> argument.
>
>> --- a/gcc/ggc-page.c
>> +++ b/gcc/ggc-page.c
>> @@ -977,7 +977,7 @@ free_page (page_entry *entry)
>>
> On Jun 25, 2019, at 4:22 PM, acsaw...@linux.ibm.com wrote:
>
> From: Aaron Sawdey
>
> * config/pdp11/pdp11.md (movmemhi, movmemhi1,
> movmemhi_nocc, UNSPEC_MOVMEM): Change movmem to cpymem.
Ok, thanks.
paul
On Thu, Jun 27, 2019 at 04:03:06PM +0200, Martin Liška wrote:
> * ggc-page.c (free_page): Use (char *) for %p printf format
> argument.
> --- a/gcc/ggc-page.c
> +++ b/gcc/ggc-page.c
> @@ -977,7 +977,7 @@ free_page (page_entry *entry)
>if (GGC_DEBUG_LEVEL >= 2)
> fprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91023
--- Comment #1 from Christoph Höger ---
Since it might help investigating the issue, here is a workaround:
#include
#include
template
struct Foo
{
};
template
std::optional>
parse_variant(const Foo &... variants)
{
return {};
}
Hi.
The patch continues to remove quite obvious dead assignments
that are not used.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-06-27 Martin Liska
* config/i386/i386-expand.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91023
Bug ID: 91023
Summary: Unification Fails for parameter pack
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Hi.
This reduces 2 warnings reported by clang.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-06-27 Martin Liska
* edit-context.c (test_applying_fixits_unreadable_file): Do not
use () for a
Hi Dave,
last version for this patch addressing the suggestion about the
JIT_BIT_FIELD macros comment description.
Thank you for all the suggestions.
Regarding the write access please see my previous answer into the binary
op patch thread.
Bests
Andrea
2019-06-20 Andrea Corallo
No. Since this is LTO, it's very hard to simplify the big application. Sorry
for that.
I think Christophe is mentioning the case from g++.dg is reporting the similar
issue like " type variant differs by TYPE_CXX_ODR_P ", right?
Thanks,
-Jiangning
> -Original Message-
> From: Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91020
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On 6/18/19 12:16 PM, Jakub Jelinek wrote:
> I think any such length changes should be moved after the two punt checks.
> Move also the len3 setting before the new checks (of course conditional on
> is_ncmp).
Ok, I'm sending updated version of the patch that addresses this.
I've been testing the
On Thu, Jun 27, 2019 at 05:46:00AM -0600, Jan Beulich wrote:
> While maybe not explicitly applicable here, the intrinsics aren't
> (afaict) providing full flexibility. In particular (just as example)
> I haven't found a way to use embedded broadcast with the
> intrinsics, but I can easily do so
On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>
> On 6/21/19 4:28 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
> >>
> >> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> >>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> On Fri, Jun 21,
On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote:
>
> On 6/21/19 4:28 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
> >>
> >> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
> >>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
> On Fri, Jun 21,
On 6/21/19 4:28 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>>
>> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
>>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> On 6/21/19
On 6/21/19 4:28 PM, Richard Biener wrote:
> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote:
>>
>> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote:
>>> On 6/21/19 1:58 PM, Jakub Jelinek wrote:
On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote:
> On 6/21/19
Hi.
So this is a patch candidate for the .gnu.lto_.lto ELF section.
As mentioned, the section contains information about bytecode version,
compression algorithm used and slim LTO object flag.
One minor issues is that I need to append random suffix to the section:
[ 6]
Hi.
So this is a patch candidate for the .gnu.lto_.lto ELF section.
As mentioned, the section contains information about bytecode version,
compression algorithm used and slim LTO object flag.
One minor issues is that I need to append random suffix to the section:
[ 6]
1 - 100 of 256 matches
Mail list logo
