[PATCH][OBVIOUS] Add IntegerRange for Wcatch-value= option.

Hi. This is small documentation fix, I'm going to install the patch as obvious. Now we display: $ ./xg++ -B. --help=c++ | grep catch-value= -Wcatch-value Warn about catch handlers of non-reference type. Same as -Wcatch-value=. -Wcatch-value=<0,3> Warn about catch

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote: > > It would help if you explained why you think it is a good idea > > ignoring the other phi arguments if you have one (or more) where you can > > determine length. > > It's a heuristic that was meant just for the -Wformat-overflow >

[PATCH] Add "native" as a valid option value for -march= on aarch64 (PR driver/83193).

Hi. This is equivalent patch for aarch64 target. I've tested that both as cross compiler and native one. Ready for trunk? Thanks, Martin >From 4fbe17099f8618ddd6a4de2d269ecb6f99625927 Mon Sep 17 00:00:00 2001 From: marxin Date: Tue, 20 Feb 2018 14:14:25 +0100 Subject: [PATCH

Add "native" as a valid option value for -march= on arm (PR driver/83193).

Hi. This is equivalent patch for ARM target. Ready for trunk? Thanks, Martin >From 656a883bc5239439ba80743f15a8df704501ee71 Mon Sep 17 00:00:00 2001 From: marxin Date: Tue, 20 Feb 2018 14:09:22 +0100 Subject: [PATCH 1/3] Add "native" as a valid option value for -march= on arm

Re: [PATCH] Add "native" as a valid option value for -march= on i386 (PR driver/83193).

On 02/20/2018 05:26 PM, Martin Liška wrote: > On 02/20/2018 05:19 PM, Richard Sandiford wrote: >> Jakub Jelinek writes: >>> On Tue, Feb 20, 2018 at 03:58:07PM +, Richard Sandiford wrote: Martin Liška writes: > Hi. > > Following patch adds

Re: [PATCH][i386] Adjust vec_construct cost for AVX256/512, penaltize elementwise load vectorization

Hello Richard, On 14 фев 11:26, Richard Biener wrote: > > The following tries to account for the fact that when constructing > AVX256 or AVX512 vectors from elements we can only use insertps to > insert into the low 128bits of a vector but have to use > vinserti128 or vinserti64x4 to build larger

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478, take 2 and 3)

On 02/20/2018 02:34 PM, Jakub Jelinek wrote: > On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote: >> A safer and even more conservative alternative that should be >> equivalent to your approach while avoiding the sprintf regressions >> is to add another mode to the function and have it

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478, take 2 and 3)

On 02/20/2018 02:34 PM, Jakub Jelinek wrote: > On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote: >> A safer and even more conservative alternative that should be >> equivalent to your approach while avoiding the sprintf regressions >> is to add another mode to the function and have it

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

On 02/20/2018 12:03 PM, Martin Sebor wrote: >> The thing that isn't handled conservatively is PHIs and COND_EXPR. >> The current code, if we can't figure one of the args out, for PHIs in >> fuzzy mode increases the *maxval value to +INF, but doesn't touch >> *minval, for COND_EXPR doesn't adjust

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

On 02/20/2018 01:13 PM, Martin Sebor wrote: > On 02/20/2018 12:03 PM, Martin Sebor wrote: >> On 02/20/2018 10:17 AM, Jakub Jelinek wrote: >>> Hi! >>> >>> The following testcase distilled from pdftex is miscompiled on i?86, >>> because gimple_fold_builtin_strlen sets incorrect value range on >>>

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

On 02/20/2018 05:14 PM, Jakub Jelinek wrote: > On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote: >>> It would help if you explained why you think it is a good idea >>> ignoring the other phi arguments if you have one (or more) where you can >>> determine length. >> >> It's a heuristic

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

On 02/20/2018 04:59 PM, Martin Sebor wrote: >> It would help if you explained why you think it is a good idea >> ignoring the other phi arguments if you have one (or more) where you can >> determine length. > > It's a heuristic that was meant just for the -Wformat-overflow > warning.  When making

