[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330 --- Comment #5 from wangzheyu --- (In reply to Richard Biener from comment #1) > Seems the parser fails to set DECL_HARD_REGISTER on that bogus decl. Hi Richard, I find that in function make_decl_rtl(gcc/varasm.c:1357), there's one line comment:

[Bug fortran/61767] ICE in generate_finalization_wrapper at fortran/class.c:1491

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61767 Reuben Budiardja changed: What|Removed |Added Severity|critical|normal

[Bug fortran/61767] New: ICE in generate_finalization_wrapper at fortran/class.c:1491

x-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc/4.10 --enable-languages=c,fortran,c++ --disable-multilib Thread model: posix gcc version 4.10.0 20140709 (experimental) (GCC) "svn info" of the gcc source code shows Revis

[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743 --- Comment #4 from Jonathan Wakely --- (In reply to Phil Miller from comment #2) > Does the committee need another nudge on this point, as practice has shifted? I don't believe practice has shifted. The difference in GCC's behaviour is probably

[Bug fortran/56789] Wrong code with contiguous dummy argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 --- Comment #4 from Sean Santos --- Oops, I mean a free() error as in comment 0, not a segfault.

[Bug fortran/56789] Wrong code with contiguous dummy argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 Sean Santos changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #3

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097 --- Comment #33 from Jonathan Wakely --- Write a plugin. It's trivial using gcc-python-plugin, see http://blog.cuviper.com/2014/01/23/add-new-warnings-to-gcc-with-python/ A custom plugin is far more suitable to your purpose than adding yet anoth

[Bug fortran/61766] [4.9 regression] ICE on trans-array.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61766 --- Comment #1 from Jürgen Reuter --- Created attachment 33097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33097&action=edit Code that triggers the ICE

[Bug fortran/61766] New: [4.9 regression] ICE on trans-array.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61766 Bug ID: 61766 Summary: [4.9 regression] ICE on trans-array.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran

[Bug fortran/61765] [4.9/4.10 Regression] Rejects valid BIND(C) ENTRY

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61765 Dominique d'Humieres changed: What|Removed |Added Summary|Rejects valid BIND(C) ENTRY |[4.9/4.10 Regression]

[Bug c++/60686] message " only declarations of constructors can be ‘explicit’ " now conflicting with C++11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60686 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/60686] message " only declarations of constructors can be ‘explicit’ " now conflicting with C++11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60686 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jul 9 22:44:42 2014 New Revision: 212415 URL: https://gcc.gnu.org/viewcvs?rev=212415&root=gcc&view=rev Log: /cp 2014-07-09 Paolo Carlini PR c++/60686 * decl.c

[Bug c++/56908] Spurious warning when XOR-ing uint8_t values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56908 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/35031] ELEMENTAL procedure with BIND(C)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35031 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org -

[Bug fortran/61765] Rejects valid BIND(C) ENTRY

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61765 Francois-Xavier Coudert changed: What|Removed |Added Keywords||rejects-valid Stat

[Bug fortran/61765] New: Rejects valid BIND(C) ENTRY

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61765 Bug ID: 61765 Summary: Rejects valid BIND(C) ENTRY Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran As

[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743 --- Comment #3 from Phil Miller --- The latest release of Microsoft Visual C++ (per the version available at http://rise4fun.com/Vcpp) now accepts this code without complaint. Cray compilers version 8.2 and onwards also accept this code. As of

[Bug libstdc++/61728] [4.10 regression] lost symbol FUNC:_ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj@@CXXABI_1.3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61728 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/61728] [4.10 regression] lost symbol FUNC:_ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj@@CXXABI_1.3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61728 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Jul 9 22:21:49 2014 New Revision: 212413 URL: https://gcc.gnu.org/viewcvs?rev=212413&root=gcc&view=rev Log: PR libstdc++/61728 * libsupc++/cxxabi.h: Define __pbase_type_info:

[Bug libstdc++/61728] [4.10 regression] lost symbol FUNC:_ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj@@CXXABI_1.3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61728 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned a

[Bug c++/57743] Code accepted by other recent compilers, but not by g++ - possibly failure to activate ADL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743 --- Comment #2 from Phil Miller --- I just went to look at this in more detail, and I'm not sure how to interpret what I've found. If the DR in question in 225 (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#225), following from 197,

[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/57465] Failed postcondition for std::function constructed with null function pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57465 Bug 57465 depends on bug 57466, which changed state. Bug 57466 Summary: [DR 1584] Argument deduction fails for 'const T*' when T is function type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466 What|Removed

[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jul 9 21:23:06 2014 New Revision: 212410 URL: https://gcc.gnu.org/viewcvs?rev=212410&root=gcc&view=rev Log: /cp 2014-07-09 Paolo Carlini DR 1584 PR c++/57466

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097 Phil Miller changed: What|Removed |Added CC||unmobile at gmail dot com --- Comment #32

[Bug c++/59800] Compilation with g++ fails when -Ofast -flto is used to compile code using some distribution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59800 Manuel López-Ibáñez changed: What|Removed |Added Status|WAITING |NEW CC|

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Dominique d'Humieres changed: What|Removed |Added CC||us15 at os dot inf.tu-dresden.de

[Bug bootstrap/61764] gcc fails to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61764 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug bootstrap/61764] gcc fails to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61764 --- Comment #1 from Udo Steinberg --- This is with SVN version 212406.

[Bug bootstrap/61764] New: gcc fails to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61764 Bug ID: 61764 Summary: gcc fails to build Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee:

[Bug c++/59800] Compilation with g++ fails when -Ofast -flto is used to compile code using some distribution

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59800 --- Comment #3 from Matteo Riondato --- What exactly does the "WAITING" status mean?

[Bug bootstrap/61763] New: [4.9 Regression] gcc-4.9.0 "Bootstrap comparison failure!"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763 Bug ID: 61763 Summary: [4.9 Regression] gcc-4.9.0 "Bootstrap comparison failure!" Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Pri

[Bug middle-end/61762] New: failure to optimize memcpy from constant string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 Bug ID: 61762 Summary: failure to optimize memcpy from constant string Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/61760] -Wconversion inconsistency between gcc and g++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61760 --- Comment #2 from Manuel López-Ibáñez --- I see now that the C FE has a FE optimization (short_shift in build_binary_op) that the C++ FE doesn't have. The optimization is probably useless for code generation, but for improving -Wconversion, it

[Bug c++/61760] -Wconversion inconsistency between gcc and g++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61760 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug libstdc++/61761] New: [C++11] std::proj returns incorrect values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761 Bug ID: 61761 Summary: [C++11] std::proj returns incorrect values Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libs

[Bug c++/61760] New: -Wconversion inconsistency between gcc and g++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61760 Bug ID: 61760 Summary: -Wconversion inconsistency between gcc and g++ Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c+

[Bug c/61741] wrong code by LTO on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61741 Richard Biener changed: What|Removed |Added Component|lto |c Known to work|

[Bug c/61741] wrong code by LTO on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61741 Richard Biener changed: What|Removed |Added Component|lto |c Known to work|

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754 emsr at gcc dot gnu.org changed: What|Removed |Added CC||emsr at gcc dot gnu.org

[Bug target/59843] ICE with return of generic vector on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 --- Comment #10 from Alan Lawrence --- I can confirm that prior to V1DFmode, all four of those cases gave an ICE (in emit_move_insn, via a variety of routes).

[Bug c++/61057] [C++11] operator . considered part of User Defined Literal invocation.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61057 --- Comment #3 from emsr at gcc dot gnu.org --- Leaving a space before the dot also works.

