Re: [patch][i386, AVX] Adding missing mask[z]_range[_round]_s[d,s] intrinsics

Hello Olga, On 04 Dec 09:44, Makhotina, Olga wrote: > Hi, > > This patch adds missing intrinsics for _mm_mask[z]_range[_round]_[sd,ss]. > > 04.12.2017 Olga Makhotina  > > gcc/ > * config/i386/avx512dqintrin.h (_mm_mask_range_sd, _mm_maskz_range_sd, > _mm_mask_range_round_sd, _mm_mas

Fix some _GLIBCXX_DEBUG pretty printer errors

Hi     Here is a patch to fix some pretty printer check errors when running those tests with _GLIBCXX_DEBUG.     I introduced a special rendered for the std::forward_list iterator which is similar to the one used for the std::list and so used inheritance, I hope it is not a problem for Pytho

Go patch committed: Update iota handling to current spec

This patch to the Go frontend updates the handling of iota to the current language spec; it was modified slightly in https://golang.org/cl/71750. Also, the Go frontend has been mishandling iota appearing in a type that appears in a const expression, as in `c = len([iota]int{})`. Correct that by c

Go patch committed: Permit empty statements after a fallthrough statement

This patch to the Go frontend permits empty statements after a fallthrough statement, as the language spec specifies. This also gives a better error message when a fallthrough statement is in the wrong place. The test case for this is in the master repository, test/fixedbugs/issue14540.go, just n

Go patch committed: In range, evaluate array if it has receives or calls

The recent patch to the Go frontend to not evaluate an array value in a range statement with a single iteration variable was too aggressive. The array value should be evaluated if the expression has any calls or receive expressions. This patch fixes that, reusing the existing code that checks whet

Go patch committed: Give error for non-int arguments to make

This patch fixes the Go frontend to issue an error for non-int arguments to make. This implements a requirement of the language spec. While we're here fix the value returned by the type method of a builtin call expression to make, although this doesn't seem to make any difference anywhere since w

Go patch committed: Don't error for goto over type or const declaration

This patch to the Go frontend fixes it to not issue an error for a goto over a type or const declaration. The frontend is only supposed to issue such an error for a goto over a var declaration. The test case for this is already in the master repository, at test/fixedbugs/issue8042.go. It just ha

Go patch committed: Correct parse of parenthesized select case

This patch to the Go frontend corrects parsing of parenthesized select cases. The frontend used to mishandle `select { case (<-c): }` and friends. The test case for this is https://golang.org/cl/91657. This fixes https://golang.org/issue/20923. Bootstrapped and ran Go testsuite on x86_64-pc-lin

libgo patch committed: Don't drop last flag from _cgo_flags entry in archive

This libgo patch fixes cmd/go: the quoting code that read _cgo_flags, currently only in the gccgo version of cmd/go, was losing the last flag read from the file. This fixes https://golang.org/issue/23666. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index:

[RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

To resolve the underlying root cause of the P1 bug c++/83503 - bogus -Wattributes for const and pure on function template specialization, that we discussed last week, I've taken a stab at making the change to avoid applying primary template's attributes to its explicit specializations. (The bug t

[patch, libfortran] Use flexible array members for array descriptor

Hello world, in the attached patch, I have used flexible array members for using the different descriptor types (following Richi's advice). This does not change the binary ABI, but the library code maches what we are actually doing in the front end. I have not yet given up hope of enabling LTO f

Add testcase for PR79966

Hi, the testcase triggers problem with inlining heuristics where time is capped and thus inlining into function makes it look not very cool for inlining further. This is solved by the profile code reorg and thus the testcase works as expected now. regtested x86_64-linux, comitted. PR midd

Re: [PATCH] WebAssembly: Disable subdirectory configuration for unsupported LD

Hello Maciej, thank you for looking at this code! The change looks obviously correct to me. Regards Pip On Sat, Feb 3, 2018 at 3:16 PM, Maciej W. Rozycki wrote: > Remove an LD subdirectory configuration error: > > *** ld does not support target wasm32-unknown-none > *** see ld/configure.tgt for

[Patch, fortran] PR84115] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256

Committed a partial patch as 'obvious' in revision 257363. Oddly, the failing test in associate_35.f90 is the only one that works in 7-branch. I have left the PR open and changed the title accordingly. Paul 2018-02-04 Paul Thomas PR fortran/84115 * trans-decl.c (gfc_get_symbol_decl):

Re: [RFA PATCH] Bug 84094 - several correctness issues in gfortran.dg

Hi Dominique, The patch is OK. By all means open the PR for the missing/confusing diagnostics. Thanks Paul On 4 February 2018 at 13:01, Dominique d'Humières wrote: > Is the following patch OK? For associate_23.f90 I have restricted should_work > to two elements, an alternative would be to u

New Spanish PO file for 'gcc' (version 8.1-b20180128)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-8.1-b20180128.es.po',

[RFA PATCH] Bug 84094 - several correctness issues in gfortran.dg

Is the following patch OK? For associate_23.f90 I have restricted should_work to two elements, an alternative would be to use ASSOCIATE(should_work=>char_var_dim(1:3)); any preference? Note that none of these invalid codes are detected by gfortran, except intrinsic_actual_4.f90 which gives a co