Re: [PR middle-end/82123] 00/06 Use EVRP range data in sprintf warnings

On 02/20/2018 05:00 PM, Joseph Myers wrote: > Does this help with any of the cases in bug 80776 that weren't already > fixed, or are those distinct despite looking similar? > I don't think so. THe __builtin_unreachable markers are removed by vrp1 -- well before the sprintf warning code gets

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

On 02/20/2018 05:14 PM, Jakub Jelinek wrote: On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote: It would help if you explained why you think it is a good idea ignoring the other phi arguments if you have one (or more) where you can determine length. It's a heuristic that was meant

[PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478, take 2 and 3)

On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote: > A safer and even more conservative alternative that should be > equivalent to your approach while avoiding the sprintf regressions > is to add another mode to the function and have it clear *minlen > as an option. This lets the

Re: RFA: Sanitize deprecation messages (PR 84195)

On 02/20/2018 05:48 AM, Nick Clifton wrote: Hi Martin, Since the class manages a resource it should ideally make sure it doesn't try to release the same resource multiple times. I.e., its copy constructor and assignment operators should either "do the right thing" (whatever you think that

Re: [PR middle-end/82123] 00/06 Use EVRP range data in sprintf warnings

Does this help with any of the cases in bug 80776 that weren't already fixed, or are those distinct despite looking similar? -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

It would help if you explained why you think it is a good idea ignoring the other phi arguments if you have one (or more) where you can determine length. It's a heuristic that was meant just for the -Wformat-overflow warning. When making decisions that affect code generation it's obviously not

Re: plugin-api.h patch to add a new interface for linker plugins

> 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. I'd say go ahead and apply the patch in binutils, and wait for Stage 1 to sync back to GCC, unless someone there OKs it sooner. Nick, is that OK? -cary

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478, take 2 and 3)

On 02/20/2018 02:34 PM, Jakub Jelinek wrote: On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote: A safer and even more conservative alternative that should be equivalent to your approach while avoiding the sprintf regressions is to add another mode to the function and have it clear

[committed] Add testcase for PR c++/84488

Hi! This testcase got fixed in r257155 aka PR83942, but unlike the PR83942 testcase which regressed during 8.x stage1 this one used to fail before too, so I think it is worth adding another testcase for it. Tested on x86_64-linux, committed to trunk as obvious. 2018-02-20 Jakub Jelinek

Re: [PATCH v2] RISC-V: Support for FreeBSD

On Sat, Feb 17, 2018 at 7:08 PM, Kito Cheng wrote: > Hi all: > > This patch is version 2 of FreeBSD supporting for RISC-V, Ruslan > (RISC-V FreeBSD maintainer) and me has been tested on FreeBSD 12 > for building kernel and whole user space programs/libraries again :) This

Re: [PATCH] libgcc: xtensa: fix build with -mtext-section-literals

On Wed, Feb 7, 2018 at 2:10 PM, Max Filippov wrote: > On Thu, Feb 1, 2018 at 9:12 AM, Max Filippov wrote: >> On Wed, Jan 31, 2018 at 11:17 AM, Max Filippov wrote: >>> On Wed, Jan 31, 2018 at 11:11 AM, augustine.sterl...@gmail.com >>>

Re: Extend aligned_membuf<> usage

On 20/02/2018 20:59, Jonathan Wakely wrote: On 8 February 2018 at 06:10, François Dumont wrote: On 06/02/2018 20:16, François Dumont wrote: On 05/02/2018 18:16, Jonathan Wakely wrote: Wouldn't it make more sense to simply make __aligned_buffer identical to __aligned_membuf for the

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

On Tue, Feb 20, 2018 at 12:03:26PM -0700, Martin Sebor wrote: > PR tree-optimization/84478 - [8 Regression] pdftex miscompilation on i386 > > gcc/ChangeLog: > > PR tree-optimization/84478 > * gimple-fold.c (get_range_strlen): Set *MINLEN to zero. > (get_range_strlen): Reset

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

