Is C++11 to be default for GCC 4.9?

[Lars Hagström]

Hi,

I'm wondering whether GCC 4.9 will switch to -std=gnu++11 as default?

I did download and build 4.9 from git (through archlinux AUR) to see
if I could answer this myself, but I got slightly contradictory
results:

I got an error that implies that "auto" is not usable, which would
mean that C++11 is not enabled, but I also got a warning that implied
that gnu++11 is "enabled by default".

> error: ‘xdir’ does not name a type

> warning: non-static data member initializers only available with -std=c++11 
> or -std=gnu++11 [enabled by default]

Or does the "enabled by default" bit mean something other than I think it means?

Thanks in advance for any insight you can offer.
/Lars

Re: Is C++11 to be default for GCC 4.9?

[Marc Glisse]

Wrong list, please send any follow-ups to gcc-h...@gcc.gnu.org only.

On Fri, 24 Jan 2014, Lars Hagström wrote:


I'm wondering whether GCC 4.9 will switch to -std=gnu++11 as default?


No. This is asked regularly, google should find the answer easily.


I got an error that implies that "auto" is not usable, which would
mean that C++11 is not enabled, but I also got a warning that implied
that gnu++11 is "enabled by default".


error: ‘xdir’ does not name a type



warning: non-static data member initializers only available with -std=c++11 or 
-std=gnu++11 [enabled by default]


Or does the "enabled by default" bit mean something other than I think it means?


It is the warning that is enabled by default (in other messages you would 
see [-Wunused] or [-Wformat] etc to tell you which option controls this 
warning).


--
Marc Glisse

Re: Is C++11 to be default for GCC 4.9?

[pinskia]

> On Jan 24, 2014, at 1:26 AM, Marc Glisse  wrote:
> 
> Wrong list, please send any follow-ups to gcc-h...@gcc.gnu.org only.
> 
>> On Fri, 24 Jan 2014, Lars Hagström wrote:
>> 
>> I'm wondering whether GCC 4.9 will switch to -std=gnu++11 as default?
> 
> No. This is asked regularly, google should find the answer easily.

Considering GCC has not switched to c99 by default what makes someone think GCC 
should switch to c++11 by default?

-- Andrew

> 
>> I got an error that implies that "auto" is not usable, which would
>> mean that C++11 is not enabled, but I also got a warning that implied
>> that gnu++11 is "enabled by default".
>> 
>>> error: ‘xdir’ does not name a type
>> 
>>> warning: non-static data member initializers only available with -std=c++11 
>>> or -std=gnu++11 [enabled by default]
>> 
>> Or does the "enabled by default" bit mean something other than I think it 
>> means?
> 
> It is the warning that is enabled by default (in other messages you would see 
> [-Wunused] or [-Wformat] etc to tell you which option controls this warning).
> 
> -- 
> Marc Glisse

Debian test rebuild on x86_64-linux-gnu with trunk 20140118

[Matthias Klose]

Here are some preliminary results of a test rebuild on x86_64-linux-gnu with
trunk 20140118, for all 10755 source packages building architecture dependent
binary packages.  Compared to the current gcc-4.8 in Debian unstable, there were
103 new build failures. The gcc-4.9 packages used can be found in Debian
experimental (apt-get -t experimental install g++ g++-4.9). Binutils 2.24 branch
was used, and glibc-2.17. The only changed components in the test rebuild were
the binary packages produced by the gcc-4.9 source package.

The build logs for the builds failing with 4.9 but succeeding with 4.8 can be
found at http://people.debian.org/~doko/tmp/logs-20140122/

 - filed issues for GCC after reproducing ICE's with trunk 20140122.
   59917, 59918, 59918, 59920, 59924, 59925, 59927.

 - There are 13 packages failing with link errors, all C++ related,
   and many of these with undefined references to vtables.

 - There are 9 packages with test failures, the most prominent ones
   perl, pcre3 and mysql-5.5 (see below).

The following build failures are triggered by the new GCC:

 - More strict C++, see below for the packages failing with the same
   error messages.

 - Some packages fail with -Werror and new warnings.
   Werror=maybe-uninitialized, -Werror=unused-function

 - missing symbols in debian symbols files

 - gfortran module version mismatches. These seem to go away once
   the dependencies of these packages are rebuilt with the new gfortran.

