Hi Segher,
Please check the patch and let me know your thoughts on the same.
On Thu, Jan 10, 2019 at 5:57 PM Lokesh Janghel
wrote:
>
> Hi Segher,
>
> Find the attached patch for the subjected issue.
> Please let me know your thoughts and comments on the same.
>
> >Do you have a copyright assignm
On Fri, Jan 25, 2019 at 06:36:53AM +, Bernd Edlinger wrote:
> 2019-01-25 Bernd Edlinger
>
> * c-warn.c (check_address_or_pointer_of_packed_member): Handle the case
> when rhs is of array type correctly. Fix handling of nested structures.
> Fix handling of indirect_ref tog
Recent commit increased GOTOOLS_TEST_TIMEOUT in Makefile.am, but
forgot to update Makefile.in. Fix the omission.
2019-01-28 Uroš Bizjak
* Makefile.in: Really regenerate.
Tested on x86_64-linux-gnu.
Uros.
diff --git a/gotools/Makefile.in b/gotools/Makefile.in
index 47235df..8bea355 100644
On Sat, Jan 19, 2019 at 10:06:29AM +, Bernd Edlinger wrote:
> 2019-01-19 Bernd Edlinger
>
> * common.opt (-Wattribute-alias): Remove "no-" from name.
> Make -Wattribute-alias command line option and
> #pragma GCC diagnostic ignore "-Wattribute-alias" work again.
>
> tests
Hi,
This simple patch fixes the ICE by getting loop bbs in dominance order and
sorting
chain references against it. Previously it didn't take dominance in
consideration for
loop thus resulted in use-before-def issue.
After looking at the code closer, I think sorting references isn't necessary,
On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries wrote:
>
> On 25-01-19 18:15, Nathan Sidwell wrote:
> > On 1/25/19 5:28 AM, Tom de Vries wrote:
> >>
> >> This patch fixes it by passing "" instead of NULL, in the call to
> >> elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
> >
On 25-01-19 18:15, Nathan Sidwell wrote:
> On 1/25/19 5:28 AM, Tom de Vries wrote:
>>
>> This patch fixes it by passing "" instead of NULL, in the call to
>> elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
>> line 3044 (for .gnu_debuglink) mentioned above.
>>
>> Nathan, doe
Hi,
On 25 January 2019 12:44:30 CET, Sebastian Huber
wrote:
libgfortran/
* io/async.c (init_adv_cond): Use
__GTHREAD_COND_INIT_FUNCTION().
LGTM.
Please CC the FORTRAN list for FORTRAN patches.
thanks,
---
libgfortran/io/async.c | 2 +-
1 file changed, 1 insertion(+), 1 de
Hi Uros,
OK for mainline and release branches?
OK, and thanks for the patch.
(I would probably have considered this one obvious).
Regards
Thomas
Hello!
As explained in PR70696, comment #17 [1], the referred testcase,
introduced as a testcase for PR70696, results in an uninitialized read
from x. Adding "save" attribute, as explained and required in the
comment #1, fixes the runtime failure for me.
2019-01-27 Uroš Bizjak
PR fortran/
On Sat, 26 Jan 2019 at 23:53, Jakub Jelinek wrote:
>
> On Sat, Jan 26, 2019 at 04:01:13PM +0100, Jakub Jelinek wrote:
> > Here is an untested patch that should fix all of that, ok for trunk
> > if it passes bootstrap/regtest on {x86_64,i686}-linux?
>
> Had to change:
> -+ { dg-do compile { targe
On Sat, Jan 26, 2019 at 07:22:17PM -0500, Jason Merrill wrote:
> On Fri, Jan 25, 2019 at 4:20 PM Marek Polacek wrote:
> > On Fri, Jan 25, 2019 at 10:05:00AM -0500, Jason Merrill wrote:
> > > On 1/24/19 7:17 PM, Marek Polacek wrote:
> > > > On Wed, Jan 23, 2019 at 03:34:04PM -0500, Jason Merrill wr
This isn't really a regression but a long standing issue related to the run
time performance of a class of dynamic discriminated record types. For them,
the size and offset calculations contain artificial MIN expressions that are
introduced to compute maximum sizes at compile time but neverthel
This is a regression present on all active branches: the compiler may generate
elaboration code that wrongly raises a Constraint_Error for a multidimensional
array whose component type is controlled if the unit is compiled at -O3.
Tested on x86_64-suse-linux, applied on all active branches.
20
On 1/27/19 1:13 AM, Janne Blomqvist wrote:
On Sat, Jan 26, 2019 at 10:42 PM Jerry DeLisle
--- snip ---
Checking remove() for an error is a good idea, although speculating why
that happened might be confusing if the error happens for some other
reason? Particularly so on POSIX systems, where
Hi,
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01120.html
This patch would be needed to avoid a rather ugly workaround for the the issue
in the linux-tree.
Thanks
Bernd.
On 1/19/19 11:06 AM, Bernd Edlinger wrote:
> Hi,
>
> the command line option -Wattribu
Hi,
The following patch is an update of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52884#c3,
I am planning to commit with a suitable ChangeLog if there is no objection.
Tested on darwin.
TIA
Dominique
--- ../_clean/gcc/fortran/invoke.texi 2019-01-19 22:48:32.0 +0100
+++ gcc/fortr
Hello world,
the attached, rather straightforward patch fixes a rejects-valid error
by fixing up the contiguous attribute for a class, and by using the
correct attributes.
Regression-tested. OK for trunk?
Regards
Thomas
2019-01-27 Thomas Koenig
PR fortran/88669
*
Hi Harald,
P.S.: this was my first actual commit to gcc.
Congratulations, and welcome to the club!
Regards
Thomas
Hi,
I know I am a bit late on the party.
But I have a question...
Consider this test case:
$ cat test.c
struct s {
int a, b;
} __attribute__((aligned(8)));
struct s f0;
int f(int a, int b, int c, int d, int e, struct s f)
{
f0 = f;
return __alignof(f);
}
$ arm-linux-gnueabihf-gcc -march
On 1/26/19, Jakub Jelinek wrote:
> Hi!
>
> The following 4 define_insn shuffle patterns don't have sufficient
> conditions. As can be seen even from the way how they transform the
> RTL representation into the mask, e.g.:
> mask = INTVAL (operands[3]) / 2;
> mask |= INTVAL (operands[5]) / 2 <
On Sat, Jan 26, 2019 at 10:42 PM Jerry DeLisle
wrote:
> Committed as simple and obvious. (With a ChangeLog Bobble fixed)
>
> Regression tested on x86_64.
>
> Committed r268301
> M libgfortran/ChangeLog
> M libgfortran/io/close.c
>
> Regards,
>
> Jerry
>
> 2019-01-26 J
22 matches
Mail list logo