[Bug c++/61057] [C++11] operator . considered part of User Defined Literal invocation.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61057 emsr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/59843] ICE with return of generic vector on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 --- Comment #9 from Jakub Jelinek --- I've been just concerned, many backends derive (perhaps incorrectly) passing conventions from DECL_MODE or TYPE_MODE and so any changes in that are a red flag to me. If passing as arguments and returning the

[Bug target/59843] ICE with return of generic vector on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 Alan Lawrence changed: What|Removed |Added CC||alan.lawrence at arm dot com --- Comment

[Bug c++/58155] -Wliteral-suffix warns about tokens which are skipped by preprocessor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58155 emsr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/58155] -Wliteral-suffix warns about tokens which are skipped by preprocessor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58155 --- Comment #3 from emsr at gcc dot gnu.org --- Author: emsr Date: Wed Jul 9 15:10:43 2014 New Revision: 212393 URL: https://gcc.gnu.org/viewcvs?rev=212393&root=gcc&view=rev Log: libcpp/ 2014-07-09 Edward Smith-Rowland <3dw...@verizon.net>

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #32 from Tom Tromey --- (In reply to Tom Tromey from comment #31) > force, adddress_space, and noderef are the final 5 commits on the branch. Err, 8 commits.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #31 from Tom Tromey --- (In reply to Tom Tromey from comment #28) > > Please let me know what I can do to help complete this branch. I'd be happy > > to help write the documentation, for instance. > > It's maybe not quite ready for

[Bug c++/58155] -Wliteral-suffix warns about tokens which are skipped by preprocessor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58155 --- Comment #2 from emsr at gcc dot gnu.org --- Author: emsr Date: Wed Jul 9 13:33:58 2014 New Revision: 212392 URL: https://gcc.gnu.org/viewcvs?rev=212392&root=gcc&view=rev Log: libcpp/ 2014-07-09 Edward Smith-Rowland <3dw...@verizon.net>

[Bug objc++/61759] internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 --- Comment #3 from Douglas Mencken --- Created attachment 33095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33095&action=edit preprocessed builder.cxx Attaching preprocessed builder.cxx (builder.mii)

[Bug objc++/61759] internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 --- Comment #2 from Douglas Mencken --- Also, there's builder.cxx (one of files which compiles after removing -x objective-c++ from line, but not with it): S=/lo-build && I=$S/instdir && W=$S/workdir && mkdir -p $W/CxxObject/vcl/source/window/

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #4 from Andreas Schwab --- This also breaks gcc.dg/tree-ssa/20030922-2.c on m68k.

