[Bug ipa/92606] [8/9/10/11 Regression][avr] invalid merge of symbols in progmem and data sections

[Bug ipa/92606] [8/9/10/11 Regression][avr] invalid merge of symbols in progmem and data sections

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|marxin at gcc dot gnu.org          |unassigned at gcc dot gnu.org
             Status|ASSIGNED                    |NEW

[Bug ipa/92606] [9/10/11/12 Regression][avr] invalid merge of symbols in progmem and data sections

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug ipa/92606] [9/10/11/12 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug ipa/92606] [10/11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug ipa/92606] [10/11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug ipa/92606] [10/11/12/13/14 Regression][avr] invalid merge of symbols in progmem and data sections

[pinskia at gcc dot gnu.org]

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

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Georg-Johann Lay from comment #3)
> Created attachment 47485 [details]
> 123f.c: C test case with address space __flash.
> 
> ...and the code is also wrong with address spaces like __flash (and the same
> options like in comment #1):
> 
> $ avr-gcc -mmcu=atmega128 123f.c -flto -Os -save-temps -o 123f.elf

Note you don't need -flto if you change xyz be static.

[Bug ipa/92606] [10/11/12/13/14 Regression][avr] invalid merge of symbols in progmem and data sections

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is a x86_64 testcase:
```
typedef __UINT16_TYPE__ T;

#define NI __attribute__((noinline,noclone,no_icf))

static const __seg_fs T xyz_prog[] = { 123, 123, 123 };
static __seg_gs T xyz[] = { 123, 123, 123 };
volatile int x = 0;

NI void prf (T f)
{
    if (f != 123)
        __builtin_abort();
}

NI void func_progmem()
{
    prf(xyz_prog[x]);
}

NI void func_ram()
{
    prf(xyz[x]);
}

int main()
{
    func_progmem();
    func_ram();
}
```

We get:
        movzwl  %fs:xyz_prog(%rax,%rax), %edi
...
        movzwl  %gs:xyz(%rax,%rax), %edi
...
        .section        .rodata
        .align 2
        .type   xyz_prog, @object
        .size   xyz_prog, 6
xyz_prog:
        .value  123
        .value  123
        .value  123
        .set    xyz,xyz_prog

Maybe for x86_64, it is less of an issue because the fs/gs address space
overlap with the main address space.

[Bug ipa/92606] [11/12/13/14 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug ipa/92606] [11/12/13/14 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
I have a patch.

[Bug ipa/92606] [11/12/13/14 Regression][avr] invalid merge of symbols in progmem and data sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:1e6c4aa47972d6b56225e7776f3cf41f2cc01da2

commit r14-6183-g1e6c4aa47972d6b56225e7776f3cf41f2cc01da2
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Dec 5 13:56:10 2023 +0100

    ipa/92606 - IPA ICF merging variables in different address-space

    The following aovids merging variables that are put in different
    address-spaces.

            PR ipa/92606
            * ipa-icf.cc (sem_variable::equals_wpa): Compare address-spaces.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13/14                |[11/12/13 Regression][avr]
                   |Regression][avr] invalid    |invalid merge of symbols in
                   |merge of symbols in progmem |progmem and data sections
                   |and data sections           |
      Known to work|                            |14.0

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
Should be fixed on trunk.  Confirmation would be nice (checked x86 only).

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[gjl at gcc dot gnu.org]

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

--- Comment #23 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #22)
> Should be fixed on trunk.  Confirmation would be nice (checked x86 only).

For AVR, this does not fix the attribute progmem case (for which it was
originally reported, because that's an attribute and not an address-space.

progmem is still in wide use:

* C++, because g++ does not implement address-spaces (as opposed to
clang/llvm).

* Existing code that uses progmem, which is supposed to work.

* Not all uses cases of progmem can be converted to address-spaces (PR84163),
  e.g. locating literals in program memory like in
      printf_P (PSTR ("Format string in flash: %d\n"), int_value);
      #define PSTR(s) \
          (__extension__({
              static const char __c[] PROGMEM = (s);
              &__c[0];
          }))

A solution would be a target hook like proposed in PR92932.

Or switch off -fno-ipa-icf-variables per default for AVR. Less optimal code is
still better than wrong code...

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[gjl at gcc dot gnu.org]

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

--- Comment #24 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #22)
> Should be fixed on trunk.  Confirmation would be nice (checked x86 only).

Tested with: gcc version 14.0.0 20231210 (experimental) (GCC)

Still fails for the progmem test case from above. It still has
.set    xyz,xyz_prog


typedef __UINT16_TYPE__ uint16_t;
typedef __UINT32_TYPE__ uint32_t;

typedef uint32_t T;

#define read_u32(X)                                                     \
    (__extension__(                                                     \
        {                                                               \
            uint16_t __addr16 = (uint16_t)(X);                          \
            uint32_t __result;                                          \
            __asm__ __volatile__ ("lpm %A0, Z+" "\n\t"                  \
                                  "lpm %B0, Z+" "\n\t"                  \
                                  "lpm %C0, Z+" "\n\t"                  \
                                  "lpm %D0, Z" "\n\t"                   \
                                  : "=r" (__result), "+z" (__addr16));  \
            __result;                                                   \
        }))

#define NI __attribute__((noinline,noclone))

__attribute((progmem))
static const T xyz_prog[] = { 123, 123, 123 };

static T xyz[] = { 123, 123, 123 };

volatile int x = 0;

NI void prf (T f)
{
    if (f != 123)
        __builtin_abort();
}

NI void func_progmem()
{
    prf (read_u32 (& xyz_prog[0]));
}

NI void func_ram()
{
    prf (xyz[x]);
}

int main()
{
    func_progmem();
    func_ram();
}

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
I see.  The relevant code to patch is still sem_variable::equals_wpa I think,
which doesn't compare any of the decls (or their types) attributes.

Note there is the "no_icf" attribute, maybe defining PROGMEM as also
setting that attribute works?

I wonder if it would be possible to set the appropriate address-space when
parsing the "progmem" attribute in the target?

For ICF (or more generally IPA) there's comp_type_attributes which
we already check and which dispatches to target code.  We're also
rejecting differing DECL_ATTRIBUTES:

  /* Merging two definitions with a reference to equivalent vtables, but
     belonging to a different type may result in ipa-polymorphic-call analysis
     giving a wrong answer about the dynamic type of instance.  */
  if (is_a <varpool_node *> (n1))
    {
...
      /* For functions we compare attributes in equals_wpa, because we do
         not know what attributes may cause codegen differences, but for
         variables just compare attributes for references - the codegen
         for constructors is affected only by those attributes that we lower
         to explicit representation (such as DECL_ALIGN or DECL_SECTION).  */
      if (!attribute_list_equal (DECL_ATTRIBUTES (n1->decl),
                                 DECL_ATTRIBUTES (n2->decl)))
        return return_false_with_msg ("different var decl attributes");
      if (comp_type_attributes (TREE_TYPE (n1->decl),
                                TREE_TYPE (n2->decl)) != 1)
        return return_false_with_msg ("different var type attributes");

so I wonder what happens here?  Does AVR not actually add the progmem
attribute?

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> For ICF (or more generally IPA) there's comp_type_attributes which
> we already check and which dispatches to target code.  We're also
> rejecting differing DECL_ATTRIBUTES:
> 
>   /* Merging two definitions with a reference to equivalent vtables, but
>      belonging to a different type may result in ipa-polymorphic-call
> analysis
>      giving a wrong answer about the dynamic type of instance.  */
>   if (is_a <varpool_node *> (n1))
>     {
> ...
>       /* For functions we compare attributes in equals_wpa, because we do
>          not know what attributes may cause codegen differences, but for
>          variables just compare attributes for references - the codegen
>          for constructors is affected only by those attributes that we lower
>          to explicit representation (such as DECL_ALIGN or DECL_SECTION).  */
>       if (!attribute_list_equal (DECL_ATTRIBUTES (n1->decl),
>                                  DECL_ATTRIBUTES (n2->decl)))
>         return return_false_with_msg ("different var decl attributes");
>       if (comp_type_attributes (TREE_TYPE (n1->decl),
>                                 TREE_TYPE (n2->decl)) != 1)
>         return return_false_with_msg ("different var type attributes");
> 
> so I wonder what happens here?  Does AVR not actually add the progmem
> attribute?

Ah, this is for merging of _functions_ which is rejected when there's
a reference to variables which differ in this way.  Interesting that
we disregard those for merging of referrees but not when mergin the
decls themselves.  IMHO those should be equal, thus either call that
function from the two equals_wpa function or duplicate the bits we
have in the function case also to the variable case.

The comment above seems to be misleading here, at least for target attributes
such as this one.

Honza?

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, and no_icf is only handled for functions (and if allowed on VAR_DECL it's
not checked by ICF).

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[gjl at gcc dot gnu.org]

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

--- Comment #28 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> I wonder if it would be possible to set the appropriate address-space when
> parsing the "progmem" attribute in the target?

No, that's not possible. You cannot adjust all uses to also refer to the
different address-space.  And qualifiers and attributes behave quite
differently.

> For ICF (or more generally IPA) there's comp_type_attributes which
> we already check and which dispatches to target code.  We're also
> rejecting differing DECL_ATTRIBUTES:

This would make sense to also use for variables, or better still call a target
hook to reject specific combinations.  Attrs like "used", "unused" etc. should
still be ok, but the back-end knows best, IMO.

And different address-spaces might also work, e.g. when one decl is progmem
(AS0) and the other is __flash (AS1).  So the current fix misses some
opportunities (just to mention it, not that I think it would matter much).

> so I wonder what happens here?  Does AVR not actually add the progmem
> attribute?

It always adds the progmem attribute (but may bail out, e.g. when not "const").

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:eee13a3730bd1d7aa7b40687b1ee49c17d95159f

commit r14-6458-geee13a3730bd1d7aa7b40687b1ee49c17d95159f
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Dec 11 10:08:24 2023 +0100

    ipa/92606 - properly handle no_icf attribute for variables

    The following adds no_icf handling for variables where the attribute
    was rejected.  It also fixes the check for no_icf by checking both
    the source and the targets decl.

            PR ipa/92606
    gcc/c-family/
            * c-attribs.cc (handle_noicf_attribute): Also allow the
            attribute on global variables.

    gcc/
            * ipa-icf.cc (sem_item_optimizer::merge_classes): Check
            both source and alias for the no_icf attribute.
            * doc/extend.texi (no_icf): Document variable attribute.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
                 CC|                            |rguenth at gcc dot gnu.org
           Assignee|rguenth at gcc dot gnu.org         |unassigned at gcc dot gnu.org

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
So as a workaround it should be possible to attach no_icf to PROGMEM vars,
either in the Arduino.h header or during backend processing of the progmem
attribute.

This support could be backported if requested.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[hubicka at gcc dot gnu.org]

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

--- Comment #31 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
This is Maritn's code, but I agree that equals_wpa should reject pairs with
"dangerous" attributes on them (ideally we should hash them). 
I think we could add test for same attributes to equals_wpa and eventually
white list attributes we consider mergeable?
There are attributes that serves no meaning once we enter backend, so it may be
also good option to strip them, so they are not confusing passes like ICF.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #32 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Georg-Johann Lay <gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:08e752e72363ae7fd5a5fcb70913a0f7b240387b

commit r15-207-g08e752e72363ae7fd5a5fcb70913a0f7b240387b
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Fri May 3 18:47:50 2024 +0200

    AVR: ipa/92606 - Don't optimize PROGMEM data against non-PROGMEM.

    ipa/92606: Inter-procedural analysis optimizes data across
    address-spaces and PROGMEM.  As of v14, the PROGMEM part is
    still not fixed (and there is still no target hook as proposed
    in PR92932).  Just disable respective bogus optimization.

            PR ipa/92606
    gcc/
            * config/avr/avr.cc (avr_option_override): Set
            flag_ipa_icf_variables = 0.
    gcc/testsuite/
            * gcc.target/avr/torture/pr92606.c: New test.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #33 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
<gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:287293786d541217e7bf47cab6b8fb522ae9156a

commit r13-8699-g287293786d541217e7bf47cab6b8fb522ae9156a
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Fri May 3 18:47:50 2024 +0200

    AVR: ipa/92606 - Don't optimize PROGMEM data against non-PROGMEM.

    ipa/92606: Inter-procedural analysis optimizes data across
    address-spaces and PROGMEM.  As of v14, the PROGMEM part is
    still not fixed (and there is still no target hook as proposed
    in PR92932).  Just disable respective bogus optimization.

            PR ipa/92606
    gcc/
            * config/avr/avr.cc (avr_option_override): Set
            flag_ipa_icf_variables = 0.
    gcc/testsuite/
            * gcc.target/avr/torture/pr92606.c: New test.

    (cherry picked from commit 08e752e72363ae7fd5a5fcb70913a0f7b240387b)

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #34 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Georg-Johann Lay
<gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:c6141ad24f73cf1771e33c7d7edf1d80d8df70b8

commit r14-10175-gc6141ad24f73cf1771e33c7d7edf1d80d8df70b8
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Fri May 3 18:47:50 2024 +0200

    AVR: ipa/92606 - Don't optimize PROGMEM data against non-PROGMEM.

    ipa/92606: Inter-procedural analysis optimizes data across
    address-spaces and PROGMEM.  As of v14, the PROGMEM part is
    still not fixed (and there is still no target hook as proposed
    in PR92932).  Just disable respective bogus optimization.

            PR ipa/92606
    gcc/
            * config/avr/avr.cc (avr_option_override): Set
            flag_ipa_icf_variables = 0.
    gcc/testsuite/
            * gcc.target/avr/torture/pr92606.c: New test.

    (cherry picked from commit 08e752e72363ae7fd5a5fcb70913a0f7b240387b)

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[cvs-commit at gcc dot gnu.org]

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

--- Comment #35 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
<gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:231728b6dd7684e031f2a05e7e43bab54b7f2c5e

commit r12-10418-g231728b6dd7684e031f2a05e7e43bab54b7f2c5e
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Fri May 3 18:47:50 2024 +0200

    AVR: ipa/92606 - Don't optimize PROGMEM data against non-PROGMEM.

    ipa/92606: Inter-procedural analysis optimizes data across
    address-spaces and PROGMEM.  As of v14, the PROGMEM part is
    still not fixed (and there is still no target hook as proposed
    in PR92932).  Just disable respective bogus optimization.

            PR ipa/92606
    gcc/
            * config/avr/avr.cc (avr_option_override): Set
            flag_ipa_icf_variables = 0.
    gcc/testsuite/
            * gcc.target/avr/torture/pr92606.c: New test.

    (cherry picked from commit 08e752e72363ae7fd5a5fcb70913a0f7b240387b)

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

[gjl at gcc dot gnu.org]

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

--- Comment #36 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Installed a work-around for v14.2+, v13.3+ and v12.4+

The work-around can be reverted once a proper fix like PR92932 is available.

[Bug ipa/92606] [11 Regression][avr] invalid merge of symbols in progmem and data sections

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13 Regression][avr]  |[11 Regression][avr]
                   |invalid merge of symbols in |invalid merge of symbols in
                   |progmem and data sections   |progmem and data sections
           Priority|P2                          |P4

--- Comment #37 from Richard Biener <rguenth at gcc dot gnu.org> ---
Tracking AVR PROGMEM here, the referenced PR is about the general IPA issue.