On 02/20/2018 12:03 PM, Martin Sebor wrote: On 02/20/2018 10:17 AM, Jakub Jelinek wrote: Hi! The following testcase distilled from pdftex is miscompiled on i?86, because gimple_fold_builtin_strlen sets incorrect value range on strlen call on SSA_NAME with def_stmt of PHI <"mu", something>

Re: Extend aligned_membuf<> usage

On 8 February 2018 at 06:10, François Dumont wrote: > On 06/02/2018 20:16, François Dumont wrote: >> >> On 05/02/2018 18:16, Jonathan Wakely wrote: >>> >>> Wouldn't it make more sense to simply make __aligned_buffer identical >>> to __aligned_membuf for the versioned-namespace? Then at least the

Re: [patch, fortran] Fix character length in constructors

Am 20.02.2018 um 20:10 schrieb Janne Blomqvist: Shouldn't the second one be "stop 2"? Corrected, r257859. Regards Thomas

Re: [RFC] Tree Loop Unroller Pass

On Mon, Feb 12, 2018 at 3:55 PM, Kugan Vivekanandarajah wrote: > Implements tree loop unroller using the infrastructure provided. > > gcc/ChangeLog: > > 2018-02-12 Kugan Vivekanandarajah > > * Makefile.in (OBJS): Add

Re: [PATCH] RL78 one_cmplhi2 improvement

