Re: GSoC (Improvements to GCC on Windows)

[Ko Phyo]

Thank for your valuable information. I couldn't made it for GSoC 2018 due
to delay of my proposal application because of my University 1st semester
examination. If you guys allow me to apply this kind of project in future
(Not as GSoC applicant), I would be happily take part in it. Thanks in
advanced.

On Apr 1, 2018 9:39 PM, "JonY" <10wa...@gmail.com> wrote:

> On 03/14/2018 05:13 PM, Martin Jambor wrote:
> > Hello,
> >
> > On Tue, Mar 13 2018, Ko Phyo wrote:
> >> Hello
> >>
> >> I want to apply the project "Improvements to GCC on Windows" of
> GCC
> >> foundation. As a student, I have some theorectical knowledges about
> C/C++
> >> and compiler technologies. And I am sure that the Windows platform has
> >> steps that are little behind than other open source platforms in pure
> C/C++
> >> technology. So I decided to work on GSoC 2018 with your "Windows
> >> Improvement program". Please let me know if I am selected as a mentored
> >> student in yours great project. I will be waiting for your kind reply.
> >
> > Well, please note that you still need to apply formally through the GSoC
> > website to stand a chance to be selected, that does not happen here.
> > We want students to contact us prior to applying so that their proposals
> > and goals make sense.
> >
> > As far as improving GCC on Windows is concerned, we may find it
> > challenging to find you a mentor (I am CCing Jonathan Yong, the cygwin
> > and mingw-w64 maintainer, maybe he has an idea what could be done in
> > this area as a GSoC project and who might mentor it?).
> >
> > Meanwhile, make sure you can build GCC from sources on Windows (I admit
> > I would not know how to do it myself!) and run the testsuite.
> >
> > Good luck,
> >
> > Martin
> > .
> >
>
> Hi, I have been away for work this past month.
>
> There is a demand for a proper C++11 threading implementation for
> Windows using native Windows APIs (post Vista APIs), I have not looked
> too much into it, nor do I know if the scope is too big or too small for
> a summer project. Liu Hao has worked on it, and should be familiar with
> the scope, I have CC'ed him.
>
> Never having run any gsoc programs, are there any specific procedures to
> get it started?
>
>

[PATCH, rs6000] Undefine vector, bool, pixel in xmmintrin.h

[Bill Schmidt]

Hi,

The xmmintrin.h and related header files make use of altivec.h to enable
vector intrinsics to be used for compatibility.  However, for C++ or C11
using strict ANSI compliance, this causes a collision with the "bool"
keyword.  We intend to later change altivec.h to not define these keywords
under those conditions, but this could cause a certain amount of community
churn, so we want to try a distro build with this before making such a
change in GCC 9.  Since these compatibility headers are new in GCC 8, we 
can safely undefine these following the include of altivec.h without
disturbing existing code.

Note that for strict-ANSI C11 code, stdbool.h must be included after
including xmmintrin.h in order to enable the bool keyword.  When we later
fix altivec.h to not define them in the first place, this ordering
requirement will no longer exist.

While testing, I discovered a couple stray instances of "vector" that
should have been "__vector" in these headers.  Fixes for those are
included in this patch.

I also updated the gcc.target/powerpc/powerpc.exp file to allow C++
tests to be placed in that directory (with a *.C suffix).

Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk?

Thanks,
Bill


[gcc]

2018-04-02  Bill Schmidt  

* config/rs6000/emmintrin.h (_mm_cvtpd_epi32): Use __vector rather
than vector.
(_mm_cvtpd_ps): Likewise.
(_mm_cvttpd_epi32): Likewise.
* config/rs6000/mmintrin.h (_mm_unpacklo_pi8): Likewise.
* config/rs6000/xmmintrin.h: For strict-ANSI C++ or C11, undefine
vector, pixel, and bool following altivec.h include.

[gcc/testsuite]

2018-04-02  Bill Schmidt  

* gcc.target/powerpc/powerpc.exp: Add .C suffix for main loop.
* gcc.target/powerpc/undef-bool.C: New file.
* gcc.target/powerpc/undef-bool.c: New file.


Index: gcc/config/rs6000/emmintrin.h
===
--- gcc/config/rs6000/emmintrin.h   (revision 258958)
+++ gcc/config/rs6000/emmintrin.h   (working copy)
@@ -885,7 +885,7 @@ _mm_cvtpd_epi32 (__m128d __A)
 
 #ifdef _ARCH_PWR8
   temp = vec_mergeo (temp, temp);
