[Bug c++/81632] spurious -Wterminate warning about throw in destructor

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81632

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Martin Sebor  ---
Resolving as Invalid per comment #1.

[Bug bootstrap/81638] [7 Regression] AIX bootstrap failure due to Recover GOTO predictor

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638

--- Comment #4 from David Edelsohn  ---
The test around the setting of incl is the same as the test around the use of
incl at the place of the false positive uninitialized error

  for (i = 0; i < vec->count; ++i)
incl = ...

  if (i < vec->count)
 filename = incl->filename

[Bug bootstrap/81638] [7 Regression] AIX bootstrap failure due to Recover GOTO predictor

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638

--- Comment #3 from Andrew Pinski  ---
Just for reference we have:
  for (i = 0; i < vec->count; ++i)
 {
   incl = (struct xcoff_incl *) vec->vec.base + i;
   if (incl->begin <= lnnoptr && lnnoptr <= incl->end)
 break;
 }
  if (begincl == -1)
 begincl = (i < vec->count);
  if (i < vec->count)
 {
   filename = incl->filename;
   if (begincl == 1)
 lnno += fcn_lnno - 1;
 }
  else
 lnno += fcn_lnno - 1;

Hmm, if i == 0 and vec->count is 0, then incl can be uninitialized.

I can't find a way for GCC to know vec->count is non zero here ...  Unless I
miss something.

[Bug c++/81609] incompatible extern C declarations of the same extern function at local scope accepted

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81609

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=32042

--- Comment #3 from Martin Sebor  ---
It does look similar or related to bug 32042.

The C front-end does the right thing and rejects the mismatched declarations,
so G++ doesn't match its behavior for the equivalent extern "C" case.  G++ only
rejects the conflicting declarations if they both have C++ linkage.

[Bug bootstrap/81638] [7 Regression] AIX bootstrap failure due to Recover GOTO predictor

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638

--- Comment #2 from David Edelsohn  ---
Created attachment 41877
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41877=edit
pre-processed xcoff.c compiled on AIX 7.2

[Bug bootstrap/81638] [7 Regression] AIX bootstrap failure due to Recover GOTO predictor

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|AIX bootstrap failure due   |[7 Regression] AIX
   |to Recover GOTO predictor   |bootstrap failure due to
   ||Recover GOTO predictor
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/81638] New: AIX bootstrap failure due to Recover GOTO predictor

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638

Bug ID: 81638
   Summary: AIX bootstrap failure due to Recover GOTO predictor
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

The patch breaks bootstrap on AIX and probably is a hidden bug on all targets.

With the patch, libbacktrace/xcoff.c fails to compile with the error:

/nasfarm/edelsohn/src/src/libbacktrace/xcoff.c: In function 'xcoff_add':
/nasfarm/edelsohn/src/src/libbacktrace/xcoff.c:822:13: error: 'incl'
may be used uninitialized in this function
[-Werror=maybe-uninitialized]
filename = incl->filename;
~^~~~
/nasfarm/edelsohn/src/src/libbacktrace/xcoff.c:777:22: note: 'incl'
was declared here
   struct xcoff_incl *incl;
  ^~~~

incl is used immediately above the line that produces the warning --
with no warning.

[Bug c/39985] Type qualifiers not actually ignored on function return type

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985

--- Comment #5 from joseph at codesourcery dot com  ---
In C, in C11 mode, type qualifiers are completely ignored on function 
return types, including not affecting type compatibility, after my commit:

r236231 | jsm28 | 2016-05-13 21:35:39 + (Fri, 13 May 2016) | 46 lines

Implement C11 DR#423 resolution (ignore function return type qualifiers).

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925

--- Comment #19 from Steve Ellcey  ---
Author: sje
Date: Mon Jul 31 21:44:34 2017
New Revision: 250752

URL: https://gcc.gnu.org/viewcvs?rev=250752=gcc=rev
Log:
2017-07-31  Steve Ellcey  

PR tree-optimization/80925
* gcc.dg/vect/no-section-anchors-vect-69.c: Add 
--param vect-max-peeling-for-alignment=0 option.
Remove unaligned access and peeling checks.
* gcc.dg/vect/section-anchors-vect-69.c: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c
trunk/gcc/testsuite/gcc.dg/vect/section-anchors-vect-69.c

