On Sat, Dec 8, 2018 at 12:57 AM Jan Hubicka wrote:
>
> > Hi Honza,
> > I have committed the typo fix as revision 266885.
> > Also I followed your suggestion (IIUC) by calling
> > profile_count::adjust_for_ipa_scaling for zero den in function
> > update_profiling_info. It works and does make more
A named constant cannot be a data object. The committed
patch catches an instance that should be caught.
2018-12-08 Steven G. Kargl
PR fortran/88048
* resolve.c (check_data_variable): Named constant cannot be a
data object.
2018-12-08 Steven G. Kargl
PR fo
An inquiry parameter cannot be a data object.
20180-12-08 Steven G. Kargl
PR fortran/87945
* decl.c (var_element): Inquiry parameters cannit be data objects.
20180-12-08 Steven G. Kargl
PR fortran/87945
* gfortran.dg/pr87945_1.f90: New test.
* gfort
The attach patch guards against a NULL pointer deference
and removes asserts that cannot trigger.
2018-12-08 Steven G. Kargl
PR fortran/88025
* expr.c (gfc_apply_init): Remove asserts that cannot trigger.
Check for a NULL pointer.
2018-12-08 Steven G. Kargl
I noticed I accidentally copied a line too many from the "volatile"
handling to the "inline" handling. This fixes it.
Tested on powerpc64-linux {-m32,-m64}; committing as trivial and obvious.
Segher
2018-12-08 Segher Boessenkool
gcc/c/
* c-parser (c_parser_asm_statement) [RID_INLI
Hi folks,
I was bitten by this, and it seemed like a few people online had similar
issues (for example https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794).
We run a configure script from another configure script, to generate
auto-build.h.
Secondary configure might fail.
This failure isn't fatal,
On Sat, 8 Dec 2018 at 20:05, Ville Voutilainen
wrote:
> > New compiler releases will usually include new warnings that require
> > some code modification to accommodate. Why is this one particularly
> > problematic?
>
> I don't think it's any more problematic than any other warning that
> introd
On 12/7/18 1:10 AM, Richard Biener wrote:
On Thu, 6 Dec 2018, Martin Sebor wrote:
On 12/5/18 7:58 AM, Richard Biener wrote:
On Wed, 5 Dec 2018, Jeff Law wrote:
On 12/4/18 6:16 AM, Richard Biener wrote:
This tries to make bugs like that in PR88317 harder to create by
introducing a bitmap_re
Invalid code can cause the gfortran to dereference NULL pointers.
The patch fixes this.
2018-12-08 Steven G. Kargl
PR fortran/88357
* class.c (insert_component_ref): Check for NULL pointer and
previous error message issued.
* parse.c (parse_associate): Check fo
On Sat, 8 Dec 2018 at 19:53, Jason Merrill wrote:
> The documented policy for -Wall is,
>
> This enables all the warnings about constructions that some users
> consider questionable, and that are easy to avoid (or modify to
> prevent the warning), even in conjunction with macros.
>
On Sat, Dec 8, 2018 at 12:17 PM Ville Voutilainen
wrote:
> On Sat, 8 Dec 2018 at 18:58, Jakub Jelinek wrote:
> > > g++ -c -pipe -O2 -fPIC -std=c++1z -fvisibility=hidden
> > > -fvisibility-inlines-hidden -ffunction-sections -fdata-sections
> > > -fno-exceptions -Wall -W -Wvla -Wdate-time -Wshift-o
On 12/7/18 1:06 AM, Richard Biener wrote:
On Thu, 6 Dec 2018, Martin Sebor wrote:
On 12/6/18 2:26 PM, Jakub Jelinek wrote:
On Thu, Dec 06, 2018 at 01:21:58PM -0700, Martin Sebor wrote:
Bug 88372 - alloc_size attribute is ignored on function pointers
points out that even though the alloc_size
On Sat, 8 Dec 2018 at 18:58, Jakub Jelinek wrote:
> > g++ -c -pipe -O2 -fPIC -std=c++1z -fvisibility=hidden
> > -fvisibility-inlines-hidden -ffunction-sections -fdata-sections
> > -fno-exceptions -Wall -W -Wvla -Wdate-time -Wshift-overflow=2
>
> -W is an alias to -Wextra.
Yeah. Jason, I seem to h
On Sat, Dec 08, 2018 at 06:46:27PM +0200, Ville Voutilainen wrote:
> On Thu, 6 Dec 2018 at 23:12, Jason Merrill wrote:
> >
> > -Wdeprecated-copy does find some real bugs, but it also complains
> > about a lot of reasonable code for which the implicitly declared copy
> > ctor/op= are fine oven thou
On Thu, 6 Dec 2018 at 23:12, Jason Merrill wrote:
>
> -Wdeprecated-copy does find some real bugs, but it also complains
> about a lot of reasonable code for which the implicitly declared copy
> ctor/op= are fine oven though the class has a user-defined destructor:
> this situation is only problema
On 12/8/18 5:14 AM, Richard Sandiford wrote:
> Andrew Stubbs writes:
>> On 21/11/2018 00:47, Jeff Law wrote:
>>> This seems like a really gross hack and sets an expectation that
>>> generating registers in the target after IRA has started is OK. It is
>>> not OK. THe fact that this works is, IMH
On December 8, 2018 10:10:22 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>Unlike convert_nonlocal_reference_stmt, convert_local_reference_stmt
>already
>had the clobber handling code, but apparently written in times where
>only
>decls were allowed on the lhs and not adjusted when we started allowin
Andrew Stubbs writes:
> On 21/11/2018 00:47, Jeff Law wrote:
>> This seems like a really gross hack and sets an expectation that
>> generating registers in the target after IRA has started is OK. It is
>> not OK. THe fact that this works is, IMHO, likely an accident.
>
> What's the proper test f
Andrew Stubbs writes:
> I finally got back to investigating this
>
> On 21/11/2018 01:00, Jeff Law wrote:
>>> --- a/gcc/testsuite/gcc.dg/gimplefe-28.c
>>> +++ b/gcc/testsuite/gcc.dg/gimplefe-28.c
>>> @@ -1,5 +1,5 @@
>>> /* { dg-do compile { target sqrt_insn } } */
>>> -/* { dg-options "-fgi
Hi!
On Fri, Dec 07, 2018 at 07:51:35AM +, Niklas DAHLQUIST wrote:
> On 12/1/18 1:15 AM, Jeff Law wrote:
> > One could argue that allocating stack space inside an ASM is a really
> > bad idea. Consider things like dwarf debugging and unwind tables. If
> > you're allocating stack inside an ASM
This is the failure of g++.dg/tree-prof/pr57451.C on the SPARC, caused by the
-freorder-blocks-and-partition RTL optimization. The optimization splits the
getData function into hold and cold parts, with the cold part throwing an
exception. Now the CFI for the cold part is emitted as a second,
Hi!
Unlike convert_nonlocal_reference_stmt, convert_local_reference_stmt already
had the clobber handling code, but apparently written in times where only
decls were allowed on the lhs and not adjusted when we started allowing
MEM_REFs in there. use_pointer_in_frame certainly ICEs if it is called
On Thu, Sep 27, 2018 at 01:15:46AM -0400, Jason Merrill wrote:
> >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:33:26:
> >> error: non-constant condition for static assertion
> >> /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:33:23:
> >
Hi!
The second part of the cancel-taskgroup-3.c ICEs on hosts that have more
than 64 CPUs (cores or threads). The problem is that the cancellation of
the taskgroup happens in the worksharing loop that iterates 64 times only,
so if each thread invokes just a single iteration, threads 64 and above
24 matches
Mail list logo