-  result = (__v4si)vec_vpkudum ((vector long)temp, (vector long)vzero);
+  result = (__v4si)vec_vpkudum ((__vector long)temp, (__vector long)vzero);
 #else
   {
 const __v16qu pkperm = {0x00, 0x01, 0x02, 0x03, 0x08, 0x09, 0x0a, 0x0b,
@@ -919,7 +919,7 @@ _mm_cvtpd_ps (__m128d __A)
 
 #ifdef _ARCH_PWR8
   temp = vec_mergeo (temp, temp);
-  result = (__v4sf)vec_vpkudum ((vector long)temp, (vector long)vzero);
+  result = (__v4sf)vec_vpkudum ((__vector long)temp, (__vector long)vzero);
 #else
   {
 const __v16qu pkperm = {0x00, 0x01, 0x02, 0x03, 0x08, 0x09, 0x0a, 0x0b,
@@ -947,7 +947,7 @@ _mm_cvttpd_epi32 (__m128d __A)
 
 #ifdef _ARCH_PWR8
   temp = vec_mergeo (temp, temp);
-  result = (__v4si)vec_vpkudum ((vector long)temp, (vector long)vzero);
+  result = (__v4si)vec_vpkudum ((__vector long)temp, (__vector long)vzero);
 #else
   {
 const __v16qu pkperm = {0x00, 0x01, 0x02, 0x03, 0x08, 0x09, 0x0a, 0x0b,
Index: gcc/config/rs6000/mmintrin.h
===
--- gcc/config/rs6000/mmintrin.h(revision 258958)
+++ gcc/config/rs6000/mmintrin.h(working copy)
@@ -317,7 +317,7 @@ _mm_unpacklo_pi8 (__m64 __m1, __m64 __m2)
   a = (__vector unsigned char)vec_splats (__m1);
   b = (__vector unsigned char)vec_splats (__m2);
   c = vec_mergel (a, b);
-  return (__builtin_unpack_vector_int128 ((vector __int128_t)c, 1));
+  return (__builtin_unpack_vector_int128 ((__vector __int128_t)c, 1));
 #else
   __m64_union m1, m2, res;
 
Index: gcc/config/rs6000/xmmintrin.h
===
--- gcc/config/rs6000/xmmintrin.h   (revision 258958)
+++ gcc/config/rs6000/xmmintrin.h   (working copy)
@@ -58,6 +58,18 @@
 #define _XMMINTRIN_H_INCLUDED
 
 #include 
+
+/* Avoid collisions between altivec.h and strict adherence to C++ and
+   C11 standards.  This should eventually be done inside altivec.h itself,
+   but only after testing a full distro build.  */
+#if defined(__STRICT_ANSI__) && (defined(__cplusplus) || \
+(defined(__STDC_VERSION__) &&  \
+ __STDC_VERSION__ >= 201112L))
+#undef vector
+#undef pixel
+#undef bool
+#endif
+
 #include 
 
 /* We need type definitions from the MMX header file.  */
Index: gcc/testsuite/gcc.target/powerpc/powerpc.exp
===
--- gcc/testsuite/gcc.target/powerpc/powerpc.exp(revision 258958)
+++ gcc/testsuite/gcc.target/powerpc/powerpc.exp(working copy)
@@ -35,7 +35,7 @@ if ![info exists DEFAULT_CFLAGS] then {
 dg-init
 
 # Main loop.
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\]]] \
+dg-runtest [lsort 

Re: [PATCH, committed] Update my MAINTAINERS entries

[Bill Schmidt]

> On Mar 31, 2018, at 7:49 AM, Gerald Pfeifer  wrote:
> 
> On Fri, 30 Mar 2018, Bill Schmidt wrote:
>> Just updating my email address and making it a little clearer which 
>> is which between Will Schmidt and me.  Committed.
> 
> Actually you can (should) remove your entry from Write after Approval
> since you are now listed in one of the previous sections already.

Ah, thanks, Gerald, I'll do that tomorrow.

Bill
> 
> Gerald
> 

[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects

[f.heckenb...@fh-soft.de]

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

--- Comment #9 from Frank Heckenbach  ---
Found another possible workaround: "Lie" to the compiler (though is it lying
when you're actually telling it the truth? ;) by specializing
std::is_trivially_copy_constructible like this (of course, one needs to repeat
it for all affected types, e.g. other containers and other non-copyable value
types):

namespace std
{
  template  struct
is_trivially_copy_constructible>: false_type {
};
}

I guess it's totally illegal to put such a specialization into std, but
realistically, can anything bad happen, seeing that it just injects a correct
answer where the default is buggy?

[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects

[f.heckenb...@fh-soft.de]

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

--- Comment #8 from Frank Heckenbach  ---
(In reply to Ville Voutilainen from comment #7)
> That's not a bug. You need to make the copy constructor of s conditionally
> deleted depending on whether T is copyconstructible.

The copy constructor of std::vector doesn't seem to do that either
(bits/stl_vector.h:326 in 7.3.0) unless I'm missing something.

Is that what Daniel Krügler meant by "not SFINAE-friendly"? But he also wrote:
"This is a QoI issue but not a violation of the requirements of the standard.",
so I'm confused now.

[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects

[ville.voutilainen at gmail dot com]

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

--- Comment #7 from Ville Voutilainen  ---
That's not a bug. You need to make the copy constructor of s conditionally
deleted depending on whether T is copyconstructible. Otherwise the trait will
result in true but the code will not compile due to an ill-formed definition of
the copy constructor of s, and you'll get the same answer on every C++
compiler.

[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects

[f.heckenb...@fh-soft.de]

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

--- Comment #6 from Frank Heckenbach  ---
Tried to use a self-written (simple) container as a stop-gap, but it also fell
prey to this bug. Daniel Krügler wrote: "std::vector's copy constructor is not
SFINAE-friendly and causes std::is_copy_constructible to evaluate to true
regradless of it's element type." The same seems to be true for my container.
Here's a very reduced example that shows the bug:

#include 

struct MoveOnly
{
  MoveOnly (MoveOnly &&) = default;
};

template  struct s
{
  T v;
  s (const s ): v (a.v) { }
};

using T = s ;

int main ()
{
  static_assert (!std::is_copy_constructible ::value, "bug");
  T *a, b (*a);  // correct error here shows T is not copy-constructible
}

So I guess "not SFINAE-friendly" means that the copy constructor is declared
unconditionally, even if it can't be instantiated due to T not being copyable,
right? Does this mean I need to endow my copy constructor with enable_if (with
all the ugliness that brings), or are there better workarounds (until the
bugfix makes it into a release)?

[wwwdocs] gcc-7/changes.html editorial changes

[Gerald Pfeifer]

Spell GCC (not gcc) and front end (instead of frontend).

Applied.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.99
diff -u -r1.99 changes.html
--- changes.html1 Feb 2018 08:08:08 -   1.99
+++ changes.html1 Apr 2018 22:54:13 -
@@ -184,8 +184,8 @@
 
 Support for processing BRIG 1.0 files was added in this release.
 BRIG is a binary format for HSAIL (Heterogeneous System Architecture
-Intermediate Language). The BRIG frontend can be used for implementing
-HSAIL "finalizers" (compilation of HSAIL to a native ISA) for gcc-supported
+Intermediate Language). The BRIG front end can be used for implementing
+HSAIL "finalizers" (compilation of HSAIL to a native ISA) for GCC-supported
 targets. An implementation of an HSAIL runtime library, libhsail-rt is
 also included.
 
@@ -237,7 +237,7 @@
is enabled by -Wall.
   
 
-  GCC 6's C and C++ frontends were able to offer suggestions for
+  GCC 6's C and C++ front ends were able to offer suggestions for
   misspelled field names:
   
 spellcheck-fields.cc:52:13: error: 
'struct s' has no member named 'colour'; did you mean 
'color'?
@@ -274,7 +274,7 @@
 ^~
 signed
 
-  and, in the C frontend, named initializers:
+  and, in the C front end, named initializers:
 
 test.c:7:20: error: 'struct s' has 
no member named 'colour'; did you mean 'color'?
  struct s test = { .colour = 3 };

Re: "file name" vs "filename"

[Sandra Loosemore]

On 04/01/2018 02:56 PM, Joel Sherrill wrote:



On Sun, Apr 1, 2018, 3:16 PM Gerald Pfeifer > wrote:


And now to the most important question of all. ;-)  Should we use
"file name" or "filename" when referring to the name of a file?

Our docs currently are about even and I think it would be good to
settle on one?

   % grep "filename" $GCC/gcc/doc/*.texi | wc -l
   92
   % grep "file name" $GCC/gcc/doc/*.texi | wc -l
   103

(Once we have consensus, I'll add that to codingconventions.html
and start by making the web pages consistent.)


Searching and looking at online dictionaries, it  looks like filename is 
the currently preferred form.


The C and C++ standards documents use "file name"; there are other 
places ("bit-field") where the GCC manual has adopted the C standard 
terminology.


In this case it might be more appropriate to adopt the POSIX 
conventions, since I suspect most of the uses in the GCC documentation 
refer to the host environment rather than the target language.  This 
looks like the POSIX glossary:


http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html

Here "filename" is given as the correct spelling, except that that 
glossary distinguishes between "filename" and "pathname" (a "filename" 
is the same as a "pathname component").  So perhaps many of the "file 
name"/"filename" uses in the GCC manual ought to be "pathname" instead?


-Sandra

gcc-8-20180401 is now available

[gccadmin]

Snapshot gcc-8-20180401 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180401/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 258999

You'll find:

 gcc-8-20180401.tar.xzComplete GCC

  SHA256=3a91c5a9cc4708211484b75e3e43a399c3d9d800e5d8773dc2c6a1169a99b835
  SHA1=cbcff51571de862f4d423c35583e90e7e8a82e3f

Diffs from 8-20180325 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: why C++ cannot alias an inline function, C can ?

[Marc Glisse]

(should have been on gcc-help I believe)

On Sun, 1 Apr 2018, Max Filippov wrote:


On Sun, Apr 1, 2018 at 5:33 AM, Jason Vas Dias  wrote:

Aha!  But how to determine the mangled name beforehand ?

Even if I compile the object without the alias, then inspect
the object with objdump, there is no mangled symbol
_ZL3foov defined in the object file .

So I must run some name mangler /  generator as a
pre-processing step to get the correct mangled name
string ?


I guess so. Or you could define foo with C linkage:

extern "C" {
 static inline __attribute__((always_inline))
 void foo(void){}
};

static inline __attribute__((always_inline,alias("foo")))
void bar(void);


Or you can use an asm label to specify some arbitrary name.

--
Marc Glisse

[wwwdocs] gcc-8/changes.html - typos,...

[Gerald Pfeifer]

This fixes a couple of typos, informal language (regs instead of
registers,...),... in our GCC 8 release notes.

Committed.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.49
diff -u -r1.49 changes.html
--- changes.html1 Apr 2018 21:33:42 -   1.49
+++ changes.html1 Apr 2018 22:17:59 -
@@ -134,7 +134,7 @@
 has a "frame" in the group segment offset to which is given as an
 argument, similar to traditional call stack frame handling.
   Reduce the number of type conversions due to
-the untyped HSAIL regs. Instead of always representing the HSAIL's
+the untyped HSAIL registers. Instead of always representing the HSAIL's
 untyped registers as unsigned int, the gccbrig now pre-analyzes
 the BRIG code and builds the register variables as a type used
 the most when storing or reading data to/from each register.
@@ -146,10 +146,10 @@
 which refer only to offset 0.
   Fixed a bug with reg+offset addressing on 32b segments.
 In 'large' mode, the offset is treated as 32bits unless it's
-in global, readonly or kernarg address space.
+in global, read-only or kernarg address space.
   Fixed a crash caused sometimes by calls with more
-than 4 args.
-  Fixed a misexecution issue with kernels that have
+than 4 arguments.
+  Fixed a mis-execution issue with kernels that have
 both unexpanded ID functions and calls to subfunctions.
   Treat HSAIL barrier builtins as setjmp/longjump style
 functions to avoid illegal optimizations.
@@ -492,7 +492,7 @@
   
 Better tuning for znver1 and Intel Core based CPUs.
   
-Vectorization cost metrics has been reworked leading to significant 
improvments
+Vectorization cost metrics has been reworked leading to significant 
improvements
 on some benchmarks.
   GCC now supports the Intel CPU named Cannonlake through
 -march=cannonlake. The switch enables the AVX512VBMI,

[Bug libstdc++/80654] is_trivially_copy_constructible fails with compiler error with vector of uncopyable objects

[f.heckenb...@fh-soft.de]

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

Frank Heckenbach  changed:

   What|Removed |Added

 CC||f.heckenb...@fh-soft.de

--- Comment #5 from Frank Heckenbach  ---
Hit the same bug.

It also seems to affect std::deque, std::list, std::forward_list, std::set,
std::unordered_set, std::map, std::unordered_map,
std::multiset, std::unordered_multiset, std::multimap, std::unordered_multimap,
so apparently all standard library containers.

Mentioning in case the fix affects the implementation of std::vector.

Re: [patch, fortran] Fix PR 85102

[Thomas Koenig]

Hi everybody,


Regression-tested. OK for trunk?


Not OK, since it misses

   integer, parameter :: a((1+1)+1) = 1

as asked by Dominique on IRC.  Good catch!

I'll look at this tomorrow.

Regards

thomas

[Bug tree-optimization/85143] Loop limit prevents (auto)vectorization

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
The test becomes

  _1 = n_15(D) <= i_46;
  _2 = i_46 > 1336;
  _3 = _1 | _2;

However, in match.pd, we only handle the AND case. The corresponding IOR
transformation should be handled similarly.

Re: [PATCH] Show dangerous warning when -Werror option is used

[Pali Rohár]

On Sunday 01 April 2018 17:05:13 David Malcolm wrote:
> On Sun, 2018-04-01 at 22:40 +0200, Pali Rohár wrote:
> > On Sunday 01 April 2018 14:32:26 Segher Boessenkool wrote:
> > > On Sun, Apr 01, 2018 at 12:05:40PM +0200, Pali Rohár wrote:
> > > > Command line option -Werror is dangerous as it could cause
> > > > problems for
> > > > compiling applications in future. Once gcc introduces a new
> > > > warning or
> > > > change logic for existing warnings then compilation of existing
> > > > application via gcc could throw a new warning.
> > > > 
> > > > As -Werror makes all warnings fatal, it makes applications not
> > > > compilable. -Werror makes sense only for specific gcc versions
> > > > against
> > > > which was application tested to compile correctly.
> > > > 
> > > > Attached patch adds a new warning when -Werror command line
> > > > option is
> > > > enabled. It warns user that usage of -Werror can be dangerous.
> > > 
> > > While I love this patch in principle...
> > > 
> > > All patches need to be bootstrapped and regression tested.  Did
> > > you?
> > 
> > Yes! Tested and it successfully failed on libgomp bootstrap part.
> > 
> >   cc1: error: command line option ‘-Werror’ is dangerous; in future
> > newly introduced non-fatal warnings can cause fatal errors [-Werror]
> >   cc1: all warnings being treated as errors
> 
> The patch sets:
>   dc->warning_as_error_requested = value;
> before issuing the warning_at, and hence the warning is itself affected
> and treated as an error, making -Werror unusable, and thus forcing
> people to turn it off.

Exactly.

> I'm working on the assumption, based on today's date [1], that this is
> the intended behavior of the patch?  My apologies if I'm
> misunderstanding.

Yes! :-)

But this change is a good for discussion if -Werror should really be
widely used. You can find it in lot of (open source) software. And this
my patch demonstrates that introduction of new warning (not error) or
changing logic when/how is warning throw can be fatal...

I agree with argument that should not be used in release (e.g. enabled
by default in release tarballs).

> Dave
> 
> > > On what target?
> > 
> > x86_64-linux-gnu
> > 
> > > And I think a feature as big as this one isn't suitable for stage
> > > 4.
> > > 
> > > 
> > > Segher
> > 
> > 
> [1] it's been almost 12 hours

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Re: [wwwdocs] Document change that ipa-pure-const pass propagates malloc attribute.

[Gerald Pfeifer]

On Fri, 27 Oct 2017, Prathamesh Kulkarni wrote:
> Applied the attached patch to changes.html.

Thank you.  I applied the follow-up below to avoid overly long
lines, use -Wsuggest-attribute=malloc (with a leading '-') and
address a grammar issue or two.

Gerald

Index: gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.46
diff -u -r1.46 changes.html
--- gcc-8/changes.html  20 Mar 2018 08:06:16 -  1.46
+++ gcc-8/changes.html  1 Apr 2018 21:26:43 -
@@ -46,9 +46,11 @@
   
 Reworked run-time estimation metrics leading to more realistic guesses
driving inliner and cloning heuristics.
-The ipa-pure-const pass is extended to propagate the 
malloc attribute,
-   and the corresponding warning option 
Wsuggest-attribute=malloc emits a
-   diagnostic for a function, which can be annotated with 
malloc attribute.
+The ipa-pure-const pass is extended to propagate the
+  malloc attribute, and the corresponding warning option
+  -Wsuggest-attribute=malloc emits a diagnostic for
+  functions which can be annotated with the malloc
+  attribute.
   
   Profile driven optimization improvements:
   
@@ -77,6 +79,9 @@
 guide for further information about the option syntax and section "New 
Targets
 and Target Specific Improvements" for IA-32/x86-64 for more details.
   
+  The -gcolumn-info option is now enabled by default.
+It includes column information in addition to just filenames and
+line numbers in DWARF debugging information.
 
 
 

Re: [wwwdocs] Couple of items for gcc-8/changes.html

[Gerald Pfeifer]

On Wed, 21 Mar 2018, Eric Botcazou wrote:
> Plus a wording change for the sake of consistency.  OK to commit?

Yes, thank you, Eric.

Gerald

Re: [PATCH] Show dangerous warning when -Werror option is used

[David Malcolm]

On Sun, 2018-04-01 at 22:40 +0200, Pali Rohár wrote:
> On Sunday 01 April 2018 14:32:26 Segher Boessenkool wrote:
> > On Sun, Apr 01, 2018 at 12:05:40PM +0200, Pali Rohár wrote:
> > > Command line option -Werror is dangerous as it could cause
> > > problems for
> > > compiling applications in future. Once gcc introduces a new
> > > warning or
> > > change logic for existing warnings then compilation of existing
> > > application via gcc could throw a new warning.
> > > 
> > > As -Werror makes all warnings fatal, it makes applications not
> > > compilable. -Werror makes sense only for specific gcc versions
> > > against
> > > which was application tested to compile correctly.
> > > 
> > > Attached patch adds a new warning when -Werror command line
> > > option is
> > > enabled. It warns user that usage of -Werror can be dangerous.
> > 
> > While I love this patch in principle...
> > 
> > All patches need to be bootstrapped and regression tested.  Did
> > you?
> 
> Yes! Tested and it successfully failed on libgomp bootstrap part.
> 
>   cc1: error: command line option ‘-Werror’ is dangerous; in future
> newly introduced non-fatal warnings can cause fatal errors [-Werror]
>   cc1: all warnings being treated as errors

The patch sets:
  dc->warning_as_error_requested = value;
before issuing the warning_at, and hence the warning is itself affected
and treated as an error, making -Werror unusable, and thus forcing
people to turn it off.

I'm working on the assumption, based on today's date [1], that this is
the intended behavior of the patch?  My apologies if I'm
misunderstanding.

Dave

> > On what target?
> 
> x86_64-linux-gnu
> 
> > And I think a feature as big as this one isn't suitable for stage
> > 4.
> > 
> > 
> > Segher
> 
> 
[1] it's been almost 12 hours

Re: [PATCH][WWWDOCS][AArch64][ARM] Update GCC 8 release notes

[Gerald Pfeifer]

On Tue, 16 Jan 2018, Tamar Christina wrote:
> I seem to have forgotten the patch :)

Ah, one thing I noticed is that you've used the spelling of "Arm"
as opposed to "ARM" and even changed some of the former to the
latter.

Is "Arm" now the new official spelling that we should use consistently?

gcc-8/changes.html still has two references to "ARM".

Gerald

Re: "file name" vs "filename"

[Joel Sherrill]

On Sun, Apr 1, 2018, 3:16 PM Gerald Pfeifer  wrote:

> And now to the most important question of all. ;-)  Should we use
> "file name" or "filename" when referring to the name of a file?
>
> Our docs currently are about even and I think it would be good to
> settle on one?
>
>   % grep "filename" $GCC/gcc/doc/*.texi | wc -l
>   92
>   % grep "file name" $GCC/gcc/doc/*.texi | wc -l
>   103
>
> (Once we have consensus, I'll add that to codingconventions.html
> and start by making the web pages consistent.)


Searching and looking at online dictionaries, it  looks like filename is
the currently preferred form.

--joel

>
> Gerald
>

[Bug libgcc/84292] __sync_add_and_fetch returns the old value instead of the new value

[andreast at gcc dot gnu.org]

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

Andreas Tobler  changed:

   What|Removed |Added

   Last reconfirmed|2018-02-08 00:00:00 |2018-4-1

--- Comment #3 from Andreas Tobler  ---
I could reproduce the issue and I can confirm that the attached patch fixes the
issue.
Once the long awaited gcc-8.x gets released I'll commit the fix to all active
branches and I'll take care that we update the FreeBSD ports tree with a fix
for all gcc versions we (FreeBSD) actively support.
Thanks a lot and sorry for the delay. It took a while to get my arm board back
to live and it took also a while to build a native gcc on it.

Re: [PATCH] Show dangerous warning when -Werror option is used

[Gerald Pfeifer]

On Sun, 1 Apr 2018, Pali Rohár wrote:
> Command line option -Werror is dangerous as it could cause problems for
> compiling applications in future. Once gcc introduces a new warning or
> change logic for existing warnings then compilation of existing
> application via gcc could throw a new warning.
> 
> As -Werror makes all warnings fatal, it makes applications not
> compilable. -Werror makes sense only for specific gcc versions against
> which was application tested to compile correctly.

I've been hit by that, when people thought they were clever and
then caused breakage down the line with new versions of GCC.

+  if (value)
+   warning_at (loc, 0, "command line option %qs is dangerous; "
+   "in future newly introduced non-fatal warnings "
+   "can cause fatal errors", "-Werror");

"command-line"

> Attached patch adds a new warning when -Werror command line option is
> enabled. It warns user that usage of -Werror can be dangerous.

I'm not sure this is going to make a material difference, though I
agree that -Werror is one that should be used less (at least when
providing source code to others).

Gerald

Re: [PATCH] Show dangerous warning when -Werror option is used

[Pali Rohár]

On Sunday 01 April 2018 14:32:26 Segher Boessenkool wrote:
> On Sun, Apr 01, 2018 at 12:05:40PM +0200, Pali Rohár wrote:
> > Command line option -Werror is dangerous as it could cause problems for
> > compiling applications in future. Once gcc introduces a new warning or
> > change logic for existing warnings then compilation of existing
> > application via gcc could throw a new warning.
> > 
> > As -Werror makes all warnings fatal, it makes applications not
> > compilable. -Werror makes sense only for specific gcc versions against
> > which was application tested to compile correctly.
> > 
> > Attached patch adds a new warning when -Werror command line option is
> > enabled. It warns user that usage of -Werror can be dangerous.
> 
> While I love this patch in principle...
> 
> All patches need to be bootstrapped and regression tested.  Did you?

Yes! Tested and it successfully failed on libgomp bootstrap part.

  cc1: error: command line option ‘-Werror’ is dangerous; in future newly 
introduced non-fatal warnings can cause fatal errors [-Werror]
  cc1: all warnings being treated as errors

> On what target?

x86_64-linux-gnu

> And I think a feature as big as this one isn't suitable for stage 4.
> 
> 
> Segher

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

[Bug target/85075] powerpc: ICE in iszero testcase

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
__float128 is "g" (long double is "e").

"file name" vs "filename"

[Gerald Pfeifer]

And now to the most important question of all. ;-)  Should we use
"file name" or "filename" when referring to the name of a file?

Our docs currently are about even and I think it would be good to
settle on one?

  % grep "filename" $GCC/gcc/doc/*.texi | wc -l
  92
  % grep "file name" $GCC/gcc/doc/*.texi | wc -l
  103

(Once we have consensus, I'll add that to codingconventions.html
and start by making the web pages consistent.)

Gerald

[Bug c++/84768] [7/8 Regression] ICE with failed class template argument deduction because of invalid template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Something as straightforward as the below avoids the ICE and error recovery is
good. I'll see if I can figure out something better:

Index: pt.c
===
--- pt.c(revision 258972)
+++ pt.c(working copy)
@@ -26003,6 +26003,12 @@ build_deduction_guide (tree ctor, tree outer_args,
  unsigned level = 1;
  tree oldelt = TREE_VEC_ELT (ftparms, i);
  tree olddecl = TREE_VALUE (oldelt);
+ if (olddecl == error_mark_node)
+   {
+ current_template_parms = save_parms;
+ --processing_template_decl;
+ return error_mark_node;
+   }
  tree newdecl = rewrite_template_parm (olddecl, index, level,
tsubst_args, complain);
  tree newdef = tsubst_template_arg (TREE_PURPOSE (oldelt),
@@ -26153,6 +26159,8 @@ do_class_deduction (tree ptype, tree tmpl, tree in
   for (ovl_iterator iter (CLASSTYPE_CONSTRUCTORS (type)); iter; ++iter)
 {
   tree guide = build_deduction_guide (*iter, outer_args, complain);
+  if (guide == error_mark_node)
+   return error_mark_node;
   if ((flags & LOOKUP_ONLYCONVERTING)
  && DECL_NONCONVERTING_P (STRIP_TEMPLATE (guide)))
elided = true;

[Bug fortran/85138] [8 regression] ICE with generic function

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
The following variant gives the same ICE

module fox_m_fsys_format
  interface mylen
 module procedure str_real_sp_len, str_real_sp_fmt_len
  end interface
contains
  pure function str_real_sp_fmt_len(x, fmt) result(n)
real, intent(in) :: x
character(len=*), intent(in) :: fmt
if (.not.checkFmt()) then
endif
  end function str_real_sp_fmt_len
  pure function str_real_sp_len(x) result(n)
real, intent(in) :: x
n = mylen(x, "")
  end function str_real_sp_len
  function str_real_dp_matrix(xa) result(s)
real, intent(in) :: xa
character(len=mylen(xa)) :: s
  end function str_real_dp_matrix
end module fox_m_fsys_format

Re: [PATCH] Show dangerous warning when -Werror option is used

[Segher Boessenkool]

On Sun, Apr 01, 2018 at 12:05:40PM +0200, Pali Rohár wrote:
> Command line option -Werror is dangerous as it could cause problems for
> compiling applications in future. Once gcc introduces a new warning or
> change logic for existing warnings then compilation of existing
> application via gcc could throw a new warning.
> 
> As -Werror makes all warnings fatal, it makes applications not
> compilable. -Werror makes sense only for specific gcc versions against
> which was application tested to compile correctly.
> 
> Attached patch adds a new warning when -Werror command line option is
> enabled. It warns user that usage of -Werror can be dangerous.

While I love this patch in principle...

All patches need to be bootstrapped and regression tested.  Did you?
On what target?

And I think a feature as big as this one isn't suitable for stage 4.


Segher

[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Nathan T. Weeks from comment #0)
> The following module code results in an internal compiler error with
> gfortran 7.3.0:
> 
> ==
> $ cat mod_test.f90 
> module mod_test
>implicit none
>integer, target :: buf(2)
>integer :: buf_i = 1
>integer, pointer :: buf_ptr => buf(buf_i) ! invalid
> end module mod_test
> 
> C461 (R443) The designator shall designate a nonallocatable variable
> that has the TARGET and SAVE attributes and does not have a vector
> subscript. Every subscript, section subscript, substring starting
> point, and substring ending point in designator shall be a constant
> expression.

Oddly, someone added code to check for only a portion of the
constraint in expr.c(gfc_check_assign_symbol).  At line 4046,
we find

  /* F08:C461. Additional checks for pointer initialization.  */

In fact it only checks for TARGET and SAVE.  A little sleuthing
shows the code came into the tree with r163356.

Re: Deprecate some C++ extensions

[Gerald Pfeifer]

On Tue, 20 Mar 2018, Sandra Loosemore wrote:
> In general, I don't think the current GCC manual should document 
> features that are no longer present in current GCC.  I've previously 
> done a bunch of cleanups to other parts of the manual removing such bits 
> for features that were documented as having gone away 10-20 years ago. 
> :-P 
> So I think it is better to remove the documentation at the same time 
> you remove the features, and mention the removal of the obsolete feature 
> in the release notes instead of in the manual proper.

I was going to suggest that for things we believe may be in more
widely spread active use, keeping a brief note in the docs, but
looking at things from a decade ago, those surely do not qualify
for that. :-)

Gerald

Re: [wwwdocs] PATCH for Re: [PATCH] Make -gcolumn-info the default

[Gerald Pfeifer]

On Sun, 1 Apr 2018, Jakub Jelinek wrote:
> LGTM, thanks.

Thanks!  

I committed the following minor variation that splits the longer 
sentence into two.

Gerald

Index: gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.46
diff -u -r1.46 changes.html
--- gcc-8/changes.html  20 Mar 2018 08:06:16 -  1.46
+++ gcc-8/changes.html  1 Apr 2018 17:23:46 -
@@ -77,6 +77,9 @@
 guide for further information about the option syntax and section "New 
Targets
 and Target Specific Improvements" for IA-32/x86-64 for more details.
   
+  The -gcolumn-info option is now enabled by default.
+It includes column information in addition to just filenames and
+line numbers in DWARF debugging information.
 
 
 

[Bug c++/71504] bogus error: accessing value through a glvalue in a constant expression

[will at dash dot org]

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

--- Comment #6 from Will  ---
A simpler example exhibiting this bogus error; an innocent, idiomatic,
pedantic, platonic pair of nested range-for loops iterating a 2D array:

g++ prog.cc -Wall -Wextra -std=c++14 -pedantic-errors

#include 

template 
constexpr auto sum(A const& a)
{
int tot = 0;
for (auto& row : a)
for (auto elem : row)
tot += elem;
return tot;
}

constexpr int const a22[2][2] = {{1,2},{3,4}};

static_assert( sum(a22) == 10, "badsum");

prog.cc:17:18:   in 'constexpr' expansion of 'sum(a22)'
prog.cc:17:24: error: accessing value of 'a22' through a 'const int' glvalue in
a constant expression

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub   
Date: Sun Apr  1 06:05:01 2018  
New Revision: 258994

URL: https://gcc.gnu.org/viewcvs?rev=258994=gcc=rev   
Log:
PR middle-end/85090 
* config/i386/sse.md (V): Add V64QI and V32HI for TARGET_AVX512F.   
(V_128_256): New mode iterator. 
(*avx512dq_vextract64x2_1 splitter): New define_split. 
(*avx512f_vextract32x4_1 splitter): Likewise.  
(xop_pcmov_): Use V_128_256 mode iterator instead  
of V.   
* config/i386/i386.c (ix86_expand_vector_set): Improve V32HImode and
V64QImode expansion for !TARGET_AVX512BW && TARGET_AVX512F. 

* gcc.target/i386/avx512f-pr85090-1.c: New test.
* gcc.target/i386/avx512f-pr85090-2.c: New test.
* gcc.target/i386/avx512f-pr85090-3.c: New test.
* gcc.target/i386/avx512bw-pr85090-2.c: New test.   
* gcc.target/i386/avx512bw-pr85090-3.c: New test.   

Added:  
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr85090-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr85090-3.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85090-1.c 
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85090-2.c 
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85090-3.c 
Modified:   
trunk/gcc/ChangeLog 
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

Re: [PATCH] Show dangerous warning when -Werror option is used

[Marek Polacek]

On Sun, Apr 01, 2018 at 12:05:40PM +0200, Pali Rohár wrote:
> Command line option -Werror is dangerous as it could cause problems for
> compiling applications in future. Once gcc introduces a new warning or
> change logic for existing warnings then compilation of existing
> application via gcc could throw a new warning.
> 
> As -Werror makes all warnings fatal, it makes applications not
> compilable. -Werror makes sense only for specific gcc versions against
> which was application tested to compile correctly.
> 
> Attached patch adds a new warning when -Werror command line option is
> enabled. It warns user that usage of -Werror can be dangerous.

While I don't think that enabling -Werror for release builds is a good idea,
I disagree that we should warn about using it.

Marek

[Bug tree-optimization/85154] New: [8 regression] gcc.dg/vect/vect-95.c fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 85154
   Summary: [8 regression] gcc.dg/vect/vect-95.c fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r258872 triggers this:

spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.dg/vect/vect-95.c
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-fdiagnostics-color=never -msse2 -ftree-vectorize -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -lm -o ./vect-95.exe
PASS: gcc.dg/vect/vect-95.c (test for excess errors)
spawn [open ...]
PASS: gcc.dg/vect/vect-95.c execution test
PASS: gcc.dg/vect/vect-95.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-95.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 0

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=silvermont
--with-cpu=silvermont

[Bug fortran/85138] [8 regression] ICE with generic function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)
> (In reply to Dominique d'Humieres from comment #2)
> > Up to revision r258235 (2018-03-04) compiling the test gave the error
> > 
> >  if (.not.checkFmt(fmt)) then
> >  1
> > Error: Reference to impure function 'checkfmt' at (1) within a PURE 
> > procedure
> > 
> > After revision r258362 (2018-03-08) I get the ICE. This has been back ported
> > to 7.3.1.
> > 
> > In this range I see only r258281, r258305, and r258347, but r258305 has not
> > been back ported.
> 
> Bizarrely it is r258347 that is the trigger. It has been backported without
> any ill effects.
>

It's probably not bizarre when a user does something like overloading
the name of an intrinsic subprogram and then tries to use it in a
specification statement.  Something that the contributor of r258347
and of very little brain would never do.  The simple fix is to not
be too clever.

   interface length
  module procedure alen, blen  ! renamed to shorter symbols for debugging
   end interface

  function str_real_dp_matrix(xa) result(s)
 real, intent(in) :: xa
 character(len=length(xa)) :: s
  end function str_real_dp_matrix

% gfc -c a.f90
a.f90:12:18:

  if (.not.checkFmt(fmt)) then
  1
Error: Reference to impure function 'checkfmt' at (1) within a PURE procedure

If I had to guess the gfc_reduce_init_expr() in r258347 is
disabling the reporting of errors at some point when
len=len(xa) is being reduced.

[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The code compiles if I replace

   integer :: buf_i = 1

with

   integer, parameter :: buf_i = 1

[Bug driver/85153] _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro

[falemagn at gmail dot com]

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

--- Comment #2 from Fabio Alemagna  ---
And removing the exclamation mark from the if condition actually makes it work
again, but only if the B and E macro are wrapped within the Y() macro,
otherwise it still complains, now indicating the parenthesis as the problem:

#define X6() B if (x) E
int test9(int val) {
switch (val) {
X6() {
case 1: return 10;
}
}

return 0;
}

pragmatest.cpp: In function ‘int test9(int)’:
pragmatest.cpp:96:25: warning: statement will never be executed
[-Wswitch-unreachable]
 #define X6() B if (x) E
 ^
pragmatest.cpp:99:21: note: in expansion of macro ‘X6’
 X6() {
 ^~

[Bug driver/85153] _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro

[falemagn at gmail dot com]

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

Fabio Alemagna  changed:

   What|Removed |Added

  Attachment #43809|0   |1
is obsolete||

--- Comment #1 from Fabio Alemagna  ---
Created attachment 43810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43810=edit
The preprocessed source, which works as expected

The real one. The previous one was from another test.

[Bug driver/85153] New: _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro

[falemagn at gmail dot com]

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

Bug ID: 85153
   Summary: _Pragma to disable -Wswitch-unreachable diagnostic not
properly working when used within preprocessor macro
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: falemagn at gmail dot com
  Target Milestone: ---

Created attachment 43809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43809=edit
The preprocessed source, which works as expected

The preprocessed output (attached) behaves as expected, so I assume this
problem has to do with the driver and/or a strange interaction between driver,
preprocessor and compiler. For lack of better knowledge, I've filed this bug
under the "driver" component.

The whole code is on godbolt: https://godbolt.org/g/rTc3AU

Given the following code, g++ properly emits a warning.

int x;

int test1(int val) {
switch (val) {
if (!x) {
case 1: return 10;
}
}

return 0;
}

pragmatest.cpp: In function ‘int test1(int)’:
pragmatest.cpp:5:25: warning: statement will never be executed
[-Wswitch-unreachable]
 if (!x) {
 ^~
If I then try to silence this warning with the proper _Pragma directive, in
clear, like in the following code, it works as expected as in the compiler
doesn't complain any longer:

int test2(int val) {
switch (val) {
_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wswitch-unreachable\"")
if (!x) {
_Pragma("GCC diagnostic pop")
case 1: return 10;
}
}

return 0;
}

If I then try to to hide the pragmas within 2 macros, like in the following
code, it still works:

#define B _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored
\"-Wswitch-unreachable\"")
#define E _Pragma("GCC diagnostic pop")

int test3(int val) {
switch (val) {
B if (!x) E {
case 1: return 10;
}
}

return 0;
}

However, if now I want to turn the whole "B if (!x) E" statement into a define
of its own, like in the following code, it doesn't work any longer.

#define X() B if (!x) E

int test4(int val) {
switch (val) {
X() {
case 1: return 10;
}
}

return 0;
}

pragmatest.cpp: In function ‘int test4(int)’:
pragmatest.cpp:39:23: warning: statement will never be executed
[-Wswitch-unreachable]
 #define X() B if (!x) E
   ^~
pragmatest.cpp:43:21: note: in expansion of macro ‘X’
 X() {
 ^

This looked quite odd, and at first thought I couldn't figure out what was
going on, but then I thought of using a layer of indirection around the pragma
macros, thinking it might have something to do with secondary expansion, so I
tried the following code, but still no luck.

#define Y(x) x
#define X2() Y(B) if (!x) Y(E)
int test5(int val) {
switch (val) {
X2() {
case 1: return 10;
}
}

return 0;
}

pragmatest.cpp: In function ‘int test5(int)’:
pragmatest.cpp:52:27: warning: statement will never be executed
[-Wswitch-unreachable]
 #define X2() Y(B) if (!x) Y(E)
   ^~
pragmatest.cpp:55:21: note: in expansion of macro ‘X2’
 X2() {
 ^~

So I tried something which in my mind wouldn't make sense at all - notice that
I wrapped the x **variable** in the Y() macro - but what did I have to lose
anyway? But the following code still (unsurprinsigly?) didn't work:

#define X3() Y(B) if (!Y(x)) Y(E)
int test6(int val) {
switch (val) {
X3() {
case 1: return 10;
}
}

return 0;
}

pragmatest.cpp: In function ‘int test6(int)’:
pragmatest.cpp:63:27: warning: statement will never be executed
[-Wswitch-unreachable]
 #define X3() Y(B) if (!Y(x)) Y(E)
   ^
pragmatest.cpp:66:21: note: in expansion of macro ‘X3’
 X3() {
 ^~

However this time around the warning message gave me a hint! Why would the
compiler complain only about the exclamation mark not being reachable? So I
tried the following... and it worked!

#define X4() Y(B) if (Y(!)x) Y(E)
int test7(int val) {
switch (val) {
X4() {
case 1: return 10;
}
}

return 0;
}

That code above makes the compiler stay silent, against all odds.

Re: GSoC (Improvements to GCC on Windows)

[JonY]

On 03/14/2018 05:13 PM, Martin Jambor wrote:
> Hello,
> 
> On Tue, Mar 13 2018, Ko Phyo wrote:
>> Hello
>>
>> I want to apply the project "Improvements to GCC on Windows" of GCC
>> foundation. As a student, I have some theorectical knowledges about C/C++
>> and compiler technologies. And I am sure that the Windows platform has
>> steps that are little behind than other open source platforms in pure C/C++
>> technology. So I decided to work on GSoC 2018 with your "Windows
>> Improvement program". Please let me know if I am selected as a mentored
>> student in yours great project. I will be waiting for your kind reply.
> 
> Well, please note that you still need to apply formally through the GSoC
> website to stand a chance to be selected, that does not happen here.
> We want students to contact us prior to applying so that their proposals
> and goals make sense.
> 
> As far as improving GCC on Windows is concerned, we may find it
> challenging to find you a mentor (I am CCing Jonathan Yong, the cygwin
> and mingw-w64 maintainer, maybe he has an idea what could be done in
> this area as a GSoC project and who might mentor it?).
> 
> Meanwhile, make sure you can build GCC from sources on Windows (I admit
> I would not know how to do it myself!) and run the testsuite.
> 
> Good luck,
> 
> Martin
> .
> 

Hi, I have been away for work this past month.

There is a demand for a proper C++11 threading implementation for
Windows using native Windows APIs (post Vista APIs), I have not looked
too much into it, nor do I know if the scope is too big or too small for
a summer project. Liu Hao has worked on it, and should be familiar with
the scope, I have CC'ed him.

Never having run any gsoc programs, are there any specific procedures to
get it started?



signature.asc
Description: OpenPGP digital signature

[Bug target/85152] VAX ICE with -O2

[coypu at sdf dot org]

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

--- Comment #1 from coypu  ---
*** Bug 85151 has been marked as a duplicate of this bug. ***

[Bug target/85151] VAX ICE with -O2

[coypu at sdf dot org]

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

coypu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from coypu  ---
Made a double bug report by mistake.

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

[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> I get the ICE with 4.8 up to trunk (8.0). Compiling the test with 4.3.6
> gives the error
> 
>integer, pointer :: buf_ptr => buf(buf_i) ! invalid
>  1
> Error: Pointer initialization requires a NULL() at (1)

4.3.6 did not support pointer initialization to anything
other than a null-init as 4.3.6 did not support Fortran
2008.  With Fortran 2008, it is legal to do 

integer, target :: m
integer, pointer :: n => m

I haven't looked too closely at Nathan's code, but it
may be invalid as buf_i is not a constant expression.

That is,

module mod_test
   implicit none
   integer, target :: buf(2)
   integer :: buf_i = 1

The above is not a named constant,

   integer, pointer :: buf_ptr => buf(buf_i) ! invalid

so it may not be valid Fortran to reference it here in
a specification statement.

end module mod_test

[Bug fortran/85102] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4464

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg4.html

Re: why C++ cannot alias an inline function, C can ?

[Max Filippov]

On Sun, Apr 1, 2018 at 5:33 AM, Jason Vas Dias  wrote:
> Aha!  But how to determine the mangled name beforehand ?
>
> Even if I compile the object without the alias, then inspect
> the object with objdump, there is no mangled symbol
> _ZL3foov defined in the object file .
>
> So I must run some name mangler /  generator as a
> pre-processing step to get the correct mangled name
> string ?

I guess so. Or you could define foo with C linkage:

 extern "C" {
  static inline __attribute__((always_inline))
  void foo(void){}
 };

 static inline __attribute__((always_inline,alias("foo")))
 void bar(void);

 static
 void f(void) { foo(); }
 // must have a usage to generate any code

> I think it is unacceptable to be forced to used
> mangled symbol names for objects which are
> not symbols (pure inline functions) .

Pure inline functions may be overloaded, how will you
decide which one to alias given only unmangled name?

-- 
Thanks.
-- Max

[patch, fortran] Fix PR 85102

[Thomas Koenig]

Hello world,

this is a minimal-invasive patch to fix the case where array
specs starting with a parenthesis were not handled correctly.

Regression-tested. OK for trunk?

Regards

Thomas

2018-04-01  Thomas Koenig  

PR fortran/85102
* array.c (strip_parens): New function.
(match_array_element_spec): Use it to strip away parentheses
from array bounds.

2018-04-01  Thomas Koenig  

PR fortran/85102
* gfortran.dg/array_simplify_2.f90: New test.
Index: array.c
===
--- array.c	(revision 258973)
+++ array.c	(working copy)
@@ -408,7 +408,23 @@ gfc_resolve_array_spec (gfc_array_spec *as, int ch
   return true;
 }
 
+/* Strip away any parentheses around an expression.  The argument is
+ assumed to be non-NULL.  */
 
+static void
+strip_parens (gfc_expr *e)
+{
+  gfc_expr *r;
+
+  r = e;
+
+  while (r->expr_type == EXPR_OP && r->value.op.op == INTRINSIC_PARENTHESES)
+r = r->value.op.op1;
+
+  if (r != e)
+gfc_replace_expr (e, gfc_copy_expr (r));
+}
+
 /* Match a single array element specification.  The return values as
well as the upper and lower bounds of the array spec are filled
in according to what we see on the input.  The caller makes sure
@@ -457,6 +473,7 @@ match_array_element_spec (gfc_array_spec *as)
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
 return AS_UNKNOWN;
 
+  strip_parens (*upper);
   if (((*upper)->expr_type == EXPR_CONSTANT
 	&& (*upper)->ts.type != BT_INTEGER) ||
   ((*upper)->expr_type == EXPR_FUNCTION
@@ -489,6 +506,7 @@ match_array_element_spec (gfc_array_spec *as)
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
 return AS_UNKNOWN;
 
+  strip_parens (*upper);
   if (((*upper)->expr_type == EXPR_CONSTANT
 	&& (*upper)->ts.type != BT_INTEGER) ||
   ((*upper)->expr_type == EXPR_FUNCTION
! { dg-do  run }
! PR 85102 - this used to ICE
! Original test case by Gerhard Steinmetz
program p
   integer, parameter :: a((1+2)) = 1
   integer, parameter :: b = dot_product(a, a)
   if (b /= 3) stop 1
end

[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-01
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I get the ICE with 4.8 up to trunk (8.0). Compiling the test with 4.3.6 gives
the error

   integer, pointer :: buf_ptr => buf(buf_i) ! invalid
 1
Error: Pointer initialization requires a NULL() at (1)

[Bug fortran/72709] Incorrect assignment of allocatable character array used as component of derived type

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #6 from Thomas Koenig  ---
Hi Paul,

I've only recently stumbled across this bug.  Just in case you
haven't seen this one yet...

Re: why C++ cannot alias an inline function, C can ?

[Jason Vas Dias]

On 01/04/2018, Max Filippov  wrote:
> On Sun, Apr 1, 2018 at 4:34 AM, Jason Vas Dias 
> wrote:
>> In C++ however, it does not compile :
>>
>>   $ g++ -g -std=gnu++11 -x c++ -c t.c
>> t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
>>void bar(void);
>> ^
>>
>> Even though, if I compile the object with the declaration
>> of bar() commented out , I can see C++ is not mangling
>> the name "foo" :
>


> gcc manual says the follwing about the alias attribute:
>  "In C++, the mangled name for the target must be used."
>
> so with the following modification your example compiles:
>
>  static inline __attribute__((always_inline,alias("_ZL3foov")))
>  void bar(void);
>
> --
> Thanks.
> -- Max
>


Aha!  But how to determine the mangled name beforehand ?

Even if I compile the object without the alias, then inspect
the object with objdump, there is no mangled symbol
_ZL3foov defined in the object file .

So I have to form the mangled name string beforehand,
even for symbols for which there is no linkage ?

ie. there should never be any symbol table entry for 'foo' -
only in the debuginfo there will be information about it .

So I must run some name mangler /  generator as a
pre-processing step to get the correct mangled name
string ?

Like, if I compile just :

static inline __attribute__((always_inline))
void foo(void) {}
void f(void)
{ foo();
}

Then both
   $ nm -a t.o | grep  ZL3foov
 and
   $ objdump -t t.o | grep ZL3foov
 and
   $ objdump -g t.o | grep ZL3foov

produce no output. So how does one determine that mangled name
a-priori ? There seems to be no way of getting cpp to do it, anyway ,
which is what it would have to do to be an acceptable solution -
there must be a string literal constant argument to '__attribute__(alias()))'.

I think some kind of new pragma is needed , to allow one to say
something like:

#define _S(_X) #X
#define QUOTED_STRING(_X) _S(_X)

static inline __attribute__((always_inline, alias(
QUOTED_STRING(
#pragma symbol_name(foo)
// insert mangled symbol name here
)
)));

I'm going to investigate patching GCC to support
something like that.

I think it is unacceptable to be forced to used
mangled symbol names for objects which are
not symbols (pure inline functions) .

Thanks & Regards,
Jason

))
 void bar(void) ;

Re: why C++ cannot alias an inline function, C can ?

[Max Filippov]

On Sun, Apr 1, 2018 at 4:34 AM, Jason Vas Dias  wrote:
> In C++ however, it does not compile :
>
>   $ g++ -g -std=gnu++11 -x c++ -c t.c
> t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
>void bar(void);
> ^
>
> Even though, if I compile the object with the declaration
> of bar() commented out , I can see C++ is not mangling
> the name "foo" :

gcc manual says the follwing about the alias attribute:
 "In C++, the mangled name for the target must be used."

so with the following modification your example compiles:

 static inline __attribute__((always_inline,alias("_ZL3foov")))
 void bar(void);

-- 
Thanks.
-- Max

[Bug fortran/72709] Incorrect assignment of allocatable character array used as component of derived type

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
*** Bug 85144 has been marked as a duplicate of this bug. ***

[Bug fortran/68241] [meta-bug] [F03] Deferred-length character

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 85144, which changed state.

Bug 85144 Summary: Wrong assignment with allocatable charlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85144

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug fortran/85144] Wrong assignment with allocatable charlen

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Thomas Koenig  ---
Correct, this is a dup.

A pretty bad bug, though...

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

why C++ cannot alias an inline function, C can ?

[Jason Vas Dias]

Good day -

I'm trying to understand why this code compiles fine
in  'gcc   -std=gnu11' mode, but not in
 'g++  -std=g++11' mode
(so far tried with gcc/g++ 5.4.0 , 7.3.1 on x86_64 linux) :

'
 static inline __attribute__((always_inline))
 void foo(void){}

 static inline __attribute__((always_inline,alias("foo")))
 void bar(void);

 static
 void f(void) { foo(); }
 // must have a usage to generate any code
 '

In C mode , no problems - I can invoke foo() or bar() to
reference the same inline, and it is always inlined .

In C++ however, it does not compile :

  $ g++ -g -std=gnu++11 -x c++ -c t.c
t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
   void bar(void);
^

Even though, if I compile the object with the declaration
of bar() commented out , I can see C++ is not mangling
the name "foo" :

$ objdump -g t.o

t.o: file format elf64-x86-64

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:0x4d (32-bit)
   Version:   4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x0): GNU
C++11 5.4.0 -mtune=haswell -march=x86-64 -g -std=gnu++11
<10>   DW_AT_language: 4(C++)
<11>   DW_AT_name: t.c
<15>   DW_AT_comp_dir: (indirect string, offset: 0x43): /tmp
<19>   DW_AT_low_pc  : 0x0
<21>   DW_AT_high_pc : 0x7
<29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e>   DW_AT_name: foo
<32>   DW_AT_decl_file   : 1
<33>   DW_AT_decl_line   : 2
<34>   DW_AT_inline  : 3(declared as inline and inlined)
 <1><35>: Abbrev Number: 3 (DW_TAG_subprogram)
<36>   DW_AT_external: 1
<36>   DW_AT_name: f
<38>   DW_AT_decl_file   : 1
<39>   DW_AT_decl_line   : 10
<3a>   DW_AT_linkage_name: (indirect string, offset: 0x3d): _Z1fv
<3e>   DW_AT_low_pc  : 0x0
<46>   DW_AT_high_pc : 0x7
<4e>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
<50>   DW_AT_GNU_all_call_sites: 1
 <1><50>: Abbrev Number: 0

So there is a symbol "foo" declared, even though it is only a debug symbol .

Why does C++ not let me alias it ?  There appears to be no mangled name
for it .

And even worse, the obvious workaround does not work:

'
static inline __attribute__((always_inline))
void foo(void) {}

//  static inline __attribute__((always_inline, alias("foo")))
//  void bar(void);

static inline __attribute__((always_inline))
void ()(void) = foo;

   void f(void)
   { bar();
   }
'
Fails to compile with:

t.c:8:19: error: 'bar' declared as an 'inline' variable
   void ()(void) = foo;


So one has to do just
static
void () ( void ) = foo;

So now foo() has lost its inline-ness:

$ nm -C t.o
0007 T f()
 r bar
 t foo()

ie. the compiler did not warn that foo
has been made into an ordinary symbol:

'
$ cat t.c
static inline __attribute__((always_inline))
void foo(void) {}
static
void ()(void) = foo;
void f(void){ bar();}
$ g++ -std=gnu++11 -x c++ -Wall -Wextra -c t.c
$
 '
I think g++ should have warned that it is not treating
an always inline function as inline here !

This problem is causing me grief in more real-world scenarios -
any advice on how to create an alias that is inline-able in C++
would be much appreciated.

Thanks & Best Regards,
Jason

Re: Gcc bugzilla is down

[Eric Gallager]

Confirming, I got the same error message at around 7:29 AM Eastern
Daylight Time. Please fix!

Eric

On 4/1/18, Thomas König  wrote:
> Hi,
>
> it seems that gcc bugzilla is currently down, error message is:
>
> Software error:
>
> Can't connect to the database.
> Error: Can't connect to local MySQL server through socket
> '/var/lib/mysql/mysql.sock' (2)
>Is your database installed and up and running?
>Do you have the correct username and password selected in localconfig?
>
> If somebody could bring it up again, it would certainly help my plans to
> do some gcc hacking over the Easter weekdend :-)
>
> Regards
>
>   Thomas
>

Re: [wwwdocs] PATCH for Re: [PATCH] Make -gcolumn-info the default

[Jakub Jelinek]

On Sun, Apr 01, 2018 at 11:34:51AM +0200, Gerald Pfeifer wrote:
> On Tue, 24 Oct 2017, Richard Biener wrote:
> >> +1 from me, FWIW.
> > Please add some changes.html blurb.
> 
> I don't find anything in gcc-8/changes.html, so how about the
> following?

LGTM, thanks.

> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
> retrieving revision 1.46
> diff -u -r1.46 changes.html
> --- changes.html  20 Mar 2018 08:06:16 -  1.46
> +++ changes.html  1 Apr 2018 09:34:00 -
> @@ -77,6 +77,9 @@
>  guide for further information about the option syntax and section "New 
> Targets
>  and Target Specific Improvements" for IA-32/x86-64 for more details.
>
> +  The -gcolumn-info option is now enabled by default,
> +including column information in addition to just files and line
> +numbers in DWARF debugging information.
>  
>  

Jakub

Successful bootstrap and install of gcc (GCC) 7.3.0 on sparc64-unknown-linux-gnu

[Aaro Koskinen]

Hi,

Here's a report of a successful build and install of GCC:

$ gcc-7.3.0/config.guess
sparc64-unknown-linux-gnu

$ newcompiler/bin/gcc -v
Using built-in specs.
COLLECT_GCC=newcompiler/bin/gcc
COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/sparc-unknown-linux-gnu/7.3.0/lto-wrapper
Target: sparc-unknown-linux-gnu
Configured with: ../gcc-7.3.0/configure --with-cpu=ultrasparc 
--enable-targets=all --disable-libsanitizer --disable-nls 
--prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ 
--host=sparc-unknown-linux-gnu --build=sparc-unknown-linux-gnu 
--target=sparc-unknown-linux-gnu --with-system-zlib --with-sysroot=/
Thread model: posix
gcc version 7.3.0 (GCC) 

-- Build environment --

host: sun-ultra-10
distro:   los.git rootfs=e263b native=e263b
kernel:   Linux 4.16.0-rc6-ultra-los_e263b
binutils: GNU binutils 2.30
make: GNU Make 4.2.1
libc: GNU C Library (GNU libc) stable release version 2.27.
zlib: 1.2.11
mpfr: 4.0.1
gmp:  60102

-- Time consumed --

configure:  real0m 26.04s
user0m 19.37s
sys 0m 3.79s

bootstrap:  real44h 48m 35s
user43h 51m 31s
sys 41m 24.99s

install:real2m 58.62s
user1m 6.04s
sys 0m 37.68s

-- Hardware details ---

MemTotal: 507728 kB

cpu : TI UltraSparc IIi (Sabre)
fpu : UltraSparc IIi integrated FPU
pmu : ultra12
prom: OBP 3.31.0 2001/07/25 20:36
type: sun4u
ncpus probed: 1
ncpus active: 1
D$ parity tl1   : 0
I$ parity tl1   : 0
Cpu0ClkTck  : 1a39de00
cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus,vis
MMU Type: Spitfire
MMU PGSZs   : 8K,64K,512K,4MB

A.

Gcc bugzilla is down

[Thomas König]

Hi,

it seems that gcc bugzilla is currently down, error message is:

Software error:

Can't connect to the database.
Error: Can't connect to local MySQL server through socket 
'/var/lib/mysql/mysql.sock' (2)

  Is your database installed and up and running?
  Do you have the correct username and password selected in localconfig?

If somebody could bring it up again, it would certainly help my plans to
do some gcc hacking over the Easter weekdend :-)

Regards

Thomas

[PATCH] Show dangerous warning when -Werror option is used

[Pali Rohár]

Command line option -Werror is dangerous as it could cause problems for
compiling applications in future. Once gcc introduces a new warning or
change logic for existing warnings then compilation of existing
application via gcc could throw a new warning.

As -Werror makes all warnings fatal, it makes applications not
compilable. -Werror makes sense only for specific gcc versions against
which was application tested to compile correctly.

Attached patch adds a new warning when -Werror command line option is
enabled. It warns user that usage of -Werror can be dangerous.

-- 
Pali Rohár
pali.ro...@gmail.com
--- gcc/opts.c	2016-03-17 16:11:35.0 +0100
+++ gcc/opts.c	2018-04-01 10:40:50.758086301 +0200
@@ -1773,6 +1773,10 @@ common_handle_option (struct gcc_options
 
 case OPT_Werror:
   dc->warning_as_error_requested = value;
+  if (value)
+	warning_at (loc, 0, "command line option %qs is dangerous; "
+		"in future newly introduced non-fatal warnings "
+		"can cause fatal errors", "-Werror");
   break;
 
 case OPT_Werror_:


signature.asc
Description: PGP signature

[wwwdocs] PATCH for Re: [PATCH] Make -gcolumn-info the default

[Gerald Pfeifer]

On Tue, 24 Oct 2017, Richard Biener wrote:
>> +1 from me, FWIW.
> Please add some changes.html blurb.

I don't find anything in gcc-8/changes.html, so how about the
following?

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.46
diff -u -r1.46 changes.html
--- changes.html20 Mar 2018 08:06:16 -  1.46
+++ changes.html1 Apr 2018 09:34:00 -
@@ -77,6 +77,9 @@
 guide for further information about the option syntax and section "New 
Targets
 and Target Specific Improvements" for IA-32/x86-64 for more details.
   
+  The -gcolumn-info option is now enabled by default,
+including column information in addition to just files and line
+numbers in DWARF debugging information.