[Bug c++/53506] Variadic templates in combination with function pointer problem

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
gcc8's output has added carets:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=c++11 53506.cc
53506.cc: In function ‘int main()’:
53506.cc:17:17: error: no matching function for call to ‘A::a(int (&)(int,
int), int)’
  A::a(foo,0);
 ^
53506.cc:5:2: note: candidate: ‘template static
void A::a(RES (*)(FARGS ..., SARGS ...), FARGS ...) [with RES = RES;
FARGS = {FARGS ...}; SARGS = {int}]’
  a(RES(*func)(FARGS...,SARGS...),FARGS...)
  ^
53506.cc:5:2: note:   template argument deduction/substitution failed:
53506.cc:17:17: note:   candidate expects 1 argument, 2 provided
  A::a(foo,0);
 ^
53506.cc:18:26: error: no matching function for call to ‘A::a(int (&)(int, int), int)’
  A::a(foo,0);
  ^
53506.cc:5:2: note: candidate: ‘template static
void A::a(RES (*)(FARGS ..., SARGS ...), FARGS ...) [with RES = RES;
FARGS = {FARGS ...}; SARGS = {int}]’
  a(RES(*func)(FARGS...,SARGS...),FARGS...)
  ^
53506.cc:5:2: note:   template argument deduction/substitution failed:
53506.cc:18:26: note:   candidate expects 1 argument, 2 provided
  A::a(foo,0);
  ^
$

For comparison, clang only errors once:

$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic -std=c++11 53506.cc
53506.cc:5:9: warning: unused parameter 'func' [-Wunused-parameter]
a(RES(*func)(FARGS...,SARGS...),FARGS...)
   ^
53506.cc:18:2: error: no matching function for call to 'a'
A::a(foo,0);
^~
53506.cc:5:2: note: candidate template ignored: failed template argument
deduction
a(RES(*func)(FARGS...,SARGS...),FARGS...)
^
1 warning and 1 error generated.
$

So, confirmed that g++ errors more than might be expected.

[Bug fortran/81903] New: compiler reports a language problem (Invalid character in name at)

[karl.may0 at freenet dot de]

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

Bug ID: 81903
   Summary: compiler reports a language problem (Invalid character
in name at)
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: karl.may0 at freenet dot de
  Target Milestone: ---

Created attachment 42010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42010=edit
source code for bug reproduction

When compiling the code in the attachement the compiler reports:

Test.f90:35:18:

   x(i)%a=>y(i)%a
  1
Error: Invalid character in name at (1)

With ifort the code complies flawless. From my perspective the code complies
with the rules.

[Bug c++/39679] Some absent attributes in the tree-dump should be added

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #6 from Eric Gallager  ---
g++ no longer supports the -fdump-translation-unit flag:

$ /usr/local/bin/g++ -c -fdump-translation-unit -fsyntax-only -std=gnu++98
53360.cc
cc1plus: error: unrecognized command line option ‘-fdump-translation-unit’
$

