date:20140628

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|tower120 at gmail dot com  |adam at jessamine dot 
co.uk

--- Comment #2 from Paolo Carlini  ---
Maybe Adam can have a look to this one too.

[Bug sanitizer/61530] [4.10 Regression] segfault with asan

2014-06-28 Thread Joost.VandeVondele at mat dot ethz.ch

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Joost VandeVondele  
---
fixed, I meant.

[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo

2014-06-28 Thread glisse at gcc dot gnu.org

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

--- Comment #16 from Marc Glisse  ---
I am now getting an abi_check failure on x86_64-linux-gnu on a -O0 -g build
because of this symbol. Is it expected?

1 incompatible symbols 
0
_ZNKSt9type_infoeqERKS_
std::type_info::operator==(std::type_info const&) const
version status: incompatible
GLIBCXX_3.4
type: function
status: added

[Bug tree-optimization/60770] disappearing clobbers

2014-06-28 Thread ebotcazou at gcc dot gnu.org

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  ---
> I am probably doing something wrong in the patch, but ada seems to be using
> clobbers differently than others since it is the only one that notices
> (well, I didn't have a chance to check go since ada broke early).

The Ada front-end is the only serious user of abnormal call edges and the like
(for example SSA_NAME_OCCURS_IN_ABNORMAL_PHI) so this is not very surprising.

[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo

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

--- Comment #17 from Paolo Carlini  ---
It is not expected of course, but I'm traveling, I cannot look into it now, I
have no idea why is the symbol exported, is the macro we added for ARM
misbehaving somehow for Linux? I can't imagine how since the operator is
defined inline on targeta like Linux and the macro should be false.

[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo

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

--- Comment #18 from Paolo Carlini  ---
In other terms, I don't see how !__GXX_TYPEINFO_EQUALITY_INLINE may end up
being true on x86_64-linux given the beginning of abi/pre/gnu.ver

[Bug tree-optimization/60770] disappearing clobbers

2014-06-28 Thread glisse at gcc dot gnu.org

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

--- Comment #9 from Marc Glisse  ---
The warnings are "normal", they also appear in a non-patched build, so that
leaves only the coalesce errors.

(In reply to Eric Botcazou from comment #8)
> The Ada front-end is the only serious user of abnormal call edges and the
> like (for example SSA_NAME_OCCURS_IN_ABNORMAL_PHI) so this is not very
> surprising.

Indeed there are setjmp related things nearby in the dump and it is most likely
related to this error.

Though I am not sure what coalesce is unhappy about:

Unable to coalesce ssa_names 3329 and 3388 which are marked as MUST COALESCE.
r_3329(ab) and  r_3388(D)(ab)

That's likely:
  # r_3329(ab) = PHI 

but r_3388 only ever appears on the rhs of PHI nodes, always uninitialized, so
it can essentially be ignored. Well, I'll keep looking when I can. (tools like
delta have a hard time removing much more than the comments there, the size of
the testcase (ali.adb) doesn't help)

[Bug c++/61637] New: C++ program does not catch exceptions on AIX 7.1

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

Bug ID: 61637
   Summary: C++ program  does not catch exceptions on AIX 7.1
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chandrakm at hotmail dot com

I have a C++ program compiled on AIX 7.1 using gcc 4.8.1 . This uses some
shared libs compiled on C language. 

None of the throws statements are caught. 

Is this a known defect or has anything to do with any gcc compiler options that
i am using.

[Bug c++/61636] generic lambda "cannot call member function without object"

2014-06-28 Thread tower120 at gmail dot com

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

--- Comment #3 from tower120  ---
I found that as only I pass *this as parameter and then call functions from it,
it works ok. But it have to be auto:

/// This work
std::cout << if_else(do_first,
*this,
[&](auto self){ return self.fn1(data); },
[&](auto self){ return self.fn2(data); }
) << '\n';


/// This not
std::cout << if_else(do_first,
*this,
[&](Test self){ return self.fn1(data); },
[&](Test self){ return self.fn2(data); }
) << '\n';

http://coliru.stacked-crooked.com/a/272a5e0b8089a5c4

And what even more strange, it work if only one lambda is auto:

std::cout << if_else(do_first,
*this,
[&](auto self){ return self.fn1(data); },
[&](Test self){ return self.fn2(data); }  // ???
) << '\n';

http://coliru.stacked-crooked.com/a/ed45a402a6c11d63

[Bug c++/60249] [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals

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

--- Comment #7 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Created attachment 33026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33026&action=edit
patch_from_hell

[Bug c++/60249] [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals

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

--- Comment #6 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
On 06/27/2014 05:39 PM, paolo.carlini at oracle dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
>
> --- Comment #5 from Paolo Carlini  ---
> Patch looks *great*. If it works, please send it to mailing list ASAP.
>
I think I finally got these weird user-defined string literal bugs. 
"Don't cross the streams!"

Dr. Egon Spengler

PR C++/58781    - Unicode
strings broken in a strange way
PR C++/59867    - Template
string literal loses first symbol
PR C++/60249    - Compiler
goes into semi-infinite loop with wrong usage of user defined string literals
Plus I fixed an misleading error message for string literal operator templates
(not available in C++11).

Built and tested clean on x86_64-linux.

OK?

I would also like to apply this to 4.9.

[Bug c++/61637] C++ program does not catch exceptions on AIX 7.1

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-06-28
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Please provide a self-contained preprocessed reproducer per the bug reporting
instructions.

[Bug c++/60249] [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals

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

--- Comment #8 from Paolo Carlini  ---
Thanks, but in general I would recommend sending patches to gcc-patches in a
separate email, with a clear [C++ Patch] or something similar in the subject.
Also, please minimize jokes and other redundant content, we already have
setious issues with lost patches, old bugs remaining umfixed for ages, etc,
without.

[Bug c++/61637] C++ program does not catch exceptions on AIX 7.1

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|blocker |normal

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-28 Thread fxcoudert at gcc dot gnu.org

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

--- Comment #15 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Sat Jun 28 14:17:41 2014
New Revision: 212102

URL: https://gcc.gnu.org/viewcvs?rev=212102&root=gcc&view=rev
Log:
PR fortran/29383

gcc/fortran/
* gfortran.h (gfc_simplify_ieee_selected_real_kind): New prototype.
* libgfortran.h (GFC_FPE_*): Use simple integer values, valid in
both C and Fortran.
* expr.c (gfc_check_init_expr): Simplify IEEE_SELECTED_REAL_KIND.
* simplify.c (gfc_simplify_ieee_selected_real_kind): New function.
* module.c (mio_symbol): Keep track of symbols which came from
intrinsic modules.
(gfc_use_module): Keep track of the IEEE modules.
* trans-decl.c (gfc_get_symbol_decl): Adjust code since
we have new intrinsic modules.
(gfc_build_builtin_function_decls): Build decls for
ieee_procedure_entry and ieee_procedure_exit.
(is_from_ieee_module, is_ieee_module_used, save_fp_state,
restore_fp_state): New functions.
(gfc_generate_function_code): Save and restore floating-point
state on procedure entry/exit, when IEEE modules are used.
* intrinsic.texi: Document the IEEE modules.

libgfortran/
* configure.host: Add checks for IEEE support, rework priorities.
* configure.ac: Define IEEE_SUPPORT, check for fpsetsticky and
fpresetsticky.
* configure: Regenerate.
* Makefile.am: Build new ieee files, install IEEE_* modules.
* Makefile.in: Regenerate.
* gfortran.map (GFORTRAN_1.6): Add new symbols.
* libgfortran.h (get_fpu_trap_exceptions, set_fpu_trap_exceptions,
support_fpu_trap, set_fpu_except_flags, support_fpu_flag,
support_fpu_rounding_mode, get_fpu_state, set_fpu_state): New
prototypes.
* config/fpu-*.h (get_fpu_trap_exceptions,
set_fpu_trap_exceptions, support_fpu_trap, set_fpu_except_flags,
support_fpu_flag, support_fpu_rounding_mode, get_fpu_state,
set_fpu_state): New functions.
* ieee/ieee_features.F90: New file.
* ieee/ieee_exceptions.F90: New file.
* ieee/ieee_arithmetic.F90: New file.
* ieee/ieee_helper.c: New file.

gcc/testsuite/
* lib/target-supports.exp (check_effective_target_fortran_ieee): 
New function.
* gfortran.dg/ieee/ieee.exp: New file.
* gfortran.dg/ieee/ieee_1.F90: New file.
* gfortran.dg/ieee/ieee_2.f90: New file.
* gfortran.dg/ieee/ieee_3.f90: New file.
* gfortran.dg/ieee/ieee_4.f90: New file.
* gfortran.dg/ieee/ieee_5.f90: New file.
* gfortran.dg/ieee/ieee_6.f90: New file.
* gfortran.dg/ieee/ieee_7.f90: New file.
* gfortran.dg/ieee/ieee_rounding_1.f90: New file.


Added:
trunk/gcc/testsuite/gfortran.dg/ieee/
trunk/gcc/testsuite/gfortran.dg/ieee/ieee.exp
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_1.F90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_2.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_3.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_4.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_5.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_6.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_7.f90
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_rounding_1.f90
trunk/libgfortran/ieee/
trunk/libgfortran/ieee/ieee_arithmetic.F90
trunk/libgfortran/ieee/ieee_exceptions.F90
trunk/libgfortran/ieee/ieee_features.F90
trunk/libgfortran/ieee/ieee_helper.c
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/libgfortran.h
trunk/gcc/fortran/module.c
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in
trunk/libgfortran/config/fpu-387.h
trunk/libgfortran/config/fpu-aix.h
trunk/libgfortran/config/fpu-generic.h
trunk/libgfortran/config/fpu-glibc.h
trunk/libgfortran/config/fpu-sysv.h
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/configure.host
trunk/libgfortran/gfortran.map
trunk/libgfortran/libgfortran.h

[Bug c++/61637] C++ program does not catch exceptions on AIX 7.1

2014-06-28 Thread daniel.kruegler at googlemail dot com

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

--- Comment #2 from Daniel Krügler  ---
As usual you need to provide a code example and the used compiler flags.

[Bug c++/60249] [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals

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

--- Comment #9 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
On 06/28/2014 10:03 AM, paolo.carlini at oracle dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
>
> --- Comment #8 from Paolo Carlini  ---
> Thanks, but in general I would recommend sending patches to gcc-patches in a
> separate email, with a clear [C++ Patch] or something similar in the subject.
> Also, please minimize jokes and other redundant content, we already have
> setious issues with lost patches, old bugs remaining umfixed for ages, etc,
> without.
>
Sorry about the noise.
Should I send a new cleaner message with new subject?

[Bug preprocessor/61638] New: "warning: multi-line comment" unclear and has false positives

2014-06-28 Thread zackw at panix dot com

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

Bug ID: 61638
Summary: "warning: multi-line comment" unclear and has false
positives
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com

The warning for a // comment continued on the next line by a backslash is
"warning: multi-line comment", which doesn't make a whole lot of sense if you
don't already know that this is a possibility. (Caret diagnostics help, but
the caret is in the wrong place: it points at the //, not the \.)

It also warns when the construct is harmless, e.g. because the next line has
another // comment on it: this naturally happens when someone feels like
drawing a tree

//A
// / \
// B C

This peeves people enough to write snarky comments like this (from
https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/test/unit/tests/graph.cc#L260
):

// This tests the nasty case described in the giant comment above
// get_uncommon_ancestors:
//
// 9
// |\ . Extraneous dots brought to you by the
// 8 \ . Committee to Shut Up the C Preprocessor
// /| \. (CSUCPP), and viewers like you and me.
/// | |
// (... ASCII art continues ...)

So I would like to suggest the following four improvements:

1) The warning message should be changed to "warning: backslash-newline
continues // comment onto the next line".
2) The caret should be corrected to point to the backslash, not the //.
3) The warning should be suppressed if the next line is blank or contains only
another // comment. (It should *not* be suppressed if the next line is blank
up to a /*, because that genuinely does change the meaning of the code.
4) "warning: backslash and newline separated by space" should not be suppressed
in // comments, because see bug 8270 for a whole bunch of people being very
confused why putting a space after the backslash in their ASCII art doesn't
make it not a backslash-newline. (It should still be suppressed in /*
comments.)

[Bug c++/60249] [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals

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

--- Comment #10 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
On 06/28/2014 10:03 AM, paolo.carlini at oracle dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
>
> --- Comment #8 from Paolo Carlini  ---
> Thanks, but in general I would recommend sending patches to gcc-patches in a
> separate email, with a clear [C++ Patch] or something similar in the subject.
> Also, please minimize jokes and other redundant content, we already have
> setious issues with lost patches, old bugs remaining umfixed for ages, etc,
> without.
>

Sorry about the noise.
Should I send a new cleaner message with new subject?

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

2014-06-28 Thread fxcoudert at gcc dot gnu.org

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.10.0

--- Comment #16 from Francois-Xavier Coudert  ---
This has now been fixed on trunk (4.10). Hurray!

[Bug fortran/20585] [meta-bug] Fortran 2003 support

2014-06-28 Thread fxcoudert at gcc dot gnu.org

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

Bug 29383 Summary: Fortran 2003/F95[TR15580:1999]: Floating point exception 
(IEEE) support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383

   What|Removed |Added

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

[Bug c++/61637] C++ program does not catch exceptions on AIX 7.1

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

--- Comment #3 from Krishnamoorthy C  ---
Compiler options tried:
---

CC= gcc
CXX=g++

Compilation flags
SYSCXXFLAGS= -Dlinux -Dlinux_x86_64 -DLINUX_AMD64 -O1 -maix64 -fpermissive
-Wextra -Wuninitialized -Winit-self -Wwrite-strings -Wall -Wno-switch
-Wno-missing-braces
CFLAGS= $(SYSCXXFLAGS) -fPIC -c  $(HEADER_PATH) $(LIBRARY_PATH)
Also tried with the different path for std library
STD_LIBRARY_PATH=-L/opt/freeware/lib64 -L/usr/lib
-L/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.8.1/ppc64

Linker flags
$(CXX) -shared -fPIC -maix64 $(CPPOBJECTS) $(COBJECTS) -o $@ -ldl -lpthread
-lbsd $(LIBRARY_PATH) $(CATALYST_LIBS)
$(CC) -shared -fPIC -maix64 $(CPPOBJECTS) $(COBJECTS) -o $@ -ldl -lpthread
-lbsd $(LIBRARY_PATH) $(CATALYST_LIBS)

Also tried with  -Wl,-brtl  , -fexeptions, -Xlinker -bM:SRE -Xlinker -bnoentry
$
Tried with the static libgcc -static-libgcc

[Bug c++/61637] C++ program does not catch exceptions on AIX 7.1

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

--- Comment #4 from Krishnamoorthy C  ---
The symptoms are as follows: 

1. Any exception thrown ( whether a empty throw or a number or a class object )
never reaches the catch

this is happening across the code base, always, i.e. none of the catch
statements are catching anything thrown.

- Krishna

[Bug c++/61637] C++ program does not catch exceptions on AIX 7.1

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

--- Comment #5 from Krishnamoorthy C  ---
// Throw and catch not working

#include 
using namespace std;

int main () {
  try
  {
throw 20;
  }
  catch (int e)
  {
cout << "This is not caught " << e << '\n';
  }
catch (...)
{
cout << "This is not caught " << e << '\n';
}

  return 0;
}

I hope this information is sufficient enough.
-Krishna

[Bug tree-optimization/54742] Switch elimination in FSM loop

2014-06-28 Thread spop at gcc dot gnu.org

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

Sebastian Pop  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #37 from Sebastian Pop  ---
Hi Jeff, can you fix this bug, or should I give it a try?
I know some folks who would be happy to have this coremark perf bug fixed in
trunk ;-)

Thanks,
Sebastian

(In reply to jgreenhalgh from comment #27)
> Created attachment 31308 [details]
> Dumps for less reduced testcase in comment 27
> 
> As of revision 205398, I'm not seeing this optimisation trigger when
> compiling the benchmark in question.
> 
> I've attached the dumps from a less agressively reduced version of the
> testcase given in the intial report, which we don't currently thread.
> 
> This testcase is more representative of the control structure in the
> benchmark code. In particular, we have the problematic scenario of two
> 'joiner' blocks in the thread path.
> 
> Looking at the dumps for this testcase I think that we would need to spot
> threads like:
> 
>   (17, 23) incoming edge; (23, 4) joiner; (4, 5) joiner; (5, 8) back-edge;
> (8, 15) switch-statement;
> 
> The testcase I am using is:
> 
> ---
> 
> int sum0, sum1, sum2, sum3;
> int foo(char * s, char** ret)
> {
>   int state=0;
>   char c;
> 
>   for (; *s && state != 4; s++)
> {
>   c = *s;
>   if (c == '*')
>   {
> s++;
> break;
>   }
>   switch (state) {
>   case 0:
> if (c == '+') state = 1;
> else if (c != '-') sum0+=c;
> break;
>   case 1:
> if (c == '+') state = 2;
> else if (c == '-') state = 0;
> else sum1+=c;
> break;
>   case 2:
> if (c == '+') state = 3;
> else if (c == '-') state = 1;
> else sum2+=c;
> break;
>   case 3:
> if (c == '-') state = 2;
> else if (c == 'x') state = 4;
> break;
>   default:
> break;
>   }
> }
>   *ret = s;
>   return state;
> }

[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo

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

--- Comment #19 from Paolo Carlini  ---
As far as I can see the macros at the beginning of gnu.ver do not work as they
normally do in C/C++ code because __GXX_WEAK__ remains undefined. For now I'm
simply going to revert the whole thing, cleanup and fix for this, I don't have
enough time to get into the details of the issue.

[Bug lto/61635] LTO partitioner does not handle &&label in statics

2014-06-28 Thread andi-gcc at firstfloor dot org

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

--- Comment #4 from Andi Kleen  ---
Yes it uses -fno-toplevel-reordering to avoid the problems with the initializer
reordering.

I tried some workarounds for this, but nothing worked so far. Likely would need
a noreorder attribute.

[Bug c++/61639] New: GCC 4.7.4 can't longer compile clang

2014-06-28 Thread alp at rsu dot ru

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

Bug ID: 61639
   Summary: GCC 4.7.4 can't longer compile clang
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alp at rsu dot ru

After updating GCC from 4.7.3 to 4.7.4 I can't longer compile Clang 3.3 (or
3.4.1) on OpenIndiana (illumos distribution).

While linking clang-check I receive the following error:

llvm[5]: Compiling CIndexCodeCompletion.cpp for Release+Asserts build (PIC)
llvm[5]: Linking Release+Asserts executable clang-check (without symbols)
Undefined   first referenced
 symbol in file
vtable for clang::tooling::FrontendActionFactory*
clang::tooling::newFrontendActionFactory(clang_check::ClangCheckActionFactory*,
clang::tooling::SourceFileCallbacks*)::FrontendActionFactoryAdapter::ConsumerFactoryAdaptor
/export/home/alp/srcs/oi-userland/components/clang/build/i86/tools/clang/tools/clang-check/Release+Asserts/ClangCheck.o
ld: fatal: symbol referencing errors. No output written to
/export/home/alp/srcs/oi-userland/components/clang/build/i86/Release+Asserts/bin/clang-check
collect2: error: ld returned 1 exit status
make[5]: ***
[/export/home/alp/srcs/oi-userland/components/clang/build/i86/Release+Asserts/bin/clang-check]
Error 1
make[5]: Leaving directory
`/export/home/alp/srcs/oi-userland/components/clang/build/i86/tools/clang/tools/clang-check'
make[4]: *** [clang-check/.makeall] Error 2

Everything works with GCC 4.7.3


$ gcc -v 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc/4.7/lib/gcc/i386-pc-solaris2.11/4.7.4/lto-wrapper
Target: i386-pc-solaris2.11
Configured with:
/export/home/alp/srcs/oi-userland/components/gcc47/gcc-4.7.4/configure
CC=/usr/gcc/4.7/bin/gcc CXX=/usr/gcc/4.7/bin/g++ F77=/usr/gcc/4.7/bin/gfortran
FC=/usr/gcc/4.7/bin/gfortran CFLAGS='-g -O2' CXXFLAGS=' ' FFLAGS=' ' FCFLAGS=
LDFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig --prefix=/usr/gcc/4.7
--mandir=/usr/gcc/4.7/share/man --bindir=/usr/gcc/4.7/bin
--libdir=/usr/gcc/4.7/lib --sbindir=/usr/gcc/4.7/sbin
--sbindir=/usr/gcc/4.7/bin --libdir=/usr/gcc/4.7/lib
--libexecdir=/usr/gcc/4.7/lib --host i386-pc-solaris2.11 --build
i386-pc-solaris2.11 --target i386-pc-solaris2.11
--with-boot-ldflags=-R/usr/gcc/4.7/lib --enable-plugins --enable-objc-gc
--enable-languages=c,c++,fortran,lto,objc --enable-ld=no
--with-build-time-tools=/usr/gnu/i386-pc-solaris2.11/bin --disable-libitm
--with-gnu-as --with-as=/usr/bin/gas LDFLAGS=-R/usr/gcc/4.7/lib
Thread model: posix
gcc version 4.7.4 (GCC)

[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo

2014-06-28 Thread paolo at gcc dot gnu.org

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

--- Comment #20 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Jun 28 15:53:30 2014
New Revision: 212104

URL: https://gcc.gnu.org/viewcvs?rev=212104&root=gcc&view=rev
Log:
2014-06-28  Paolo Carlini  

Revert:
2014-06-18  Paolo Carlini  
Ramana Radhakrishnan  

PR libstdc++/61536
* config/abi/pre/gnu.ver: Adjust for out of line comparisons.

2014-06-08  Paolo Carlini  

* config/abi/pre/gnu.ver: Tighten some patterns; tidy.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver

[Bug lto/61635] LTO partitioner does not handle &&label in statics

2014-06-28 Thread andi-gcc at firstfloor dot org

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

--- Comment #5 from Andi Kleen  ---
Also I forgot to state: the git tree above now has a workaround
(disabling LTO for that file). If you want to reproduce revert the latest
commit first.

[Bug target/61637] C++ program does not catch exceptions on AIX 7.1

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 CC||dje at gcc dot gnu.org
  Component|c++ |target
 Ever confirmed|1   |0

--- Comment #6 from Paolo Carlini  ---
Certainly exceptions generally work on other targets.

[Bug target/61637] C++ program does not catch exceptions on AIX 7.1

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

--- Comment #7 from Krishnamoorthy C  ---
Hi Paolo - S0orry , not in this case. The last few days were spent in playing
with the compiler options, but none seem to work. None of the throws are being
caught. 

When you say certain exceptions work on other targets, could you please
elaborate?

[Bug target/61637] C++ program does not catch exceptions on AIX 7.1

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

--- Comment #8 from Paolo Carlini  ---
Something else besides AIX 7.1. Fore sure all the Linux targets are fine, for
example. This isn't a generic C++ front-end issue.

[Bug c++/61639] GCC 4.7.4 can't longer compile clang

2014-06-28 Thread alp at rsu dot ru

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

--- Comment #1 from Alexander Pyhalov  ---
LLVM developers confirmed the issue exists on OSX whith gcc 4.7.4 (but not
4.8/4.9).

[Bug target/17277] [AIX] could not catch an exception when specified -maix64

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

Krishnamoorthy C  changed:

   What|Removed |Added

 CC||chandrakm at hotmail dot com

--- Comment #6 from Krishnamoorthy C  ---
The exact same code/application compiles and runs fine on multiple OS's ( HP
UX, Windows , Red Hat etc ) , i am seeing the problem only on AIX 7.1

But when you say this problem could be something other than AIX 7.1, could it
be the environment variables, or a mismatch in the shared libs used. Btw, a
shared lib , compiled with gcc on AIX 7.1, but in C language is also being
used. 

Would you suggest using a lower verion of the gcc compiler what we used?

[Bug target/61637] C++ program does not catch exceptions on AIX 7.1

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

--- Comment #9 from Krishnamoorthy C  ---
(In reply to Paolo Carlini from comment #8)
> Something else besides AIX 7.1. Fore sure all the Linux targets are fine,
> for example. This isn't a generic C++ front-end issue.

The program works fine on all other OS's ( HP UX, Linux and WIndows ) except
AIX 7.1 . Do you think using a lower gcc compiler version might help.

thanks and regards,
Krishna

[Bug libfortran/61640] New: KIND=4 Character Array Internal Unit Read Fail

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

Bug ID: 61640
   Summary: KIND=4 Character Array Internal Unit Read Fail
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: jvdelisle at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org

The following fails on the read. Found while working on another bug.

program read_internal
  integer :: x(9),i,iostat
  character(len=512) :: iomsg
  character(kind=4,len=30), dimension(3) :: source

  source=[4_"  1   1  -1",4_"  1  -1   1",4_" -1   1   1"]
  print *, (trim(source(i)), i=1,3)
  read(source,*) (x(i), i=1,6) ! This read fails for KIND=4 character
end program read_internal

The fix is:

Index: list_read.c
===
--- list_read.c(revision 212104)
+++ list_read.c(working copy)
@@ -273,7 +273,7 @@ next_char_internal (st_parameter_dt *dtp)
   /* Get the next character and handle end-of-record conditions.  */

   if (dtp->common.unit) /* Check for kind=4 internal unit.  */
-   length = sread (dtp->u.p.current_unit->s, &c, sizeof (gfc_char4_t));
+   length = sread (dtp->u.p.current_unit->s, &c, 1);
   else
{
  char cc;
Index: unix.c
===
--- unix.c(revision 212104)
+++ unix.c(working copy)
@@ -808,10 +808,10 @@ mem_read4 (stream * s, void * buf, ssize_t nbytes)
   void *p;
   int nb = nbytes;

-  p = mem_alloc_r (s, &nb);
+  p = mem_alloc_r4 (s, &nb);
   if (p)
 {
-  memcpy (buf, p, nb);
+  memcpy (buf, p, nb * 4);
   return (ssize_t) nb;
 }
   else

[Bug c++/51400] [c++0x] ICE with constexpr and attribute noreturn

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug target/61637] C++ program does not catch exceptions on AIX 7.1

2014-06-28 Thread dje at gcc dot gnu.org

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

--- Comment #10 from David Edelsohn  ---
Exceptions had been working. There is no wholesale failure of exceptions in the
G++ testsuite.  I also don't know why you are defining macros for Linux and
AMD, or why you think that randomly adding linker options will help. I also
think library search order seems strange -- you should not need to change the
library search path and you should be linking with G++.

The more that you override defaults and add options, the less this is
considered a real bug. Fixing it by adding more options does not help.  And the
testcase is invalid.

[Bug libfortran/61640] KIND=4 Character Array Internal Unit Read Fail

2014-06-28 Thread dominiq at lps dot ens.fr

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-28
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed and it is fixed with the patch.

[Bug fortran/61632] memory corruption in Fortran RTL when writing formatted data

2014-06-28 Thread dominiq at lps dot ens.fr

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

--- Comment #3 from Dominique d'Humieres  ---
With the following reduced test

  program p
  CHARACTER(3), save :: ZTYP(3)
  DATA ZTYP /'XXX','YYY','ZZZ'/
  write(*,600,IOSTAT=iosa) 0.0,ZTYP
  if (iosta /= 0) print *, 'error'
  write(*,600,IOSTAT=iosa) 0.0,ZTYP
  if (iosta /= 0) print *, 'error'
 600  FORMAT(1PE13.5,4X,A3)
  end program p

valgrind reports

==95142== Memcheck, a memory error detector
==95142== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==95142== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==95142== Command: a.out
==95142== 
  0.0E+00XXX
 error
  0.0E+00XXX
==95142== Invalid write of size 8
==95142==at 0x1000DCF40: _gfortrani_format_error (in
/opt/gcc/gcc4.10w/lib/libgfortran.3.dylib)
==95142==by 0x6F66204C4145521F: ???
==95142==by 0x33206D6574692071: ???
==95142==by 0x6D726F66206E691F: ???
==95142==by 0x7274206465747460: ???
==95142==by 0x202C726566736E60: ???
==95142==by 0x5241484320746F66: ???
==95142==by 0xA5245544340: ???
==95142==by 0x32AAABA6: ???
==95142==  Address 0x7fff5f7adda9 is not stack'd, malloc'd or (recently) free'd
==95142== 
==95142== Invalid read of size 8
==95142==at 0x1000DCF45: _gfortrani_format_error (in
/opt/gcc/gcc4.10w/lib/libgfortran.3.dylib)
==95142==by 0x6F66204C4145521F: ???
==95142==by 0x33206D6574692071: ???
==95142==by 0x6D726F66206E691F: ???
==95142==by 0x7274206465747460: ???
==95142==by 0x202C726566736E60: ???
==95142==by 0x5241484320746F66: ???
==95142==by 0xA5245544340: ???
==95142==by 0x32AAABA6: ???
==95142==  Address 0x10045166c is not stack'd, malloc'd or (recently) free'd
==95142== 
==95142== 
==95142== Process terminating with default action of signal 11 (SIGSEGV)
==95142==  General Protection Fault
==95142==at 0x100298FC1: dyld_stub_binder (in /usr/lib/libSystem.B.dylib)
==95142==by 0x10013502F: ??? (in /opt/gcc/gcc4.10w/lib/libgfortran.3.dylib)
==95142==by 0x10013502F: ??? (in /opt/gcc/gcc4.10w/lib/libgfortran.3.dylib)
==95142==by 0x6F66204C4145521F: ???
==95142==by 0x33206D6574692071: ???
==95142==by 0x6D726F66206E691F: ???
==95142==by 0x7274206465747460: ???
==95142==by 0x202C726566736E60: ???
==95142==by 0x5241484320746F66: ???
==95142==by 0xA5245544340: ???
==95142==by 0x4F: ???
==95142== 
==95142== HEAP SUMMARY:
==95142== in use at exit: 7,732 bytes in 21 blocks
==95142==   total heap usage: 23 allocs, 2 frees, 8,244 bytes allocated
==95142== 
==95142== LEAK SUMMARY:
==95142==definitely lost: 0 bytes in 0 blocks
==95142==indirectly lost: 0 bytes in 0 blocks
==95142==  possibly lost: 0 bytes in 0 blocks
==95142==still reachable: 7,644 bytes in 20 blocks
==95142== suppressed: 88 bytes in 1 blocks
==95142== Rerun with --leak-check=full to see details of leaked memory
==95142== 
==95142== For counts of detected and suppressed errors, rerun with: -v
==95142== ERROR SUMMARY: 380 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault

[Bug lto/61635] LTO partitioner does not handle &&label in statics

2014-06-28 Thread hubicka at ucw dot cz

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

--- Comment #6 from Jan Hubicka  ---
> Yes it uses -fno-toplevel-reordering to avoid the problems with the 
> initializer
> reordering.
> 
> I tried some workarounds for this, but nothing worked so far. Likely would 
> need
> a noreorder attribute.

Actually I think other chance to make this to fail is when the address/value of
the local static
is propagated by ipa-prop into some extra function...

Perhaps as a workaround in 4.9 we may disable such a propagation.
Honza

[Bug libfortran/61640] KIND=4 Character Array Internal Unit Read Fail

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

--- Comment #2 from Jerry DeLisle  ---
One subtlety.  If I change the read to:

read(source,*) (x(i), i=1,9)  ! 9 instead of 6

I get an EOF with kind=4 but the read is OK with kind=1.

I am investigating this.  Probably yet another unrelated problem..

[Bug libfortran/61640] KIND=4 Character Array Internal Unit Read Fail

2014-06-28 Thread dominiq at lps dot ens.fr

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

--- Comment #3 from Dominique d'Humieres  ---
I also confirm comment 2.

[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason

2014-06-28 Thread felix at fontein dot de

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

--- Comment #4 from Felix Fontein  ---
I can confirm this bug for GCC 4.9.0 20140604 (prerelease).

[Bug rtl-optimization/61641] New: [4.9 Regression] undefined label in jump_table_data

2014-06-28 Thread danglin at gcc dot gnu.org

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

Bug ID: 61641
   Summary: [4.9 Regression] undefined label in jump_table_data
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

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

dave@mx3210:~/mesa-gcc$ g++ -fpreprocessed -fvisibility=hidden -g -O2 -Wformat
-Werror=format-security -Wall -Wall -fno-strict-aliasing -fno-builtin-memcmp
-MT opt_vectorize.lo -MD -MP -MF .deps/opt_vectorize.Tpo -c opt_vectorize.ii 
-fPIC -DPIC -o opt_vectorize.o
/tmp/ccGEh3f3.s: Assembler messages:
/tmp/ccGEh3f3.s:717: Error: can't resolve `.L71' {.text section} - `.L78'
{*UND* section}
/tmp/ccGEh3f3.s:718: Error: can't resolve `.L79' {.text section} - `.L78'
{*UND* section}
/tmp/ccGEh3f3.s:719: Error: can't resolve `.L72' {.text section} - `.L78'
{*UND* section}
/tmp/ccGEh3f3.s:720: Error: can't resolve `.L82' {.text section} - `.L78'
{*UND* section}
/tmp/ccGEh3f3.s:721: Error: can't resolve `.L72' {.text section} - `.L78'
{*UND* section}
/tmp/ccGEh3f3.s:722: Error: can't resolve `.L72' {.text section} - `.L78'
{*UND* section}
/tmp/ccGEh3f3.s:723: Error: can't resolve `.L72' {.text section} - `.L78'
{*UND* section}
/tmp/ccGEh3f3.s:724: Error: can't resolve `.L70' {.text section} - `.L78'
{*UND* section}

We have following RTL after barriers pass:

(jump_insn:TI 135 164 136 (parallel [
(set (pc)
(mem:SI (plus:SI (mult:SI (reg:SI 20 %r20 [orig:141 D.35077 ]
[141])
(const_int 4 [0x4]))
(label_ref 136)) [0  S4 A32]))
(clobber (reg:SI 21 %r21))
(clobber (reg:SI 22 %r22))
]) ../../../../src/glsl/opt_vectorize.cpp:224 193 {casesi32p}
 (expr_list:REG_DEAD (reg:SI 20 %r20 [orig:141 D.35077 ] [141])
(expr_list:REG_UNUSED (reg:SI 22 %r22)
(expr_list:REG_UNUSED (reg:SI 21 %r21)
(nil
 -> 136)
(code_label 136 135 295 78 "" [1 uses])
(insn 295 136 137 (const_int 1 [0x1]) -1
 (nil))
(jump_table_data 137 295 296 (addr_diff_vec:SI (label_ref:SI 136)
 [
(label_ref:SI 62)
(label_ref:SI 139)
(label_ref:SI 57)
(label_ref:SI 163)
(label_ref:SI 57)
(label_ref:SI 57)
(label_ref:SI 57)
(label_ref:SI 53)
]
(const_int 0 [0])
(const_int 0 [0])))
(insn 296 137 138 (const_int 2 [0x2]) -1
 (nil))
(barrier 138 296 53)

After dbr pass, we have:

(barrier 59 57 58)
(note 58 59 164 [bb 11] NOTE_INSN_BASIC_BLOCK)
(note 164 58 137 [bb 12] NOTE_INSN_BASIC_BLOCK)
(jump_table_data 137 164 296 (addr_diff_vec:SI (label_ref:SI 136)
 [
(label_ref:SI 62)
(label_ref:SI 139)
(label_ref:SI 57)
(label_ref:SI 163)
(label_ref:SI 57)
(label_ref:SI 57)
(label_ref:SI 57)
(label_ref:SI 53)
]
(const_int 0 [0])
(const_int 0 [0])))
(insn 296 137 138 (const_int 2 [0x2]) 211 {end_brtab}
 (nil))
(barrier 138 296 53)

The casesi jump and code_label 136 have been deleted, but not the
addr_diff_vec using code_label 136.

This results in the incorrect assembly code.

[Bug rtl-optimization/61641] [4.9 Regression] undefined label in jump_table_data

2014-06-28 Thread danglin at gcc dot gnu.org

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

--- Comment #1 from John David Anglin  ---
Created attachment 33028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33028&action=edit
opt_vectorize.ii.240r.barriers

[Bug rtl-optimization/61641] [4.9 Regression] undefined label in jump_table_data

2014-06-28 Thread danglin at gcc dot gnu.org

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

--- Comment #2 from John David Anglin  ---
Created attachment 33029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33029&action=edit
opt_vectorize.ii.241r.dbr

[Bug c++/61642] New: g++ confuses template member template function with template class

2014-06-28 Thread felix at fontein dot de

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

Bug ID: 61642
   Summary: g++ confuses template member template function with
template class
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix at fontein dot de

The following code does not compile under GCC 4.9.0 20140604 (prerelease):

-8<-8<-8<-
template struct X { };

template
void fCall(Ftype & f)
{
f.template X(); // compiler stops here, confuses f's 
  // member template X with the template
  // class X defined above  
}

// To be used like this:

struct F
{
template void X() { }
};

int main()
{
F f;
fCall(f);
}
-8<-8<-8<-

The error message:

$ g++ -Wall -Wextra t2.cpp -o t2
t2.cpp: In function ‘void fCall(Ftype&)’:
t2.cpp:6:22: error: wrong number of template arguments (2, should be 1)
 f.template X();
  ^
t2.cpp:1:29: error: provided for ‘template struct X’
 template struct X { };


$ g++ -v

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9-20140604/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-isl-version-check
--disable-cloog-version-check --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.0 20140604 (prerelease) (GCC)

[Bug libfortran/61640] KIND=4 Character Array Internal Unit Read Fail

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

--- Comment #4 from Jerry DeLisle  ---
Full patch submitted to gfortran list. The problem found in this PR was masking
a problem in eat_spaces for KIND=4.  Was missing some parenthesis for the
indexing into the internal unit.

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-06-28 Thread tromey at gcc dot gnu.org

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

--- Comment #25 from Tom Tromey  ---
(In reply to Manuel López-Ibáñez from comment #24)

> There is a patch for GCC that was basically approved in January:
> https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01284.html
> 
> I am not sure why it hasn't been committed yet.

I'm going to submit the fixed up version this week.

[Bug libfortran/61640] KIND=4 Character Array Internal Unit Read Fail