On 6/23/19 11:39 AM, 김규래 wrote:
GNU style brace wrapping rules have been added to clang-format quite a while
ago.
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Format/Format.h?revision=197138=markup
This simple patch proposes to use the built-in rules instead of the custom
brace
Hi Honza,
Thanks very much to get so many useful comments from you.
As a newbie to GCC, not sure whether my questions are described clearly
enough. Thanks for your patience in advance. :)
On 2019/6/20 21:47, Jan Hubicka wrote:
Hi,
some comments on the ipa part of the patch
(and thanks for
The attached patch cleans up a number of outstanding -Wformat-diag
instances. I plan to commit it tomorrow.
With it applied, an x86_64-linux bootstrap shows just 79 unique
instances of the warning originating in 17 files. 49 of those are
in the Go front-end that Ian is already dealing with. I
On Fri, Jun 7, 2019 at 5:04 AM Martin Liška wrote:
>
> On 6/7/19 10:57 AM, Richard Biener wrote:
> > On Mon, Jun 3, 2019 at 3:35 PM Martin Liška wrote:
> >>
> >> On 6/1/19 12:06 AM, Jeff Law wrote:
> >>> On 5/22/19 3:13 AM, Martin Liška wrote:
> On 5/21/19 1:51 PM, Richard Biener wrote:
>
This patch to the Go frontend edits various error messages to avoid
-Wformat-diag warnings.
GCC recently introduced -Wformat-diag to scrutinize GCC error
messages. It reports a number of warnings about gofrontend code, such
as:
../../trunk/gcc/go/gofrontend/import.cc: In member function ‘Type*
This patch to the Go frontend adds a new function go_debug and uses it
for debug messages.
GCC recently added a new warning -Wformat-diag which does a lot of
rigorous checks on GCC diagnostic messages. This produces a number of
unnecessary diagnostics on gofrontend diagnostic output, such as:
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
initialization introduced a couple of bugs.
Dear all,
the attached patch provides run-time checks for the bit manipulation
intrinsic functions (IBSET/IBCLR/BTEST/SHIFT[RLA]/ISHFT/ISHFTC).
I am using only one testcase whose purpose is mainly to verify that
there are no false positives, which I consider essential, and one
"failing" test at
This cannot pass for current Darwin, since it requires VSX and we don't have
any hardware supporting that. The “fix” is to add a dg-requires clause for
this.
2019-06-23 Iain Sandoe
* gcc.target/powerpc/builtins-2.c: Require VSX hardware support.
diff --git
Darwin (unlike most of the members of the PowerPC port family)
defaults to signed chars, so the test was failing to compile with
a "mismatched parameters" error.
tested on powerpc-darwin9, powerpc-linux-gnu
applied to mainline
thanks
Iain
2019-06-23 Iain Sandoe
*
The test needs to account for Darwin's __USER_LABEL_PREFIX__.
tested on powerpc-darwin9, powerpc-linux-gnu
applied to mainline
thanks
Iain
2019-06-23 Iain Sandoe
* gcc.target/powerpc/builtins-1.c: Account for Darwin's use of
__USER_LABEL_PREFIX__.
diff --git
Primarily, for compatibility with other members of the port.
Note, that we do not handle the longcall attribute, since longcall is not
required/used on current Darwin (supported only for legacy cases).
2019-06-23 Iain Sandoe
* config/rs6000/darwin.h: Handle GCC target pragma.
diff
Emit __PPC__ (32b) and __PPC64__ (64bit) as per the other members
of the PowerPC port. Darwin has always emitted __ppc__ and __ppc64__
but some testcases rely on the upper case variants.
tested on powerpc-darwin9, applied to mainline.
thanks
Iain
2019-06-23 Iain Sandoe
*
The test was failing with false positive for the scan-assembler-not.
Firstly, we adjust the test conditions to use non-PIC code for Darwin.
Secondly, we have to account for out-of-line GPR restores which gives
a false positive on the scan-assembler-not. Lastly, we make the test a
bit more
* Claudiu Zissulescu [2019-06-06 10:32:11 +0300]:
> Hi Andrew,
>
> This is a proposed fix for bugzilla PR89838 issue. It also needs to be
> backported to gcc9 and, eventually, gcc8 branches.
>
> Ok to apply?
> Claudiu
I had a look through the patch and found just one small nit detailed
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 to handle functions found by a using declaration, for various
reasons. In particular, we
This patch tries to make sure that, when optimising at -Og, the gimple
IL has appropriate debug information for the whole of a variable's scope.
It does the same for parameters in functions that always return (but still
misses cases in functions that don't return -- a TODO for later).
The idea is
This patch adds an option called -O1g, a half-way house between
-Og and -O1 in terms of both performance and debuggability.
2019-06-23 Richard Sandiford
config/
* bootstrap-O1g.mk: New file.
gcc/
* common.opt (O1g): New option.
* doc/invoke.texi: Document it.
This patch adds a mode in which debug stmts and debug insns are
explicitly allowed to affect codegen. In particular:
- uses in debug binds become first-class uses, acting like uses in
executable code
- the use of DEBUG_EXPR_DECLs is banned. If we want to refer to
a temporary value in debug
-Og is documented as:
@option{-Og} should be the optimization
level of choice for the standard edit-compile-debug cycle, offering
a reasonable level of optimization while maintaining fast compilation
and a good debugging experience. It is a better choice than @option{-O0}
for producing
Hi,
here there are a couple of rather straightforward improvements in the
second half of grokdeclarator plus a check_tag_decl change consistent
with the other existing case of multiple_types_p diagnostic. Tested
x86_64-linux.
Thanks, Paolo.
/
/cp
2019-06-23 Paolo
... 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 to handle functions found by a using declaration, for various
reasons. In particular, we know whether we found a function fn where
> I opened:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90952
>
> We shouldn't use costs for moves for costs of RTL expressions. We can
> experiment different RTL expression cost formulas. But we need to separate
> costs of RTL expressions from costs for moves first. What is the best
GNU style brace wrapping rules have been added to clang-format quite a while
ago.
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Format/Format.h?revision=197138=markup
This simple patch proposes to use the built-in rules instead of the custom
brace rules.
Ray Kim
2019-06-27 Ray
24 matches
Mail list logo
