[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Janne Blomqvist --- Fixed on trunk, closing.
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705 Dominique d'Humieres changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Dominique d'Humieres --- > Regression fixed on trunk. > > repeat with larger counts than were previously possible can be tracked > under PR 66310. Revision r257281 does not fix the ICE when using PARAMETER (pr78534): f951: internal compiler error: Segmentation fault: 11 nor the ICE for the second test in comment 0: internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:148 7.3.0 gives the error: Error: Argument NCOPIES of REPEAT intrinsic is too large at (1)
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157
--- Comment #4 from Tom de Vries ---
(In reply to Uroš Bizjak from comment #3)
> Oops.
>
> --cut here--
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 970dd26..a9929f2 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -11483,7 +11483,7 @@ change_zero_ext (rtx pat)
>
> if (mode != inner_mode)
> {
> - if (HARD_REGISTER_P (x)
> + if (REG_P (x) && HARD_REGISTER_P (x)
> && !can_change_dest_mode (x, 0, mode))
> continue;
>
> @@ -11501,7 +11501,7 @@ change_zero_ext (rtx pat)
> x = SUBREG_REG (XEXP (x, 0));
> if (GET_MODE (x) != mode)
> {
> - if (HARD_REGISTER_P (x)
> + if (REG_P (x) && HARD_REGISTER_P (x)
> && !can_change_dest_mode (x, 0, mode))
> continue;
>
> --cut here--
After rebuilding cc1 with the patch in place, the ICE no longer occurs on the
attached test-case.
I'll do a build and test run with this patch (which in the case of the setup
where I encountered the ICE means building host and accelerator compiler and
running libgomp testsuite), and report back.
[Bug preprocessor/84161] New: preprocessor should discard Fortran comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84161 Bug ID: 84161 Summary: preprocessor should discard Fortran comments Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Consider this Fortran test case: #define _ASSERT_(a, b) if (.not. (a)) print *, b program preproc_test ! _ASSERT_() is a nice macro :) end Putting this into an .F90 file and compiling with gfortran results in this error: ! _ASSERT_() is a nice macro :) Error: macro "_ASSERT_" requires 2 arguments, but only 1 given The GCC preprocessor apparently ignores comments by default (at least with C/C++, as documented in https://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-Options.html), so this should also work with Fortran.
[Bug libgomp/84041] [nvptx] Hang in for-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84041 --- Comment #3 from Tom de Vries --- Hmm, with the latest trunk and after upgrading to driver version 390.25, for-3.exe passes.
[Bug tree-optimization/84013] wrong __restrict clique with inline asm operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84013
--- Comment #3 from rguenther at suse dot de ---
On Wed, 31 Jan 2018, katsunori.kumatani at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84013
>
> --- Comment #2 from Katsunori Kumatani
> ---
> I'm not familiar with tree-ssa-structalias, but it appears to me that the
> "fix"
> is quite simple? Or am I missing something? Here's the snippet from it,
> updated
> with my attempt:
>
> if (restrict_var)
> {
> /* Now look at possible dereferences of ptr. */
> imm_use_iterator ui;
> gimple *use_stmt;
> bool used = false;
> FOR_EACH_IMM_USE_STMT (use_stmt, ui, ptr)
> {
> if (!gimple_assign_single_p (use_stmt))
> {
> /* ??? Calls. */
> if (gimple_code (use_stmt) != GIMPLE_ASM)
> continue;
>
> gasm *asm_stmt = as_a (use_stmt);
> unsigned n = gimple_asm_ninputs (asm_stmt);
> for (unsigned i = 0; i < n; i++)
> {
> tree op = TREE_VALUE (gimple_asm_input_op (asm_stmt,
> i));
> used |= maybe_set_dependence_info (op, ptr, clique,
> restrict_var,
> last_ruid);
> }
> n = gimple_asm_noutputs (asm_stmt);
> for (unsigned i = 0; i < n; i++)
> {
> tree op = TREE_VALUE (gimple_asm_output_op (asm_stmt,
> i));
> used |= maybe_set_dependence_info (op, ptr, clique,
> restrict_var,
> last_ruid);
> }
> continue;
> }
>
>
> Does this not work? Sorry if I am missing something here.
Yes, this should work. It's not difficult to fix I just thought it
wasn't important to track restrict across asm()s ... A similar
fix is needed for call return and operands. Writing the code
a little nicer and more compact should be possible as well - I
just need to think about it somewhat (similar to the code a bit
below we should be able to use walk_stmt_load_store_ops).
I will deal with this for GCC 9 given this isn't a regression.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #15 from rguenther at suse dot de --- On Wed, 31 Jan 2018, andrewjenner at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 > > Andrew Jenner changed: > >What|Removed |Added > > Status|NEW |ASSIGNED >Assignee|unassigned at gcc dot gnu.org |andrewjenner at gcc > dot gnu.org > > --- Comment #14 from Andrew Jenner --- > I've got most of the major chunks removed now as you can see from my > work-in-progress patch, but I'm still working through a long list of little > things I've noticed that need cleaning up. I'm not sure that the backend will > build with the changes in their current state so I haven't committed them yet, > but I expect to be able to do so by the end of the week. Thanks for your > patience! As said the most important part is to have user-facing things like config/powerpcspe/*.opt pruned from irrelevant stuff as well as a general update for user-facing documentation. Documentation updates could be as simple as duplicating any rs6000 specific documentation and pruning the duplicate from irrelevant parts. This may need re-surrecting removed doc parts (if there were any) and/or pruning SPE parts from rs6000 specific documentation sections. Esp. install.texi and invoke.texi should be audited in that respect. Whether you manage to prune all unreachable code-paths from the implementation is not so important for the GCC 8 release.
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157 --- Comment #5 from Segher Boessenkool --- Hi Tom, That looks good. But maybe the REG_P check should be in the outer "if"? Slightly easier and safer to exit as early as possible.
[Bug c++/84162] New: Internal compiler error: in tsubst, at cp/pt.c:13617 / SEGFAULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84162 Bug ID: 84162 Summary: Internal compiler error: in tsubst, at cp/pt.c:13617 / SEGFAULT Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lumosimann at gmail dot com Target Milestone: --- Created attachment 43316 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43316&action=edit Segfault with flag -DV1 ## Summary Template instantiation leads to internal compile error or segfault. ## GCC version Initially observed on GCC 7.2.1, but reproducible in all versions from 4.7.1 onwards up to 7.3 (compile using godbolt). ## Command g++ -o out compilererror.cpp -std=c++11 -DV1 leads to a segfault and g++ -o out compilererror.cpp -std=c++11 -DV2 leads to an internal compiler error ## Diagnostics # V1: compilererror.cpp: In instantiation of ‘void C::Fail() [with void (C::* f)() = &C::h]’: compilererror.cpp:32:17: required from here compilererror.cpp:25:45: internal compiler error: Segmentation fault typename Object>::fail a; ^ # V2: compilererror.cpp: In instantiation of ‘void C::Fail() [with SomeEnum = (SomeEnum)0; void (C::* f)() = &C::h]’: compilererror.cpp:34:34: required from here compilererror.cpp:25:45: internal compiler error: in tsubst, at cp/pt.c:13617 typename Object>::fail a; ^
[Bug c++/84162] Internal compiler error: in tsubst, at cp/pt.c:13617 / SEGFAULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84162 --- Comment #1 from Lukas Mosimann --- The minimal example is already reduced a lot; until now, I wasn't able to track the error down to an even smaller chunk of code.
[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 --- Comment #16 from Segher Boessenkool --- Darwin has its own ABI, and that is what those assembler routines are for. This has nothing to do with this bug report; please use the mailing lists for other questions/discussions/etc.
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 --- Comment #3 from Alexandre Oliva --- With the current vect alignment computations, we end up using the alignment of the arrays, so on x86_64 it's 256bits (DATA_ALIGNMENT bumps the alignment up) and on ppc64 it's 32bits, no alignment bump. Back on Jul 2, AFAICT we'd miscompute the alignment: dr_analyze_innermost would set up base_iv with the array ptr and the loop increment, and the offset from base, that would have made to offset_iv and from that to DR_ALIGNED_TO, ends up having the constant moved to DR_INIT, and DR_ALIGNED_TO, initialized from a zero offset, ends up as BIGGEST_ALIGNMENT. I don't see that we can proceed to vectorizing the loop if we can't guarantee alignment, so it seems like the so-called regression is actually progress, and it would only have worked at run time by accident. The solution to enable vectorization, AFAICT, is to explicitly specify higher alignment for the arrays in the testcases.
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157 --- Comment #6 from Tom de Vries --- (In reply to Segher Boessenkool from comment #5) > Hi Tom, > > That looks good. Hi, that patch was by Uros though. > But maybe the REG_P check should be in the outer "if"? > Slightly easier and safer to exit as early as possible. I'm not familiar with this code, but AFAIU already before r257270 we can generate a SUBREG of an LSHIFTRT, which is incorrect RTL. And the patch does not fix that, it only fixes the ICE introduces in r257270.
[Bug c++/84162] Internal compiler error: in tsubst, at cp/pt.c:13617 / SEGFAULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84162 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Both is fixed for 8 by r247842.
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157 --- Comment #7 from Segher Boessenkool --- (In reply to Tom de Vries from comment #6) > (In reply to Segher Boessenkool from comment #5) > > That looks good. > that patch was by Uros though. Yes I misread. Uros: that patch is pre-approved. > > But maybe the REG_P check should be in the outer "if"? > > Slightly easier and safer to exit as early as possible. > > I'm not familiar with this code, but AFAIU already before r257270 we can > generate a SUBREG of an LSHIFTRT, which is incorrect RTL. And the patch does > not fix that, it only fixes the ICE introduces in r257270. It doesn't have to be fixed: the generated RTL is passed to recog, which will fail it. That is what combine does with everything (it even creates invalid RTL on purpose to abort combination attempts!) It seems a bit neater and easier and safer to test for REG_P a bit earlier, but the patch is fine as-is.
[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157 --- Comment #8 from Tom de Vries --- (In reply to Tom de Vries from comment #4) > I'll do a build and test run with this patch (which in the case of the setup > where I encountered the ICE means building host and accelerator compiler and > running libgomp testsuite), and report back. Done, no issues found.
[Bug c++/84151] [6/7/8 Regression] g++ generates two identical loads in a volatile-qualified member function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84151
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-01
Target Milestone|--- |6.5
Summary|[4.9/5/6/7 Regression] g++ |[6/7/8 Regression] g++
|generates two identical |generates two identical
|loads in a |loads in a
|volatile-qualified member |volatile-qualified member
|function. |function.
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
The C++ FE generates
;; Function int A::foo() volatile (null)
;; enabled by -tree-original
{
int v;
int v;
;
< = *(volatile struct A *) this;, *A::bar ((int
&) &v);>>;
}
which results in
int A::foo() volatile (volatile struct A * const this)
{
int v;
struct A vol.0;
int _1;
int & _2;
int _8;
[0.00%]:
_1 ={v} this_4(D)->c;
v = _1;
vol.0 ={v} *this_4(D);
_2 = A::bar (&v);
_8 = *_2;
v ={v} {CLOBBER};
return _8;
I'm not sure how the behavior of a volatile this is specified but this
unused copy of *this looks unwarranted.
[Bug fortran/84115] [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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Clearly this is mine. Paul
[Bug tree-optimization/84117] [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Feb 1 10:08:26 2018 New Revision: 257284 URL: https://gcc.gnu.org/viewcvs?rev=257284&root=gcc&view=rev Log: PR tree-optimization/81661 PR tree-optimization/84117 * tree-eh.h (rewrite_to_non_trapping_overflow): Declare. * tree-eh.c: Include gimplify.h. (find_trapping_overflow, replace_trapping_overflow, rewrite_to_non_trapping_overflow): New functions. * tree-vect-loop.c: Include tree-eh.h. (vect_get_loop_niters): Use rewrite_to_non_trapping_overflow. * tree-data-ref.c: Include tree-eh.h. (get_segment_min_max): Use rewrite_to_non_trapping_overflow. * gcc.dg/pr81661.c: New test. * gfortran.dg/pr84117.f90: New test. Added: trunk/gcc/testsuite/gcc.dg/pr81661.c trunk/gcc/testsuite/gfortran.dg/pr84117.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-eh.c trunk/gcc/tree-eh.h trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/81661] [7/8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81661 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Thu Feb 1 10:08:26 2018 New Revision: 257284 URL: https://gcc.gnu.org/viewcvs?rev=257284&root=gcc&view=rev Log: PR tree-optimization/81661 PR tree-optimization/84117 * tree-eh.h (rewrite_to_non_trapping_overflow): Declare. * tree-eh.c: Include gimplify.h. (find_trapping_overflow, replace_trapping_overflow, rewrite_to_non_trapping_overflow): New functions. * tree-vect-loop.c: Include tree-eh.h. (vect_get_loop_niters): Use rewrite_to_non_trapping_overflow. * tree-data-ref.c: Include tree-eh.h. (get_segment_min_max): Use rewrite_to_non_trapping_overflow. * gcc.dg/pr81661.c: New test. * gfortran.dg/pr84117.f90: New test. Added: trunk/gcc/testsuite/gcc.dg/pr81661.c trunk/gcc/testsuite/gfortran.dg/pr84117.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-eh.c trunk/gcc/tree-eh.h trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/84152] [7 Regression] ICE in tree-if-conv.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84152 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.4 --- Comment #4 from Richard Biener --- Mine.
[Bug tree-optimization/84152] [7 Regression] ICE in tree-if-conv.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84152 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Richard Biener --- A dup of PR82795. Forgot to backport that it seems :/ *** This bug has been marked as a duplicate of bug 82795 ***
[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82795 Richard Biener changed: What|Removed |Added CC||drohr at jwdt dot org --- Comment #6 from Richard Biener --- *** Bug 84152 has been marked as a duplicate of this bug. ***
[Bug c/84163] New: [avr] Allow address space qualifier for compound literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84163
Bug ID: 84163
Summary: [avr] Allow address space qualifier for compound
literals
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
avr-gcc currently accepts address-space qualifiers in compound literals
provided this is outside of a function:
#define FSTR(X) ((const __flash char[]) { X } )
const __flash char *pet = FSTR ("pet");
$ avr-gcc literal.c -S -mmcu=atmega8
.section.progmem.data,"a",@progbits
.type __compound_literal.0, @object
.size __compound_literal.0, 4
__compound_literal.0:
.string "pet"
.global pet
.data
.type pet, @object
.size pet, 2
pet:
.word __compound_literal.0
Hence this works great and perfectly as expected. Unfortunately, this does not
work locally in a function:
const __flash char* get_pet (void)
{
static const __flash char *pet = FSTR ("pet");
return pet;
}
literal.c: In function 'get_pet':
literal.c:7:3: error: compound literal qualified by address-space qualifier
static const __flash char *pet = FSTR ("pet");
^~
Would be great if the C front end also supported such compound literals with
the obvious semantics as a GNU-C extension (which __flash and other
address-spaces already are).
[Bug target/84154] [7/8 Regression] PowerPC GCC 7 and 8 have regression in converting fp to short/char and returning it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84154 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 Target Milestone|--- |7.4 Summary|PowerPC GCC 7 and 8 have|[7/8 Regression] PowerPC |regression in converting fp |GCC 7 and 8 have regression |to short/char and returning |in converting fp to |it |short/char and returning it
[Bug c/84163] [avr] Allow address space qualifier for compound literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84163 Georg-Johann Lay changed: What|Removed |Added Keywords||addr-space Target||avr Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-01 Ever confirmed|0 |1
[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 fiesh at zefix dot tv changed: What|Removed |Added CC||fiesh at zefix dot tv --- Comment #6 from fiesh at zefix dot tv --- For what it's worth, I'd like to mention that what chuck mentions in the previous post can be used to circumvent the issue: Setting CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES and CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES manually serves as a workaround until the CMake ticket is closed. This took me quite a while to understand, so hopefully it helps someone else.
[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52477 --- Comment #11 from Rainer Orth --- (In reply to Martin Liška from comment #10) > I will try to look at it. Do you see a chance to look at this before GCC 8? Thanks. Rainer
[Bug preprocessor/84161] preprocessor should discard Fortran comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84161 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- It should not. Use /* ... */ or // comments instead if you don't want expansion in them. The preprocessor doesn't know anything about Fortran parsing and changing this would e.g. break OpenMP or OpenACC, where we do want normal preprocessing in !$omp and !$acc comments.
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I actually think it is the right thing that the attributes from templates are inherited by specializations.
[Bug tree-optimization/81661] [7 Regression] ICE in gimplify_modify_expr, at gimplify.c:5638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81661 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |gimplify_modify_expr, at|gimplify_modify_expr, at |gimplify.c:5638 |gimplify.c:5638 --- Comment #10 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/84117] [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/81661] [7 Regression] ICE in gimplify_modify_expr, at gimplify.c:5638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81661 Bug 81661 depends on bug 84117, which changed state. Bug 84117 Summary: [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5798 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/83845] [8 regression] new failures after r256620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83845 --- Comment #5 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Thu Feb 1 11:02:52 2018 New Revision: 257285 URL: https://gcc.gnu.org/viewcvs?rev=257285&root=gcc&view=rev Log: [AArch64] Tighten aarch64_secondary_reload condition (PR 83845) aarch64_secondary_reload enforced a secondary reload via aarch64_sve_reload_be for memory and pseudo registers, but failed to do the same for subregs of pseudo registers. To avoid this and any similar problems, the patch instead tests for things that the move patterns handle directly; if the operand isn't one of those, we should use the reload pattern instead. The patch fixes an ICE in sve/mask_struct_store_3.c for aarch64_be, where the bogus target description was (rightly) causing LRA to cycle. 2018-02-01 Richard Sandiford gcc/ PR tearget/83845 * config/aarch64/aarch64.c (aarch64_secondary_reload): Tighten check for operands that need to go through aarch64_sve_reload_be. Reviewed-by: James Greenhalgh Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug target/83846] Some SVE tests fail with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83846 --- Comment #6 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Thu Feb 1 11:04:58 2018 New Revision: 257290 URL: https://gcc.gnu.org/viewcvs?rev=257290&root=gcc&view=rev Log: [AArch64] Fix SVE testsuite failures for ILP32 (PR 83846) The SVE tests are split into code-quality compile tests and runtime tests. A lot of the former are geared towards LP64. It would be possible (but tedious!) to mark up every line that is expected to work only for LP64, but I think it would be a constant source of problems. Since the code has not been tuned for ILP32 yet, I think the best thing is to select only the runtime tests for that combination. They all pass on aarch64-elf and aarch64_be-elf except vec-cond-[34].c, which are unsupported due to the lack of fenv support. The patch also replaces uses of built-in types with stdint.h types where possible. (This excludes tests that change the endianness, since we can't assume that system header files work in that case.) 2018-02-01 Richard Sandiford gcc/testsuite/ PR testsuite/83846 * gcc.target/aarch64/sve/aarch64-sve.exp: Only do *_run tests for ILP32. * gcc.target/aarch64/sve/clastb_2_run.c (main): Use TYPE instead of hard-coding the choice. * gcc.target/aarch64/sve/clastb_4_run.c (main): Likewise. * gcc.target/aarch64/sve/clastb_5_run.c (main): Likewise. * gcc.target/aarch64/sve/clastb_3_run.c (main): Likewise. Generalize memset call. * gcc.target/aarch64/sve/const_pred_1.C: Include stdint.h and use stdint.h types. * gcc.target/aarch64/sve/const_pred_2.C: Likewise. * gcc.target/aarch64/sve/const_pred_3.C: Likewise. * gcc.target/aarch64/sve/const_pred_4.C: Likewise. * gcc.target/aarch64/sve/load_const_offset_2.c: Likewise. * gcc.target/aarch64/sve/logical_1.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_1.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_2.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_3.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_4.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_5.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_6.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_7.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_8.c: Likewise. * gcc.target/aarch64/sve/mask_struct_store_1.c: Likewise. * gcc.target/aarch64/sve/mask_struct_store_2.c: Likewise. * gcc.target/aarch64/sve/mask_struct_store_3.c: Likewise. * gcc.target/aarch64/sve/mask_struct_store_4.c: Likewise. * gcc.target/aarch64/sve/struct_vect_1.c: Likewise. * gcc.target/aarch64/sve/struct_vect_2.c: Likewise. * gcc.target/aarch64/sve/struct_vect_2_run.c: Likewise. * gcc.target/aarch64/sve/struct_vect_3.c: Likewise. * gcc.target/aarch64/sve/struct_vect_3_run.c: Likewise. * gcc.target/aarch64/sve/struct_vect_4.c: Likewise. * gcc.target/aarch64/sve/struct_vect_4_run.c: Likewise. * gcc.target/aarch64/sve/struct_vect_7.c: Likewise. * gcc.target/aarch64/sve/struct_vect_8.c: Likewise. * gcc.target/aarch64/sve/struct_vect_8_run.c: Likewise. * gcc.target/aarch64/sve/struct_vect_9.c: Likewise. * gcc.target/aarch64/sve/struct_vect_9_run.c: Likewise. * gcc.target/aarch64/sve/struct_vect_10.c: Likewise. * gcc.target/aarch64/sve/struct_vect_10_run.c: Likewise. * gcc.target/aarch64/sve/struct_vect_11.c: Likewise. * gcc.target/aarch64/sve/struct_vect_11_run.c: Likewise. * gcc.target/aarch64/sve/struct_vect_12.c: Likewise. * gcc.target/aarch64/sve/struct_vect_12_run.c: Likewise. * gcc.target/aarch64/sve/struct_vect_13.c: Likewise. * gcc.target/aarch64/sve/struct_vect_13_run.c: Likewise. * gcc.target/aarch64/sve/struct_vect_14.c: Likewise. * gcc.target/aarch64/sve/struct_vect_18.c: Likewise. * gcc.target/aarch64/sve/struct_vect_19.c: Likewise. * gcc.target/aarch64/sve/struct_vect_20.c: Likewise. * gcc.target/aarch64/sve/struct_vect_21.c: Likewise. * gcc.target/aarch64/sve/struct_vect_22.c: Likewise. * gcc.target/aarch64/sve/struct_vect_23.c: Likewise. * gcc.target/aarch64/sve/popcount_1.c (popcount_64): Use __builtin_popcountll rather than __builtin_popcountl. Reviewed-by: James Greenhalgh Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/sve/aarch64-sve.exp trunk/gcc/testsuite/gcc.target/aarch64/sve/clastb_2_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/clastb_3_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/clastb_4_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/clastb_5_run.c trunk/gcc/testsuite/gcc.target/aarch64/sve/const_pred_1.C trunk/gcc/testsuite/gcc.ta
[Bug fortran/84155] [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #7 from Paul Thomas --- Stranger and stranger. Not only does the removal of a line in a subroutine that is not called make the testcase work but explicitly using the subroutine to do the allocation works as well: module test_case implicit none type :: array_t integer, dimension(:), allocatable :: child contains procedure :: write_raw => particle_write_raw procedure :: read_raw => particle_read_raw end type array_t type :: container_t type(array_t), dimension(:), allocatable :: array end type container_t contains subroutine proc () type(container_t) :: container integer :: unit, child allocate (container%array(1)) !allocate (container%array(1)%child (1), source = [2]) call container%array(1)%read_raw () unit = 33 open (unit, action="readwrite", form="unformatted", status="scratch") print *, 1 call container%array(1)%write_raw (unit) print *, 2 rewind (unit) read(unit) child print *, "value from scratch file = ", child end subroutine proc subroutine particle_write_raw (array, u) class(array_t), intent(in) :: array integer, intent(in) :: u write (u) array%child end subroutine particle_write_raw subroutine particle_read_raw (array) class(array_t), intent(out) :: array allocate (array%child (1), source = [99])! comment this out end subroutine particle_read_raw end module test_case program main use test_case call proc () end program main I have taken it, although I might need help from you Thomas since I rather suspect something is bad in the i/o library. Paul
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #19 from Paul Thomas --- I had better take this one :-( This works as intended: subroutine vamp_equivalence_write (eq, unit) integer, intent(in), optional :: unit integer :: u type(vamp_equivalence_t), intent(in) :: eq integer, dimension(:), pointer :: permutation! copy the component allocate (permutation, source = eq%permutation) ! here and all is well u = 6; if (present (unit)) u = unit write (u, "(5x,A,99(1x,I0))") "Permutation:", permutation ! for IO deallocate (permutation) end subroutine vamp_equivalence_write Paul
[Bug preprocessor/84161] preprocessor should discard Fortran comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84161 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) > It should not. Well, why not? If you say that the preprocessor is meant only for C/C++, then it shouldn't be used with Fortran at all. If one uses it with Fortran, it should also understand the specifics of Fortran syntax, no? Would it make sense to have a "Fortran mode" or something like that? Right now gfortran is using 'traditional' mode IIUC. > Use /* ... */ or // comments instead if you don't want expansion in them. Using // actually does not work for me: comment.F90:5:0: // _ASSERT_() is a nice macro :) ^ Error: macro "_ASSERT_" requires 2 arguments, but only 1 given comment.F90:5:1: // _ASSERT_() is a nice macro :) 1 Error: Invalid character in name at (1) Using /* ... */ does work, but it's strange to do that in Fortran code (plus it breaks if the code is not preprocessed; preprocessing is 'optional' for Fortran). !/* ... */ is a reasonable workaround for now. > The preprocessor doesn't know anything about Fortran parsing and changing > this would e.g. break OpenMP or OpenACC, where we do want normal > preprocessing in !$omp and !$acc comments. That's true (and it's different from C/C++ where OpenMP uses pragmas, not comment-like directive). One could still teach the preprocessor to discard !... , but not !$..., in a Fortran context.
[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- The problem still exists, and according to gcc-testresults the test FAILs on i386-pc-solaris2.11, x86_64-pc-solaris2.11, x86_64-apple-darwin15.6.0, i686-pc-linux-gnu, and x86_64-pc-linux-gnu. Should I rather open a new PR for this? Rainer
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157
--- Comment #9 from Segher Boessenkool ---
I've tested this on powerpc64-linux {-m64,-m32} as well (change_zero_ext
is pretty important for us; we have big testcases for this and related code).
No issues found.
[Bug target/82795] [7 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82795 David Malcolm changed: What|Removed |Added Status|RESOLVED|ASSIGNED CC||dmalcolm at gcc dot gnu.org Resolution|FIXED |--- Target Milestone|8.0 |7.4 Summary|[8 Regression] ICE in |[7 Regression] ICE in |predicate_mem_writes, at|predicate_mem_writes, at |tree-if-conv.c:2251 |tree-if-conv.c:2251 --- Comment #7 from David Malcolm --- You closed out PR 84152 with: > A dup of PR82795. Forgot to backport that it seems :/ Hence reopening this one and marking for gcc-7-branch.
[Bug rtl-optimization/84164] New: [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84164 Bug ID: 84164 Summary: [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1 Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 43317 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43317&action=edit reduced testcase This occurs only with the aarch64-unknown-linux-gnu target. Compiler output: $ cc1 -quiet testcase.c -O during RTL pass: ira testcase.c: In function 'foo': testcase.c:15:1: internal compiler error: in elimination_costs_in_insn, at reload1.c:3633 } ^ 0xbed921 elimination_costs_in_insn /repo/gcc-trunk/gcc/reload1.c:3630 0xbf68cf calculate_elim_costs_all_insns() /repo/gcc-trunk/gcc/reload1.c:1607 0xa64ced ira_costs() /repo/gcc-trunk/gcc/ira-costs.c:2249 0xa5d17c ira_build() /repo/gcc-trunk/gcc/ira-build.c:3427 0xa53d66 ira /repo/gcc-trunk/gcc/ira.c:5293 0xa53d66 execute /repo/gcc-trunk/gcc/ira.c:5604 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ xgcc -v Using built-in specs. COLLECT_GCC=/repo/build-trunk-257290-checking-yes-rtl-df-extra-aarch64/./gcc/xgcc Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-257290-checking-yes-rtl-df-extra-aarch64 Thread model: posix gcc version 8.0.1 20180201 (experimental) (GCC)
[Bug tree-optimization/82726] ICE in verify_ssa during GIMPLE pass: pcom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82726 --- Comment #7 from amker at gcc dot gnu.org --- Author: amker Date: Thu Feb 1 12:00:57 2018 New Revision: 257291 URL: https://gcc.gnu.org/viewcvs?rev=257291&root=gcc&view=rev Log: Backport from mainline 2017-11-15 Bin Cheng PR tree-optimization/82726 PR tree-optimization/70754 * tree-predcom.c (order_drefs_by_pos): New function. (combine_chains): Move code setting has_max_use_after to... (try_combine_chains): ...here. New parameter. Sort combined chains according to position information. (tree_predictive_commoning_loop): Update call to above function. (update_pos_for_combined_chains, pcom_stmt_dominates_stmt_p): New. testsuite Backport from mainline 2017-11-15 Bin Cheng PR tree-optimization/82726 * gcc.dg/tree-ssa/pr82726.c: New test. Backport from mainline 2017-01-23 Bin Cheng PR tree-optimization/70754 * gfortran.dg/pr70754.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr82726.c branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70754.f90 Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-predcom.c
[Bug tree-optimization/70754] [6 Regression] ICE during predictive commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70754 --- Comment #21 from amker at gcc dot gnu.org --- Author: amker Date: Thu Feb 1 12:00:57 2018 New Revision: 257291 URL: https://gcc.gnu.org/viewcvs?rev=257291&root=gcc&view=rev Log: Backport from mainline 2017-11-15 Bin Cheng PR tree-optimization/82726 PR tree-optimization/70754 * tree-predcom.c (order_drefs_by_pos): New function. (combine_chains): Move code setting has_max_use_after to... (try_combine_chains): ...here. New parameter. Sort combined chains according to position information. (tree_predictive_commoning_loop): Update call to above function. (update_pos_for_combined_chains, pcom_stmt_dominates_stmt_p): New. testsuite Backport from mainline 2017-11-15 Bin Cheng PR tree-optimization/82726 * gcc.dg/tree-ssa/pr82726.c: New test. Backport from mainline 2017-01-23 Bin Cheng PR tree-optimization/70754 * gfortran.dg/pr70754.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr82726.c branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70754.f90 Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-predcom.c
[Bug target/82795] [7/8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82795 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||7.3.1 Resolution|--- |FIXED Summary|[7 Regression] ICE in |[7/8 Regression] ICE in |predicate_mem_writes, at|predicate_mem_writes, at |tree-if-conv.c:2251 |tree-if-conv.c:2251 Known to fail||7.3.0 --- Comment #8 from Richard Biener --- Fixed.
[Bug target/82795] [7/8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82795 --- Comment #9 from Richard Biener --- Author: rguenth Date: Thu Feb 1 12:07:46 2018 New Revision: 257292 URL: https://gcc.gnu.org/viewcvs?rev=257292&root=gcc&view=rev Log: 2018-02-01 Richard Biener Backport from mainline 2017-11-02 Richard Biener PR tree-optimization/82795 * tree-if-conv.c (predicate_mem_writes): Remove bogus assert. * gcc.target/i386/pr82795.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr82795.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-if-conv.c
[Bug rtl-optimization/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84164 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-01 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- I've just checked a x86_64-apple-darwin11.4.2 build: the test PASSes for -m64, but FAILs for -m32 with /var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//cchNxmiW.s:7:no such instruction: `shrx %eax, 4(%esp),%eax'
[Bug c/77331] incorrect range location in -Wformat with a concatenated format literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77331 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52952 --- Comment #3 from Eric Gallager --- (In reply to Michał Mirosław from comment #1) > This looks similar (related to PR#52952?): when showing error for > concatenated format string, caret does not point to the triggering format. If you replace the '#' with a space, bugzilla will autolink the bug: PR 52952
[Bug rtl-optimization/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84164 --- Comment #2 from ktkachov at gcc dot gnu.org --- We encounter an unrecognizable insn: (insn 59 58 43 7 (set (reg:DI 124) (rotatert:DI (reg:DI 125 [ c ]) (subreg:QI (and:SI (reg:SI 128) (const_int 65535 [0x])) 0))) "ice.c":8 -1 It comes from the *aarch64_reg_3_neg_mask2 splitter. Need to figure out what went wrong there
[Bug target/35179] execs crash in shared lib destructor = do_global_dtors_aux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35179 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Eric Gallager --- (In reply to Eric Gallager from comment #8) > (In reply to Eric Gallager from comment #7) > > (In reply to Radu Hociung from comment #6) > > > Comment on attachment 17939 [details] > > > Improved hello-test case showing working and failing command lines, with > > > Makefile > > > > > > Works as expected: > > > gcc -g -o hello-exec hellomain.o -L. -lhello > > > > > > Triggers the bug: > > > gcc -g -static -o hello-exec-gccbug35179 hellomain.o -shared -L. -lhello > > > -v > > > > Testcase fails to link for me on Darwin due to a difference in linkers: > > > > $ make hello-exec-gccbug35179 > > /usr/local/bin/gcc -o hellomain.o -c -g hellomain.c > > hellomain.c: In function ‘main’: > > hellomain.c:9:2: warning: implicit declaration of function ‘exit’ > > [-Wimplicit-function-declaration] > > exit(0); > > ^~~~ > > hellomain.c:9:2: warning: incompatible implicit declaration of built-in > > function ‘exit’ > > hellomain.c:9:2: note: include ‘’ or provide a declaration of > > ‘exit’ > > /usr/local/bin/gcc -o hello_.o -g -c -fpic -DPIC hello.c > > /usr/local/bin/gcc -o libhello.so -shared -g hello_.o > > echo Linking with both -static and -shared flags exposes the bug. > > Linking with both -static and -shared flags exposes the bug. > > /usr/local/bin/gcc -g -static -o hello-exec-gccbug35179 hellomain.o -shared > > -L. -lhello -v > > Using built-in specs. > > COLLECT_GCC=/usr/local/bin/gcc > > COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto- > > wrapper > > Target: i386-apple-darwin9.8.0 > > Configured with: ../configure --disable-werror --disable-werror-always > > --enable-languages=c,c++,lto,objc,obj-c++ > > --enable-stage1-checking=release,rtl -C --with-system-libunwind > > --enable-secureplt --enable-frame-pointer --enable-debug --with-isl > > --disable-host-shared --enable-maintainer-mode --disable-default-pie > > --with-ld64 --without-pic --enable-target-optspace CC=/usr/local/bin/gcc > > CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf > > AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf > > AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan > > AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames > > Thread model: posix > > gcc version 8.0.0 20170702 (experimental) (GCC) > > COMPILER_PATH=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/ > > local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/local/libexec/gcc/i386- > > apple-darwin9.8.0/:/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/ > > local/lib/gcc/i386-apple-darwin9.8.0/ > > LIBRARY_PATH=/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/local/lib/ > > gcc/i386-apple-darwin9.8.0/8.0.0/../../../ > > COLLECT_GCC_OPTIONS='-g' '-static' '-o' 'hello-exec-gccbug35179' '-L.' '-v' > > '-mmacosx-version-min=10.5.8' '-asm_macosx_version_min=10.5' '-mtune=core2' > > '-Zdynamiclib' > > /usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/collect2 -static -dylib > > -arch i386 -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o > > hello-exec-gccbug35179 -ldylib1.10.5.o -L. > > -L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0 > > -L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/../../.. hellomain.o > > -lhello -lgcc_eh -lgcc -v -idsym > > collect2 version 8.0.0 20170702 (experimental) > > /usr/bin/ld -static -dylib -arch i386 -macosx_version_min 10.5.8 > > -weak_reference_mismatches non-weak -o hello-exec-gccbug35179 > > -ldylib1.10.5.o -L. -L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0 > > -L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/../../.. hellomain.o > > -lhello -lgcc_eh -lgcc -v > > Apple Computer, Inc. version cctools-698.1~1 > > ld_classic: incompatible flag -dylib used (must specify "-dynamic" to be > > used) > > collect2: error: ld returned 1 exit status > > make: *** [hello-exec-gccbug35179] Error 1 > > $ > > > > Someone running GNU/Linux will have to try the testcase to move this out of > > WAITING. > > Now that I have access to the GCC compile farm, the testcase still fails on > me when I try it there: "fails" as in "doesn't link" before it even gets to the crashes part. I guess since it's been in WAITING with no response for so long I'll close this as INVALID.
[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569 --- Comment #13 from Uroš Bizjak --- (In reply to r...@cebitec.uni-bielefeld.de from comment #12) > I've just checked a x86_64-apple-darwin11.4.2 build: the test PASSes for > -m64, but FAILs for -m32 with > > /var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//cchNxmiW.s:7:no such > instruction: `shrx %eax, 4(%esp),%eax' http://www.felixcloutier.com/x86/SARX:SHLX:SHRX.html
[Bug preprocessor/84165] New: #define strlen asdf affects calls to asdf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84165
Bug ID: 84165
Summary: #define strlen asdf affects calls to asdf
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: manuel.rigger at jku dot at
Target Milestone: ---
Hi,
I have a file asdf.h with the following content:
#define strlen asdf
I have another file test.c with the following content:
#include
#include
#include
unsigned long asdf(const char* s) {
printf("asdf gets called with argument %s.", s);
return 1234;
}
int main(void) {
asdf("asdf");
return 0;
}
After compiling with clang -include asdf.h test.c -o test I get the following
output:
test.c:11:5: warning: ignoring return value of function declared with pure
attribute [-Wunused-value]
asdf("asdf");
^~~~ ~~
1 warning generated.
Executing the executable does not print anything.
I would have expected that the executable calls asdf(), but it seems that
asdf() was expected to be strlen(), which does not have any side effects, and
was thus deleted. Is this the correct behavior? Are defines bidirectional?
GCC version: gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0
[Bug c/84166] New: Wrong warning message emitted for loss of qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84166
Bug ID: 84166
Summary: Wrong warning message emitted for loss of qualifiers
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ttsiodras at gmail dot com
Target Milestone: ---
The code shown below...
#include
#include
extern void get_buffer_from_HW_driver(volatile uint32_t **p);
void getBuffer(volatile uint32_t **pp)
{
// Write an address into p, that is obtained from a driver
// The underlying HW will be DMA-ing into this address,
// so the data pointed-to by the pointer returned by this
// call are volatile.
get_buffer_from_HW_driver(pp);
}
void work()
{
uint32_t *p = NULL;
getBuffer((volatile uint32_t **)&p);
}
...is erroneously forgetting to set the `volatile` qualifier for the pointer
`p` declared in `work`. Unfortunately, GCC's related warning indicates that
there is a missing `const` - instead of a missing `volatile`:
$ gcc -c -Wall -Wextra -Wcast-qual constqual.c
constqual.c: In function ‘work’:
constqual.c:20:15: warning: to be safe all intermediate pointers in cast
from
‘uint32_t ** {aka unsigned int **}’ to ‘volatile uint32_t **
{aka volatile unsigned int **}’ must be ‘const’ qualified
[-Wcast-qual]
getBuffer((volatile uint32_t **)&p);
^
It appears that GCC confuses `const` with `volatile` here.
[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83370 --- Comment #1 from Renlin Li --- Author: renlin Date: Thu Feb 1 13:02:24 2018 New Revision: 257294 URL: https://gcc.gnu.org/viewcvs?rev=257294&root=gcc&view=rev Log: [PR83370][AARCH64]Use tighter register constraint for sibcall patterns. In aarch64 backend, ip0/ip1 register will be used in the prologue/epilogue as temporary register. When the compiler is performing sibcall optimization. It has the chance to use ip0/ip1 register for indirect function call to hold the address. However, those two register might be clobbered by the epilogue code which makes the last sibcall instruction invalid. The patch here renames the register class CALLER_SAVE_REGS to TAILCALL_ADDR_REGS to reflect its usage, and remove IP registers from this class. gcc/ 2018-02-01 Renlin Li PR target/83370 * config/aarch64/aarch64.c (aarch64_class_max_nregs): Handle TAILCALL_ADDR_REGS. (aarch64_register_move_cost): Likewise. * config/aarch64/aarch64.h (reg_class): Rename CALLER_SAVE_REGS to TAILCALL_ADDR_REGS. (REG_CLASS_NAMES): Likewise. (REG_CLASS_CONTENTS): Rename CALLER_SAVE_REGS to TAILCALL_ADDR_REGS. Remove IP registers. * config/aarch64/aarch64.md (Ucs): Update register constraint. gcc/testsuite/ 2018-02-01 Richard Sandiford PR target/83370 * gcc.target/aarch64/pr83370.c: New. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr83370.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.h trunk/gcc/config/aarch64/constraints.md trunk/gcc/testsuite/ChangeLog
[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83370 Renlin Li changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Renlin Li --- fix has been commit in trunk.
[Bug preprocessor/84165] #define strlen asdf affects calls to asdf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84165 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- You get a declaration from stdio.h for asdf because you redefined strlen
[Bug target/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84164 Richard Biener changed: What|Removed |Added Component|rtl-optimization|target Target Milestone|--- |8.0
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #20 from Paul Thomas --- A temporary fix: Index: ../trunk/gcc/fortran/trans-io.c === *** ../trunk/gcc/fortran/trans-io.c (revision 257261) --- ../trunk/gcc/fortran/trans-io.c (working copy) *** gfc_trans_transfer (gfc_code * code) *** 2590,2596 if (expr->ts.type != BT_CLASS && expr->expr_type == EXPR_VARIABLE !&& gfc_expr_attr (expr).pointer) goto scalarize; --- 2590,2596 if (expr->ts.type != BT_CLASS && expr->expr_type == EXPR_VARIABLE !&& (gfc_expr_attr (expr).pointer || gfc_expr_attr (expr).allocatable)) goto scalarize; fixes this and pr84155. transfer_array is receiving a dtype with all the fields set to zero. I will get back to this tonight or tomorrow morning. I have to go to the lab now. Paul
[Bug fortran/84155] [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 --- Comment #8 from Paul Thomas --- A temporary fix: Index: ../trunk/gcc/fortran/trans-io.c === *** ../trunk/gcc/fortran/trans-io.c (revision 257261) --- ../trunk/gcc/fortran/trans-io.c (working copy) *** gfc_trans_transfer (gfc_code * code) *** 2590,2596 if (expr->ts.type != BT_CLASS && expr->expr_type == EXPR_VARIABLE !&& gfc_expr_attr (expr).pointer) goto scalarize; --- 2590,2596 if (expr->ts.type != BT_CLASS && expr->expr_type == EXPR_VARIABLE !&& (gfc_expr_attr (expr).pointer || gfc_expr_attr (expr).allocatable)) goto scalarize; fixes this and pr84141. transfer_array is receiving a dtype with all the fields set to zero. I will get back to this tonight or tomorrow morning. I have to go to the lab now. Paul
[Bug c++/84162] Internal compiler error: in tsubst, at cp/pt.c:13617 / SEGFAULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84162 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-01 Known to work||8.0.1 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- So fixed? Or is this a regression or worth fixing anyways? Confirmed for GCC 7 b ranch head.
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug tree-optimization/84013] wrong __restrict clique with inline asm operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84013 --- Comment #4 from Katsunori Kumatani --- Thanks, it's quite useful in some "meta asm" cases (in conjunction with plugins, asms can be useful since you can't add builtins). Or when doing custom calls in asms (or syscalls, etc) and you know what memory they touch, without having to clobber everything. :)
[Bug web/84167] New: bugzilla should have a "next bug" button
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84167 Bug ID: 84167 Summary: bugzilla should have a "next bug" button Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: LpSolit at netscape dot net Target Milestone: --- I'm currently using the web gcc-bug mailinglist archive to cycle through all new bugs each morning. It would be much easier to do and to keep track where I left if there were a "next bug by ID" button somewhere (right next to the "Bug ID" link at the top?). Probably doable on the client side somehow but my web-fu isn't great enough to do that ;)
[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- >> /var/folders/zz/zyxvpxvq6csfxvn_n87r00021y/T//cchNxmiW.s:7:no such >> instruction: `shrx %eax, 4(%esp),%eax' > http://www.felixcloutier.com/x86/SARX:SHLX:SHRX.html Could be a bug in the old Apple as. However, the testcase is fishy in explicitly passing -m16. For multilibbed x86 targets, that gets overridden for the non-default multilibs (either with -m32 or m64).
[Bug target/84164] [8 Regression] ICE: in elimination_costs_in_insn, at reload1.c:3633 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84164 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- Testing a patch.
[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83370 Richard Earnshaw changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2018-02-01 CC||renlin.li at arm dot com Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from Richard Earnshaw --- Doesn't this need backporting?
[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569 --- Comment #15 from H.J. Lu --- > > Could be a bug in the old Apple as. However, the testcase is fishy in > explicitly passing -m16. For multilibbed x86 targets, that gets > overridden for the non-default multilibs (either with -m32 or m64). This shouldn't happen with degagnu after http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347
[Bug c/84168] New: Please backport "Avoid assembler warnings from AArch64 constructor/destructor priorities."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84168 Bug ID: 84168 Summary: Please backport "Avoid assembler warnings from AArch64 constructor/destructor priorities." Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: frank.mehnert at googlemail dot com Target Milestone: --- Please backport changeset 41be51b050e5de25e711657bdc0b19a7e98a564a at least to gcc-7, if possible also to gcc-6. This warning is triggered very often in our (L4Re) project. Thank you!
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158 --- Comment #3 from Jakub Jelinek --- As C++ now has standardized attributes, the question is what does the standard say about whether standard attributes on a template are inherited to specializations or not, and if the standard is fuzzy about it, what do other compilers do.
[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80569 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE --- > This shouldn't happen with degagnu after > > http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347 Which would mean requiring at least DejaGnu 1.6, while install.texi still states a minimum of 1.4.4. The other issue (unconditionally generating .code16gcc without checking if the assembler supports it) still stands. Rainer
[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #13 from Jan Hubicka --- I have started with experiments on czerny. Set --param inline-min-speedup from 8 to 15 at 30th of January and to 30 yesterday. Most of size regression comes away with 15 and I observed to off-noise regressions. GCC of spec2006 improves 32.5->34.5 With 30 there are regressions in botan (but not wrt earlier releases, just wrt best values we got) that are bit random (improvements too) and mesa of spec2000 5200->4950. There is still noticeable code size improvements and also facerec improves 6400->8000. (may be independent as it fixes regression from 19th) So consistent improvement is possible with 15. I will also check inline-insns-auto/single and arrive to patch hopefully by end of weekend. Honza
[Bug tree-optimization/81635] [8 Regression] nvptx SLP test cases regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635
--- Comment #13 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Feb 1 14:17:07 2018
New Revision: 257296
URL: https://gcc.gnu.org/viewcvs?rev=257296&root=gcc&view=rev
Log:
Use range info in split_constant_offset (PR 81635)
This patch implements the original suggestion for fixing PR 81635:
use range info in split_constant_offset to see whether a conversion
of a wrapping type can be split. The range info problem described in:
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01002.html
seems to have been fixed.
The patch is part 1. There needs to be a follow-on patch to handle:
for (unsigned int i = 0; i < n; i += 4)
{
...[i + 2]...
...[i + 3]...
which the old SCEV test handles, but which the range check doesn't.
At the moment we record that the low two bits of "i" are clear,
but we still end up with a maximum range of 0x rather than
0xfffc.
2018-01-31 Richard Sandiford
gcc/
PR tree-optimization/81635
* tree-data-ref.c (split_constant_offset_1): For types that
wrap on overflow, try to use range info to prove that wrapping
cannot occur.
gcc/testsuite/
PR tree-optimization/81635
* gcc.dg/vect/bb-slp-pr81635-1.c: New test.
* gcc.dg/vect/bb-slp-pr81635-2.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pr81635-1.c
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pr81635-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c
[Bug middle-end/81812] [7/8 Regression] Empty virtual function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81812 Jan Hubicka changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #8 from Jan Hubicka --- Martin, I seem to recall that this was related to icf trying to merge variadic function. Would it be possible to work out the patch that fixed this?
[Bug target/68028] [6/7/8 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028
Nick Clifton changed:
What|Removed |Added
CC||nickc at gcc dot gnu.org
--- Comment #9 from Nick Clifton ---
Created attachment 43318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43318&action=edit
Proposed patch
Hi Guys,
Richard was right - there is code that sets extra flags based upon the setting
of -mcpu. In fact it is just before the code he mentioned:
/* For the E500 family of cores, reset the single/double FP flags to let us
check that they remain constant across attributes or pragmas. */
switch (rs6000_cpu)
{
case PROCESSOR_PPC8540:
case PROCESSOR_PPC8548:
case PROCESSOR_PPCE500MC:
case PROCESSOR_PPCE500MC64:
case PROCESSOR_PPCE5500:
case PROCESSOR_PPCE6500:
rs6000_single_float = 0;
rs6000_double_float = 0;
break;
default:
break;
}
This has lead me to propose the attached patch. Basically what it does is to
tell the rs6000 backend that when it is operating in LTO mode, it should trust
the function attributes and not the command line.
My assumption here is that if there are any discrepancies between real
function attributes (ie not ones generated for LTO) and the command line,
then these will have been detected and reported during the original
compilation.
What do people think ? Is the patch OK ?
Cheers
Nick
[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926
--- Comment #10 from Peter Bergner ---
A similar error happens with the __builtin_vsx_udiv_2di() that happens with
__builtin_vsx_div_2di(), which shows the splitter for vsx_udiv_v2di calling
gen_udivdi3() directly:
[bergner@makalu-lp1 PR83926]$ cat udiv.i
__attribute__ ((altivec(vector__))) unsigned long long
foo (__attribute__ ((altivec(vector__))) unsigned long long a,
__attribute__ ((altivec(vector__))) unsigned long long b)
{
return __builtin_vsx_udiv_2di (a, b);
}
[bergner@makalu-lp1 PR83926]$
/home/bergner/gcc/build/gcc-fsf-mainline-pr83926-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr83926-debug/gcc -S -mcpu=power8
-O1 -m32 -mno-fold-gimple udiv.i
gimple folding of rs6000 builtins has been disabled.
udiv.i: In function ‘foo’:
udiv.i:6:1: error: unrecognizable insn:
}
^
(insn 16 15 17 2 (set (reg:DI 127)
(udiv:DI (reg:DI 125)
(reg:DI 126))) "udiv.i":6 -1
(nil))
during RTL pass: subreg2
udiv.i:6:1: internal compiler error: in extract_insn, at recog.c:2304
0x10ddd69f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/bergner/gcc/gcc-fsf-mainline-pr83926/gcc/rtl-error.c:108
[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #11 from Peter Bergner --- I have two patches 1) modify gen_[u]divdi3() to handle calling the lib func __[u]divdi3 when needed and 2) Call expand_divmod() in the vsx_[u]div_v2di splitters. I'm evaluating which generates better code.
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
--- Comment #4 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #2)
> I actually think it is the right thing that the attributes from templates
> are inherited by specializations.
That cannot be correct. Because there is no way to remove an attribute from a
declaration such a design would make it impossible to declare a specialization
that differed from the primary.
Here's a modified example that should bring the problem into focus:
template T __attribute__ ((noreturn)) f (T) { __builtin_abort (); }
template <> int f (int) { return 0; } // bogus warning here
int g (int i)
{
f (i); // missing -Wreturn-type
}
t.C: In function ‘T f(T) [with T = int]’:
t.C:3:34: warning: function declared ‘noreturn’ has a ‘return’ statement
template <> int f (int) { return 0; }
^
t.C:3:34: warning: ‘noreturn’ function does return
[Bug c++/83796] [6/7/8 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796
--- Comment #5 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Feb 1 15:36:04 2018
New Revision: 257298
URL: https://gcc.gnu.org/viewcvs?rev=257298&root=gcc&view=rev
Log:
/cp
2018-02-01 Paolo Carlini
PR c++/83796
* call.c (convert_like_real): If w're initializing from {} explicitly
call abstract_virtuals_error_sfinae.
/testsuite
2018-02-01 Paolo Carlini
PR c++/83796
* g++.dg/cpp0x/abstract-default1.C: New.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/abstract-default1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
[Bug c++/83796] [6/7 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796 Paolo Carlini changed: What|Removed |Added Summary|[6/7/8 Regression] Abstract |[6/7 Regression] Abstract |classes allowed to be |classes allowed to be |instantiated when |instantiated when |initialised as default |initialised as default |parameter to function or|parameter to function or |constructor |constructor --- Comment #6 from Paolo Carlini --- Fixed in trunk so far.
[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503 --- Comment #17 from Jason Merrill --- On Wed, Jan 31, 2018 at 9:45 PM, msebor at gcc dot gnu.org wrote: > Jason, I'm only starting to look into it but if I understand your suggestion > correctly, I don't think the bug can be fixed by relying on attribute > exclusions. > > Based on the test cases alone (I haven't yet stepped through the code) the > underlying problem seems to be that explicit specializations "inherit" > attributes from their primary template rather than starting with a clean > slate. Often that will be correct; I don't think we want to require people to repeat all attributes on every explicit specialization. The problem here is that there's a conflicting attribute on the specialization, and we want that to win, so I'm suggesting that when we see that, we go through and remove conflicting attributes which came from the template.
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
--- Comment #5 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #3)
> As C++ now has standardized attributes, the question is what does the
> standard say about whether standard attributes on a template are inherited
> to specializations or not, and if the standard is fuzzy about it, what do
> other compilers do.
To my reading the standard doesn't specify attributes with enough detail to
answer the question, but inheriting attributes wouldn't make sense. For
another example, consider class templates and alignas:
template
struct alignas (32) A { T a; };
template <>
struct A { char c; };
static_assert (alignof (A) < 32, "alignof A < 32");
This passes with all compilers I tried, including Clang, GCC, ICC, and MSVC.
It would be most surprising if the rules for class templates were different
than for function templates.
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157 --- Comment #10 from uros at gcc dot gnu.org --- Author: uros Date: Thu Feb 1 16:04:18 2018 New Revision: 257302 URL: https://gcc.gnu.org/viewcvs?rev=257302&root=gcc&view=rev Log: PR rtl-optimization/84157 * combine.c (change_zero_ext): Use REG_P predicate in front of HARD_REGISTER_P predicate. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug rtl-optimization/84157] [8 Regression] [nvptx] ICE: RTL check: expected code 'reg', have 'lshiftrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84157 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Uroš Bizjak --- Fixed.
[Bug target/84128] i686: Stack spilling in -fstack-clash-protection prologue neglects %esp change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84128 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/84128] i686: Stack spilling in -fstack-clash-protection prologue neglects %esp change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84128 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Thu Feb 1 16:22:56 2018 New Revision: 257303 URL: https://gcc.gnu.org/viewcvs?rev=257303&root=gcc&view=rev Log: PR target/84128 * config/i386/i386.c (release_scratch_register_on_entry): Add new OFFSET and RELEASE_VIA_POP arguments. Use SP+OFFSET to restore the scratch if RELEASE_VIA_POP is false. (ix86_adjust_stack_and_probe_stack_clash): Un-constify SIZE. If we have to save a temporary register, decrement SIZE appropriately. Pass new arguments to release_scratch_register_on_entry. (ix86_adjust_stack_and_probe): Likewise. (ix86_emit_probe_stack_range): Pass new arguments to release_scratch_register_on_entry. PR target/84128 * gcc.target/i386/pr84128.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr84128.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
Your Weekly Breeze - February. 01 - February. 07
This email newsletter was sent to you in graphical HTML format. If you're seeing this version, your email program prefers plain text emails. You can read the original version online: http://ymlptrack7.com/zwbctq Having problems viewing Weekly Breeze Click here ( http://myoasisliving.com/weekly_breeze/weekly_breeze.php ). >> ( y ) --> Feeling bloated after too much turkey and plates of mince pies? Get into the shape of your life in 2018 with a new fitness regime – here are some helpful expert tips >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/b53a230d6e6d918b0a7f1526b2dedefa ) The end of last year saw the 21st Faldo Series Grand Final tee up in Al Ain’s AESGC, bringing Sir Nick himself to the greens. Oasis Living was lucky enough to have a chat with a living legend >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/fac8c74f2e95c9cb9c7741faf6748425 ) Al Ain Rugby Club activities in full swing >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/2d6476579c954312447ad6df5fb08e4c ) Abu Dhabi set to host over 4,000 tri-athletes on one of the most unique triathlon courses in the world >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/36d37ef8f848677bebb848d561055902 ) A once-in-a-lifetime opportunity bounces in for youth basketball players worldwide >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/4fea2c60a18b5d7a466458f897ede786 ) Eighth edition of Abu Dhabi’s famed community sporting event to take place in February 2018 >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/1df55ebf7501156898d6b16f4e415cc8 ) breeze@ myoasisliving.com for your chance to win aHanayen gift voucher in Bawadi Mall worth Dh100. To win, simply email your complete name and indicate Hanayenin the subject and you will qualify for a random draw. *If you win, you have 30 days to pick up your prize. If your prize is not collected within 30 days of notification, it will be cancelled. Participants who have won before are not eligible to win again within 90 days after winning --> www.nascintl.com. Al Nada Beauty Salon will be having a 50% discount on beauty and hair services for the first 10 days of Ramadan. Al Nada Beauty Salon timings will be 10:30 a.m. until 2 p.m. and 8 p.m. until 12 a.m. For appointments and inquiries call 03-7664017. --> Money matters Looking to create a financial plan for 2018 but don’t know where to start? Oasis Living chats with expert Catalin Voicu for some insights – as VAT rolls into the UAE >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/710718018521202fc85448c2b2c1976f ) What’s hot in health? Abu Dhabi’s Intercare Wellness Consultants, Dr Nas Al-Jafari and Dr Mourad Habib, predict some of the wellness trends you will be seeing everywhere this year >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/46e5535e8caf136bbebd41547cb67aa1 ) What to expect in 2018 Six new things coming to the UAE this year >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/9183cbcbf2b3187e12154b1401ef156b ) 2017 in search Google releases most trending searches in the UAE of last year >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/175b84862b37613ad8bcd2a6b8b19a56 ) Greener pastures GCC's first vertical farm launches in Dubai >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/15d9bb997af04708d42e8499fe699a9b ) Omar Abdulrahman says Al Ain target three points against Al Jazira 'to get back on a better footing' Al Ain are out to restore their battered pride when they meet Arabian Gulf League leaders Al Jazira in their rescheduled Round 1 match on Monday at the Hazza bin Zayed Stadium. >> ( http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dna/opt/local_news_catch/offset/15 ) Al Ain in talks with 'two potential' replacements for Zlatko Dalic, with Jorge da Silva one of them Al Ain say they are yet to finalise a replacement for departed manager Zlatko Dalic but "are in talks" with two candidates with experience in the Arabian Gulf League. >> ( http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dn8/opt/local_news_catch/offset/0 ) Zlatko Dalic to depart Al Ain after Al Jazira defeat: 'Thanks for three great years' Al Ain manager Zlatko Dalic is leaving the Garden City club after more than two years in charge following their 3-1 defeat at home to Al Jazira on Monday night. >> ( http://www.myoasisliving.com/oasis_living_magazine/show_detail/encid/dn9/opt/local_news_catch/offset/5 ) Get a recap ( ALDAR Young Chef Award : March 14, 2017 ) This year’s ALDAR Young Chef Award, held in collaboration with the local Ayla hotels, saw talented students present some of their finest dishes for a panel of judges includin
[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
--- Comment #6 from Martin Sebor ---
I tested the modified C++ 11 example below with Clang, EDG, GCC, ICC, and MSVC.
Of these, only MSVC implements the behavior I expect and doesn't warn. The
others do. (I verified that MSVC does support the attribute.)
Still, given that it's obviously meaningful to define a specialization that
does return, treating it as noreturn based on the definition of the primary is
incorrect.
Given the difference among implementations I think the standard ought to be
clarified which of the two is intended.
(See https://godbolt.org/g/sYPbD2 for Clang and MSVC output.)
template
[[noreturn]] T
g (T) { throw "not implemented"; }
template <> int
g (int) { return 0; }
int h (int i)
{
return g (i);
}
[Bug target/84169] New: [8 Regression] wrong code with u128 multiplication result at aarch64 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169 Bug ID: 84169 Summary: [8 Regression] wrong code with u128 multiplication result at aarch64 -O Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 43319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43319&action=edit reduced testcase Output: $ aarch64-unknown-linux-gnu-gcc testcase.c -static -O $ ./a.out qemu: uncaught target signal 6 (Aborted) - core dumped Aborted The most-significant 64bit are zeros, but should be ones. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-257303-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-257303-checking-yes-rtl-df-extra-aarch64 Thread model: posix gcc version 8.0.1 20180201 (experimental) (GCC)
[Bug c/84166] Wrong warning message emitted for loss of qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84166 --- Comment #1 from joseph at codesourcery dot com --- It's not confused. It's saying that it's type-safe to convert "uint32_t **" to "volatile uint32_t *const *", but not to convert it to "volatile uint32_t *". http://c-faq.com/ansi/constmismatch.html
[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089 --- Comment #6 from Aldy Hernandez --- Author: aldyh Date: Thu Feb 1 17:12:28 2018 New Revision: 257304 URL: https://gcc.gnu.org/viewcvs?rev=257304&root=gcc&view=rev Log: PR target/84089 * config/pa/predicates.md (base14_operand): Handle E_VOIDmode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/predicates.md
[Bug libstdc++/84170] New: std::find_if performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84170
Bug ID: 84170
Summary: std::find_if performance issues
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barannikov88 at gmail dot com
Target Milestone: ---
Hi,
There are two internal implementations of std::find_if in bits/stl_algo.h. One
is for the input iterator case, the other is for the random access iterator
case. They are almost identical, except that the second is somewhat
"optimized".
> /// This is an overload used by find algos for the Input Iterator case.
> template
>inline _InputIterator
>__find_if(_InputIterator __first, _InputIterator __last,
> _Predicate __pred, input_iterator_tag)
>{
> while (__first != __last && !__pred(__first))
> ++__first;
> return __first;
>}
>
> /// This is an overload used by find algos for the RAI case.
> template
>_RandomAccessIterator
>__find_if(_RandomAccessIterator __first, _RandomAccessIterator __last,
> _Predicate __pred, random_access_iterator_tag)
>{
> typename iterator_traits<_RandomAccessIterator>::difference_type
> __trip_count = (__last - __first) >> 2;
>
> for (; __trip_count > 0; --__trip_count)
> {
> if (__pred(__first))
> return __first;
> ++__first;
>
> if (__pred(__first))
> return __first;
> ++__first;
>
> if (__pred(__first))
> return __first;
> ++__first;
>
> if (__pred(__first))
> return __first;
> ++__first;
> }
>
> switch (__last - __first)
> {
> case 3:
> if (__pred(__first))
> return __first;
> ++__first;
> case 2:
> if (__pred(__first))
> return __first;
> ++__first;
> case 1:
> if (__pred(__first))
> return __first;
> ++__first;
> case 0:
> default:
> return __last;
> }
>}
Manual unrolling increases the code size and reduces the chances of this
function to be inlined. Inlining of this function is critical because it can
contain indirect calls to the predicate function, and inlining can change this
calls to direct improving performance.
I would suggest to revert manual unrolling and let the compiler decide which
optimization steps should be taken.
[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Aldy Hernandez --- Fixed in trunk.
[Bug ipa/80899] [6/7/8 Regression] Devirtualization causes incorrect code generation with placement new in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80899 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill --- (In reply to Jan Hubicka from comment #4) > Is this valid C++? bar.mem is non-POD and is already constructed and it > seems fishy to placement new it to something different. It's very fishy; the code should use aligned_storage rather a different non-trivial type. My old proposed resolution for wg21.link/cwg1116 would have clarified that this is undefined, and might still happen to resolve wg21.link/cwg1027 , but it hasn't been accepted yet. On the other hand, it is careful to use the pointer returned from placement new rather than a pointer derived from mem, and it seems like we ought to use the information from placement new to guide devirtualization. So...sketchy code in a volatile area of semantics, but it seems like we could get it right without breaking important optimizations.
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #6 from Pierre-Marie de Rodat --- Just got a notification that it got assigned issue #180123.1: http://dwarfstd.org/ShowIssue.php?issue=180123.1
[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169 ktkachov at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-01 CC||ktkachov at gcc dot gnu.org Known to work||7.3.1 Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed
[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84169
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #2 from ktkachov at gcc dot gnu.org ---
I think combine is at fault here. The faulty assembly is:
foo:
ldrbw0, [sp, 16]
neg x0, x0, lsl 4
csetm x3, ne
The csetm is supposed to set the top 64 bits of the TImode value (in x3) to
ones, based on the CC content, but the CC-setting instruction has disappeared.
The correct sequence (by hacking the assembly output and checking that it
passes) would be:
ldrbw0, [sp, 16]
negs x0, x0, lsl 4 // NEG sets the condition code as well.
csetm x3, ne
There's a few complex combinations going on, but before combine we have (some
RTL edited to tone down verbosity):
(insn 14 12 17 2 (set (reg:DI 87)
(lshiftrt:DI (reg:DI 103)
(const_int 60 [0x3c]))) "wrong.c":9 676
{*aarch64_lshr_sisd_or_int_di3}
(insn 19 17 20 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (reg:DI 85)
(reg:DI 105)))
(set (reg:DI 90)
(minus:DI (reg:DI 85)
(reg:DI 105)))
]) "wrong.c":9 270 {subdi3_compare1}
(insn 20 19 23 2 (set (reg:DI 91)
(minus:DI (minus:DI (reg:DI 85)
(reg:DI 87))
(ltu:DI (reg:CC 66 cc)
(const_int 0 [0] "wrong.c":9 327 {*subdi3_carryin}
where insn 19 sets the CC and insn 20 uses it. After combine we have:
(insn 14 12 17 2 (set (reg:DI 87)
(lshiftrt:DI (reg:DI 103)
(const_int 60 [0x3c]))) "wrong.c":9 676
{*aarch64_lshr_sisd_or_int_di3}
(note 19 17 20 2 NOTE_INSN_DELETED)
(insn 20 19 23 2 (set (reg:DI 91)
(neg:DI (ne:DI (reg:CC 66 cc)
(const_int 0 [0] "wrong.c":9 441 {cstoredi_neg}
with insn 20 still using the CC but the CC setting instruction being deleted.
There's a number of exciting things going on in combine so my analysis may not
be entirely accurate, but I see things like:
Trying 14 -> 20:
14: r87:DI=r103:DI 0>>0x3c
20: r91:DI=r85:DI-r87:DI-ltu(cc:CC,0)
REG_DEAD r87:DI
REG_DEAD r85:DI
REG_DEAD cc:CC
REG_EQUAL -r87:DI-ltu(cc:CC,0)
Successfully matched this instruction:
(set (reg:DI 91)
(neg:DI (ltu:DI (reg:CC 66 cc)
(const_int 0 [0]
and
Trying 19 -> 26:
19: cc:CC=cmp(r103:DI,0)
REG_DEAD r103:DI
26:
{cc:CC_C=zero_extend(r90:DI)+zero_extend(r111:DI)!=zero_extend(r90:DI+r111:DI);r95:DI=r90:DI+r111:DI;}
REG_DEAD r111:DI
REG_DEAD r90:DI
Successfully matched this instruction:
(parallel [
(set (reg:CC_C 66 cc)
(ne:CC_C (plus:TI (zero_extend:TI (reg:DI 90))
(zero_extend:TI (reg:DI 111 [ b ])))
(zero_extend:TI (plus:DI (reg:DI 90)
(reg:DI 111 [ b ])
(set (reg:DI 95)
(plus:DI (reg:DI 90)
(reg:DI 111 [ b ])))
])
deferring deletion of insn with uid = 19.
So insn 19 ends up being combined into a subsequent instruction and ends up
being deleted even though insn 20 depends on it's CC-setting effects
[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010 --- Comment #11 from Peter Bergner --- Author: bergner Date: Thu Feb 1 18:26:51 2018 New Revision: 257305 URL: https://gcc.gnu.org/viewcvs?rev=257305&root=gcc&view=rev Log: PR target/56010 PR target/83743 * config/rs6000/driver-rs6000.c: #include "diagnostic.h". #include "opts.h". (rs6000_supported_cpu_names): New static variable. (linux_cpu_translation_table): Likewise. (elf_platform) : Define new static variable and use it. Translate kernel AT_PLATFORM name to canonical name if needed. Error if platform name is unknown. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/driver-rs6000.c
[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743 --- Comment #6 from Peter Bergner --- Author: bergner Date: Thu Feb 1 18:26:51 2018 New Revision: 257305 URL: https://gcc.gnu.org/viewcvs?rev=257305&root=gcc&view=rev Log: PR target/56010 PR target/83743 * config/rs6000/driver-rs6000.c: #include "diagnostic.h". #include "opts.h". (rs6000_supported_cpu_names): New static variable. (linux_cpu_translation_table): Likewise. (elf_platform) : Define new static variable and use it. Translate kernel AT_PLATFORM name to canonical name if needed. Error if platform name is unknown. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/driver-rs6000.c