[Bug c/79696] missing -Wunused-result on calls to malloc() and calloc()

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79696

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #3 from Martin Sebor  ---
Whoops.  The test case is below.  Also, the calls to the functions are only
eliminated with optimization.  Otherwise they're emitted and the leaks allowed
to go undetected.  (For some reason I don't understand, Glibc only also marks
functions warn_unused_result with _FORTIFY_SOURCE, otherwise its __wur macro
that's used for this purpose expands to nothing.)

$ cat a.c && gcc -S -Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout
a.c
void f (unsigned n)
{
  __builtin_malloc (n);
}

void g (unsigned n)
{
  __builtin_calloc (n, n);
}

void h (unsigned n)
{
  __builtin_aligned_alloc (n, 2);
}

;; Function f (f, funcdef_no=2, decl_uid=2364, cgraph_uid=2, symbol_order=2)

f (unsigned int n)
{
  long unsigned int _1;

   [0.00%] [count: INV]:
  _1 = (long unsigned int) n_2(D);
  __builtin_malloc (_1);
  return;

}



;; Function g (g, funcdef_no=3, decl_uid=2367, cgraph_uid=3, symbol_order=3)

g (unsigned int n)
{
  long unsigned int _1;
  long unsigned int _2;

   [0.00%] [count: INV]:
  _1 = (long unsigned int) n_3(D);
  _2 = (long unsigned int) n_3(D);
  __builtin_calloc (_2, _1);
  return;

}



;; Function h (h, funcdef_no=4, decl_uid=2370, cgraph_uid=4, symbol_order=4)

h (unsigned int n)
{
  long unsigned int _1;

   [0.00%] [count: INV]:
  _1 = (long unsigned int) n_2(D);
  __builtin_aligned_alloc (_1, 2);
  return;

}

[Bug c/80130] Wrong diagnostic: dereferencing type-punned pointer

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80130

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
I only get 1 warning on (1) and only with -Wstrict-aliasing=1.
-Wstrict-aliasing=2 and -Wstrict-aliasing=3 are both silent.

(In reply to Richard Biener from comment #1)
> The warning implementation is incredibly stupid, don't use it.  It doesn't
> have any context (so the two stmt variant is different from the single stmt
> one).

It'd still be nice if it could be improved though. Although, maybe it already
has been?

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

--- Comment #12 from Bill Schmidt  ---
(In reply to Jakub Jelinek from comment #9)
> I take back the ARRAY_TYPE thing, apparently it is different for C vs. C++,
> in C one always sees there POINTER_TYPE, while in C++ always ARRAY_TYPE.
> Anyway, your patch seems to be wrong, POINTER_TYPE_P's argument should be a
> type, while you are passing it an argument instead ((*arglist)[1] is arg1,
> not
> arg1_type = TREE_TYPE (arg1)).

Yes, I agree.  I'll let you lead on this from here as you are well into it. 
Thanks!

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

--- Comment #11 from Bill Schmidt  ---
I went spelunking and found that the ARRAY_TYPE change was added here: 
https://gcc.gnu.org/viewcvs/gcc?view=revision=237077.  Looks like a
C++ implementation detail.

[Bug testsuite/81626] Need effective target omp_target

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626

--- Comment #5 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #4)
> (In reply to Thomas Schwinge from comment #3)
> > Yeah, I suppose you just need to remove a "--disable-multilib" from your
> > nvptx offloading GCC build configuration, so that the "mgomp" multilib gets
> > built in addition to the "default" one?
> 
> It would be great if it is that simple.

It is (at least in my build scripts).

> Have you ever tried that?

Have been using that ever since the OpenMP nvptx offloading got committed to
GCC trunk, which added the "mgomp" multilib, r242503 "nvptx backend
prerequisites for OpenMP offloading".

> I see you're the one who's added the "--disable-multilib" in our nvptx
> offloading GCC build configuration (which is what I'm using).

Which exactly?

> What was the
> reason for that?

Off-hand I can only remember using "--disable-multilib" for the target GCC
build configuration, for we're not supporting offloading in 32-bit
configurations, and are thus interested only in 64-bit x86_64 but not 32-bit
i686, which also gets built by default for x86_64-pc-linux-gnu.

[Bug tree-optimization/81637] New: [8 regression] compilation of 416.games from spec2006 fails starting with r250670

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81637

Bug ID: 81637
   Summary: [8 regression] compilation of 416.games from spec2006
fails starting with r250670
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

/home/seurer/gcc/install/gcc-test2/bin/gfortran -c -o symorb.fppized.o -m64 -O3
-mcpu=power8 -ffast-math -funroll-loops -fpeel-loops -fvect-cost-model
-mpopcntd -mrecip=rsqrt -funconstrained-commons symorb.fppized.f
during GIMPLE pass: pcom
symorb.fppized.f:2246:0:

   SUBROUTINE SYMOR2(GEN1,GEN2,GEN3,CHARR,TRACEP,TRACED,

internal compiler error: in is_inv_store_elimination_chain, at
tree-predcom.c:1651
0x10b390fb is_inv_store_elimination_chain
/home/seurer/gcc/gcc-test2/gcc/tree-predcom.c:1651
0x10b390fb prepare_initializers_chain_store_elim
/home/seurer/gcc/gcc-test2/gcc/tree-predcom.c:2786
0x10b390fb prepare_initializers_chain
/home/seurer/gcc/gcc-test2/gcc/tree-predcom.c:2846
0x10b390fb prepare_initializers
/home/seurer/gcc/gcc-test2/gcc/tree-predcom.c:2901
0x10b3ba1f tree_predictive_commoning_loop
/home/seurer/gcc/gcc-test2/gcc/tree-predcom.c:3092
0x10b3e167 tree_predictive_commoning()
/home/seurer/gcc/gcc-test2/gcc/tree-predcom.c:3170

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759

--- Comment #61 from Daniel Santos  ---
(In reply to Dominique d'Humieres from comment #60)
> At revision r250610 I still see
> 
> WARNING: Could not generate
> /opt/gcc/build_w/gcc/testsuite/gcc/ms-sysv/ms-sysv-generated.h

Thank you for the report.  Perhaps I should have had the test error here
instead of issue a warning.  Can you please post the part of the log file where
the generator fails?

The various building ms-sysv.c are expected if the generator failed.  The
contents of ms-sysv-generated.h are part of each test run.  The -DGEN_ARGS= is
actually ignored by the program -- it's just there to make each test
description unique while reflecting the arguments passed to the generator (to
create the ms-sysv-generated.h used to build that test).

Thanks!
Daniel

[Bug c++/81636] New: Confusing warning message containing "#‘obj_type_ref’ not supported by expression#"

[abbeyj+gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81636

Bug ID: 81636
   Summary: Confusing warning message containing "#‘obj_type_ref’
not supported by expression#"
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abbeyj+gcc at gmail dot com
  Target Milestone: ---

This occurs with any version of GCC that I've tried that recognizes -std=c++11.
 It seems to affect all versions v4.7.1 through v7.1 according to
https://gcc.godbolt.org/

Test case:
class C {
  virtual int MyVirtual();
  void Foo();
};

void C::Foo() {
  int x{ MyVirtual() / 2.0 };
}


$ g++-4.9.4 -std=c++11 -c test.cpp
test.cpp: In member function ‘void C::Foo()’:
test.cpp:7:22: warning: narrowing conversion of ‘((double)(#‘obj_type_ref’ not
supported by expression#)(this) / 2.0e+0)’ from ‘double’ to ‘int’ inside { }
[-Wnarrowing]
   int x{ MyVirtual() / 2.0 };
  ^


I believe that GCC is correct to issue a warning here.  But the text of the
warning message is not friendly, especially the "#‘obj_type_ref’ not supported
by expression#" part.

[Bug c++/81632] spurious -Wterminate warning about throw in destructor

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81632

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
You are wrong. The warning is correct, because the code only catches the first
exception and then rethrows it within the int handler again. The rethrown
exception is not caught, you would need a separate try/catch for this.

[Bug target/81635] New: nvptx SLP test cases regressions

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635

Bug ID: 81635
   Summary: nvptx SLP test cases regressions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

I noticed that trunk r249896 "Tweak BB analysis for dr_analyze_innermost"
breaks some of the nvptx SLP test cases recently contributed by Tom.  (Tom
committed the nvptx SLP patches later, but had tested these on an earlier GCC
sources revision, apparently.)

PASS: gcc.target/nvptx/slp.c (test for excess errors)
FAIL: gcc.target/nvptx/slp.c scan-assembler ld.v2.u32
FAIL: gcc.target/nvptx/slp.c scan-assembler st.v2.u32

PASS: gcc.target/nvptx/slp-2.c (test for excess errors)
FAIL: gcc.target/nvptx/slp-2.c scan-assembler ld.v2.u64
FAIL: gcc.target/nvptx/slp-2.c scan-assembler st.v2.u64

I have not analyzed what the actual problem is, whether it is something latent
that r249896 just uncovered, for example.

Testing on top of last week's trunk r250635, I can make these SLP test cases
PASS again (with no other regressions/changes) if reverting trunk r249896, plus
a handful of later patches touching the same code: r249911, r249913, r249914,
r249915, r249916, r249917.

[Bug c/79959] -Wimplicit-fallthrough doesn't recognize some more complex exit cases

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79959

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that gcc warns.

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=30552

--- Comment #5 from Eric Gallager  ---
Related due to also mixing ({...}) with VLA: bug 30552. (Can stay separate
since they're different testcases though)

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #41875|0   |1
is obsolete||

--- Comment #10 from Jakub Jelinek  ---
Created attachment 41876
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41876=edit
gcc8-pr81622.patch

Updated, but still untested, patch.  For vec_st, if the computation is moved
where it is actually used, I think we don't really need to check that
explicitly, the rs6000_builtin_type_compatible calls should ensure that.

[Bug c/79696] missing -Wunused-result on calls to malloc() and calloc()

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79696

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-31
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Was the testcase truncated or something? I don't see how it's supposed to show
anything about malloc() et al. when the source doesn't even contain calls to
them...

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

--- Comment #9 from Jakub Jelinek  ---
I take back the ARRAY_TYPE thing, apparently it is different for C vs. C++, in
C one always sees there POINTER_TYPE, while in C++ always ARRAY_TYPE.
Anyway, your patch seems to be wrong, POINTER_TYPE_P's argument should be a
type, while you are passing it an argument instead ((*arglist)[1] is arg1, not
arg1_type = TREE_TYPE (arg1)).

[Bug c/79667] spurious -Wunused-variable on a local array of struct declared unused

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79667

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug c/79688] ICE with a RTL test-case and -O1 provided

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79688

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that gcc ICEs, although is 'c' really the right component?

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

--- Comment #8 from Bill Schmidt  ---
I should clarify that Richard reviewed the VEC_LD / VEC_ST code chunks.  The
other pieces predate me.  The stylistic issues were copied from another place
at the time and I missed those, sorry about that...

[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81633

--- Comment #4 from Jakub Jelinek  ---
I'm afraid the tree-vect-slp.c change is completely wrong, the original change
in
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01090.html if the oprnd == NULL
has child_index++; looks reasonable to me.  It changed a fragile code into much
more fragile code which will be always wrong if there are stmts with duplicated
(or more) operands.
Trying to recompute child_index from just oprnd is wrong, there can be multiple
arguments equal to the same SSA_NAME and which exact one it is should really be
derived from the index (dunno why we need child_index var, wouldn't it be
sufficient to use i for that)?
Are there (after the tree-vect-loop.c caller has been fixed in the same
revision) any vect_get_slp_defs callers which pass arguments with gaps or where
the oprnd i to child_index mapping shouldn't be identity?
I wonder about COND_EXPR with non-COMPARISON_CLASS_P first argument, but am not
sure.
E.g. vect_create_new_slp_node counts it as 2 regardless of what the first
argument is:
  else if (is_gimple_assign (stmt))
{
  nops = gimple_num_ops (stmt) - 1;
  if (gimple_assign_rhs_code (stmt) == COND_EXPR)
nops++;
}
while vect_get_and_check_slp_defs has:
  if (gimple_assign_rhs_code (stmt) == COND_EXPR
  && COMPARISON_CLASS_P (gimple_assign_rhs1 (stmt)))
{
  first_op_cond = true;
  number_of_oprnds++;
}
which then matches e.g. masked handling in tree-vect-stmts.c
(vectorizable_condition).

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

--- Comment #7 from Bill Schmidt  ---
This code was reviewed and approved by Richard back when it was first written.

It's been some time since this was written, so I don't recall the origin of the
array type, but it was definitely necessary.  There are probably some test
cases from the original patch submission that show this.  I would have to go
digging to find that.

As stated in the submission note, the real long-term fix for this is to have
these built-in functions handled during gimple built-in folding instead.  I
wasn't aware of that as a target-hook option at the time this code went in. 
Gimple built-in folding would be much simpler since the grotty work of parsing
and error handling is behind us.  This is on the list to be done, but hasn't
been completed yet.

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033

--- Comment #25 from Dominique d'Humieres  ---
I have posted the results on darwin for r250610 at
https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg02582.html. I see 646
failures compared to 318 with r249104.

I am planning to open new Pos for the most offending problems.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 Ever confirmed|0   |1

--- Comment #60 from Dominique d'Humieres  ---
At revision r250610 I still see

WARNING: Could not generate
/opt/gcc/build_w/gcc/testsuite/gcc/ms-sysv/ms-sysv-generated.h
WARNING: Could not generate
/opt/gcc/build_w/gcc/testsuite/gcc/ms-sysv/ms-sysv-generated.h
WARNING: Could not generate
/opt/gcc/build_w/gcc/testsuite/gcc/ms-sysv/ms-sysv-generated.h
WARNING: Could not generate
/opt/gcc/build_w/gcc/testsuite/gcc/ms-sysv/ms-sysv-generated.h
WARNING: Could not generate
/opt/gcc/build_w/gcc/testsuite/gcc5/ms-sysv/ms-sysv-generated.h
WARNING: Could not generate
/opt/gcc/build_w/gcc/testsuite/gcc5/ms-sysv/ms-sysv-generated.h
WARNING: Could not generate
/opt/gcc/build_w/gcc/testsuite/gcc5/ms-sysv/ms-sysv-generated.h
WARNING: Could not generate
/opt/gcc/build_w/gcc/testsuite/gcc5/ms-sysv/ms-sysv-generated.h
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O0 -g3 "-DGEN_ARGS=-p0\\
--omit-rbp-clobbers" (test for excess errors)
UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O0 -g3 "-DGEN_ARGS=-p0\\
--omit-rbp-clobbers" compilation failed to produce executable
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O2 "-DGEN_ARGS=-p0" (test for
excess errors)
UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O2 "-DGEN_ARGS=-p0"
compilation failed to produce executable
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O2 "-DGEN_ARGS=-p1" (test for
excess errors)
UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O2 "-DGEN_ARGS=-p1"
compilation failed to produce executable
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O2 "-DGEN_ARGS=-p5" (test for
excess errors)
UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O2 "-DGEN_ARGS=-p5"
compilation failed to produce executable
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0 -g3
"-DGEN_ARGS=-p0\\ --omit-rbp-clobbers" (test for excess errors)
UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0
-g3 "-DGEN_ARGS=-p0\\ --omit-rbp-clobbers" compilation failed to produce
executable
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2
"-DGEN_ARGS=-p0" (test for excess errors)
UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2
"-DGEN_ARGS=-p0" compilation failed to produce executable
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2
"-DGEN_ARGS=-p1" (test for excess errors)
UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2
"-DGEN_ARGS=-p1" compilation failed to produce executable
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2
"-DGEN_ARGS=-p5" (test for excess errors)
UNRESOLVED: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2
"-DGEN_ARGS=-p5" compilation failed to produce executable

with -m64 (see https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg02582.html).

Looking at the log file, I see

spawn -ignore SIGHUP /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/
/opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -m64
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -DGEN_ARGS=-p1
-I/opt/gcc/build_w/gcc/testsuite/gcc1/ms-sysv
-I/opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv -Wall -Wall
/opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S -lm -o
./ms-sysv.exe^M
/opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:136:37:
warning: 'do_tests' used but never defined^M
/opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:345:39:
warning: 'check_results' defined but not used [-Wunused-function]^M
/opt/gcc/work/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:227:1:
warning: 'init_test' defined but not used [-Wunused-function]^M
Undefined symbols for architecture x86_64:^M
  "_do_tests", referenced from:^M
  _main in cciP9N43.o^M
ld: symbol(s) not found for architecture x86_64^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c  -O2 "-DGEN_ARGS=-p1" (test for
excess errors)

but the test compiles if I compile it manually.

[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81633

--- Comment #3 from Jakub Jelinek  ---
In *.ifcvt dump we have
  _69 = identity[j_31][0];
  _71 = _69 * _69;
  tmp[j_31][0] = _71;
  _77 = identity[j_31][1];
  _78 = _69 * _77;
  tmp[j_31][1] = _78;
  _84 = identity[j_31][2];
  _85 = _69 * _84;
  tmp[j_31][2] = _85;
  _91 = identity[j_31][3];
  _92 = _69 * _91;
  tmp[j_31][3] = _92;
but the fact that the first stmt is _69 * _69 doesn't mean the whole SLP is a
square of another vector.

[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Thomas Koenig  ---
I agree that the current handling of *.f90 and *.f with
-cpp and -save-temps is undocumented and partially broken.

Consider creating a *.f90 file from a *.f file:

$ cat foo.f
  programme main
  end
$ gfortran -cpp -save-temps foo.f
$ cat foo.f90
# 1 "foo.f"
# 1 ""
# 1 ""
# 1 "foo.f"
  programme main
  end
$ gfortran foo.f90 
foo.f90:1:13:

 # 1 "foo.f"
 1
Fehler: Ungültige Form der PROGRAM-Anweisung bei (1)

Here, we generate a fixed-form program source with an
extension that is usually an indicator of fixed form.

One possibility would be to disable -save-temps together
with -cpp when the source file is *.f or *.f90 (or *.f03).

Creating *.f90 from *.F90 is also dangerous on Windows systems.

I think creating *.i and *.i90 files, respectively, would be
a better option. ifort does so, so there is at least some
precedent.

[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81633

--- Comment #2 from Jakub Jelinek  ---
In -fdump-tree-vect-details, the difference with this commit is:
--- pr81633.c.149t.vect.239539 2017-07-31 12:00:11.0 -0400
+++ pr81633.c.149t.vect.239542 2017-07-31 12:00:33.0 -0400
@@ -1721,8 +1721,8 @@ pr81633.c:10:5: note: vect_is_simple_use
 pr81633.c:10:5: note: def_stmt: _69 = identity[j_31][0];
 pr81633.c:10:5: note: type of def: internal
 pr81633.c:10:5: note: transform binary/unary operation.
-pr81633.c:10:5: note: add new stmt: vect__71.20_33 = vect__69.14_23 *
vect__69.18_14;
-pr81633.c:10:5: note: add new stmt: vect__71.20_19 = vect__69.15_22 *
vect__69.19_18;
+pr81633.c:10:5: note: add new stmt: vect__71.20_33 = vect__69.14_23 *
vect__69.14_23;
+pr81633.c:10:5: note: add new stmt: vect__71.20_19 = vect__69.15_22 *
vect__69.15_22;
 pr81633.c:10:5: note: -->vectorizing SLP node starting from: tmp[j_31][0]
= _71;
 pr81633.c:10:5: note: vect_is_simple_use: operand _71
 pr81633.c:10:5: note: def_stmt: _71 = _69 * _69;
@@ -1753,8 +1753,8 @@ pr81633.c:10:5: note: -->vectorizing
 pr81633.c:10:5: note: -->vectorizing statement: vectp_identity.16_5 =
vectp_identity.16_17 + 16;
 pr81633.c:10:5: note: -->vectorizing statement: vect__69.19_18 =
MEM[(double *)vectp_identity.16_5];
 pr81633.c:10:5: note: -->vectorizing statement: _91 = identity[j_31][3];
-pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_33 =
vect__69.14_23 * vect__69.18_14;
-pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_19 =
vect__69.15_22 * vect__69.19_18;
+pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_33 =
vect__69.14_23 * vect__69.14_23;
+pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_19 =
vect__69.15_22 * vect__69.15_22;
 pr81633.c:10:5: note: -->vectorizing statement: _92 = _69 * _91;
 pr81633.c:10:5: note: -->vectorizing statement: MEM[(double
*)vectp_tmp.21_16] = vect__71.20_33;
 pr81633.c:10:5: note: -->vectorizing statement: vectp_tmp.21_87 =
vectp_tmp.21_16 + 16;
@@ -1864,8 +1864,8 @@ main ()
   vectp_identity.16_5 = vectp_identity.16_17 + 16;
   vect__69.19_18 = MEM[(double *)vectp_identity.16_5];
   _91 = identity[j_31][3];
-  vect__71.20_33 = vect__69.14_23 * vect__69.18_14;
-  vect__71.20_19 = vect__69.15_22 * vect__69.19_18;
+  vect__71.20_33 = vect__69.14_23 * vect__69.14_23;
+  vect__71.20_19 = vect__69.15_22 * vect__69.15_22;
   _92 = _69 * _91;
   MEM[(double *)vectp_tmp.21_16] = vect__71.20_33;
   vectp_tmp.21_87 = vectp_tmp.21_16 + 16;

The multiplication has different operands, so the newer output looks clearly
wrong.

[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81633

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 CC||alahay01 at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |7.2
Summary|Incorrect floating point|[7/8 Regression] Incorrect
   |result with tree vectoriser |floating point result with
   ||tree vectoriser
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r239542.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490

--- Comment #15 from Uroš Bizjak  ---
I'm testing the following patch:

--cut here--
Index: i386.c
===
--- i386.c  (revision 250745)
+++ i386.c  (working copy)
@@ -19421,8 +19421,10 @@ ix86_print_operand_address_as (FILE *file, rtx add
   fputs (string, file);
 }

-  /* Use one byte shorter RIP relative addressing for 64bit mode.  */
-  if (TARGET_64BIT && !base && !index && !no_rip)
+  /* Use one byte shorter RIP relative addressing for
+ symbols in the generic address space.  */
+  if (TARGET_64BIT && !base && !index
+  && ADDR_SPACE_GENERIC_P (as) && !no_rip)
 {
   rtx symbol = disp;

@@ -19442,7 +19444,7 @@ ix86_print_operand_address_as (FILE *file, rtx add
   /* Displacement only requires special attention.  */
   if (CONST_INT_P (disp))
{
- if (ASSEMBLER_DIALECT == ASM_INTEL && parts.seg ==
ADDR_SPACE_GENERIC)
+ if (ASSEMBLER_DIALECT == ASM_INTEL && ADDR_SPACE_GENERIC_P (as))
fputs ("ds:", file);
  fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (disp));
}
--cut here--

The patched compiler compiles following testcase:

--cut here--
int __seg_gs a;

void test_as (void)
{
  a += 1;
}

__thread int b;

void test_thr (void)
{
  b += 2;
}
--cut here--

to:

test_as:
addl$1, %gs:a
ret

test_thr:
addl$2, %fs:b@tpoff
ret

[Bug testsuite/81626] Need effective target omp_target

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626

--- Comment #4 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #3)
> Yeah, I suppose you just need to remove a "--disable-multilib" from your
> nvptx offloading GCC build configuration, so that the "mgomp" multilib gets
> built in addition to the "default" one?

It would be great if it is that simple. Have you ever tried that?

I see you're the one who's added the "--disable-multilib" in our nvptx
offloading GCC build configuration (which is what I'm using). What was the
reason for that?

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

--- Comment #6 from Jakub Jelinek  ---
The aligned computation also looks like invalid IL, BIT_AND_EXPR should not
have pointer arguments I believe (though please double check with Richard), so
it should be first cast to corresponding integral type with the same precision,
then masked and then cast back to the pointer type.

[Bug c++/81634] New: Some types are incorrectly detected as not standard layout

[raskolnikov at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81634

Bug ID: 81634
   Summary: Some types are incorrectly detected as not standard
layout
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raskolnikov at gnu dot org
  Target Milestone: ---

The following code fails to compile with GCC 7.1.0 when passing -std=c++17:

```
#include 

struct a {};
struct b { int x; };
struct ca : a {};
struct cb : ca { b x; };
static_assert(std::is_standard_layout::value, "");
```

https://wandbox.org/permlink/DjuHERFFvgJg84ub

Instead of using `is_standard_layout`, we can detect the bug by using
`offsetof(cb, b)`, which incorrectly rises a warning about `cb` not being
standard layout.

It does work as expected, with -std=c++14 or with other versions of GCC.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Created attachment 41875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41875=edit
gcc8-pr81622.patch

There are many other issues in that function.

As for ARRAY_TYPE, do you have a testcase that would show how you could end up
with ARRAY_TYPE there?  I mean, C/C++ array-to-pointer conversion should happen
already before this function is called.  Or can say passing reference-to-array
result in that?

There is another issue I haven't fixed, because it means adjusting hundreds of
tests:
error ("Builtin function %s not supported in this compiler configuration",
should not use capital letter in Builtin, that is against GCC diagnostic
conventions.

[Bug c++/81618] Warn for unused functions declared in local scope

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81618

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
This request makes sense to me as an enhancement to -Wunused-function.   With
all the different forms of initialization in C++, it's not rare to accidentally
declare a function when a variable is intended, e.g., like so:

  template 
  void f ()
  {
T x ();   // declares an external function
T y (T ());   // ditto
  }

These mistakes are usually exposed when the symbol is used in a context where
an object is expected but extending -Wunused-function to diagnose locally
declared functions would help detect those that are not.

[Bug testsuite/81626] Need effective target omp_target

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords|openacc |
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-31
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
Yeah, I suppose you just need to remove a "--disable-multilib" from your nvptx
offloading GCC build configuration, so that the "mgomp" multilib gets built in
addition to the "default" one?

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

--- Comment #4 from Bill Schmidt  ---
Created attachment 41874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41874=edit
Patch under test

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #3 from Bill Schmidt  ---
Mine, need to avoid an optimization when we don't have a pointer/array type.

[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files

[barrowes at alum dot mit.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615

--- Comment #2 from Ben Barrowes  ---
Then how does one get a preprocessed/savetemp file from an existing *.f90 file?

In the case of C, preprocessed and temp files have different extensions and are
thus easily identified after compiling. For gfortran,
preprocessing/saveingtemps of *.f files produces *.f90 files which is
confusing, and preprocessing/savetemps of *.f90 files produces no output.

Gfortran needs to produce preprocessed/savetemps that have unique and easily
identifiable extensions. If not *.i and *.i90, then something else like *.t and
*.t90 or similar.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 Ever confirmed|0   |1

--- Comment #2 from Bill Schmidt  ---
Never mind, it fails that way as well.  Confirmed.  I had thought we had seen
and fixed this scenario some time ago...

[Bug tree-optimization/81633] New: Incorrect floating point result with tree vectoriser

[wence at gmx dot li]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81633

Bug ID: 81633
   Summary: Incorrect floating point result with tree vectoriser
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wence at gmx dot li
  Target Milestone: ---

Created attachment 41873
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41873=edit
Preprocessed source.

The attached source (reduced from a real kernel) multiplies a 4x4 identity
matrix by its first column,  It should produce the output:

1 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0

With GCC 7.1.0, (and a recent 8.0.0 snapshot) it produces instead:

1 1 1 1
0 0 0 0
0 0 0 0
0 0 0 0

The bug disappears if I say either -fno-tree-vectorize or
-fno-tree-loop-vectorize

$ gcc -o prog.exe -Wall -Wextra -std=c99 -pedantic -O3 -v prog.c
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-7.1.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-7.1.0/configure --prefix=/opt/wandbox/gcc-7.1.0
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-7.1.0/lib,-rpath,/opt/wandbox/gcc-7.1.0/lib64,-rpath,/opt/wandbox/gcc-7.1.0/lib32
--enable-lto
Thread model: posix
gcc version 7.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-Wpedantic' '-std=c99' '-Wall' '-Wextra'
'-O3' '-v' '-mtune=generic' '-march=x86-64'
 /opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1 -quiet -v
-imultiarch x86_64-linux-gnu prog.c -quiet -dumpbase prog.c -mtune=generic
-march=x86-64 -auxbase prog -O3 -Wpedantic -Wall -Wextra -std=c99 -version -o
/tmp/ccorXUPc.s
GNU C99 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include
 /opt/wandbox/gcc-7.1.0/include
 /opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C99 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5122689c716743eb07fee255d0dfe7c4
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-Wpedantic' '-std=c99' '-Wall' '-Wextra'
'-O3' '-v' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/cc0c1aeA.o /tmp/ccorXUPc.s
GNU assembler version 2.26.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.26.1
COMPILER_PATH=/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-Wpedantic' '-std=c99' '-Wall' '-Wextra'
'-O3' '-v' '-mtune=generic' '-march=x86-64'
 /opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/collect2 -plugin
/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/liblto_plugin.so
-plugin-opt=/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccfS7LEX.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
prog.exe /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/crtbegin.o
-L/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0
-L/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../.. -rpath
/opt/wandbox/gcc-7.1.0/lib64 /tmp/cc0c1aeA.o -lgcc --as-needed -lgcc_s

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81622

--- Comment #1 from Bill Schmidt  ---
Do you see the same behavior with "vec_ld (1, 2);" ?

[Bug libgomp/81591] segmentation fault when using priorities of nested tasks

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81591

--- Comment #4 from Jakub Jelinek  ---
Before that is available, perhaps backtrace from the gomp_fatal call in the
_LIBGOMP_CHECKING_ enabled build might be also useful.

[Bug libgomp/81591] segmentation fault when using priorities of nested tasks

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81591

--- Comment #3 from Jakub Jelinek  ---
I think we need a reproducer for this.  Can you provide something?

[Bug c/51515] Unable to forward declare nested functions

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51515

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Because it's not valid C.

[Bug libstdc++/81599] Error in documentation of std::stack

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81599

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug libstdc++/81599] Error in documentation of std::stack

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81599

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jul 31 13:44:16 2017
New Revision: 250743

URL: https://gcc.gnu.org/viewcvs?rev=250743=gcc=rev
Log:
PR libstdc++/81599
* include/bits/stl_stack.h: Fix typo.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_stack.h

[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-31
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> I was under the impression that I would get a test0.i file since the only
> documentation of using -save-temps I can find comes from the gcc docs:
> https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-save-temps

Which says

 Store the usual “temporary” intermediate files permanently.

> which mentions *.i files in their example.

because the compiled file is a C file. The *.i (*.ii) files are C (C++ files),
thus cannot (shall not) be produced by gfortran.

As noticed in comment 0, -save-temps generates a preprocessed *.f90 if it does
not already exists. Note that INCLUDE statements are ignored.

IMO this PR should be closed as INVALID or WONTFIX.

[Bug c++/81632] New: spurious -Wterminate warning about throw in destructor

[akim.demaille at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81632

Bug ID: 81632
   Summary: spurious -Wterminate warning about throw in destructor
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akim.demaille at gmail dot com
  Target Milestone: ---

In the following piece of code GCC issues a spurious warning about an exception
that escapes a dtor, although it is actually caught.

Observed with GCC 6 and 7.  GCC 5 does not feature -Wterminate.

$ cat /tmp/foo.cc
struct foo
{
  ~foo()
  {
try
  {
throw 42;
  }
catch (int)
  {
throw;
  }
catch (...)
  {
  }
  }
};

int main()
{

}
$ g++-mp-6 --version
g++-mp-6 (MacPorts gcc6 6.3.0_2) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-mp-6 -Wterminate /tmp/foo.cc -std=c++14
/tmp/foo.cc: In destructor 'foo::~foo()':
/tmp/foo.cc:11:9: warning: throw will always call terminate() [-Wterminate]
 throw;
 ^
/tmp/foo.cc:11:9: note: in C++11 destructors default to noexcept
$ g++-mp-7 --version
g++-mp-7 (MacPorts gcc7 7-20170622_0) 7.1.
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-mp-7 -Wterminate /tmp/foo.cc -std=c++14
/tmp/foo.cc: In destructor 'foo::~foo()':
/tmp/foo.cc:11:9: warning: throw will always call terminate() [-Wterminate]
 throw;
 ^
/tmp/foo.cc:11:9: note: in C++11 destructors default to noexcept

There is no such warning if this try/catch is wrapped in another one, so that's
really just the logic of bouncing to another catch clause that is missing.

Cheers!

[Bug libstdc++/81599] Error in documentation of std::stack

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81599

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81400

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
TLS canary is initialized by the libc; in Glibc sources you can grep for
THREAD_STACK_SET_GUARD.

In this example the leftmost byte of the SSP canary is overwritten by a zero.
This does not change the canary because Glibc deliberately zeroes that leftmost
byte (presumably, to harden against information-leak attacks when a string
function like strcpy can be used to copy the canary value in an
attacker-controlled manner):

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/dl-osinfo.h;h=823cd8224df939134018fbd8f0227e9f501393ab;hb=HEAD#l63

So what is the GCC bug here? What do we want to change?

[Bug target/25967] Add attribute naked for x86

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967

--- Comment #21 from Uroš Bizjak  ---
The above patch is needed to pass arguments to a naked function.

Please note that arguments can be reliably passed only in registers, so regparm
convention is necessary for x86_32.

gcc.target/i386/naked-3.c and gcc.target/i386/naked-4.c testcases show function
arguments and function result passing in action.

[Bug libstdc++/81599] Error in documentation of std::stack

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81599

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  I'll send a patch.

[Bug target/25967] Add attribute naked for x86

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jul 31 13:11:59 2017
New Revision: 250742

URL: https://gcc.gnu.org/viewcvs?rev=250742=gcc=rev
Log:
PR target/25967
* config/i386/i386.c (ix86_allocate_stack_slots_for_args):
New function.
(TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS): Define.

testsuite/ChangeLog:

PR target/25967
* gcc.target/i386/naked-3.c (dg-options): Use -O0.
(naked): Add attribute regparm(1) for x86_32 targets.
Add integer argument.  Remove global "data" variable.
(main): Pass integer argument to naked function.
* gcc.target/i386/naked-4.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/naked-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/naked-3.c

[Bug testsuite/81624] [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c scan-assembler-not and[^\n\r]*sp

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81624

H.J. Lu  changed:

   What|Removed |Added

 CC|hjl at gcc dot gnu.org |jakub at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #1 from H.J. Lu  ---
A patch was posted at

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00400.html

and waiting from review from Jakub:

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01568.html

H.J.

[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307

--- Comment #4 from Jakub Jelinek  ---
Looking at gdb I see though that the block_address_function_relative variable
is computed from the object format, so I'm afraid it has to be relative.
Another option is to pretend there isn't just one function, but two with the
same origin.
As -g* options shouldn't affect code generation, we can hardly disable hot/cold
partitioning if -gstabs is used.

[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jan.kratochvil at redhat dot 
com,
   ||palves at redhat dot com

--- Comment #3 from Jakub Jelinek  ---
For the N_SLINE stuff, I guess something like:
--- dbxout.c.jj 22017-07-29 09:50:38.0 +0200
+++ dbxout.c 2017-07-31 14:30:00.474385901 +0200
@@ -1273,7 +1273,8 @@ dbxout_source_line (unsigned int lineno,
 #ifdef DBX_OUTPUT_SOURCE_LINE
   DBX_OUTPUT_SOURCE_LINE (asm_out_file, lineno, dbxout_source_line_counter);
 #else
-  if (DBX_LINES_FUNCTION_RELATIVE)
+  if (DBX_LINES_FUNCTION_RELATIVE
+  && in_cold_section_p == first_function_block_is_cold)
 {
   char begin_label[20];
   dbxout_begin_stabn_sline (lineno);

could cure that part.  No idea how the debugger finds out if it is absolute or
relative though.
Then there is DBX_BLOCKS_FUNCTION_RELATIVE macro which decides if N_LBRAC or
N_RBRAC should be relative to start of function or not.  Again, no idea how the
debugger finds out if it is relative or absolute.
So I guess we need help from the debugger folks here...

[Bug testsuite/81626] Need effective target omp_target

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626

--- Comment #2 from Jakub Jelinek  ---
Ugh, that is going to be a maintainance nightmare for the testsuite.
Why and how are you configuring your accel compiler without the OpenMP support?

[Bug tree-optimization/81588] [7/8 Regression] Wrong code at -O2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81588

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #41860|0   |1
is obsolete||

--- Comment #3 from Jakub Jelinek  ---
Created attachment 41872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41872=edit
gcc8-pr81588.patch

Untested fix - second attempt.

[Bug hsa/81477] HSA offloading regressions: "function cannot be cloned"

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81477

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Jambor  ---
Fixed.

[Bug hsa/81477] HSA offloading regressions: "function cannot be cloned"

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81477

--- Comment #4 from Martin Jambor  ---
Author: jamborm
Date: Mon Jul 31 11:18:31 2017
New Revision: 250738

URL: https://gcc.gnu.org/viewcvs?rev=250738=gcc=rev
Log:
[PR 81477] Set versionable regardless of optimization level

2017-07-31  Martin Jambor  

PR hsa/81477
* ipa-fnsummary.c (ipa_fn_summary_generate): Set versionable
regardless of optimization level.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-fnsummary.c

[Bug testsuite/81626] Need effective target omp_target

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81626

--- Comment #1 from Tom de Vries  ---
Created attachment 41871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41871=edit
Tentative patch

[Bug c/81631] New: -Wcast-qual false positive for pointer to array

[gcc17 at cwde dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81631

Bug ID: 81631
   Summary: -Wcast-qual false positive for pointer to array
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc17 at cwde dot de
  Target Milestone: ---

Hi,

--
typedef int footype[6];

extern void const * bar;

void baz(void)
{
  footype const * x;
  x = (footype const *) bar;
}
--

with -Wcast-qual, this yields

--
$ gcc -Wcast-qual -c foo.c
foo.c:12:7: warning: cast discards 'const' qualifier from pointer target type
[-Wcast-qual]
   x = (footype const *) bar;
   ^
--

If "footype" is any other type than an array, I don't get the warning. I tested
gcc 4.5.1, 6.3.0, 7.1.0, on cygwin and Debian, all show this behavior. clang
doesn't warn.

[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81400

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Adding to CC people who can know how initialization of TLS stack protection
canary should work.

[Bug fortran/44292] [libgfortran ABI breakage] Increase internal size of RECL= of the OPEN statement

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44292

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2010-05-30 05:38:00 |2017-7-31
 CC||jvdelisle at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
Hi Jerry,

should we also look at this when we bump the library number?

[Bug c/81630] powl returns values with insufficient accuracy

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81630

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Marc Glisse  ---
> Apple LLVM version 8.1.0 (clang-802.0.42)

That's not gcc.

[Bug target/25967] Add attribute naked for x86

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967

--- Comment #19 from Daniel Santos  ---
(In reply to Uroš Bizjak from comment #18)
> Implemented for gcc 8.

Awesome!  There are actually a number of times over the years that I've wished
this were implemented, thanks! :)

[Bug c/81629] redefined memcpy leads to segmentation fault

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
We'll need something like -Wincompatible-library-redeclaration.  If the user
declares a library function and that declaration is not compatible, shout.

[Bug target/81614] Should -mtune-ctrl=partial_reg_stall be turned by default?

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81614

--- Comment #7 from Jan Hubicka  ---
As a historical note, X86_TUNE_PARTIAL_REG_STALL was moved to historical relics
at the time both current designs (Penium 4 and Athlon) were using
PARTIAL_REG_DEPENDENCY. I believed that main reason for this design was good
perofrmance for 16bit code which is no longer a priority.

It should have been pulled back when this concept was re-introduced for Pentium
M and Cores (which i did not notice :)

[Bug target/25967] Add attribute naked for x86

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Uroš Bizjak  ---
Implemented for gcc 8.

[Bug c/81630] New: powl returns values with insufficient accuracy

[kakehi at waseda dot jp]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81630

Bug ID: 81630
   Summary: powl returns values with insufficient accuracy
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kakehi at waseda dot jp
  Target Milestone: ---

Created attachment 41870
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41870=edit
compare powl(t,N) with exp2l(N*log2l(t))

I calculated powl(t,N) where t= (N+1)/N, N: an integer value 2^n (n: positive
integer) to get an approximation to Napier's constant.
Here is some results:
  n  powl(t, N)exp2l(N*log2l(t))
 25: 2.7182817879534639155837683e+00  2.7182817879534906457209692e+00
 26: 2.7182818082062409458920377e+00  2.7182818082062676638861742e+00
 27: 2.7182818183325918449770586e+00  2.7182818183326563803766523e+00
 28: 2.7182818233957862993910304e+00  2.7182818233958507905551755e+00
 29: 2.7182818259273639105617903e+00  2.7182818259274480086548631e+00
 30: 2.7182818271931621957604452e+00  2.7182818271932466208488932e+00
 31: 2.7182818278260525070993969e+00  2.7182818278261459278132700e+00
 32: 2.7182818278260525070993969e+00  2.7182818281425955814038786e+00
 33: 2.7182818278260525070993969e+00  2.7182818283008204083076031e+00
 34: 2.7182818278260525070993969e+00  2.7182818283799328217594654e+00
 35: 2.7182818278260525070993969e+00  2.7182818284194890285938168e+00
As you see, powl(t,N) values have saturated when n>30, where exp2l(N*log2l(t)),
which is a formula mathematically equivalent to powl(t,N), produces increasing
values in converging to Napier's constant.

The values are obtained by the program "comparePow.c":

#include 
#include 
#include 
/*  checking the powl function.
*/

int main(int argc, char *argv[]){
  if( argc==1 ){ printf("usage: $ comparePOW n [m]"); exit(-1);}
  int n= atoi(argv[1]), m;
  if( argc==2 ) m= n; else m= atoi(argv[2]);
  for(int i= n; i<=m; i++){
long double N=powl(2.0, (long double)i);
if( N==N+1 ){ printf("too large N\n"); exit(-1); }
long double t= (N+1)/N;
long double powlx= powl(t,N);
long double powly= exp2l(N*log2l(t));
printf("%3d: %.25Le  %.25Le\n", i, powlx, powly);
  }

  return 0;

}

by running it with the command "./a.out 25 35".

The command "gcc -v" produces:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/c++/4.2.1
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[Bug target/25967] Add attribute naked for x86

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967

--- Comment #17 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jul 31 10:22:41 2017
New Revision: 250736

URL: https://gcc.gnu.org/viewcvs?rev=250736=gcc=rev
Log:
PR target/25967
* config/i386/i386.c (ix86_function_naked): New function.
(ix86_can_use_return_insn_p): Return false for naked functions.
(ix86_expand_prologue): Skip prologue for naked functions.
(ix86_expand_epilogue): Skip epilogue for naked functions
and emit trap instruction.
(ix86_warn_func_return): New function.
(ix86_attribute_table): Add "naked" attribute specification.
(TARGET_WARN_FUNC_RETURN): Define.
* doc/extend.texi (x86 Function Attributes) : Document it.

testsuite/ChangeLog:

PR target/25967
* gcc.target/i386/naked-1.c: New test.
* gcc.target/i386/naked-2.c: Ditto.
* gcc.target/i386/naked-3.c: Ditto.
* gcc.target/x86_64/abi/ms-sysv/ms-sysv.c: Remove
do_test_body0 stub function, use attribute "naked" instead.
* gcc.dg/pr44290-1.c: Use naked_functions effective target.
* gcc.dg/pr44290-2.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/naked-1.c
trunk/gcc/testsuite/gcc.target/i386/naked-2.c
trunk/gcc/testsuite/gcc.target/i386/naked-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr44290-1.c
trunk/gcc/testsuite/gcc.dg/pr44290-2.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c

[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug target/81614] Should -mtune-ctrl=partial_reg_stall be turned by default?

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81614

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #6 from Jan Hubicka  ---
There are two flags (which I believe was introduced by me)
 - partial-reg-stall which models behavior of PentiumPro where partial writes
   to register were cheap as long as the partially written register was never
   used in wider mode as the stall.
 - partial-reg-dependency which models later CPUs where partial writes are
   handled as read-mody-write instructions and thus slow even if the result
   is used only in same width as write.

   This was design of Athlons.

The first flag avoids random optimizations which replace full sized instruction
by part size (for example xol $1, eax is not changed to xorb to save size).
Still we could generate partial register stalls out of combine.

The second is trying to make sure we always read full register (by movzx). 

We set those as: 

DEF_TUNE (X86_TUNE_PARTIAL_REG_STALL, "partial_reg_stall", m_PPRO)
DEF_TUNE (X86_TUNE_PARTIAL_REG_DEPENDENCY, "partial_reg_dependency",
  m_P4_NOCONA | m_CORE_ALL | m_BONNELL | m_SILVERMONT | m_INTEL
  | m_KNL | m_AMD_MULTIPLE | m_GENERIC)

I would say that it makes no sense to have both X86_TUNE_PARTIAL_REG_STALL and
X86_TUNE_PARTIAL_REG_DEPENDENCY set on one chip.
According to Fog's manual indeed Core and later chips can rename partial
registers again so they should be moved to X86_TUNE_PARTIAL_REG_STALL category
and we should try to fix possible regressions.

In the testcase given, for X86_TUNE_PARTIAL_REG_DEPENDENCY we ought to emit the
dependency breaking instruction to clear full register before partial write 
when optimizing for speed.

All AMD chips since Athlon are however X86_TUNE_PARTIAL_REG_DEPENDENCY design
so for generic we will need to check what are the tradeoffs.  I would say that
X86_TUNE_PARTIAL_REG_DEPENDENCY is in general more conservative and works well
for (X86_TUNE_PARTIAL_REG_STALL chips as the cases we produce partial write
(sete) are relatively rare.

[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[arnd at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81592

--- Comment #2 from Arnd Bergmann  ---
I have scanned the linux kernel sources for related bogus warnings and found
six others like this one that do not show up using gcc-7.1.1 without UBSAN but
do show up with UBSAN added in:

security/keys/proc.c: In function 'proc_keys_show':
security/keys/proc.c:232:19: error: '%lu' directive writing between 1 and 20
bytes into a region of size 16 [-Werror=format-overflow=]
sound/soc/fsl/fsl_sai.c: In function 'fsl_sai_probe':
sound/soc/fsl/fsl_sai.c:837:21: error: '%d' directive writing between 1 and 10
bytes into a region of size 4 [-Werror=format-overflow=]
drivers/block/cciss.c: In function 'cciss_init_one':
drivers/block/cciss.c:5039:28: error: '%d' directive writing between 1 and 10
bytes into a region of size 3 [-Werror=format-overflow=]
sound/isa/gus/gus_mem_proc.c: In function 'snd_gf1_mem_proc_init':
sound/isa/gus/gus_mem_proc.c:72:27: error: '%i' directive writing between 1 and
10 bytes into a region of size 8 [-Werror=format-overflow=]
sound/isa/gus/gus_mem_proc.c:72:18: note: directive argument in the range [0,
2147483646]
drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_probe':
drivers/net/ethernet/marvell/mvneta_bm.c:306:17: error: ',capacity' directive
writing 9 bytes into a region of size between 1 and 10
[-Werror=format-overflow=]
drivers/net/ethernet/marvell/mvneta_bm.c:306:3: note: 'sprintf' output between
15 and 24 bytes into a destination of size 15
drivers/pnp/pnpbios/proc.c: In function 'pnpbios_proc_exit':
drivers/pnp/pnpbios/proc.c:338:18: error: '%02x' directive writing between 2
and 8 bytes into a region of size 3 [-Werror=format-overflow=]
drivers/pnp/pnpbios/proc.c:338:17: note: directive argument in the range [0,
2147483646]
drivers/mfd/max77620.c: In function 'max77620_probe':
drivers/mfd/max77620.c:282:25: error: '%d' directive writing between 1 and 10
bytes into a region of size 7 [-Werror=format-overflow=]

These are all similarly bogus to the original warning, in all cases it seems
that gcc normally has no problems identifying the range. I can provide
preprocessed source files for all instances if that helps.

[Bug c/81629] redefined memcpy leads to segmentation fault

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|ASSIGNED|NEW
  Component|middle-end  |c
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Oh.  The real issue is that the FE registers the function with the bogus
prototype as builtin.  So gimple_builtin_call_types_compatible_p sees the call
matches
the prototype.

That this is BUILT_IN_MEMCPY is simply a lie by the FE.

Still invalid input.

We also do not even warn about the bogus prototype given.

[Bug middle-end/81629] redefined memcpy leads to segmentation fault

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-31
  Component|c   |middle-end
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Use -ffreestanding or -fno-builtin-memcpy.

We ICE because gimple_builtin_call_types_compatible_p doesn't detect the arg
mismatch.

[Bug go/81617] mksigtab.sh fails to resolve NSIG with glibc 2.26

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81617

Andreas Schwab  changed:

   What|Removed |Added

Version|8.0 |7.0
   Target Milestone|--- |7.2

[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607

--- Comment #9 from rguenther at suse dot de  ---
On Mon, 31 Jul 2017, mpolacek at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607
> 
> --- Comment #8 from Marek Polacek  ---
> I'm actually testing this
> 
> --- a/gcc/cp/cp-gimplify.c
> +++ b/gcc/cp/cp-gimplify.c
> @@ -2314,9 +2314,9 @@ cp_fold (tree x)
> 
>/* A COND_EXPR might have incompatible types in branches if one or both
>  arms are bitfields.  If folding exposed such a branch, fix it up.  */
> -  if (TREE_CODE (x) != code)
> -   if (tree type = is_bitfield_expr_with_lowered_type (x))
> - x = fold_convert (type, x);
> +  if (TREE_CODE (x) != code
> + && !useless_type_conversion_p (TREE_TYPE (org_x), TREE_TYPE (x)))
> +   x = fold_convert (TREE_TYPE (org_x), x);
> 
>break;
> 
> so I hope that case is covered.  We'll see.

Yeah, hopefully the FE doesn't mess up types for aggregates ;)

useless_type_conversion_p should be fine in the gimplify hook.

[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607

--- Comment #8 from Marek Polacek  ---
I'm actually testing this

--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -2314,9 +2314,9 @@ cp_fold (tree x)

   /* A COND_EXPR might have incompatible types in branches if one or both
 arms are bitfields.  If folding exposed such a branch, fix it up.  */
-  if (TREE_CODE (x) != code)
-   if (tree type = is_bitfield_expr_with_lowered_type (x))
- x = fold_convert (type, x);
+  if (TREE_CODE (x) != code
+ && !useless_type_conversion_p (TREE_TYPE (org_x), TREE_TYPE (x)))
+   x = fold_convert (TREE_TYPE (org_x), x);

   break;

so I hope that case is covered.  We'll see.

[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607

--- Comment #7 from rguenther at suse dot de  ---
On Mon, 31 Jul 2017, mpolacek at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607
> 
> --- Comment #6 from Marek Polacek  ---
> Actually I think richi's fix is the right one.  Let me test.

Note for aggregate types fold_const might just ICE so I'm not 100% sure
we don't need some more guards on it.  Like if type != expected-type or 
so?

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81604

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed everywhere.

[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307

Jan Hubicka  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Jan Hubicka  ---
*** Bug 81623 has been marked as a duplicate of this bug. ***

[Bug debug/81623] [8 Regression] FAIL: g++.dg/debug/debug9.C -gstabs -O3 (test for excess errors)

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81623

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||hubicka at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jan Hubicka  ---
This is bug in stabs output - I am not sure if we can support debug info for
split functions there somehow. Added some info to PR81307

*** This bug has been marked as a duplicate of bug 81307 ***

[Bug fortran/81581] runtime checks for DIM argument of intrinsic SUM missing

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81581

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug fortran/81581] runtime checks for DIM argument of intrinsic SUM missing

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81581

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Jul 31 09:34:36 2017
New Revision: 250735

URL: https://gcc.gnu.org/viewcvs?rev=250735=gcc=rev
Log:
2017-07-31  Thomas Koenig  

PR fortran/81581
* m4/ifuntion.m4 (name`'rtype_qual`_'atype_code): Perform check
for dim.
(`m'name`'rtype_qual`_'atype_code): Likewise. Change type of rank
and tim to index_type.
(`s'name`'rtype_qual`_'atype_code): Perform check for dim.
* generated/iall_i16.c: Regenerated.
* generated/iall_i1.c: Regenerated.
* generated/iall_i2.c: Regenerated.
* generated/iall_i4.c: Regenerated.
* generated/iall_i8.c: Regenerated.
* generated/iany_i16.c: Regenerated.
* generated/iany_i1.c: Regenerated.
* generated/iany_i2.c: Regenerated.
* generated/iany_i4.c: Regenerated.
* generated/iany_i8.c: Regenerated.
* generated/iparity_i16.c: Regenerated.
* generated/iparity_i1.c: Regenerated.
* generated/iparity_i2.c: Regenerated.
* generated/iparity_i4.c: Regenerated.
* generated/iparity_i8.c: Regenerated.
* generated/maxloc1_16_i16.c: Regenerated.
* generated/maxloc1_16_i1.c: Regenerated.
* generated/maxloc1_16_i2.c: Regenerated.
* generated/maxloc1_16_i4.c: Regenerated.
* generated/maxloc1_16_i8.c: Regenerated.
* generated/maxloc1_16_r10.c: Regenerated.
* generated/maxloc1_16_r16.c: Regenerated.
* generated/maxloc1_16_r4.c: Regenerated.
* generated/maxloc1_16_r8.c: Regenerated.
* generated/maxloc1_4_i16.c: Regenerated.
* generated/maxloc1_4_i1.c: Regenerated.
* generated/maxloc1_4_i2.c: Regenerated.
* generated/maxloc1_4_i4.c: Regenerated.
* generated/maxloc1_4_i8.c: Regenerated.
* generated/maxloc1_4_r10.c: Regenerated.
* generated/maxloc1_4_r16.c: Regenerated.
* generated/maxloc1_4_r4.c: Regenerated.
* generated/maxloc1_4_r8.c: Regenerated.
* generated/maxloc1_8_i16.c: Regenerated.
* generated/maxloc1_8_i1.c: Regenerated.
* generated/maxloc1_8_i2.c: Regenerated.
* generated/maxloc1_8_i4.c: Regenerated.
* generated/maxloc1_8_i8.c: Regenerated.
* generated/maxloc1_8_r10.c: Regenerated.
* generated/maxloc1_8_r16.c: Regenerated.
* generated/maxloc1_8_r4.c: Regenerated.
* generated/maxloc1_8_r8.c: Regenerated.
* generated/maxval_i16.c: Regenerated.
* generated/maxval_i1.c: Regenerated.
* generated/maxval_i2.c: Regenerated.
* generated/maxval_i4.c: Regenerated.
* generated/maxval_i8.c: Regenerated.
* generated/maxval_r10.c: Regenerated.
* generated/maxval_r16.c: Regenerated.
* generated/maxval_r4.c: Regenerated.
* generated/maxval_r8.c: Regenerated.
* generated/minloc1_16_i16.c: Regenerated.
* generated/minloc1_16_i1.c: Regenerated.
* generated/minloc1_16_i2.c: Regenerated.
* generated/minloc1_16_i4.c: Regenerated.
* generated/minloc1_16_i8.c: Regenerated.
* generated/minloc1_16_r10.c: Regenerated.
* generated/minloc1_16_r16.c: Regenerated.
* generated/minloc1_16_r4.c: Regenerated.
* generated/minloc1_16_r8.c: Regenerated.
* generated/minloc1_4_i16.c: Regenerated.
* generated/minloc1_4_i1.c: Regenerated.
* generated/minloc1_4_i2.c: Regenerated.
* generated/minloc1_4_i4.c: Regenerated.
* generated/minloc1_4_i8.c: Regenerated.
* generated/minloc1_4_r10.c: Regenerated.
* generated/minloc1_4_r16.c: Regenerated.
* generated/minloc1_4_r4.c: Regenerated.
* generated/minloc1_4_r8.c: Regenerated.
* generated/minloc1_8_i16.c: Regenerated.
* generated/minloc1_8_i1.c: Regenerated.
* generated/minloc1_8_i2.c: Regenerated.
* generated/minloc1_8_i4.c: Regenerated.
* generated/minloc1_8_i8.c: Regenerated.
* generated/minloc1_8_r10.c: Regenerated.
* generated/minloc1_8_r16.c: Regenerated.
* generated/minloc1_8_r4.c: Regenerated.
* generated/minloc1_8_r8.c: Regenerated.
* generated/minval_i16.c: Regenerated.
* generated/minval_i1.c: Regenerated.
* generated/minval_i2.c: Regenerated.
* generated/minval_i4.c: Regenerated.
* generated/minval_i8.c: Regenerated.
* generated/minval_r10.c: Regenerated.
* generated/minval_r16.c: Regenerated.
* generated/minval_r4.c: Regenerated.
* generated/minval_r8.c: Regenerated.
* generated/norm2_r10.c: Regenerated.
* generated/norm2_r16.c: Regenerated.
* generated/norm2_r4.c: Regenerated.
* generated/norm2_r8.c: Regenerated.
* generated/parity_l16.c: Regenerated.
* 

[Bug c/81629] redefined memcpy leads to segmentation fault

[frederic.besson at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629

--- Comment #1 from Frédéric Besson  ---
Created attachment 41869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41869=edit
preprcessed source

[Bug c/81629] New: redefined memcpy leads to segmentation fault

[frederic.besson at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81629

Bug ID: 81629
   Summary: redefined memcpy leads to segmentation fault
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederic.besson at inria dot fr
  Target Milestone: ---

Hi,

The simple code below crashes with  internal compiler error: Segmentation
fault.
It seems gcc does not like the redefinition of memcpy.


extern unsigned long long memcpy(unsigned long long, unsigned long long,
unsigned long long);

void foo(unsigned long long ctx, unsigned long long output)
{
  memcpy(ctx + 2LLU, ctx,  1U);
  return;
}


Best regards,

[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607

--- Comment #6 from Marek Polacek  ---
Actually I think richi's fix is the right one.  Let me test.

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81604

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 31 09:29:58 2017
New Revision: 250733

URL: https://gcc.gnu.org/viewcvs?rev=250733=gcc=rev
Log:
PR sanitizer/81604
* ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't
change type to the element type, instead add eltype variable and
use it where we are interested in the element type.

* c-c++-common/ubsan/pr81604.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr81604.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/ubsan.c

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #11 from Georg-Johann Lay  ---
This cannot be fixed in GCC as C++ doesn't support ISO/IEC DTR 18037 named
address spaces.  This feature requires that the C++ front-end knows about ASes
and handles them properly.  This doesn't imply that ASes are exposed on
language level; knowing about ASes "internally" would be sufficient.  As it's
pretty much clear that C++ WG21 will never accept such qualifiers (not even the
C WG14) did, just close this as WON'T FIX.

All that can be done is proposing work-arounds: Use "Embedded-C++" coding
convention that avoids VTABLEs, or use a device that can host .rodata in flash
like families -mmcu=avrtiny and -mmcu=avrxmega3.

[Bug target/81628] New: Backport r250637 and r250638 to the powerpcspe* target

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81628

Bug ID: 81628
   Summary: Backport r250637 and r250638 to the powerpcspe* target
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: andrewjenner at gcc dot gnu.org, charlet at gcc dot gnu.org
  Target Milestone: ---
Target: powerpcspe-*-linux-gnu*

Revisions r250637 and r250638 remove -mno-lra (i.e. reload-based RA) from the
rs6000 target, leaving -mlra as a stub. They also remove -mlra from one
testcase specific to SPE targets.

However, SPE support was factored out to its own target during the stage 1 of
the gcc 8 branch lefiteme, after the point when LRA had been switched on for
rs6000 by default, so -mlra and -mno-lra still make difference there. AFAICT,
tests in testsuite/gcc.target/powerpc are shared by both targets now, so the
changes in testsuite by the aforementioned revisions also affect both of them.
Furtunately, changes in testsuite made there are safe, as they don't change RA
used by the SPE target when compiling them.

Nevertheless, it seems reasonable to disable reload for SPE as well, until two
targets did not diverge too much.

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81604

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 31 08:56:03 2017
New Revision: 250732

URL: https://gcc.gnu.org/viewcvs?rev=250732=gcc=rev
Log:
PR sanitizer/81604
* ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't
change type to the element type, instead add eltype variable and
use it where we are interested in the element type.

* c-c++-common/ubsan/pr81604.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/ubsan/pr81604.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/ubsan.c

[Bug sanitizer/81530] [8 Regression] ICE in add_stmt in gcc/cp/semantics.c:387

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81530

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Liška  ---
Fixed.