Planning to do the same for arm-linux-gnueabihf as soon as 59913 is fixed.

Thanks to David Suarez for actually doing the test rebuild.

  Matthias


ace, calligra, digikam, indigo, kdeconnect, kdepim, libreoffice,
objcryst-fox, onscripter, ostinato, schroot, scummvm, vavoom:
  link error, undefined reference to some c++ symbols
  often undefined reference to `vtable for ...'

paraview:
  link error. reason?

gmsh:
  memory hog?
  cc1: out of memory allocating 104 bytes after a total of 8847925248 bytes
  make[4]: *** [CMakeFiles/gmsh.dir/contrib/Chaco/eigen/warnings.c.o] Error 1

aspectc++:
  Weaving aspects into CCSemExpr.cc...
  pure virtual method called
  terminate called without an active exception
  make[3]: ***
[/build/aspectc++-Thyask/aspectc++-1.2/Puma.copy/gen-release/step2/src/CScanner.cc]
Aborted
  make[3]: *** Waiting for unfinished jobs
  pure virtual method called
  terminate called without an active exception
  make[3]: ***
[/build/aspectc++-Thyask/aspectc++-1.2/Puma.copy/gen-release/step2/src/UnitManager.cc]
Aborted
  pure virtual method called
  terminate called without an active exception
  pure virtual method called
  make[3]: ***
[/build/aspectc++-Thyask/aspectc++-1.2/Puma.copy/gen-release/step2/src/PreFileIncluder.cc]
Aborted
  terminate called without an active exception
  pure virtual method called

botan1.10:
  test failure
  Testing Block Ciphers: ...
  Testing Cipher Modes: ..
  Segmentation fault

glib2.0:
  test failure
  /gvariant/serialiser/array:  FAIL
  GTester: last random seed: R02S3c7e13660160155b748b31e3e25479e9

libapache2-mod-perl2
  test failures
  [  error] oh jeez, server dumped core
  [  error] oh shucks, server dumped core

matplotlib:
  test timeout after 60min

mia:
  test failure
  The following tests FAILED:
192 - 3dimage-filter-mlv (Failed)

mysql-5.5:
  Too many failed: Failed 10/436 tests, 97.71% were successful.

pcre3:
  test failures
  FAIL: RunTest

perl:
  test failures
  t/op/numconvert  FAILED at test 104
  t/op/range . FAILED at test 84
  Failed 2 tests out of 2329, 99.91% okay.

roboptim-core:
  test failures
  88% tests passed, 3 tests failed out of 24

brainparty, igstk:
  error: redeclaration of '...' may not have default arguments [-fpermissive]

0ad, aria2, cupt, dssp, fish, fldigi, iverilog, mednafen, mkvtoolnix, mrs,
nmap, v4l-utils:
  error: converting to '...' from initializer list would use explicit
constructor '...'


activiz.net:
  a function call cannot appear in a constant-expression

apron, cadabra:
  error: 'ptrdiff_t' does not name a type

aptitude, curlpp, diagnostics, mongodb, qtwebkit:
  -Werror & -Werror=unused-function

beast:
  error: '...' is protected within this context

binutils-msp430, xorp:
  -Werror & -Werror=maybe-uninitialized

blackbox, libgtextutils, owncloud-client, qapt, wfmath:
  symbols in debian symbols file missing

cdftools, elkcode, flexpart, slepc:
  Cannot read module file '...' opened at (1),
  because it was created by a different version of GNU Fortran

etsf-io:
  GNU Fortran module version mismatch

faumachine:
  ./dyngen -p chip_intel_80286_op_ -o cpu_286_jit_op_gen.h.tmp
libqemu_gen_286_a-cpu_286_jit_op.o
  dyngen: Multiple return instructions in chip_intel_80286_op_ldub_kernel_T0_A0
  make[6]: *** [cpu_286_jit_op_gen.h] Error 1

cutter-testing-framework:
  unreproducible build failure

feel++, llvm-toolchain-3.3,

Re: clang vs free software

[Duncan Sands]

Hi Vladimir,

o Comparing LLVM and GCC on Fortran benchmarks.  LLVM has no fortran FE and just
quietly call system GCC.  So comparison of LLVM and GCC on Fortran benchmarks
means comparison of system GCC and a given GCC.


a few people are working on LLVM based Fortran compilers.  I'm not sure how far 
they got though.  I think the one farthest along is this one:

  https://github.com/hfinkel/lfort/
There is also:
  https://github.com/isanbard/flang/
Of course you can always cheat and use the GCC Fortran front-end, using the 
dragonegg plugin bridging it to LLVM, but as I'm not maintaining dragonegg any 
more (no time) this solution is likely to bitrot fast unless someone else picks 
up the project.


Best wishes, Duncan.

Re: ICE in trunk due to MEM with address in vector mode

[Richard Sandiford]

Paulo Matos  writes:
> Hello,
>
> I have found a strange case of an ICE due to a MEM with an address
> with vector mode.

AFAIK that isn't supported.  Addresses are assumed to be MODE_INT or
MODE_PARTIAL_INT.  Hopefully someone will correct me if this has changed
without me noticing it.

Is this for some kind of gather load?  I think an address like that
would have to be mode-dependent anyway, since the number of units
in the MEM mode and the address mode would need to match.

Thanks,
Richard

Re: Debian test rebuild on x86_64-linux-gnu with trunk 20140118

[Jonathan Wakely]

On 24 January 2014 10:08, Matthias Klose wrote:
>
> 0ad, aria2, cupt, dssp, fish, fldigi, iverilog, mednafen, mkvtoolnix, mrs,
> nmap, v4l-utils:
>   error: converting to '...' from initializer list would use explicit
> constructor '...'

That one was a GCC problem, fixed by
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=206939

RE: ICE in trunk due to MEM with address in vector mode

[Paulo Matos]

> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 24 January 2014 10:46
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: ICE in trunk due to MEM with address in vector mode
> 
> Paulo Matos  writes:
> > Hello,
> >
> > I have found a strange case of an ICE due to a MEM with an address
> > with vector mode.
> 
> AFAIK that isn't supported.  Addresses are assumed to be MODE_INT or
> MODE_PARTIAL_INT.  Hopefully someone will correct me if this has changed
> without me noticing it.
> 
> Is this for some kind of gather load?  I think an address like that
> would have to be mode-dependent anyway, since the number of units
> in the MEM mode and the address mode would need to match.
>

Thanks for your comment.
We have an instruction that loads two 32 bit values into a lower and upper 
parts of a 64bit register using a base register and a 64 bit register used as a 
double index.
So,
r1 <- [r0, r2] 
means:
low(r1) = [r0 + low(r2)]
high(r1) = [r0 + high(r2)]

In this case we use vector addresses. If it is indeed not allowed then I need 
another solution. Used to work well in 4.8 and before. In trunk it breaks, but 
works with the patch I included before.
Can't find anything in the documentation regarding this case so it would be 
good to make it clear one way or the other.

Paulo Matos

 
> Thanks,
> Richard

Re: ICE in trunk due to MEM with address in vector mode

[Richard Sandiford]

Paulo Matos  writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>> Sent: 24 January 2014 10:46
>> To: Paulo Matos
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: ICE in trunk due to MEM with address in vector mode
>> 
>> Paulo Matos  writes:
>> > Hello,
>> >
>> > I have found a strange case of an ICE due to a MEM with an address
>> > with vector mode.
>> 
>> AFAIK that isn't supported.  Addresses are assumed to be MODE_INT or
>> MODE_PARTIAL_INT.  Hopefully someone will correct me if this has changed
>> without me noticing it.
>> 
>> Is this for some kind of gather load?  I think an address like that
>> would have to be mode-dependent anyway, since the number of units
>> in the MEM mode and the address mode would need to match.
>>
>
> Thanks for your comment.
> We have an instruction that loads two 32 bit values into a lower and
> upper parts of a 64bit register using a base register and a 64 bit
> register used as a double index.
> So,
> r1 <- [r0, r2] 
> means:
> low(r1) = [r0 + low(r2)]
> high(r1) = [r0 + high(r2)]
>
> In this case we use vector addresses. If it is indeed not allowed then I
> need another solution. Used to work well in 4.8 and before. In trunk it
> breaks, but works with the patch I included before.

Just in case: the point I was trying to make in the second paragraph
was that the code in the patch only triggers (as you say) because the
address isn't seen as mode-dependent.  But this kind of address does
look mode-dependent to me, since it only works for MEM modes that have
the same number of elements as the index vector.  So this does sound
like a case where mode_dependent_address_p ought to return true.

If we do support vector addresses than I think the right fix is to
check VECTOR_MODE_P there.

Thanks,
Richard

compiling multi file project

[Jan de Haan]

Hi All,

banging my head, exhausted google, don't know where I make the mistake,
can somebody please tell me the errors of my ways?

Project layout:

projectheader.h
   #ifndef PROJECTHEADER
   #define PROJECTHEADER
   #include 
   #include "class1header"
main.cpp
   #include "projectheader"
class1header.h
   #ifndef CLASS1HEADER
   #define CLASS1HEADER
   #include 
   #include 
   typedef shared_ptr Class1Ptr;
class1source.cpp
   #include "class1header"
   definitions

A sound and logical layout, as far as I know.

Problem: class1source.cpp fails to compile on it's header with
"error: ‘shared_ptr’ does not name a type"

What is wrong with my layout (because including the projectheader in
class1source compiles) and what is the best thing I can do about it?

Sincerely,

Jan de Haan.

-- 
"Piracy is simply demand where supply does not exist."

Re: compiling multi file project

[Marc Glisse]

Wrong list, please send any follow-ups to gcc-help ONLY, or better yet to 
some C++ forum wherever since this has little to do with gcc in 
particular.


On Fri, 24 Jan 2014, Jan de Haan wrote:


   banging my head, exhausted google, don't know where I make the mistake,
can somebody please tell me the errors of my ways?

Project layout:


Irrelevant.


Problem: class1source.cpp fails to compile on it's header with
"error: ‘shared_ptr’ does not name a type"


Have you heard of namespaces?

--
Marc Glisse

Re: Debian test rebuild on x86_64-linux-gnu with trunk 20140118

[Jonathan Wakely]

On 24 January 2014 10:08, Matthias Klose wrote:
>
> brainparty, igstk:
>   error: redeclaration of '...' may not have default arguments [-fpermissive]

G++ was fixed to reject this, the code is invalid.

>
> apron, cadabra:
>   error: 'ptrdiff_t' does not name a type

These should be qualifying the type as std::ptrdiff_t.

> grail:
>   ext/new_allocator.h:120:4: error: use of deleted function

That's another bug I fixed yesterday:
http://gcc.gnu.org/viewcvs?rev=206994&root=gcc&view=rev


> lcalc, sofa-framework:
>  error: redeclaration of '...' may not have default arguments [-fpermissive]

Looks like the same issue as brainparty and isgtk.

> ppl:
>   error: no type named 'difference_type' in 'class ...'
>   error: no matching function for call to 'distance(...)'

The root cause is using ptrdiff_t not std::ptrdiff_t again.

> supercollider:
>   error: no matching function for call

I thought that might be my fault so looked into it, but it's an
upstream bug in SuperCollider, fixed in the latest release. It only
used to work with GCC 4.8 because our std::map was non-conforming in
exactly the right way for supercollider's non-conforming allocator to
do the right thing.

> sslsniff:
>   error: redeclaration of 'std::string error' [-fpermissive]
>
> tripwire:
>   archive.cpp:889:28: error: redeclaration of 'eArchiveOpen e' [-fpermissive]
>  eArchiveOpen e(strTempFile, errStr);
> ^
>   archive.cpp:886:29: note: 'eFSServices& e' previously declared here
>  catch( eFSServices& e)

The sslsniff and tripwire failures are the same issue, G++ no longer
allows this:

try {
} catch (int var) {
  int var;
}


So several cases are real bugs that G++ now catches, and some were
known libstdc++ regressions that were fixed yesterday.

Re: Don't shoot the messenger

[Richard Kenner]

> To the extent that clang/LLVM and GCC are fighting, which is not
> really the case, then I think it makes sense for GCC to focus on its
> strengths, not its weaknesses.  Objective C is not a strength.  I'm
> not sure it makes sense for the GCC project to encourage its limited
> volunteer resources to work on it.

I agree.  Competition is a good thing.  But it's best when it's not
"head to head".  Instead each should have what it's best at.

Re: clang vs free software

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

In the free software movement, we campaign for the freedom of the
users of computing.  The values of free software are fundamentally
different from the values of open source, which make "better code" the
ultimate goal.  If GCC were to change from a free compiler into a
platform for nonfree compilers, it would no longer serve the goal of
freedom very well.  Therefore, we had to take care to prevent that.

(See http://www.gnu.org/philosophy/open-source-misses-the-point.html
for more explanation of the difference between free software and open
source.  See also http://thebaffler.com/past/the_meme_hustler for
Evgeny Morozov's article on the same point.)

The Clang and LLVM developers reach different conclusions from ours
because they do not share our values and goals.  They object to the
measures we have taken to defend freedom because they see the
inconvenience of them and do not recognize (or don't care about) the
need for them.  I would guess they describe their work as "open
source" and do not talk about freedom.  They have been supported by
Apple, the company which hates our freedom so much that its app store
for the ithings _requires_ all apps to be nonfree. (*)

The nonfree compilers that are now based on LLVM prove that I was
right -- that the danger was real.  If I had "opened" up GCC code for
use in nonfree combinations, that would not have prevented a defeat;
rather, it would have caused that defeat to occur very soon.

For GCC to be replaced by another technically superior compiler that
defended freedom equally well would cause me some personal regret, but
I would rejoice for the community's advance.  The existence of LLVM is
a terrible setback for our community precisely because it is not
copylefted and can be used as the basis for nonfree compilers -- so
that all contribution to LLVM directly helps proprietary software as
much as it helps us.

The cause of the setback is the existence of a non-copylefted compiler
that therefore becomes the base for nonfree compilers.  The identity
of that compiler -- whether it be LLVM, GCC, or something else -- is a
secondary detail.  To make GCC available for such use would be
throwing in the towel.  If that enables GCC to "win", the victory
would be hollow, because it would not be a victory for what really
matters: users' freedom.

If you think we ought to "compromise" on this point, please see
http://www.gnu.org/philosophy/compromise.html.

The only code that helps us and not our adversaries is copylefted
code.  Free software released under a pushover license is available
for us to use, but available to our adversaries just as well.  If you
want your work to give freedom an advantage, use the leverage
available to you -- copyleft your code.  I invite those working on
major add-ons to LLVM to release them under GNU GPL
version-3-or-later.


If you want to argue for changing the goals of the GNU Project, the
proper place to do this is gnu-misc-disc...@gnu.org.  Please move this
discussion there.


* If a binary is made from published source code, but you can't
  install your binary of a modified version of that source code, the
  binary is proprietary even if the source code is free.  (See
  http://www.gnu.org/philosophy/free-sw.html.)  A binary in Apple's
  app store may be made from published free source code, but under
  Apple's rules and Apple's DRM, the binary can't be free.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

RE: ICE in trunk due to MEM with address in vector mode

[Paulo Matos]

> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 24 January 2014 12:21
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: ICE in trunk due to MEM with address in vector mode
> 
> Just in case: the point I was trying to make in the second paragraph
> was that the code in the patch only triggers (as you say) because the
> address isn't seen as mode-dependent.  But this kind of address does
> look mode-dependent to me, since it only works for MEM modes that have
> the same number of elements as the index vector.  So this does sound
> like a case where mode_dependent_address_p ought to return true.
> 

Yes, you're probably right. Sorry I haven't gotten back to you on that part of 
your initial email.

> If we do support vector addresses than I think the right fix is to
> check VECTOR_MODE_P there.
> 

Well, isn't it the case that a mem with vector mode is always mode dependent, 
in which case adding VECTOR_MODE_P to mode-dependent target hook would be 
enough making the patch not so useful?

Cheers,

Paulo Matos

> Thanks,
> Richard

Re: -Wformat-security warnings generated in gcc build

[Prathamesh Kulkarni]

On Thu, Jan 23, 2014 at 9:09 PM, Prathamesh Kulkarni
 wrote:
> On Thu, Jan 23, 2014 at 8:24 PM, Dodji Seketeli  wrote:
>> Prathamesh Kulkarni  writes:
>>
>>>
>>> Shall it be correct then to replace calls to error() and friends,
>>> taking only format string with no-argument specifiers
>>> to error_at_no_args() ? (similarly we shall need warning_at_no_args,
>>> pedwarn_no_args, etc.)
>>
>> I would guess so, yes.
>>

 Also, you'd need to modify cp/error.c:cp_printer in a similar way, to
 issue an internal_error each time we try to access a null test->args_ptr.
>>>
>>> Shall check for text->args_ptr be required in each case label of
>>> argument specifier in pp_format()
>>> and client-specific functions like cp_printer() ?
>>
>> Yes, I think so.  Maybe you can make that a bit more maintainable by
>> creating a macro like those used to access text->args_ptr in cp_printer,
>> e.g:
>>
>> #define next_int va_arg (*text->args_ptr, int)
>>
>> In that macro, make the check for text->args_ptr before accessing it,
>> and then use that macro to access text->args_ptr through the function.
>>
>
> I was going through diagnostic.c, it appears that many functions in
> (error(), error_at(), warning(), etc.) share common code (mostly
> contains call to diagnostic_set_info() followed by call to
> report_diagnostic()), which I guess can be re-written in terms of
> emit_diagnostic(), however since it's variadic that's not possible. I
> wrote a v_emit_diagnostic() function, that takes same arguments as
> emit_diagnostic(), with additional va_list * at end (va_list * instead
> of va_list, so I could pass NULL for error_no_args() and friends). Is
> it correct to write these other functions (emit_diagnostic(), error(),
> inform(), etc.) in terms of v_emit_diagnostic() ?

silly mistake in warning_at(), it should be:
ret = v_emit_diagnostic (DK_WARNING, location, opt, gmsgid, &ap);

>
>
>
>
>
>> --
>> Dodji

Re: Don't shoot the messenger

[Joseph S. Myers]

On Thu, 23 Jan 2014, Eric S. Raymond wrote:

> Really, attempts to shoot the messenger *won't help*.  By ignoring the
> areas where clang *does* have a clear advantage, *right now*, you are
> displaying the exact head-in-the-sand attitude that is most likely to
> concede the high ground to clang.

You appear to think things are being ignored, based on a notion of FSF 
policy that is several years out of date (if it was ever accurate).

Contributions of patches to improve GCC in areas where clang has an 
advantage, such as modularity and usability as a library in editors, 
refactoring tools, static analyzers etc., are welcome and have been 
welcome for several years, at least since plugin support was added (of 
course, such tools using parts of GCC would need to be released as free 
software under GPLv3+).  See the proposed improvement projects at 
, and the architectural goals 
linked therefrom, for something more accurate regarding GCC developers' 
notions of current deficiencies and desired directions for GCC than an old 
notion of FSF policy.  Poorly defined interfaces, lack of modularity and 
presence of global state do not reflect some sort of policy decision; they 
reflect the history of a code base that is about twice as old as LLVM.  
Global cleanups in all these areas have been going in at least since the 
start of EGCS, and remain welcome.

Actual FSF policy is as documented at 
.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ICE in trunk due to MEM with address in vector mode

[Richard Sandiford]

Paulo Matos  writes:
>> If we do support vector addresses than I think the right fix is to
>> check VECTOR_MODE_P there.
>
> Well, isn't it the case that a mem with vector mode is always mode
> dependent, in which case adding VECTOR_MODE_P to mode-dependent target
> hook would be enough making the patch not so useful?

Yeah, adding it to the target hook would work too.  I'd just prefer it
to be in generic code because I think it's a target-independent rule.

I can see that for an out-of-tree port it would be easier to put it in
the target hook though.

Thanks,
Richard

Re: clang vs free software

[Ludovic Courtès]

Chris Lattner  skribis:

> On Jan 23, 2014, at 12:14 PM, Steven Bosscher  wrote:
>> (Hint: read http://vmakarov.fedorapeople.org/spec/ as an example of a
>> better-supported point of view.)
>
> Unrelated to this thread, it would be great for this web page to get updated. 
>  You may find it to be "a better-supported point of view", but it is also 
> comparing against clang 3.2, which is from the end of 2012, and a lot has 
> changed since then.

Similarly,  compares to GCC 4.2,
released between May 2007 and May 2008.

That makes the other web page a better-supported point of view.

Ludo’.

[gomp4] gomp-4_0-branch

[Thomas Schwinge]

Hi!

First, pardon the long CC list.  You are, in my understanding, the people
who are interested in collaborating on the topics that are being prepared
on gomp-4_0-branch: "LTO" streaming, acceleration device offloading,
OpenMP target, OpenACC, nvptx backend -- and more?

As we've noticed, and he has just recently told me, Jakub currently is
totally occupied with getting the GCC 4.9 release in shape, and thus
can't spend any reasonable amount of time on reviewing/developing patches
for the gomp-4_0-branch topics.  He suggested that I "take over" the
branch, and he would chime in again, once his GCC 4.9 duties have calmed
down.

Now, my experience of GCC of course is nowhere close to Jakub's, and even
though I'm learning a lot, it's not possible for me to provide patch
reviews with the same quality as he does.  On the other hand, I consider
gomp-4_0-branch to be a development branch, so I'm fine with people
committing stuff there that is not totally polished, as long as it
doesn't cause havoc to the existing code (as made evident by compiler
warnings during the GCC build as well as regressions in the testsuite).
There can be occasional exceptions to this, for example if a patch causes
a testsuite regression, but that regression is known and understood, and
will be addressed in the following.  (Please state such things in your
patch submissions.)  Also, I'm fine with getting work-in-progress stuff
committed on the branch, with the same expectations of mentioning this in
the submission, and completing the implementation later on.  Let's first
try to play this by email, but if it grows out of bound, perhaps a wiki
page will help to track known-broken/incomplete stuff?


As before, patches should be posted (with a [gomp4] tag) before
committing them, and at least be given some review and acknowledgement.
That is, consensus by the people interested in the topics worked on on
this branch.  Also, let's not be shy to ask GCC's area maintainers
(top-level MAINTAINERS file) for help (CC them in your submissions), for
example for front end changes.  It should be in their own interest to do
such review early ;-), as eventually all these changes aggregated on the
branch are to be merged into trunk.  Also, as far as possible, let's try
to get individual changes into trunk early, instead of aggregating lots
of stuff on gomp-4_0-branch, so that the diff between the two branches
doesn't grow too big (which makes branch maintenence difficult, such as
when doing merges from trunk).  (I'm aware this is less relevant/possible
until GCC 4.9 has branched.)


Jakub suggested (and I agree) the first thing to be done on
gomp-4_0-branch is a merge from trunk, which he hasn't done for a long
time.  I have prepared this yesterday morning, and have it ready for
commit, but...

..., now Samsung have posted,
,
patches for OpenACC support for Fortran, which likely will be conflicting
with the trunk merge as well as it does partially conflict with my
pending patch series for initial support for OpenACC data clauses,
.
Nevertheless, many thanks, Samsung people, for forward-porting this first
set of changes from your openacc-1_0-branch to gomp-4_0-branch!

We shall now work on integrating all this, and start reviewing the
patches that have been posted.  :-)


Grüße,
 Thomas


pgpGCwuXkuzlH.pgp
Description: PGP signature

Suspected bugs in ptr_difference_const & split_address_to_core_and_offset

[Bingfeng Mei]

Hi,
I experienced an issue in our port, which I suspected due to bugs
in ptr_difference_const & split_address_to_core_and_offset. Basically,
ptr_difference_const, called by ivopts pass, tries to evaluate 
whether e1 & e2 differ by a const. In this example,

e1 is (addr_expr (mem_ref (ssa_name1, 8))
e2 is just ssa_name1.

It is obvious to me that ptr_difference_const should return true. But
it calls split_address_to_core_and_offset to split e1 to some base pointer
and offset. split_addess_to_core_and_offset in turn calls get_inner_reference
to do it. get_inner_reference cannot handle (mem_ref (ssa_name1, 8)),
it just returns the same expression back. 

get_inner_reference function
case MEM_REF:
  /* Hand back the decl for MEM[&decl, off].  */
  if (TREE_CODE (TREE_OPERAND (exp, 0)) == ADDR_EXPR)
{
  tree off = TREE_OPERAND (exp, 1);
  if (!integer_zerop (off))
{
  double_int boff, coff = mem_ref_offset (exp);
  boff = coff.alshift (BITS_PER_UNIT == 8
   ? 3 : exact_log2 (BITS_PER_UNIT),
   HOST_BITS_PER_DOUBLE_INT);
  bit_offset += boff;
}
  exp = TREE_OPERAND (TREE_OPERAND (exp, 0), 0);
}
  goto done;

Then in ptr_difference_const, we get core1 as (mem_ref (ssa_name1, 8))
and toffset1 is empty. ptr_difference_const will return false as result.

There is another possible bug in ptr_difference_const. If one of toffset1
& toffset2 is true, why it returns false?  The comment doesn't make sense
to me. In this example, toffset1 should be 8 and toffset2 should be empty.
No way it should return false.

  else if (toffset1 || toffset2)
{
 /* If only one of the offsets is non-constant, the difference cannot
be a constant.  */
  return false;
}


Any comment? I would like to submit a patch for it. The problem is I don't
have an reproducible example on x86 or other public targets. I ran through
the x86-64 tests and didn't hit a single case that meets this condition.
e1 is (addr_expr (mem_ref (ssa_name1, 8))
e2 is just ssa_name1.
Not sure about other targets though.

Thanks,
Bingfeng

netgull.com mirror doesn't have gcc release .sig files.

[Andrew Engelbrecht]

there are no .sig files here:

http://www.netgull.com/gcc/releases/gcc-4.8.2/

i assumed that gcc didn't use gpg for releases, and became very
discouraged about the idea of building gcc from source.

then i noticed that there are .sig files at ftp.gnu.org and became very
happy. :)

i've only checked the above mirrors, but it would be nice if that
mirror, and others, (automatically?) distributed .sig files too.

thanks,
-andrew

GCC Mips has 31 Masks in mips.opt

[Steve Ellcey]

Richard,

While experimenting with a local GCC change I added two new Masks to
mips.opt and ran into a build failure about too many masks:

./options.h:4172:2: error: #error too many target masks

It looks like we already have 31 Masks in the MIPS mips.opt file and 32
is the limit.  It looks like the fix for this is to put some of the Masks
in a variable other then target_flags with the Var() syntax.  I see i386
and rs6000 doing this with ix86_isa_flags and rs6000_isa_flags.

Now I could just put my new flags (and any other new flags that come
up) in a separate variable, but I was wondering if we wanted to
move a set of existing Masks to a new variable instead of just using
a first-come first-serve approach to what goes into the default
target_flags and what goes into a new flags variable.

My thought is that by moving some of the existing Masks to a different
variable it would make it easier to add new flags later, especially if
someone is just adding a flag temporarily as an experiment to test
something.

Does this sound reasonable to you?  If so what flags do you think we
might want to move out of target_flags to a different variable?

Steve Ellcey
sell...@mips.com

Re: GCC Mips has 31 Masks in mips.opt

[H.J. Lu]

On Fri, Jan 24, 2014 at 3:20 PM, Steve Ellcey  wrote:
> Richard,
>
> While experimenting with a local GCC change I added two new Masks to
> mips.opt and ran into a build failure about too many masks:
>
> ./options.h:4172:2: error: #error too many target masks
>
> It looks like we already have 31 Masks in the MIPS mips.opt file and 32
> is the limit.  It looks like the fix for this is to put some of the Masks
> in a variable other then target_flags with the Var() syntax.  I see i386
> and rs6000 doing this with ix86_isa_flags and rs6000_isa_flags.
>

i386 uses HOST_WIDE_INT for ix86_isa_flags, which
bugs us some time, until we need more than 64 bits.

-- 
H.J.

print out %D spec

[Perry Smith]

I think, a %D in a spec creates a list of -L/a/b/c -L/d/e/f.  gcc -dumpspecs 
shows me that link_libgcc goes to %D but it does not show me what %D produces.  
Is there a way to get gcc to dump that out?

Basically what I'm trying to do is find the list of library paths that GCC 
tells ld to use when it calls ld.

Thank you for your time,
Perry



signature.asc
Description: Message signed with OpenPGP using GPGMail