https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98048
H.J. Lu changed:
What|Removed |Added
Summary|ICE in |[11 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98048
Bug ID: 98048
Summary: ICE in build_vector_from_val, at tree.c:1985
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #15 from eggert at cs dot ucla.edu ---
(In reply to Andreas Schwab from comment #14)
> I don't follow. It works exactly the same way.
Let me try to explain further. In my comment #11, the first directive:
#warning "You are too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98046
--- Comment #2 from kargl at gcc dot gnu.org ---
> This problem was originally reported on
> https://www.linuxquestions.org/questions/linux-general-1/lock-in-libpthread-
> occurs-only-on-one-arch-installation-only-with-gcc-fortran-4175685889/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #17 from abebeos at lazaridis dot com ---
Things look well, me being on 2 parallel solution paths:
a) using https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c6 as a foundation.
b) focusing more on a from-scratch work (cc0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Dominique d'Humieres changed:
What|Removed |Added
CC||anthony.debeus at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98046
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98047
Bug ID: 98047
Summary: assignment does not drop qualifier as observed by
typeof
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Snapshot gcc-10-20201128 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20201128/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98029
Martin Uecker changed:
What|Removed |Added
CC||uecker at eecs dot berkeley.edu
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
--- Comment #5 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-November/055367.html
When substituting an array-valued character parameter variable, the call to
gfc_copy_expr returns character length 1. Fix up the resulting length.
I could not figure out whether this is a bug or a feature of gfc_copy_expr.
But the fix to simplify_parameter_variable would not do any harm in any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
Hi,
This patch adds necessary predefined version symbols and support for
moduleinfo sections for darwin to allow testing libphobos support.
OK for mainline?
Regards
Iain.
---
gcc/ChangeLog:
* config.gcc (*-*-darwin*): Set d_target_objs and target_has_targetdm.
* config/elfos.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
--- Comment #3 from anlauf at gcc dot gnu.org ---
Further reduced variant:
program p
implicit none
character(*), parameter :: exprs(1) = ['abc()']
print *, len (pack ( exprs , exprs(:)(:1) =='a'))
print *, len (pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98046
Bug ID: 98046
Summary: lock in libpthread occurs with gcc-fortran and
atlas-lapack
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #14 from Andreas Schwab ---
I don't follow. It works exactly the same way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #13 from eggert at cs dot ucla.edu ---
(In reply to Andreas Schwab from comment #12)
> > GCC already treats that case differently
>
> In which way?
A "#line" directive suppresses most of the duplication in later #warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #27 from Toon Moene ---
Yes, I am now convince this works (64 leads to stop 1, but 63 works).
Note that I slightly changed the program today, to add a sync all before the
forecasting loop, and adding one to the copy_local_to_global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #12 from Andreas Schwab ---
> GCC already treats that case differently
In which way?
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
seen with trunk 20201128, building powerpc64le-linux-gnu, compiler configured
with a profiled bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #11 from eggert at cs dot ucla.edu ---
(In reply to Andreas Schwab from comment #10)
> See the #line directive.
GCC already treats that case differently, and it can continue to do so.
Come to think of it, GCC works better with #line
> On Nov 25, 2020, at 12:07 PM, Maciej W. Rozycki wrote:
>
> On Mon, 23 Nov 2020, Paul Koning wrote:
>
>>> ...
>
>> I've hacked together a primitive newlib based "bare metal" execution
>> test setup that uses SIMH, but it's not a particularly clean setup.
>> And it hasn't been posted, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98031
--- Comment #3 from Jakub Jelinek ---
The compiler just can't try to instantiate random templates it would think the
user may wanted to instantiate but didn't.
> On Nov 25, 2020, at 5:05 PM, Hans-Peter Nilsson wrote:
>
> On Tue, 24 Nov 2020, Eric Botcazou wrote:
>
>>> I'm intested in any notes, however vague, on that matter. I was
>>> a bit surprised to see that myself...that is, after fixing
>>> *some* related regressions, like the one in
Hi,
The bootstrap has been succeeding for some time now, there's no need to
set it as an unsupported language.
OK for mainline?
Regards
Iain.
---
ChangeLog:
PR d/87788
* configure.ac: Don't disable D for *-*-darwin*.
* configure: Regenerate.
---
configure| 3 ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #10 from Andreas Schwab ---
See the #line directive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94024
Jonathan Wakely changed:
What|Removed |Added
CC||gcc at linkmauve dot fr
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98044
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98044
--- Comment #1 from Jonathan Wakely ---
This is a dup of another bug, which has already been fixed for GCC 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #9 from eggert at cs dot ucla.edu ---
(In reply to Andreas Schwab from comment #8)
> That still doesn't handle the case when the source comes from a different
> place.
I don't know what you mean by "source comes from a different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #26 from Thomas Koenig ---
After 00c2e5d1c15c67fc2c9d9ed86bfa1f5aa13848cc ,
the segfault for too many images is now also fixed,
and your program runs as expected.
I'd say an important milestone has been reached :-)
Hi,
This patch adds the necessary version conditions and configure rules in
place to allow building the D compiler on FreeBSD.
Running the testsuite on both i386 and x86_64, all tests except for one
passes (gdc.test/runnable/test17338.d, though the problem appears to be
the linker producing a
This fixes an issue with nested structures and adds an Alignment clause to
counter the effect of the Pack aspect.
Tested on x86_64/Linux, applied on the mainline.
2020-11-28 Eric Botcazou
c-family/
* c-ada-spec.c (dump_nested_type) : Remove obsolete code.
(dump_ada_structure):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98044
Bug ID: 98044
Summary: Last line always highlighted as error in constructor
initializer list when another is bogus
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
This patch to the Go frontend marks bad types are erroneous, to avoid
generating further errors. This required some code using array types
to check for errors. This is for https://golang.org/issue/19880.
This requires updating one of the tests in the testsuite.
Bootstrapped and ran Go testsuite
This patch to the Go frontend gives a better error message when the
same variable is declared multiple times on the left hand side of a :=
statement.
Was
assign.go:59:28: error: multiple assignments to x
Now
assign.go:59:28: error: ‘x’ repeated on left side of :=
Bootstrapped and ran Go
Hello Jakub,
thanks a lot for taking this on!
As far as I can tell, the patch works very well, and really speeds up
things.
As (somewhat confusingly) discussed in the PR, there are a couple of
things that could still be done incrementally with this method.
Fist, it can be combined with, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95662
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98043
Bug ID: 98043
Summary: (Regression) ICE in verify_gimpl due to bitpacked enum
class (amd64)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98042
Bug ID: 98042
Summary: error diagnostic for unmatched parentheses could be
improved
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98031
--- Comment #2 from tangyixuan ---
(In reply to Jakub Jelinek from comment #1)
> This is again diagnostics on uninstantiated template, invalid, no
> diagnostics required.
> Instantiate the template and it will be diagnosed.
Yeah, I agree with
Am 27.11.20 um 00:50 schrieb Jonathan Wakely via Gcc:
Does anybody object to raising the line length for libstdc++ code
(not the rest of GCC) to 100 columns?
In gfortran, we have a habit of using long and expressive function
names (which is good) which lead to lots of columns of indentation,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |9.4
Status|ASSIGNED
I overlooked the little dance around 4096 that the add/sub instructions do on
the SPARC when implementing the overflow arithmetic operations. It cannot be
done for unsigned overflow, but it can be done for signed overflow. Tested on
SPARC64/Linux and SPARC/Solaris, applied on the mainline, 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #11 from CVS Commits ---
The releases/gcc-9 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:e6280f66297e5886a62dc5f1ae3c6b559868193b
commit r9-9078-ge6280f66297e5886a62dc5f1ae3c6b559868193b
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:25218e34136fb7f89dd1cbb72b2d920546031bfb
commit r10-9092-g25218e34136fb7f89dd1cbb72b2d920546031bfb
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #9 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:c04bd12b06a21ad4a9c432c109ec2a543725ad1b
commit r11-5511-gc04bd12b06a21ad4a9c432c109ec2a543725ad1b
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95662
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-11-28
Ever confirmed|0
Am 27.11.20 um 16:46 schrieb Tobias Burnus:
Hi Thomas,
On 25.11.20 12:58, Tobias Burnus wrote:
On 15.11.20 18:52, Thomas Koenig via Fortran wrote:
+#define ADD_CHAR(c) do { *fp++ = c; *fp++ = ' '; } while(0)
...
+ ADD_CHAR ('.'); /* Function return. */
Shouldn't this be ".c" instead of ".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98041
Bug ID: 98041
Summary: [11 Regression] libgo doesn't build on
mipsel-linux-gnu
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
(resending - this didn’t seem to reach gcc-patches@)
Jason Merrill wrote:
On Mon, Nov 23, 2020 at 8:52 AM Iain Sandoe wrote:
Jason Merrill wrote:
(NOTE: likewise, ^~~ starting indent is below ‘int’ for a fixed spacing
font)
===
I’m inclined to think that the second is more useful,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
--- Comment #11 from CVS Commits ---
The releases/gcc-9 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:2d9acb94cb78956b8451bc01cdda275926f6a1c2
commit r9-9077-g2d9acb94cb78956b8451bc01cdda275926f6a1c2
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:d1fbbc13b5ac04163f8eda30834dc090349df5f7
commit r10-9091-gd1fbbc13b5ac04163f8eda30834dc090349df5f7
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021
--- Comment #8 from Andreas Schwab ---
That still doesn't handle the case when the source comes from a different
place.
58 matches
Mail list logo