I think I remember some debate on gcc-patches about removing it for gcc8 but I
forget the link to the thread... closing as WONTFIX since the flag probably
won't be coming back

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #33 from H.J. Lu  ---
(In reply to Eric Botcazou from comment #32)
> > Sparc defines STRICT_ALIGNMENT which leads to
> > 
> >   unsigned mode_align = GET_MODE_ALIGNMENT (TYPE_MODE (type));
> > 
> >   /* Don't override a larger alignment requirement coming from a user
> >  alignment of one of the fields.  */
> >   if (mode_align >= TYPE_ALIGN (type))
> > {
> >   SET_TYPE_ALIGN (type, mode_align);
> >   TYPE_USER_ALIGN (type) = 0; 
> > }
> > 
> > so __attribute__ ((packed)) is basically ignored on Sparc.
> 
> I don't think that's correct.  Simply, on strict-alignment targets, you
> cannot have an aggregate type less aligned than its scalar mode, if any; for
> other targets, that's only true for scalar types.  But you can have an
> aggregate type with alignment 1 if it has BLKmode.
> 
> > diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> > index 3028d55773a..6dd605810ac 100644
> > --- a/gcc/stor-layout.c
> > +++ b/gcc/stor-layout.c
> > @@ -1784,7 +1784,7 @@ finalize_type_size (tree type)
> >  
> >/* Don't override a larger alignment requirement coming from a user
> > alignment of one of the fields.  */
> > -  if (mode_align >= TYPE_ALIGN (type))
> > +  if (mode_align > TYPE_ALIGN (type))
> >{
> >  SET_TYPE_ALIGN (type, mode_align);
> >  TYPE_USER_ALIGN (type) = 0;
> > 
> > works with cross compiler.
> 
> The existing code works as intended: if the alignment given by the mode is
> larger than or equal to the type's alignment, then this alignment given by
> the mode becomes the natural alignment and TYPE_USER_ALIGN becomes
> obsolete/wrong.

We should add a testcase to show there is a difference in generated
code on Sparc.

[Bug c/53037] warn_if_not_aligned(X)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #32 from Eric Botcazou  ---
> Sparc defines STRICT_ALIGNMENT which leads to
> 
>   unsigned mode_align = GET_MODE_ALIGNMENT (TYPE_MODE (type));
> 
>   /* Don't override a larger alignment requirement coming from a user
>  alignment of one of the fields.  */
>   if (mode_align >= TYPE_ALIGN (type))
> {
>   SET_TYPE_ALIGN (type, mode_align);
>   TYPE_USER_ALIGN (type) = 0; 
> }
> 
> so __attribute__ ((packed)) is basically ignored on Sparc.

I don't think that's correct.  Simply, on strict-alignment targets, you cannot
have an aggregate type less aligned than its scalar mode, if any; for other
targets, that's only true for scalar types.  But you can have an aggregate type
with alignment 1 if it has BLKmode.

> diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> index 3028d55773a..6dd605810ac 100644
> --- a/gcc/stor-layout.c
> +++ b/gcc/stor-layout.c
> @@ -1784,7 +1784,7 @@ finalize_type_size (tree type)
>  
>/* Don't override a larger alignment requirement coming from a user
> alignment of one of the fields.  */
> -  if (mode_align >= TYPE_ALIGN (type))
> +  if (mode_align > TYPE_ALIGN (type))
>{
>  SET_TYPE_ALIGN (type, mode_align);
>  TYPE_USER_ALIGN (type) = 0;
> 
> works with cross compiler.

The existing code works as intended: if the alignment given by the mode is
larger than or equal to the type's alignment, then this alignment given by the
mode becomes the natural alignment and TYPE_USER_ALIGN becomes obsolete/wrong.

So I think that the absence of warning is correct on strict-alignment platforms
and that, if you want to make the tests portable, then you must use structures
whose rounded size is not a power of 2 or is larger than 128 bits, so that they
don't get a scalar mode.

[Bug target/81863] [7 regression] -mword-relocations is unreliable

[arnd at linaro dot org]

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

--- Comment #7 from Arnd Bergmann  ---
Created attachment 42009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42009=edit
preprocessed net/rds/recv.i

(In reply to ard.biesheuvel from comment #6)
> FWIW, the following makes the issue go away (tested on 4.9.4)
> 
> @@ -6196,7 +6210,9 @@
>[(set (match_operand:SI 0 "nonimmediate_operand" "=r")
>   (lo_sum:SI (match_operand:SI 1 "nonimmediate_operand" "0")
>  (match_operand:SI 2 "general_operand"  "i")))]
> -  "arm_arch_thumb2 && arm_valid_symbolic_address_p (operands[2])"
> +  "arm_arch_thumb2 && arm_valid_symbolic_address_p (operands[2])
> +   && (   GET_CODE (operands[2]) != SYMBOL_REF
> +   || !target_word_relocations)"
>"movt%?\t%0, #:upper16:%c2"
>[(set_attr "predicable" "yes")
> (set_attr "predicable_short_it" "no")
> 
> I have no idea whether this is a suitable fix: I will leave that to the
> experts. Just providing this as a data point.

I tried this change and it apparently addressed one such problem on gcc-7.1.1
(in multiple kernel configurations):

/home/arnd/cross-gcc/bin/arm-linux-gnueabi-ld: drivers/mfd/janz-cmodio.o:
relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when
making a shared object; recompile with -fPIC

but not another one:

/home/arnd/cross-gcc/bin/arm-linux-gnueabi-ld: net/rds/recv.o: relocation
R_ARM_MOVW_ABS_NC against `rds_stats' can not be used when making a shared
object; recompile with -fPIC

The first only showed up in configurations using -mthumb, while the second only
appeared only once so far, in a configuration using -marm. Attaching the
preprocessed source file, build with "arm-linux-gnueabi-gcc-7.1.1
-mword-relocations -march=armv7-a  -O1 -c recv.i"

[Bug c++/53360] g++ prints 'invalid use of incomplete type' error when compiling code with -std=gnu++0x and newer

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-19
 CC||egallager at gcc dot gnu.org
Summary|Problems with -std=gnu++0x  |g++ prints 'invalid use of
   ||incomplete type' error when
   ||compiling code with
   ||-std=gnu++0x and newer
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Alex from comment #0)
> I have such code:
> 
> 
> template
> struct make_literal;
> 
> template<>
> struct make_literal {
>   typedef int type;
> };
> 
> template
> struct make_expression {
>   typedef typename make_literal::type type;
> };
> 
> struct column {
>   template
>   typename make_expression::type operator= (const T& t) const {
> return typename make_expression::type(t);
>   }
> };
> 
> struct expression : column
> {
> expression() { }
> using column::operator =;
> };
> 
> int main()
> {
> expression ex;
> ex = 2;
> 
> return 0;
> }
> 
> which failed to compile with such command line:
> c++ -std=gnu++0x file.cpp
> 
> Compiler produces such error:
> bug.cpp: In instantiation of ‘make_expression’:
> bug.cpp:31:10:   instantiated from here
> bug.cpp:12:42: error: invalid use of incomplete type ‘struct
> make_literal’
> bug.cpp:3:8: error: declaration of ‘struct make_literal’

(In reply to Marc Glisse from comment #1)
> clang and gcc reject it, but intel and oracle accept it.

The errors with gcc and clang are now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=gnu++0x 53360.cc
53360.cc: In instantiation of ‘struct make_expression’:
53360.cc:16:36:   required by substitution of ‘template typename
make_expression::type column::operator=(const T&) const [with T = column]’
53360.cc:30:10:   required from here
53360.cc:11:41: error: invalid use of incomplete type ‘struct
make_literal’
  typedef typename make_literal::type type;
 ^~~~
53360.cc:2:8: note: declaration of ‘struct make_literal’
 struct make_literal;
^~~~
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic -std=gnu++0x 53360.cc
53360.cc:11:19: error: implicit instantiation of undefined template
'make_literal'
typedef typename make_literal::type type;
 ^
53360.cc:16:11: note: in instantiation of template class
'make_expression' requested here
typename make_expression::type operator= (const T& t) const {
 ^
53360.cc:16:36: note: while substituting deduced template arguments into
function template 'operator=' [with T = column]
typename make_expression::type operator= (const T& t) const {
  ^
53360.cc:2:8: note: template is declared here
struct make_literal;
   ^
1 error generated.
$

Note that it also fails with gnu++14 and gnu++1z. When compiled with
-std=gnu++98 and -Wc++11-compat, it prints no errors or warnings, which is odd,
because if it were actually supposed to error out with gnu++11, you'd think
-Wc++11-compat would at least warn about it. So, confirmed.

[Bug c++/52202] [C++11][DR 1376] Should not extend lifetime of temporary wrapped in static_cast to reference type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed that the testcase aborts when run

[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
After thinking about this, I think I have a better idea which gets rid of the
stash completely and will avoid allocating a unit structure for internal units.
To accomplish this, I intend to pass the string, string length and string array
descriptor directly to the dtio child procedures vis hidden arguments. Just
want to capture the idea here for others heads up.

[Bug sanitizer/81902] New: new -fsanitize=pointer-overflow option undocumented

[msebor at gcc dot gnu.org]

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

Bug ID: 81902
   Summary: new -fsanitize=pointer-overflow option undocumented
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
Blocks: 80998
  Target Milestone: ---
  Keywords: documentation
Blocks: 80998

While working on an overview of features new in GCC 8 I came across r250656
which added two new sanitizer options: -fsanitize=pointer-overflow and
-fsanitize-recover=pointer-overflow.  Unfortunately the options are  not
documented.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80998
[Bug 80998] Implement -fsanitize=pointer-overflow

[Bug c++/81042] Too many constexpr interations on unreachable loop.

[maxmati4 at gmail dot com]

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

Mateusz Nowotynski  changed:

   What|Removed |Added

 CC||maxmati4 at gmail dot com

--- Comment #2 from Mateusz Nowotynski  ---
I also experienced this bug on gcc (Gentoo 6.4.0 p1.0) 6.4.0 and gcc (GCC)
8.0.0 20170819 (experimental). On version 6.4 it results in never ending
compilation and on 8.0 it trigers same error as @KevinCox.

Whats more for me it looks like regrsion since my code compiles fine on gcc
(Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005 haven't tried @KevinCox version.

My program triggering this error:
struct Table
{
constexpr Table() : primes()
{
for(int i = 1; i < 100; ++i){ 
if(!primes[i]) continue;
for(int j = 1; j < 100; ++j);
}

}
bool primes[100];
};


int main(){
constexpr auto primes = Table();
}

[Bug tree-optimization/81900] GCC trunk miscompiles Perl / __sigsetjmp issue

[mikpelinux at gmail dot com]

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

--- Comment #2 from Mikael Pettersson  ---
Started with r250767.

[Bug c++/53215] Warn if orphaned memory is created by ignoring return value of new

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-19
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Gallager  ---
Confirming (as an enhancement) that g++ prints no warnings for the example
code. Dunno if it really could/should though...

[Bug c++/52953] function parameter name redeclarations not detected

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to meng from comment #0)
> source code demonstrating the problem.
> --- BEGIN 
> void f (int i) try
> {
>  void i (); // 1
> }
> catch (...)
> {
>  void i (); // 2
> }
> 
> int main ()
> {
>  return 0;
> }
> ---  END  
> 
> compiled with :
> $HOME/gcc/4.7.0/bin/c++ -std=c++0x -Wall -O3 tt.cc
> 
> compiler output : 
> nothing
> 
> g++-4.7.0 accepts the code as it is, issuing no warnings and no errors. I
> think this is wrong. According to c++11 3.3.3/2 
> "A parameter name shall not be redeclared in the outermost block of the
> function definition nor in the outermost block of any handler associated
> with a function-try-block."
> 
> In the above example, i is the name of the parameter of function f. The name
> i, therefore, cannot be redeclared in the outermost block of the function
> definition (case 1) nor can it be redeclared in the outermost block of any
> associated handler (case 2). But my g++ accepts both cases while they should
> be rejected.

I can get some other warnings from this but not what you want:

$ /usr/local/bin/g++ -c -std=c++0x -Wall -O3 -Wextra -Wshadow -pedantic
-Wmissing-declarations -Wredundant-decls 52953.c
52953.c:1:6: warning: no previous declaration for ‘void f(int)’
[-Wmissing-declarations]
 void f (int i) try
  ^
52953.c: In function ‘void f(int)’:
52953.c:1:13: warning: unused parameter ‘i’ [-Wunused-parameter]
 void f (int i) try
 ^
$

(In reply to meng from comment #1)
> another example showing violation of c++11 3.3.3/4
>  BEGIN ---
> int main ()
> {
>  if (int a = 1)
>  {
>   void a (); // 1
>  }
>  else
>  {
>   void a (); // 2
>  }
> 
>  while (int a = 0)
>  {
>   void a (); // 3
>  }
> 
>  for (int a = 0;;)
>  {
>   void a (); // 4
>   break;
>  }
>  for (; int a = 0;)
>  {
>   void a (); // 5
>  }
> 
>  return 0;
> }
>   END  ---
> 
> According to my understanding, all numbered cases are illegal based on c++11
> 3.3.3/4.g++-4.7.0 correctly caught case 3 and 5 as compiler errors, the rest
> are accepted.

Yup, 3 and 5 are still the only ones that error:

$ /usr/local/bin/g++ -c -std=c++0x -Wall -O3 -Wextra -Wshadow -pedantic
-Wmissing-declarations -Wredundant-decls 52953_2.c
52953_2.c: In function ‘int main()’:
52953_2.c:3:10: warning: unused variable ‘a’ [-Wunused-variable]
  if (int a = 1)
  ^
52953_2.c:14:11: error: ‘void a()’ redeclared as different kind of symbol
   void a (); // 3
   ^
52953_2.c:12:13: note: previous declaration ‘int a’
  while (int a = 0)
 ^
52953_2.c:12:13: warning: unused variable ‘a’ [-Wunused-variable]
52953_2.c:17:11: warning: unused variable ‘a’ [-Wunused-variable]
  for (int a = 0;;)
   ^
52953_2.c:24:11: error: ‘void a()’ redeclared as different kind of symbol
   void a (); // 5
   ^
52953_2.c:22:13: note: previous declaration ‘int a’
  for (; int a = 0;)
 ^
52953_2.c:22:13: warning: unused variable ‘a’ [-Wunused-variable]
$

So, confirmed.

[Bug c++/81895] gcc rejects out-of-line definition of enum member of class template under -pedantic-errors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-19
 Ever confirmed|0   |1

[Bug c++/52801] improve selective typedef unwrapping

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Manuel López-Ibáñez from comment #2)
> (In reply to Eric Gallager from comment #1)
> > Confirmed that the notes could ease up on the template spew; g++ output is
> > now:
> 
> Note that I'm not complaining about the redundant notes listing the
> declaration of the candidates (which are the subject of a different PR that
> I cannot find right now). 
> 
> The object of improvement here is:
> 
> no known conversion from 'vector' to 'const std::basic_string'
> 
> versus
>  
> no known conversion for argument 1 from ‘std::vector’ to ‘const
> std::__cxx11::basic_string&’
> 
> On the latter, gcc is excessively unwrapping typedef.

There's no typedef involved in those string types (well there is, as it should
show std::string, but not in either form you showed), and the presence of the &
is important.

[Bug preprocessor/81794] "would be stringified in traditional C" warning should be controlled by -Wtraditional

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to David Malcolm from comment #2)
> Please can you turn it into a patch that contains both the fix *and* the new
> testcase?  (e.g. gcc.dg/pragma-diag-8.c)

I will once I get some issues with my email sorted out...

[Bug tree-optimization/81900] GCC trunk miscompiles Perl / __sigsetjmp issue

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
Created attachment 42008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42008=edit
executable testcase

Standalone executable testcase, exits 0 when compiled correctly, aborts or
exits 1 otherwise.  Fails for me with gcc-8 on x86_64-linux but works on same
with gcc-7, gcc-6, and gcc-5.

[Bug c/53037] warn_if_not_aligned(X)

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #31 from Rainer Orth  ---
(In reply to H.J. Lu from comment #29)
> This patch
> 
> diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> index 3028d55773a..6dd605810ac 100644
> --- a/gcc/stor-layout.c
> +++ b/gcc/stor-layout.c
> @@ -1784,7 +1784,7 @@ finalize_type_size (tree type)
>  
>/* Don't override a larger alignment requirement coming from a user
> alignment of one of the fields.  */
> -  if (mode_align >= TYPE_ALIGN (type))
> +  if (mode_align > TYPE_ALIGN (type))
>{
>  SET_TYPE_ALIGN (type, mode_align);
>  TYPE_USER_ALIGN (type) = 0;
> 
> works with cross compiler.  But I have no idea if it is correct.

I've included it in a sparc bootstrap and the only effect on testresults was
to fix the set of failures I've reported.

Let's ask Eric for his opinion.

  Rainer

[Bug other/81334] -Wmisleading-indentation prints notes about being disabled even when already intentionally ignored

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
It should be a matter of checking for warn_misleading_indentation at
c-family/c-indentation.c:get_visual_column()

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #3 from Manuel López-Ibáñez  ---
It seems pretty straight-forward:

1. Abstract out the check for classification_history.

2. Create a function diagnostic_report_warnings_p that checks the
classification history of Wsystem-headers in addition to the option value.

Not that -Wsystem-headers is not a typical warning option, so more work would
be needed to have

#pragma GCC diagnostic error "-Wsystem-headers"

give errors instead  of warnings

or

-Werror
#pragma GCC diagnostic warning "-Wsystem-headers"

give warnings instead of errors. But that seems less important to fix.

[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
Currently, the macro controlling this only looks at the state of the option:

/* Returns nonzero if warnings should be emitted.  */
#define diagnostic_report_warnings_p(DC, LOC)   \
  (!(DC)->dc_inhibit_warnings   \
   && !(in_system_header_at (LOC) && !(DC)->dc_warn_system_headers))

It needs to look at the classification_history like
diagnostic_report_diagnostic() does.

[Bug middle-end/70879] Missed jump threading opportunity with multiple != conditions

[amacleod at redhat dot com]

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

--- Comment #6 from Andrew Macleod  ---
oops, wasnt meant to actually attach that note to this PR.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||damien at iwi dot me

--- Comment #31 from Manuel López-Ibáñez  ---
*** Bug 79701 has been marked as a duplicate of this bug. ***

[Bug preprocessor/79701] #pragma ignored "-Wcomment" has no effect

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  ---
Dup

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

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||akim.demaille at gmail dot com

--- Comment #30 from Manuel López-Ibáñez  ---
*** Bug 80650 has been marked as a duplicate of this bug. ***

[Bug c++/80650] #pragma do not control -Wcpp

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  ---
Dup

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

[Bug tree-optimization/81900] New: GCC trunk miscompiles Perl / __sigsetjmp issue

[pipcet at gmail dot com]

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

Bug ID: 81900
   Summary: GCC trunk miscompiles Perl / __sigsetjmp issue
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pipcet at gmail dot com
  Target Milestone: ---

Created attachment 42007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42007=edit
creduce-minimized test case

Hi,

I'm having trouble running a GCC/trunk-compiled Perl; I first noticed
the problem on my WebAssembly port, but I think I can reproduce it on
x86_64 built from the standard GCC tree. I also think this is a GCC
bug.

After some editing, I've managed to generate a (somewhat) minimized
testcase:

Perl_croak() __attribute__((noreturn));
*Perl_sv_gets();
a() {
  __sigsetjmp();
  char *b;
  if ((b = Perl_sv_gets()) == 0)
Perl_croak("No Perl script found in input\n");
  if (*b == '#')
__asm__("" : : ""("badbad"));
}

The intended behaviour is that Perl_sv_gets() can return a NULL
pointer, in which case the pointer isn't dereferenced and Perl_croak()
is called instead.  However, the assembly output I get is:

xorl%eax, %eax
call__sigsetjmp
xorl%eax, %eax
callPerl_sv_gets
cmpb$35, (%rax)

The call to Perl_croak has been removed, and the return value of
Perl_sv_gets() is unconditionally dereferenced.  That's wrong, right?

I'm compiling with:

$ ~/git/asmjs/subrepos/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc -B
/home/pip/git/asmjs/subrepos/gcc/host-x86_64-pc-linux-gnu/gcc/ -v -S
-DPERL_CORE -fwrapv -std=c89 -O3 -fno-strict-aliasing -w -Wfatal-errors
testcase.i -o tmp.s || exit 1
Reading specs from
/home/pip/git/asmjs/subrepos/gcc/host-x86_64-pc-linux-gnu/gcc/specs
COLLECT_GCC=/home/pip/git/asmjs/subrepos/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ./configure --target=x86_64-pc-linux-gnu --disable-bootstrap
--enable-languages=c
Thread model: posix
gcc version 8.0.0 20170819 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-B'
'/home/pip/git/asmjs/subrepos/gcc/host-x86_64-pc-linux-gnu/gcc/' '-v' '-S' '-D'
'PERL_CORE' '-fwrapv' '-std=c90' '-O3' '-fno-strict-aliasing' '-w'
'-Wfatal-errors' '-o' 'tmp.s' '-mtune=generic' '-march=x86-64'
 /home/pip/git/asmjs/subrepos/gcc/host-x86_64-pc-linux-gnu/gcc/cc1
-fpreprocessed testcase.i -quiet -dumpbase testcase.i -mtune=generic
-march=x86-64 -auxbase-strip tmp.s -O3 -Wfatal-errors -w -std=c90 -version
-fwrapv -fno-strict-aliasing -o tmp.s
GNU C89 (GCC) version 8.0.0 20170819 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 6.4.0 20170724, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C89 (GCC) version 8.0.0 20170819 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 6.4.0 20170724, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: d531daafd687d9500452e3b103d32887
COMPILER_PATH=/home/pip/git/asmjs/subrepos/gcc/host-x86_64-pc-linux-gnu/gcc/
LIBRARY_PATH=/home/pip/git/asmjs/subrepos/gcc/host-x86_64-pc-linux-gnu/gcc/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B'
'/home/pip/git/asmjs/subrepos/gcc/host-x86_64-pc-linux-gnu/gcc/' '-v' '-S' '-D'
'PERL_CORE' '-fwrapv' '-std=c90' '-O3' '-fno-strict-aliasing' '-w'
'-Wfatal-errors' '-o' 'tmp.s' '-mtune=generic' '-march=x86-64'




The call to sigsetjmp appears to be necessary to trigger the bug.

Sorry if this is a duplicate or a known issue; right now, I don't have
the time to investigate further. The call appears to be eliminated in a tree
optimization pass, so I'm tentatively choosing that component.

[Bug c++/81899] [8 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Started with r251154:

commit 49a669e2fa6641bb1bb93b21d866962d3999dd07
Author: nathan 
Date:   Thu Aug 17 15:56:49 2017 +

* lex.c (maybe_add_lang_type_raw): BOUND_TEMPLATE_TEMPLATE_PARMs
don't need lang_type.
(cxx_make_type): Use maybe_add_lang_type_raw return value.
* mangle.c (CLASSTYPE_TEMPLATE_ID_P): Don't rely on
TYPE_LANG_SPECIFIC.

[Bug c++/52801] improve selective typedef unwrapping

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Eric Gallager from comment #1)
> Confirmed that the notes could ease up on the template spew; g++ output is
> now:

Note that I'm not complaining about the redundant notes listing the declaration
of the candidates (which are the subject of a different PR that I cannot find
right now). 

The object of improvement here is:

no known conversion from 'vector' to 'const std::basic_string'

versus

no known conversion for argument 1 from ‘std::vector’ to ‘const
std::__cxx11::basic_string&’

On the latter, gcc is excessively unwrapping typedef.

[Bug c++/81899] [8 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-19
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug c++/81899] New: [8 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Bug ID: 81899
   Summary: [8 Regression] ICE: Segmentation fault
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

% cat auto_switch_lexerstate.ii
template  struct bool_;
template > struct token;
template  class FunctorData,
  typename>
struct functor {
  friend FunctorData;
  void foo();
};
template  struct data;
template<> void functor, data, bool_<0>>::foo();

 % g++ -c auto_switch_lexerstate.ii
auto_switch_lexerstate.ii: In instantiation of ‘struct functor, data,
bool_<0> >’:
auto_switch_lexerstate.ii:11:49:   required from here
auto_switch_lexerstate.ii:6:16: internal compiler error: Segmentation fault
 struct functor {
^
0x10ba3023 crash_signal
../../gcc/gcc/toplev.c:341
0x1044d53c instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10727
0x1044d53c instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:10892
0x104c1ceb complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:136
0x103a69e7 cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6269
0x103a7833 cp_parser_nested_name_specifier
../../gcc/gcc/cp/parser.c:6332
0x103a794b cp_parser_ptr_operator
../../gcc/gcc/cp/parser.c:20451
0x103aac0b cp_parser_declarator
../../gcc/gcc/cp/parser.c:19771
0x103bf7ab cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19335
0x103c0b53 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:27053
0x103c1d73 cp_parser_explicit_specialization
../../gcc/gcc/cp/parser.c:16619
0x103ce603 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12720
0x103cc6ef cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12650
0x103ccaeb cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4387
0x103ccaeb c_parse_file()
../../gcc/gcc/cp/parser.c:38894
0x10563ee7 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1106

[Bug c++/81787] [5/6/7/8 Regression] `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
struct T { int c; char d[]; };  

#pragma GCC diagnostic push 
#pragma GCC diagnostic ignored "-fpermissive"   
struct T t1 = { 1, "a" };   

#pragma GCC diagnostic pop  
struct T t = { 1, "a" };


This is not a bug and it was never meant to work. If it did, it was by chance
rather than by design.

warning: '-fpermissive' is not an option that controls warnings [-Wpragmas]

Similarly, one cannot use -Werror=permissive nor -Wno-error=permissive.

-fpermissive is an odd C++-only option and the warnings it generates cannot be
disabled.

My personal opinion is that we should instead have -Wpermissive, which defaults
to -Werror=permissive and works like any other -W* option should (and would
work with #pragma). -fpermissive can then become an alias for -Wpermissive,
like I did with -pedantic -> -Wpedantic.

Thus, either this is not a bug because -fpermissive is not an -W* option, or
-fpermissive should be reimplemented as -Wpermissive (with a default of
-Werror=permissive).

[Bug c/80529] Split "C++ style comments are not allowed in ISO C90" pedwarn into its own warning flag

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #3)
> Because I'm not childish and realise that clang-tidy is a better tool than a
> compiler when you want to enforce style guides.

In fact, the effort and time spent on adding more and more warnings about style
would be better spent on creating a gcc-tidy tool. Even adding a flag for an
existing warning has a cost.

Having a gcc-tidy tool would benefit gcc by encouraging abstraction and
modularization, and benefit users by making easier to add any particular style
warnings.

[Bug target/81894] Typo in x86 built-in function list

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Aug 19 08:25:14 2017
New Revision: 251200

URL: https://gcc.gnu.org/viewcvs?rev=251200=gcc=rev
Log:
PR target/81894
* doc/extend.texi (x86 Built-in Functions): Correct the name of
__builtin_ia32_lzcnt_u16.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/doc/extend.texi

[Bug target/81894] Typo in x86 built-in function list

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |5.5

--- Comment #6 from Uroš Bizjak  ---
Fixed.

[Bug target/81894] Typo in x86 built-in function list

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Aug 19 08:23:56 2017
New Revision: 251199

URL: https://gcc.gnu.org/viewcvs?rev=251199=gcc=rev
Log:
PR target/81894
* doc/extend.texi (x86 Built-in Functions): Correct the name of
__builtin_ia32_lzcnt_u16.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/doc/extend.texi

[Bug target/81894] Typo in x86 built-in function list

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Aug 19 08:22:54 2017
New Revision: 251198

URL: https://gcc.gnu.org/viewcvs?rev=251198=gcc=rev
Log:
PR target/81894
* doc/extend.texi (x86 Built-in Functions): Correct the name of
__builtin_ia32_lzcnt_u16.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/doc/extend.texi

[Bug target/81894] Typo in x86 built-in function list

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat Aug 19 08:20:20 2017
New Revision: 251197

URL: https://gcc.gnu.org/viewcvs?rev=251197=gcc=rev
Log:
PR target/81894
* doc/extend.texi (x86 Built-in Functions): Correct the name of
__builtin_ia32_lzcnt_u16.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug libgomp/81886] Means to determine at runtime foffload targets specified at compile time

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
AFAICT, this is the last version of the patch that was submitted:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01771.html