Const type promotion is the bane of embedded developers... One thing to try is to use (subreg:QI in a define_expand, so that there's a one_cmplhi2 pattern that expands to two QImode insns that operate on HImode input/outputs via SUBREGs. I don't have high hopes of gcc optimizing this properly

Re: Fix find_widening_optab_handler_and_mode assertion (PR 84406)

On 02/20/2018 10:18 AM, Richard Sandiford wrote: > r254302 tried to clean up find_widening_optab_handler_and_mode > so that it really did only handle widening ops rather than > simple single-mode ones. But this PR shows that I'd fluffed > the MODE_PARTIAL_INT handling. It turns out that all four

Re: [patch, fortran] Fix character length in constructors

On Tue, Feb 20, 2018 at 8:59 PM, Thomas Koenig wrote: > Am 20.02.2018 um 08:51 schrieb Janne Blomqvist: > >> It's better to use gfc_mpz_get_hwi() instead of mpz_get_si(). >> mpz_get_si() returns a long, which is a 32-bit type on win64. >> >> Otherwise Ok with the spelling

Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

On 02/20/2018 10:17 AM, Jakub Jelinek wrote: Hi! The following testcase distilled from pdftex is miscompiled on i?86, because gimple_fold_builtin_strlen sets incorrect value range on strlen call on SSA_NAME with def_stmt of PHI <"mu", something> where we can't determine anything about string

[PATCH][committed][PR middle-end/82123] 06/06 Use EVRP range data in another query

The final patch, and the one that actually fixes 82123/81592. This replaces the final query of global range information with a query into the EVRP range analyzer and adds the new tests. Bootstrapped and regression tested on x86_64-linux-gnu. Jeff * gimple-ssa-sprintf.c (format_integer):

Re: [patch, fortran] Fix character length in constructors

Am 20.02.2018 um 08:51 schrieb Janne Blomqvist: It's better to use gfc_mpz_get_hwi() instead of mpz_get_si(). mpz_get_si() returns a long, which is a 32-bit type on win64. Otherwise Ok with the spelling fix suggested by Steve. Committed as r257856. Thanks to you and Steve for the review and

[PATCH][committed][PR tree-optimization/82123] 05/06 Use EVRP range data in get_int_range.

This is the 5th patch in the series. It updates another global range query to instead use the EVRP range data. Bootstrapped and regression tested on x86_64-linux-gnu. Jeff * gimple-ssa-sprintf.c (get_int_range): Query EVRP range analyzer for range data rather than using global

[PATCH][committed][PR tree-optimization/82123] 04/06 Make vr_values available where needed

This is the 4th patch in the series. It doesn't change the analysis in any way shape or form. It just arranges to pass around the range data to the points where we're going to need it. Bootstrapped and regression tested on x86_64-linux-gnu. Jeff commit

[PATCH][committed][PR tree-optimization/82123] 03/06 Query EVRP range data in sprintf warning pass

This is the 3rd patch in the series. It updates one of the 3 range queries to start using the EVRP computed range data. This one is trivial as it's occurring in a member function where we have direct access to the range analyzer data. Bootstrapped and regression tested on x86_64-linux-gnu.

[PATCH][committed][PR tree-optimization/82123] 02/06 Perform EVRP analysis in sprintf warning pass

This is the second patch in the series to fix 82123/81592. It generates range information within the sprintf warning pass using the EVRP analyzer. We don't use the range information in this patch. This twiddles one test -- adding the calls into the analyzer from the sprintf pass causes us to

[PATCH][committed][PR tree-optimization/82123] 01/06 Do nothing in EVRP analyzer is not optimizing

This is part #1 of the patches to fix 81592/82123. The changes aren't particularly large or invasive, but I already had them broken down internally into distinct chunks, so I'm going to send them out that way. This patch allows the EVRP range analyzer to be safely called even when not

[PR middle-end/82123] 00/06 Use EVRP range data in sprintf warnings

So I'm finally getting back to this. To recap, the issue here is the sprintf pass is querying global range information. As a result the range for the key object is not narrowed by the conditionals leading to the sprintf call and we get a false positive (pr81592 and pr82123). The plan for the

Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier

Hi Andre, Thanks for your latest work on CAF features.  Could you let us know whether this commit should be tested against the OpenCoarrays master branch or another branch?  With the master branch, I get one test failure (not counting two known teams failures that are actually false negatives

[PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478)

Hi! The following testcase distilled from pdftex is miscompiled on i?86, because gimple_fold_builtin_strlen sets incorrect value range on strlen call on SSA_NAME with def_stmt of PHI <"mu", something> where we can't determine anything about string length of something, so the right value range is

Re: [PATCH] Add "native" as a valid option value for -march= on i386 (PR driver/83193).

On Tue, Feb 20, 2018 at 03:58:07PM +, Richard Sandiford wrote: > Martin Liška writes: > > Hi. > > > > Following patch adds "native" as a possible option for -march value on > > i386 target. I have similar patches for other targets. Would it be > > possible to install the

Re: plugin-api.h patch to add a new interface for linker plugins

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 patch was approved for binutils by Cary: >

[Patch] Document __builtin_extend_pointer

While working on PR 83335 I proposed a change to a test case that used __builtin_extend_pointer and Richared Earnshaw pointed out that this builtin is not documented.  Since I could not find any other (reasonable) way to generate an extended address in inline assembly other than this builtin I

Fix find_widening_optab_handler_and_mode assertion (PR 84406)

r254302 tried to clean up find_widening_optab_handler_and_mode so that it really did only handle widening ops rather than simple single-mode ones. But this PR shows that I'd fluffed the MODE_PARTIAL_INT handling. It turns out that all four combinations of:

Make fix for PR 83965 handle SLP reduction chains

This patch prevents pattern-matching of fold-left SLP reduction chains, which the previous patch for 83965 didn't handle properly. It only stops the last statement in the group from being matched, but that's enough to cause the group to be dissolved later. A better fix would be to put all the

Re: [PATCH] Add "native" as a valid option value for -march= on i386 (PR driver/83193).

On 02/20/2018 05:19 PM, Richard Sandiford wrote: > Jakub Jelinek writes: >> On Tue, Feb 20, 2018 at 03:58:07PM +, Richard Sandiford wrote: >>> Martin Liška writes: Hi. Following patch adds "native" as a possible option for -march value on

Re: [PATCH] Add "native" as a valid option value for -march= on i386 (PR driver/83193).

Jakub Jelinek writes: > On Tue, Feb 20, 2018 at 03:58:07PM +, Richard Sandiford wrote: >> Martin Liška writes: >> > Hi. >> > >> > Following patch adds "native" as a possible option for -march value on >> > i386 target. I have similar patches for other

Re: [PATCH] Add "native" as a valid option value for -march= on i386 (PR driver/83193).

Martin Liška writes: > Hi. > > Following patch adds "native" as a possible option for -march value on > i386 target. I have similar patches for other targets. Would it be > possible to install the patch in current stage? [...] > diff --git a/gcc/config/i386/i386.c

Re: [RFC] Tree loop unroller pass

Hi, On Fri, 16 Feb 2018, Wilco Dijkstra wrote: > > How so? > > I thought it is well-known for many years that the rtl unroller doesn't > work properly. In practically all cases where LLVM beats GCC, it is due > to unrolling small loops. I thought it was because of vectorizing at -O2, not due

libgo patch committed: Check for preemption in fast syscall return

This libgo patch checks for preemption in the fast return path from a system call. This helps with tight loops that make system calls, as in BenchmarkSyscallExcessWork. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE

Re: [patch, fortran] Fix character length in constructors

On Tue, Feb 20, 2018 at 09:51:14AM +0200, Janne Blomqvist wrote: > On Tue, Feb 20, 2018 at 12:41 AM, Thomas Koenig wrote: > > Hello world, > > > > when putting in a seemingly innocent simplification for PR 56342, > > I caused a regression in PR 82823, in PACK. The root

Go patch committed: Look through aliases for type compatibility

In Go, aliases are supposed to be identical to the type being aliased, so questions about type compatibility need to always ignore aliases, except for error messages involving the type name. This patch implements that. This test case for this is https://golang.org/cl/94995. This fixes

[PATCH] [ARC] Cleanup unused functions.

From: Claudiu Zissulescu Cleanup unsed functions and macros. OK to apply? Claudiu gcc/ 2018-01-26 Claudiu Zissulescu * config/arc/arc.c (arc_finalize_pic): Remove function. (arc_must_save_register): We use single base PIC

Re: Fixed incorrect TARGET_MEM_REF alignment (PR 84419)

On February 20, 2018 10:43:40 AM GMT+01:00, Richard Sandiford wrote: >expand_call_mem_ref checks for TARGET_MEM_REFs that have compatible >type, but it didn't then go on to install the specific type we need, >which might have different alignment due to: > > if

[PATCH] Add "native" as a valid option value for -march= on i386 (PR driver/83193).

Hi. Following patch adds "native" as a possible option for -march value on i386 target. I have similar patches for other targets. Would it be possible to install the patch in current stage? Before: $ ./xgcc -B. -march=abcdef /tmp/empty.c cc1: error: bad value (‘abcdef’) for ‘-march=’ switch

Re: [PATCH] Defer pow (C, x) folding until after vectorization always (PR middle-end/82004)

On February 19, 2018 11:02:50 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >While I've over-simplified the testcase and so this patch doesn't help >the 628.pop2_s miscompare, I still believe it is beneficial to defer >this >folding until late for these reasons: >1) if we propagate

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Martin, > Since the class manages a resource it should ideally make sure it > doesn't try to release the same resource multiple times.  I.e., its > copy constructor and assignment operators should either "do the right > thing" (whatever you think that is) or be made inaccessible (or declared

Re: [PATCH] Fix missing info for -march and -mtune wrong values on aarch64 (PR driver/83193).

On Tue, Feb 20, 2018 at 01:05:33PM +0100, Martin Liška wrote: > Hi. > > This is fix for one of multiple issues seen in the PR. Note that I also have > some patches > for the others, but it's not stage4 material in my opinion. > This one is quite obvious and should land in GCC 8. > > Output

Re: [PATCH] Add limit for maximal alignment options (PR c/84310).

On Tue, Feb 20, 2018 at 11:05:50AM +0100, Martin Liška wrote: > Thanks Jakub! > Would it be possible to backport that to active branches? Yes, but give it some time on the trunk first. Jakub

Re: [PATCH] Fix missing info for -march and -mtune wrong values on aarch64 (PR driver/83193).

On 02/20/2018 01:09 PM, Jakub Jelinek wrote: > On Tue, Feb 20, 2018 at 01:05:33PM +0100, Martin Liška wrote: >> Hi. >> >> This is fix for one of multiple issues seen in the PR. Note that I also have >> some patches >> for the others, but it's not stage4 material in my opinion. >> This one is

[PATCH] RL78 one_cmplhi2 improvement

Hello, The following patch defines one_cmplhi2 pattern. The improvement does not come from the two xor instructions used (in fact for the second xor the pattern uses xor saddr , #byte is used which is 1 bytes longer than xor a, #byte) it comes from the fact that that the number of move

[PATCH] Fix missing info for -march and -mtune wrong values on aarch64 (PR driver/83193).

Hi. This is fix for one of multiple issues seen in the PR. Note that I also have some patches for the others, but it's not stage4 material in my opinion. This one is quite obvious and should land in GCC 8. Output before: $ ./xgcc -B. -march=sparta /tmp/main.c cc1: error: unknown value ‘sparta’

Re: [PATCH] c++: Fix spurious fallthrough warning on break

On Tuesday 20 February 2018 03:14 PM, Jakub Jelinek wrote: > On Mon, Feb 19, 2018 at 09:59:00PM +0530, Siddhesh Poyarekar wrote: >> The C++ frontend generates a break that results in the fallthrough >> warning misfiring in nested switch blocks where cases in the inner >> switch block return,

Re: Mising Patch #2 from the RISC-V v3 Submission

On Feb 15 2018, Palmer Dabbelt wrote: > On Mon, 12 Feb 2018 15:18:39 PST (-0800), Jim Wilson wrote: >> On 02/12/2018 03:23 AM, Andreas Schwab wrote: >>> On Feb 06 2017, Palmer Dabbelt wrote: >>> +/* Because RISC-V only has word-sized atomics, it

Re: [PATCH] Add limit for maximal alignment options (PR c/84310).

On 02/20/2018 09:43 AM, Jakub Jelinek wrote: > On Mon, Feb 12, 2018 at 01:09:43PM +0100, Martin Liška wrote: >> Following patch fixes 2 issues with -falign-*: >> 1) when using -malign-x=16 (or corresponding -falign-* value) then ICE >> appeared >> as code in final.c can deal just with limited

Re: [PATCH] c++: Fix spurious fallthrough warning on break

On Mon, Feb 19, 2018 at 09:59:00PM +0530, Siddhesh Poyarekar wrote: > The C++ frontend generates a break that results in the fallthrough > warning misfiring in nested switch blocks where cases in the inner > switch block return, rendering the break pointless. The fallthrough > detection in

Fixed incorrect TARGET_MEM_REF alignment (PR 84419)

expand_call_mem_ref checks for TARGET_MEM_REFs that have compatible type, but it didn't then go on to install the specific type we need, which might have different alignment due to: if (TYPE_ALIGN (type) != align) type = build_aligned_type (type, align); This was causing masked stores to

Re: [PATCH] c++: Fix spurious fallthrough warning on break

On Monday 19 February 2018 09:59 PM, Siddhesh Poyarekar wrote: > The C++ frontend generates a break that results in the fallthrough > warning misfiring in nested switch blocks where cases in the inner > switch block return, rendering the break pointless. The fallthrough > detection in

Re: [PATCH] Add limit for maximal alignment options (PR c/84310).

On Mon, Feb 12, 2018 at 01:09:43PM +0100, Martin Liška wrote: > Following patch fixes 2 issues with -falign-*: > 1) when using -malign-x=16 (or corresponding -falign-* value) then ICE > appeared > as code in final.c can deal just with limited alignment. > 2) thus I also documented and limited the

Re: [PATCH] Add limit for maximal alignment options (PR c/84310).

PING^1 On 02/12/2018 01:09 PM, Martin Liška wrote: > Hi. > > Following patch fixes 2 issues with -falign-*: > 1) when using -malign-x=16 (or corresponding -falign-* value) then ICE > appeared > as code in final.c can deal just with limited alignment. > 2) thus I also documented and limited the