[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 --- Comment #5 from Jonathan Wakely --- (In reply to Martin von Gagern from comment #4) > (In reply to Jonathan Wakely from comment #2) > > It is totally unsupported (and unlikely to work) to mix C++11 code built > > with GCC 4.x and 4.y, for any

[Bug objc++/61759] internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 --- Comment #1 from Douglas Mencken --- Created attachment 33094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33094&action=edit preprocessed a11yselectionwrapper.mm Attaching preprocessed a11yselectionwrapper.mm (a11yselectionwrapper.mii

[Bug objc++/61759] New: internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 Bug ID: 61759 Summary: internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2792 Product: gcc Version: 4.8.3 Status: UNCONFIRMED

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Andreas Schwab changed: What|Removed |Added CC||rguenther at suse dot de Compo

[Bug target/61756] arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot

[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 --- Comment #4 from Martin von Gagern --- Thanks for the quick reply. (In reply to Jonathan Wakely from comment #2) > It is totally unsupported (and unlikely to work) to mix C++11 code built > with GCC 4.x and 4.y, for any x!=y Any particular r

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725 Marat Zakirov changed: What|Removed |Added CC||joseph at codesourcery dot com,

[Bug lto/61741] wrong code by LTO on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61741 --- Comment #4 from Richard Biener --- The testcase fails without LTO as well if you use -Os -fno-strict-overflow, fixed by -fno-tree-vrp (not necessarily caused by it though). Also fails with -O2 -fno-strict-overflow. Smells similar to PR61184

[Bug bootstrap/61757] [4.10 Regression] genmodes failure with enable-checking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Richard Biener changed: What|Removed |Added Keywords||build Priority|P3

[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3

[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 --- Comment #2 from Jonathan Wakely --- It is totally unsupported (and unlikely to work) to mix C++11 code built with GCC 4.x and 4.y, for any x!=y Mixing code built with 4.8.x and 4.8.y should work, and does with the default configuration. You

[Bug target/59843] ICE with return of generic vector on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 --- Comment #7 from Jakub Jelinek --- Isn't even this change ABI changing? I know you ICE when returning such vectors, but doesn't the change from BLKmode to V1DFmode change how such vars are laid out in structures, or passed in as arguments, or

[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 --- Comment #1 from Martin von Gagern --- I just read https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01553.html indicating that this is likely a deliberate ABI breakage for an experimental API. If that is your official position, feel free to close

[Bug bootstrap/61757] genmodes failure with enable-checking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||aarch64-linux, x86, ia64

[Bug target/52435] ICE in arm_select_dominance_cc_mode, at config/arm/arm.c:10625

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52435 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug target/61756] arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code

[Bug target/49423] [4.8/4.9/4.10 Regression] [arm] internal compiler error: in push_minipool_fix

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|

[Bug target/49423] [4.8/4.9/4.10 Regression] [arm] internal compiler error: in push_minipool_fix

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org

[Bug target/43999] Gcc (lib1funcs.asm) doesn't build on ARM/Thumb2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43999 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC

[Bug libstdc++/61758] New: std::chrono::steady_clock::now() no longer exported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 Bug ID: 61758 Summary: std::chrono::steady_clock::now() no longer exported Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug testsuite/61453] [4.10 Regression]: gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61453 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug testsuite/61453] [4.10 Regression]: gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61453 --- Comment #3 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Wed Jul 9 09:01:06 2014 New Revision: 212387 URL: https://gcc.gnu.org/viewcvs?rev=212387&root=gcc&view=rev Log: 2014-07-09 Dominique d'Humieres PR testsuite/61453

[Bug bootstrap/61757] genmodes failure with enable-checking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/52412] another unnecessary register move on arm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52412 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC

[Bug target/46329] ICE on ARM for __attribute__ ((vector_size (8 * sizeof(int)))) operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC

[Bug target/48183] ICE [arm] immed_double_const at emit-rtl.c (-mfpu=neon -g -O1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48183 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC

[Bug c++/59361] cannot expand parenthesized pack expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/59361] cannot expand parenthesized pack expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jul 9 08:32:43 2014 New Revision: 212386 URL: https://gcc.gnu.org/viewcvs?rev=212386&root=gcc&view=rev Log: /cp 2014-07-09 Andrew Sutton Paolo Carlini PR

[Bug ipa/61602] [4.10 Regression] ICE in lto1 on x86_64-linux-gnu in ipa_single_use, at ipa.c:1257

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61602 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug bootstrap/61757] New: genmodes failure with enable-checking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Bug ID: 61757 Summary: genmodes failure with enable-checking Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap

[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #53 from Dmitry Vyukov --- If we instrument libgomp with tsan, this can introduce lots of extraneous synchronization which is useful only for verification of libgomp itself, but harmful for libgomp users (as it will lead to false posi

[Bug c/61756] New: arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61756 Bug ID: 61756 Summary: arm-none-eabi-gcc-4.10.0 internal compiler error with atomic_flag Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal

[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #52 from Joost VandeVondele --- (In reply to Jakub Jelinek from comment #51) > Your assumption is wrong, reductions are not handled in libgomp, but in the > code emitted by the compiler. does this imply that the combination of -fsa

[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #51 from Jakub Jelinek --- (In reply to Roland Schulz from comment #50) > I must say I don't know how the internals work. But I assume that reductions > are implemented in libgomp (I know they are in iomp). Thus for any code > which u